Roman Haefeli wrote: > 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). >
Thanks. That's what I suspected. Thanks for substantiating. > >> 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] > | > My error. I had thought that you meant that the signals from [gemhead 99] would *take the place of snap*. Your solution solves *half* the problem -- the movie now has the correct number of frames, but they're all identical to the first frame. However ---> > > (actually i am not sure anymore about the order: whether 'snap' or the > gemlist message should be received first) > [t b a] turns out to be the one that works. Possibly that makes consistent sense? You'd want the gemlist to be "available" (whatever that means in this context -- the buffer?) first, before sending the message to snap it, right? I dunno. But it works! > >> 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. > Again, thanks for confirming my suspicion. > >> 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. > Thanks for the info. I guess a certain abstract data is still flowing (the "data" being "do this calculation") but I appreciate the help on understanding the time structure of the process. > (@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] Thanks. That answers a question I hadn't yet submitted to the ng. I *could* ask for more details -- like how to give the multiple instances different characteristics, how to create a random (or at least not hardwired) number of instances, etc. But that would be a brand new thread, and I'll experiment with it first before asking for help. > > i hope that sheds some light on your questions. > Absolutely! Thanks Roman, Chris, and Marius, for the help! And it's still in time to make my DVD and send it in by the deadline tonight! -- Dudley _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
