[GEM-dev] framebuffer frustum

Sun Feb 15 15:39:46 CET 2009

absolutely clear
that´s perfect - i was always fixed on the master head
which controls the whole setup and split in to cluster axis
which ends on the primitives…

i will proof the 2 pass rendering in a big set

another theme - geometry shader

i use also gps data and think if it could help draw modulations
from line to planes with the geometry shader.

did anybody try this with gem?

Matthias

Am 14.02.2009 um 18:44 schrieb 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
> #N canvas 178 30 922 708 10;
> #X text 120 44 1st gemhead to be rendered : render the feedback buffer
> ;
> #X obj 40 96 gemhead -1;
> #X text 125 95 last gemhead to be rendered : snap the buffer for  
> rendering
> in the next image. (btw \, This is usless if the rendernig is made
> in a framebuffer);
> #X obj 41 222 gemhead 1;
> #X obj 39 42 gemhead 2;
> #X text 40 152 every gemhead from 3 to inf should be rendered between
> rendering the feedback buffer and snap this buffer. so we can use Z
> of each primitive to set gemhead priority;
> #X text 122 222 dummy gemhead \, to know the position of the primitive
> ;
> #X obj 143 267 gemhead;
> #X obj 42 366 translateXYZ;
> #X obj 42 450 translateXYZ;
> #X obj 42 472 alpha;
> #X obj 42 494 color 1 0 0 0.5;
> #X obj 42 586 spigot 0;
> #X obj 42 411 rotateXYZ;
> #X obj 41 245 t a b;
> #X msg 73 267 0;
> #X obj 92 520 f;
> #X obj 143 585 spigot 0;
> #X obj 196 563 == 0;
> #X obj 92 561 == 1;
> #X obj 143 289 t a b;
> #X msg 175 311 1;
> #X text 219 268 real gemhead to draw the primitive;
> #X text 229 292 order depend on Z position;
> #X obj 143 608 gemlist_info;
> #X obj 224 632 unpack f f f;
> #X msg 305 701 set \$1;
> #X floatatom 132 338 5 0 0 0 - - -;
> #X floatatom 181 340 5 0 0 0 - - -;
> #X floatatom 230 343 5 0 0 0 - - -;
> #X floatatom 132 387 5 0 0 0 - - -;
> #X floatatom 181 389 5 0 0 0 - - -;
> #X floatatom 235 391 5 0 0 0 - - -;
> #X floatatom 136 416 5 0 0 0 - - -;
> #X floatatom 185 418 5 0 0 0 - - -;
> #X floatatom 239 420 5 0 0 0 - - -;
> #X obj 539 227 gemhead 1;
> #X obj 641 272 gemhead;
> #X obj 540 371 translateXYZ;
> #X obj 540 455 translateXYZ;
> #X obj 540 477 alpha;
> #X obj 540 591 spigot 0;
> #X obj 540 416 rotateXYZ;
> #X obj 539 250 t a b;
> #X msg 571 272 0;
> #X obj 590 525 f;
> #X obj 641 590 spigot 0;
> #X obj 694 568 == 0;
> #X obj 590 566 == 1;
> #X obj 641 294 t a b;
> #X msg 673 316 1;
> #X obj 641 613 gemlist_info;
> #X obj 722 637 unpack f f f;
> #X msg 803 711 set \$1;
> #X floatatom 630 343 5 0 0 0 - - -;
> #X floatatom 679 345 5 0 0 0 - - -;
> #X floatatom 728 348 5 0 0 0 - - -;
> #X floatatom 630 392 5 0 0 0 - - -;
> #X floatatom 679 394 5 0 0 0 - - -;
> #X floatatom 733 396 5 0 0 0 - - -;
> #X floatatom 634 421 5 0 0 0 - - -;
> #X floatatom 683 423 5 0 0 0 - - -;
> #X floatatom 737 425 5 0 0 0 - - -;
> #X obj 540 499 color 0 1 0 0.5;
> #X obj 42 608 circle 1;
> #X floatatom 373 709 5 0 0 0 - - -;
> #X floatatom 865 710 5 0 0 0 - - -;
> #X obj 540 613 circle 1;
> #X obj 305 678 * 1000;
> #X obj 305 655 + 50;
> #X obj 803 660 + 50;
> #X obj 803 685 * 1000;
> #X obj 620 121 gemwin 5;
> #X msg 620 68 create \, 1;
> #X msg 627 95 destroy;
> #X connect 3 0 14 0;
> #X connect 7 0 20 0;
> #X connect 8 0 13 0;
> #X connect 9 0 10 0;
> #X connect 10 0 11 0;
> #X connect 11 0 12 0;
> #X connect 11 0 17 0;
> #X connect 12 0 64 0;
> #X connect 13 0 9 0;
> #X connect 14 0 8 0;
> #X connect 14 1 15 0;
> #X connect 15 0 16 0;
> #X connect 16 0 19 0;
> #X connect 16 0 18 0;
> #X connect 17 0 24 0;
> #X connect 18 0 17 1;
> #X connect 19 0 12 1;
> #X connect 20 0 8 0;
> #X connect 20 1 21 0;
> #X connect 21 0 16 0;
> #X connect 24 4 25 0;
> #X connect 25 2 69 0;
> #X connect 26 0 7 0;
> #X connect 27 0 8 1;
> #X connect 28 0 8 2;
> #X connect 29 0 8 3;
> #X connect 30 0 13 1;
> #X connect 31 0 13 2;
> #X connect 32 0 13 3;
> #X connect 33 0 9 1;
> #X connect 34 0 9 2;
> #X connect 35 0 9 3;
> #X connect 36 0 43 0;
> #X connect 37 0 49 0;
> #X connect 38 0 42 0;
> #X connect 39 0 40 0;
> #X connect 40 0 63 0;
> #X connect 41 0 67 0;
> #X connect 42 0 39 0;
> #X connect 43 0 38 0;
> #X connect 43 1 44 0;
> #X connect 44 0 45 0;
> #X connect 45 0 48 0;
> #X connect 45 0 47 0;
> #X connect 46 0 51 0;
> #X connect 47 0 46 1;
> #X connect 48 0 41 1;
> #X connect 49 0 38 0;
> #X connect 49 1 50 0;
> #X connect 50 0 45 0;
> #X connect 51 4 52 0;
> #X connect 52 2 70 0;
> #X connect 53 0 37 0;
> #X connect 54 0 38 1;
> #X connect 55 0 38 2;
> #X connect 56 0 38 3;
> #X connect 57 0 42 1;
> #X connect 58 0 42 2;
> #X connect 59 0 42 3;
> #X connect 60 0 39 1;
> #X connect 61 0 39 2;
> #X connect 62 0 39 3;
> #X connect 63 0 41 0;
> #X connect 63 0 46 0;
> #X connect 68 0 26 0;
> #X connect 69 0 68 0;
> #X connect 69 0 65 0;
> #X connect 70 0 66 0;
> #X connect 70 0 71 0;
> #X connect 71 0 53 0;
> #X connect 73 0 72 0;
> #X connect 74 0 72 0;