Re: [GEM-dev] framebuffer frustum - GEM-dev

15 Feb 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@iem.at
http://lists.puredata.info/listinfo/gem-dev

GEM-dev mailing list
GEM-dev@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;