[GEM-dev] CVS: checkins and notifications

IOhannes m zmoelnig zmoelnig at iem.at
Tue Aug 24 11:00:50 CEST 2004


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




More information about the GEM-dev mailing list