On Fri, 2008-02-29 at 12:30 -0800, Dudley Brooks wrote:
chris clepper wrote:
[gemhead 99] | | [pix_snap]
Of course! Ingenious!
However ... I tried it, and, even though the frame count output of pix_record churned out frame numbers, the resulting file was only one frame long and that frame only showed one of the geos. I even made the priorities of the various geos' gemheads explicitly lower and it still didn't work.
I can't figure out why that particular geo registered -- none of the geo's were connected to pix_snap. That's the intention, right?
actually they don't need to be connected. you can have all the geo stuff attached to a different [gemhead]. important is only the order of execution. first all geos need to be rendered and _after_ that you make a snapshot of the current buffer. that is why chris clepper is suggesting to use a [gemhead 99] (the higher the number, the later the according [gemhead] is drawing).
I also tried connecting several of the geos to pix_snap and the results were still the same: the movie had only one frame,
you have to send a 'snap' message to [pix_snap] for each frame you want to capture. usually this is done with something like:
[gemhead 99] | [t a b] | / | [snap( |/ [pix_snap] |
(actually i am not sure anymore about the order: whether 'snap' or the gemlist message should be received first)
which contained only one geo -- even when that particular geo was the only one which was *not* connected to pix_snap. So the connections were irrelevant.
exactly, they _are_ irrelevant. geos are drawn to the framebuffer and [pix_snap] captures a snapshot of the buffer, which means there is no connection needed.
I assume it has something to do with rendering/buffering, but I don't know enough about those.
i hope it rather helps than it confuses, but for me it was important to understand, that Gem doesn't really reflect the dataflow paradigm: unlike in pd's audio connection, not the data itself is 'flowing' through the connections. rather Gem's object classes are used to compose instructions for the graphic card. those instructions are passed through all objects (actually only a pointer is passed around) and then the instructions are sent to card, where all the geos, textures and stuff are drawn into the buffer. when all the calculations are finished, the content of the buffer is displayed in the gemwin. (@devs: please correct me, if i am saying bullshit...) yo...having said, it might be easy now to understand a few cool tricks in Gem. for example, you don't necessarily need several geo objects (e.g. [cube]) in order to draw several of them. you could draw as many cubes with only one [cube] by passing more than one gemlist message per tick to it (a.k.a multiplying the number of instructions):
[gemhead] | [t a a a a] | / / / [rotateXYZ 2 4 6] | [translateXYZ 0.2 0.1 0.3] | [cube]
i hope that sheds some light on your questions.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de