[GEM-dev] framebuffer frustum

cyrille henry cyrille.henry at la-kitchen.fr
Sun Feb 15 16:48:47 CET 2009



Matthias Neuenhofer a écrit :
> absolutely clear
good.

> 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?

i don't really understand.
for now, the geometry shader is not implemented in Gem.
but that would be really interesting to have.
maybe we should put a feature request on sourceforge.

anyway, you can use vertex shader to modulate lines.
look at the examples...

Cyrille

> 
> 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;
> 
> 





More information about the GEM-dev mailing list