Based on the presentation, here are some wordshreds, just to confirm the mystery...(or what all this stuff sounds like to an absolute beginner in any technics)

Beginning with a short and fast review on the pasttimes, with the graphis environment of max, the projection showed something which has one body, 2 arms, 2 hands and (I guess) ten fingers...Changes have been in 1997. gemMan (as manager) triggers gemhead-objects, which are derived from gemobjects.

in answering the question, what´s going on a gemrendering engine, 6 files are important (base, gemMan...) the core is gemMan: it has a static place in memory, provides interface to the window manager and is the execution of render-chains.

gemWin controlls gemMan, whereby gemWin cannot do anything on its own, it comes into action, just when it gets an input.gehHead render chain, a collection of objects,gemBase is a virtual class, which provides several methodes: start rendering (video), stop rendering (zero), render-function: the code is executed, now you can do whatever you like; and postrender (i.e. afterwards)

*Passing data between objects: some gem-objets need no data at all (here only the open GL-state is modified) -other gem-objects need complex data (images = pixel data + texture information)

• gemstate: structure contains data :framerate, lighting model

  *What´s really going on ?* GemMan: render 1) reset the open GL state: reset values 2) initialize the Gemstate (general values) 3) render all positive gemheads 4) reset the viewpoint 5) render all negative gemheads 6) swapp buffers 7) schedule the next call of render

• gemcache: memory shared between all objects of a render chain, "talk"back: gemBase --> gemhead, e.g. reseng images; -single images (no video streams)

calling the render-chains: each gemhead register itself with GemMan: add objects, 2 ordered lists * gemhead: render GL-function: 1) current open GL-state is pushed to stack 2) the GemState is "localized" (dirty-flag image data is set to zero) 3) a pd-message is emitted 4)the open GL-stae is popped off the stack

• 1) the gemState message is received 2) save gem-cache 3) the render (gemstate) function is called 4) call the continue Render (gemstate) function 5) call the postrender (gemstate) function windowhandling: -windowmanagement is done by gemMan, -only one window, -only one output-device, -seperate rendering passers into buffers hardly possible (e.g. selection buffer)

IMPORTANT: 1 object! = 1 context

Following now proposals, i.e. multiple windows (remove all windowhandling code from gemMan, gemMan should handle render chains, scheduler could stay within gemMan, stay compatible with older version of GEm) gemcontrol: new object for controlling the gemMan, controlling the scheduler, turn rendering on/off, change framerate, ... creating new class for Gem output, camera, background....settings -virtual methods*: make open GL-the current one; -do Render () call GEmMan :render, -PostRender :swap buffers

-gemOutput, Implements for gemOutputs, Compatibility