here's something a bit different from what we've been talking about:
I'm trying to create a patch that would show some typical uses of the OpenGL wrapper objects, but I'm stuck on creating the looping mechanism: basically, I'd like to draw one object many times in different translations (imagine a cube made of sub-triangles where the row size of sub-triangles can be changed)...so I'm trying to do 3 nested for loops to produce xyz coordinates, and then send them to a GEMglTranslatef within a routine for drawing a triangle...
...the accompanying patch uses 3 [until]'s, but doesn't produce the desired result; has anyone figured out a way to do this? I figure that this would be a first step toward better documentation, and would like to also do it for things such as the newWave, ripple, etc geos, so that we don't get object bloat ;-)
thanx, jamie
Hi Jamie,
I think I understand what you are trying to do, but I fear that this is not possible yet (I may be wrong, I actually never looked to closely at the new implementation.)
If I understand correctly it should not be too hard to implement this "looping" feature based on the new gem scheduler.
Currently a gemlist gets only drawn once. It is possible to write a simple object ("gemloop" or the like) that triggers "n" of these redraws (just like the part_render does) and at the same time has a second outlet that tells you the number of the redraw. This way you could built more complex geos with just one gemlist ..
Guenter
On Thu, 24 Jul 2003, tigital wrote:
here's something a bit different from what we've been talking about:
I'm trying to create a patch that would show some typical uses of the OpenGL wrapper objects, but I'm stuck on creating the looping mechanism: basically, I'd like to draw one object many times in different translations (imagine a cube made of sub-triangles where the row size of sub-triangles can be changed)...so I'm trying to do 3 nested for loops to produce xyz coordinates, and then send them to a GEMglTranslatef within a routine for drawing a triangle...
...the accompanying patch uses 3 [until]'s, but doesn't produce the desired result; has anyone figured out a way to do this? I figure that this would be a first step toward better documentation, and would like to also do it for things such as the newWave, ripple, etc geos, so that we don't get object bloat ;-)
thanx, jamie
On Saturday, July 26, 2003, at 04:50 PM, guenter geiger wrote:
I think I understand what you are trying to do, but I fear that this
is not possible yet (I may be wrong, I actually never looked to closely at the new implementation.)
I don't know if you have access to a mac with pd on it, but I put up a binary of the latest GEM cvs for OSX (mainly to test the FTGL stuff), and it has some "hidden" objects/geos like [cubeArray], [kasser], and [tunnel], which I pulled out of some demo examples...I haven't committed them to cvs because I feel they would be better as "abstractions"...
If I understand correctly it should not be too hard to implement this "looping" feature based on the new gem scheduler.
Currently a gemlist gets only drawn once. It is possible to write a simple object ("gemloop" or the like) that triggers "n" of these redraws (just like the part_render does) and at the same time has a second outlet that tells you the number of the redraw. This way you could built more complex geos with just one gemlist ..
...pardon me if I missed it before, but where should I look to figure out the gem scheduler stuff? I also wonder if this would allow for processing of still images? I'll definitely take a look at part_render...
thanx, jamie
On Saturday, July 26, 2003, at 04:50 PM, guenter geiger wrote:
If I understand correctly it should not be too hard to implement this "looping" feature based on the new gem scheduler.
Currently a gemlist gets only drawn once. It is possible to write a simple object ("gemloop" or the like) that triggers "n" of these redraws (just like the part_render does) and at the same time has a second outlet that tells you the number of the redraw. This way you could built more complex geos with just one gemlist ..
...excellent suggestion: with chris egg-ing me on, I found that we can put a "for loop" between the glPushMatrix and glPopMatrix in gemhead::renderGL(), and that this will make several loops of the object (if you try rotateXYZ or translateXYZ quick enough)...now the question would be how to control this correctly?
...Obviously it should have accept a message for the length of the loop, but there seems to be a need to output when the loop is done: Should it have a bang out on every loop iteration? Or would it be bet�a!Zwith a counter-type output?
Any thoughts appreciated!
jamie
Hey jamie et all,
I'm not at a machine with GEM installed at the moment so I haven't checked the patch you sent... but I think I understand what you're trying to do.
I've done similar things by using [counter] and the bang to trigger mode of [gemhead]. It's a bit ugly, but things look like this:
[gemhead] | [render_trigger] | [counter 1 30] | [t b f] | | | +------+ | | [gemhead] | | | | | [translateXYZ] | [rectangle]
This ensures that the render chain is triggered at the appropriate time (during the GEM render cycle) and does the necessary looping. I've left out the 0 and 1 to enable and disable the lower gemhead from triggering at its normal time in the render order.
This would be nice if wrapped up in a [gemloop] object as you've been discussing. I think that a counter style outlet is probably more useful.
I've also been wondering if it would be good to have another gemhead which takes in a list of values of length n. It would then render n times, passing out a value each time before it triggers the render. Actually, you'd probably do it so that you could send sublists of length greater than one out at a time... and allow the possibility of using a table/array as the list source. This would allow nice "asynchronous" multiple iteration rendering in GEM...
Daniel
On 28/7/03 3:53 PM, "tigital" tigital@mac.com wrote:
On Saturday, July 26, 2003, at 04:50 PM, guenter geiger wrote:
If I understand correctly it should not be too hard to implement this "looping" feature based on the new gem scheduler.
Currently a gemlist gets only drawn once. It is possible to write a simple object ("gemloop" or the like) that triggers "n" of these redraws (just like the part_render does) and at the same time has a second outlet that tells you the number of the redraw. This way you could built more complex geos with just one gemlist ..
...excellent suggestion: with chris egg-ing me on, I found that we can put a "for loop" between the glPushMatrix and glPopMatrix in gemhead::renderGL(), and that this will make several loops of the object (if you try rotateXYZ or translateXYZ quick enough)...now the question would be how to control this correctly?
...Obviously it should have accept a message for the length of the loop, but there seems to be a need to output when the loop is done: Should it have a bang out on every loop iteration? Or would it be bet?a!Zwith a counter-type output?
Any thoughts appreciated!
jamie
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
On Monday, July 28, 2003, at 02:16 AM, Daniel Heckenberg wrote:
I'm not at a machine with GEM installed at the moment so I haven't checked the patch you sent... but I think I understand what you're trying to do.
I've done similar things by using [counter] and the bang to trigger mode of [gemhead]. It's a bit ugly, but things look like this:
[gemhead] | [render_trigger] | [counter 1 30] | [t b f] | | | +------+ | | [gemhead] | | | | | [translateXYZ] | [rectangle]
This ensures that the render chain is triggered at the appropriate time (during the GEM render cycle) and does the necessary looping. I've left out the 0 and 1 to enable and disable the lower gemhead from triggering at its normal time in the render order.
...hmmm, I don't think I'm getting this hooked up correctly: at best, I simply get a kind of animation of a rectangle moving in the x direction...do you think you could send a patch? Here's a simplistic sketch of what I'm trying to do:
cube cube cube cube cube cube cube cube cube
...so we basically have a "rectangle" made out of "cubes", and have the ability to change the properties of individual cubes, at least through some kind of general function (say, apply a sin() to the size of the cubes)...
This would be nice if wrapped up in a [gemloop] object as you've been discussing. I think that a counter style outlet is probably more useful.
I've also been wondering if it would be good to have another gemhead which takes in a list of values of length n. It would then render n times, passing out a value each time before it triggers the render. Actually, you'd probably do it so that you could send sublists of length greater than one out at a time... and allow the possibility of using a table/array as the list source. This would allow nice "asynchronous" multiple iteration rendering in GEM...
...this sounds good too: time to hit the debugger ;-)
jamie
Quoting tigital tigital@mac.com:
...hmmm, I don't think I'm getting this hooked up correctly: at best,
I simply get a kind of animation of a rectangle moving in the x direction...do you think you could send a patch? Here's a simplistic sketch of what I'm trying to do:
cube cube cube cube cube cube cube cube cube
...so we basically have a "rectangle" made out of "cubes", and have the
ability to change the properties of individual cubes, at least through
some kind of general function (say, apply a sin() to the size of the cubes)...
Ben Bogart is someone to talk to about this. He's done similar patches using quads and spheres to make grids etc. He might even be on this list. I think he's reachable at bbogart@ryerson.edu still.
Quoting tigital tigital@mac.com:
...hmmm, I don't think I'm getting this hooked up correctly: at best,
I simply get a kind of animation of a rectangle moving in the x direction...do you think you could send a patch? Here's a simplistic sketch of what I'm trying to do:
cube cube cube cube cube cube cube cube cube
...so we basically have a "rectangle" made out of
"cubes", and have the
ability to change the properties of individual cubes, at least through
some kind of general function (say, apply a sin() to the size of the cubes)...
Ben Bogart is someone to talk to about this. He's done similar patches using quads and spheres to make grids etc. He might even be on this list. I think he's reachable at bbogart@ryerson.edu still.
On Mon, 28 Jul 2003, tigital wrote:
On Monday, July 28, 2003, at 02:16 AM, Daniel Heckenberg wrote:
I'm not at a machine with GEM installed at the moment so I haven't checked the patch you sent... but I think I understand what you're trying to do.
I've done similar things by using [counter] and the bang to trigger mode of [gemhead]. It's a bit ugly, but things look like this:
[gemhead] | [render_trigger] | [counter 1 30] | [t b f] | | | +------+ | | [gemhead] | | | | | [translateXYZ] | [rectangle]
This ensures that the render chain is triggered at the appropriate time (during the GEM render cycle) and does the necessary looping. I've left out the 0 and 1 to enable and disable the lower gemhead from triggering at its normal time in the render order.
You have to use "until", the counter will only trigger once each cycle (I have attached an example). But a cool idea ... actually I doubt we need something additional. The only "drawback" is that the first object will be rendered twice, because if you turn off the gemhead it won't render anything, not even with a bang. But this could be easily fixed.
Guenter
...hmmm, I don't think I'm getting this hooked up correctly: at best, I simply get a kind of animation of a rectangle moving in the x direction...do you think you could send a patch? Here's a simplistic sketch of what I'm trying to do:
cube cube cube cube cube cube cube cube cube
...so we basically have a "rectangle" made out of "cubes", and have the ability to change the properties of individual cubes, at least through some kind of general function (say, apply a sin() to the size of the cubes)...
This would be nice if wrapped up in a [gemloop] object as you've been discussing. I think that a counter style outlet is probably more useful.
I've also been wondering if it would be good to have another gemhead which takes in a list of values of length n. It would then render n times, passing out a value each time before it triggers the render. Actually, you'd probably do it so that you could send sublists of length greater than one out at a time... and allow the possibility of using a table/array as the list source. This would allow nice "asynchronous" multiple iteration rendering in GEM...
...this sounds good too: time to hit the debugger ;-)
jamie
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
-
cgc＠humboldtblvd.com -
Daniel Heckenberg -
guenter geiger -
tigital