[GEM-dev] framebuffer frustum

[cyrille henry]

hello,

here is a patch that should explain what i thing regarding your 2 comments.

hope you'll understand what i try to say

Cyrille


Matthias Neuenhofer a écrit :
> 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
> 
> 
> _______________________________________________
> GEM-dev mailing list
> GEM-dev at iem.at
> http://lists.puredata.info/listinfo/gem-dev
> 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: test_render.pd
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20090214/de9c1b54/attachment.asc>