hello, i'm using more and more framebuffer so i'm facing some limitation.
by exemple, i'd like to be able to change perspective and view point. This should not be to hard to add this fonctionality, and i'll give a try when i've got few time.
To be able to change lighting on different framebuffer would also be nice, but i don't think it would be easy.
But the biggest limitation i have is that it's only possible to to draw in a framebuffer with 1 gemhead. does anyone have an idea how to use multiples gemhead to draw in the same framebuffer? what change would it need in the gem sources?
thanks Cyrille
cyrille henry wrote:
hello, i'm using more and more framebuffer so i'm facing some limitation.
by exemple, i'd like to be able to change perspective and view point. This should not be to hard to add this fonctionality, and i'll give a try when i've got few time.
To be able to change lighting on different framebuffer would also be nice, but i don't think it would be easy.
But the biggest limitation i have is that it's only possible to to draw in a framebuffer with 1 gemhead. does anyone have an idea how to use multiples gemhead to draw in the same framebuffer? what change would it need in the gem sources?
my plan to allow multiple render trees is, to break the functionality of [gemhead] and [gemwin] into separate objects and to use send/receive for the communication.
see attached patch
fgmasdrt IOhannes
hello, thanks for the answer,
that would be great i think, but is this a plan or a work in progress?
is it part of the multiple windows branch that is in development since many years now?
Cyrille
IOhannes m zmoelnig a écrit :
cyrille henry wrote:
hello, i'm using more and more framebuffer so i'm facing some limitation.
by exemple, i'd like to be able to change perspective and view point. This should not be to hard to add this fonctionality, and i'll give a try when i've got few time.
To be able to change lighting on different framebuffer would also be nice, but i don't think it would be easy.
But the biggest limitation i have is that it's only possible to to draw in a framebuffer with 1 gemhead. does anyone have an idea how to use multiples gemhead to draw in the same framebuffer? what change would it need in the gem sources?
my plan to allow multiple render trees is, to break the functionality of [gemhead] and [gemwin] into separate objects and to use send/receive for the communication.
see attached patch
fgmasdrt IOhannes
cyrille henry wrote:
hello, thanks for the answer,
that would be great i think, but is this a plan or a work in progress?
well, the patch i sent should actually work (with a recent Gem that already has [gemreceive]), so it is already "work in progress".
the things that have to go away are: - the use of [gemhead] within [gemfbhead] ([gemhead] should be an abstraction with a [gemreceive] and some "gemreset" object(s)) - a [gemwin] abstraction should do the [send] and setup the viewpoint and the like (rather than code hidden within GemMan)
is it part of the multiple windows branch that is in development since many years now?
it is related to that. though the "is in development" hurts a bit :-)
fgnmasdr IOhannes
IOhannes m zmoelnig a écrit :
cyrille henry wrote:
hello, thanks for the answer,
that would be great i think, but is this a plan or a work in progress?
well, the patch i sent should actually work (with a recent Gem that already has [gemreceive]), so it is already "work in progress".
ok, cool. look like my 2 month old Gem was to old! i update / recompile and yes, this patch is working.
trying to understand the use of gemreceive, i realized that replacing it with a simple receive did work. look like gemreceive is a receive with priority, is it true?
This mean that even with older Gem version it is possible to render multiple gemhead in the same frambuffer using something similar to your example...
the things that have to go away are:
- the use of [gemhead] within [gemfbhead] ([gemhead] should be an abstraction with a [gemreceive] and some
"gemreset" object(s))
the gemreset objets does not exist yet (?). should/could it be made with GEMgl objects?
- a [gemwin] abstraction should do the [send] and setup the viewpoint
and the like (rather than code hidden within GemMan)
ok same question : should/could it be made with GEMgl objects?
is it part of the multiple windows branch that is in development since many years now?
it is related to that. though the "is in development" hurts a bit :-)
oups, sorry, did not wanted to hurt.
cyrille
fgnmasdr IOhannes
cyrille henry wrote:
IOhannes m zmoelnig a écrit :
cyrille henry wrote:
hello, thanks for the answer,
that would be great i think, but is this a plan or a work in progress?
well, the patch i sent should actually work (with a recent Gem that already has [gemreceive]), so it is already "work in progress".
ok, cool. look like my 2 month old Gem was to old! i update / recompile and yes, this patch is working.
trying to understand the use of gemreceive, i realized that replacing it with a simple receive did work. look like gemreceive is a receive with priority, is it true?
exactly. it really has nothing to do with Gem per se, but as it is not in Pd-vanilla and would be needed i added it.
This mean that even with older Gem version it is possible to render multiple gemhead in the same frambuffer using something similar to your example...
oh yes. it was just a matter of show off (and of course i didn't know whether you needed a certain render-order, which is impossible to do with pure [receive]s)
([gemhead] should be an abstraction with a [gemreceive] and some"gemreset" object(s))
the gemreset objets does not exist yet (?).
correct
should/could it be made with GEMgl objects?
part of it could be done with GEMgl; other parts will need access to the gem_list structure (and thus have to be done in C++)
- a [gemwin] abstraction should do the [send] and setup the viewpoint
and the like (rather than code hidden within GemMan)
ok
same question : should/could it be made with GEMgl objects?
yes, i think most of it can be done with GEMgl.
it is related to that. though the "is in development" hurts a bit :-)
oups, sorry, did not wanted to hurt.
well, it was just a reminder of something that should have been done for ages. sometimes it is good to be kicked (very lightly)
gfmasdr IOhannes
IOhannes m zmoelnig a écrit :
cyrille henry wrote:
IOhannes m zmoelnig a écrit :
cyrille henry wrote:
...
This mean that even with older Gem version it is possible to render multiple gemhead in the same frambuffer using something similar to your example...
oh yes. it was just a matter of show off (and of course i didn't know whether you needed a certain render-order, which is impossible to do with pure [receive]s)
it is possible using triggers and many send/receive. but it's lot's easier with gemreceive...
for the archive, here is a patch that work with older gem version.
cyrille
([gemhead] should be an abstraction with a [gemreceive] and some"gemreset" object(s))
the gemreset objets does not exist yet (?).
correct
should/could it be made with GEMgl objects?
part of it could be done with GEMgl; other parts will need access to the gem_list structure (and thus have to be done in C++)
- a [gemwin] abstraction should do the [send] and setup the
viewpoint and the like (rather than code hidden within GemMan)
ok
same question : should/could it be made with GEMgl objects?
yes, i think most of it can be done with GEMgl.
it is related to that. though the "is in development" hurts a bit :-)
oups, sorry, did not wanted to hurt.
well, it was just a reminder of something that should have been done for ages. sometimes it is good to be kicked (very lightly)
gfmasdr IOhannes
#N canvas 0 0 734 487 10; #X obj 128 88 gemwin; #X obj 318 82 gemhead; #X obj 318 62 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X obj 258 417 translateXYZ 1 0 0; #X obj 411 398 translateXYZ -1 0 0; #X obj 411 439 circle; #X obj 318 188 rotateXYZ; #X floatatom 398 190 5 0 0 0 - - -; #X floatatom 349 395 5 0 0 0 - - -; #X floatatom 497 378 5 0 0 0 - - -; #X obj 524 104 gemhead; #X obj 524 84 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X floatatom 589 145 5 0 0 0 - - -; #X obj 318 108 gemframebuffer; #X obj 258 438 triangle; #X obj 524 203 pix_texture; #X floatatom 458 149 5 0 0 0 - - -; #X obj 318 149 translateXYZ 0 0 -4; #X msg 128 61 create , 1; #X obj 411 419 color 1 0 0; #X obj 524 170 rotateXYZ; #X obj 524 225 square 3; #X obj 352 233 s gemfbhead_trigger1; #X obj 318 213 t b b; #X obj 260 331 r gemfbhead_trigger1; #X obj 256 385 gemhead; #X msg 192 354 0; #X obj 192 325 loadbang; #X obj 410 373 gemhead; #X obj 412 330 r gemfbhead_trigger2; #X obj 318 257 s gemfbhead_trigger2; #X connect 1 0 13 0; #X connect 2 0 1 0; #X connect 3 0 14 0; #X connect 4 0 19 0; #X connect 6 0 23 0; #X connect 7 0 6 2; #X connect 8 0 3 2; #X connect 9 0 4 2; #X connect 10 0 20 0; #X connect 11 0 10 0; #X connect 12 0 20 1; #X connect 13 0 17 0; #X connect 13 1 15 1; #X connect 15 0 21 0; #X connect 16 0 17 3; #X connect 17 0 6 0; #X connect 18 0 0 0; #X connect 19 0 5 0; #X connect 20 0 15 0; #X connect 23 0 30 0; #X connect 23 1 22 0; #X connect 24 0 25 0; #X connect 25 0 3 0; #X connect 26 0 25 0; #X connect 26 0 28 0; #X connect 27 0 26 0; #X connect 28 0 4 0; #X connect 29 0 28 0;
-
cyrille henry -
IOhannes m zmoelnig