chris clepper wrote:
the idea is, to use pd's messaging system for controlling. imagine a patch with 3 [gemwindow] objects, 2 of which are connected to the sole [gemcontrol]. you create 3 windows by sending a "create"-message to the [gemwindow]s and turn rendering on by sending "1" to [gemcontrol]. 2 of the windows will render the scene, the 3rd (which is not connected) will stay blank.
This explanation makes more sense to me. I haven't gotten the code yet, but the idea of having render targets independent of individual windows is great.
actually it doesn't work this way yet: you cannot tell one gemhead to render to window-1 and the other to window-2 and yet another to all windows.
What about having render targets that are not displayed directly to a window like a render to texture or pbuffer? Those possibilities should be included with the reworking of the window and control elements. Does [gemrender] make sense as a way to render to a non-window target?
right, that was part of the idea. to have render-targets (aka "Output"s) that could be anything, on-screen (normal windows, embedded windows) and off-screen (pbuffers: output to movies, video-out, firewire,...)
my first thought was, to have integrated output-modules (this is: one object that renders to AVI, another object that renders to 1394); i am now thinking that it might be better to have one pbuffer-output-object that passes the data to the actual encoders,...
but i am not sure at all; (class inheritance is really a cool think for not doubling code)
i was thinking to put these output-modules into src/Output and build them as _externals_ to Gem, as they are likely to be highly platform and hardware specific.
Also, are their any opportunities to take display lists further? Like build a chain that is a display list and then calling the list in another chain?
you can already do this. (ok, it is a but tricky and the problem is that you cannot build the display-lists outside the rendering-chain (to ensure to have an openGL-context)
apropos openGL-context: i guess we will have to think about getting a generic way to solve the "haveValidContext"-problem. right now, win/lin do not care at all, and osx get's the information from GemMan (which will not be possible with multiple-contexts any more)
Finally, the render control could use some work. We should probably take a look at where time is being spent managing the chains and if timing could have a finer resolution and more stable frequency. Oh and if we could work out some sort of thread and priority solution to keep the damn GUI from stopping rendering then that would be top.
ah. finally make gem threaded! this will be huge work! (especially since we use pd's messaging system so much now) but it might be worth the hazzle
mfg.a.sdr IOhannes