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