[GEM-dev] framebuffer frustum

[Matthias Neuenhofer]

Am 14.02.2009 um 01:21 schrieb cyrille henry:

>
>
> 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.
for the feedback with pix_snap the texture must be drawn first behind  
all other so i use a master
head

[gemhead]
|
[t b a a]
right outlet to pix_snap
middle outlet to all other
left bang to snap message for pix_snap

now i need gemreceive to sort all the other clients

with set message to gemhead, the pix_snap head has to rendered last  
otherwise is nothing to grab and
laying on top off all other when you feed it back.
just for recording without feedback it doesn´t matter

>
>
>
>>>
>>>> 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 :-)
any suggestion?
how can i compute the the planes without drawing?
>
> cyrille
>
>>>> Matthias
>>>> Am 12.02.2009 um 14:14 schrieb cyrille henry:
>> _______________________________________________
>> GEM-dev mailing list
>> GEM-dev at iem.at
>> http://lists.puredata.info/listinfo/gem-dev