Matthias Neuenhofer a écrit :
Am 13.02.2009 um 00:40 schrieb cyrille henry:
Matthias Neuenhofer a écrit :
super i compiled on Mac Osx 10.5.6. there was no OS specific part in, should also work on Microsoft. but shouldnŽt the default texture out to rectangle?
why? anyway, changing default could break old patch, so it's usually bad.
ok leave it, gemframebuffer needs initial values anyway like size .... even pix_texture use rectangle from default
my attention to the framebuffer was a side effect looking for a way to sort the render order for proper keying and discovered [gemreceive] - thanx IOhannes - which support the [set $1( to sort the chain with z values via [gemlist_info] itŽs not perfect - always 1 frame to late - looks ok.
gemhead does also accept ordering. (via set message)
yop but i like to go with a feedback via pix_snap in background and this snaps only which belongs to the headtree - i know snap2tex is faster but i couldnŽt get it in to pix_record so in this set the gemreceive was perfect
pix_record record a texture that is in main memory, so you can't make it work with pix_snap2tex. but, i can't see why using the set message to the gemhead is not what you need.
but - is a gemhead which sort all clients by himself thinkable?
i can't imagine a generic solution
maybe later
a mapping from the z position multiplied with 1000 to the priority before itŽs drawn in the framebuffer.
you can do this by hand, in a 2 pass rendering : render a 1st time only to know the Z, then use it to change priority of the gemhead for the final rendering.
and the performance will stay acceptable ?
you don't really have to draw your primitive, just to compute there position. so performance should not be to bad... you'll have to try :-)
cyrille
Matthias Am 12.02.2009 um 14:14 schrieb cyrille henry:
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev