Re: [Gnu3dkit-discuss] gnuDKit.info: RenderKit - questions

[Philippe C . D . Robert]

On Wednesday, October 30, 2002, at 10:07  Uhr, Brent Gulanowski wrote:
> > The RenderKit defines an abstract, object-oriented rendering system. 
> > It
> >   implements and provides the following key components:
> >
> >   o A generic scene database, including reader and writer classes
> >   o A generic scene graph data structure used to render a scene
>
> So, RenderKit's main purpose is now to provide data management for the 
> externalized renderer. It moves scene data to/from disk, retains it in 
> memory, and provides an interface to manipulate the data. All the 
> rendering intelligence is being moved into a "head" which gets dropped 
> on the body at application launch.

No, but the RenderKit's scene graph part will become a pure scene graph 
data structure providing thread safe data structure handling 
functionality. It won't contain any rendering stuff anymore. This will 
ensure a cleaner design.

> >   o A camera controller
>
> Is the camera controller different than a camera, or are they in fact 
> the same thing? Is a camera analogous to a scene element, or is 
> distinct? Anthropomorphically, I think of a camera as an attribute on 
> a scene element. Is this a useful concept? Or is the camera 
> conceptually outside of the scene, with its lens poked in at some 
> point?

A camera often contains/is a view as well (see ie. N3DCamera which is a 
NSView), whereas I want the camera to use a view not to be one.

> >   o A semi abstract rendering API which implements an object oriented 
> > state
> >     machine. Concrete implementations are provided by separate 
> > bundles.
>
> >   o Actions to be performed by the rendering system on a scene, ie
> >
> >     - DRAW action
> >     - CULL action
> >     - Update action
> >     - Isect action
>
> How will these actions work? Will RK provide a mechanism to walk the 
> tree, returning objects which the renderer can then inspect, 
> manipulate, and whose attributes and geometry it can retrieve? Will 
> there be one standard -getChildren: method used by the renderer for 
> all four actions (after which it would request attributes, then 
> geometry and/or more child nodes)?

Depending on the action the render engine will be triggered by the 
traversal code to perform specific tasks. This guarantees that only the 
render engine interfaces with a concrete, lowlevel graphics API.

> Update: is this really done by the renderer? For each dynamic 3d 
> object, an application has to tie it to some application object which 
> gives it behaviour (physics and/or A.I). Should the application manage 
> that all by itself, or should a 3d object know which application 
> object or objects manage it?

The 3DKit performs internal graph updates upon this action, ie. 
bounding volume transformations, transformation matrix computations and 
so on. Application specific updates can be done using special purpose 
delegates.

> >   o Classes which provide the interface for concrete renderers, 
> > required to
> >     visualise data from a scene database:
> >
> >     - state/attribute
> >     - appereance/shader/texture
> >     - geometry
> >     - ...
>
> This means that the renderer decides if it wants to re-sort the tree 
> for optimizations particular to itself, right? And these visual data 
> classes must maintain renderer-agnostic descriptions of these data.

More or less, yes.

> >   o Protocols which provide the interface for concrete renderers, 
> > required
> >     to visualise data from a scene database:
> >
> >     - RenderTechnique ( GL cartoon rendering, GL realistic rendering, 
> > ... )
> >     - ...
>
> This suggests that my guess above (about how actions work) is wrong, 
> and that RK pulls the strings on the renderer using the Protocol 
> methods. That would require controller objects for nodes, attributes 
> and geometry, as well as the camera. E.g., for drawing, a DRAW 
> mechanism walks the tree, optionally submitting a bounding volume (if 
> the renderer responds to some initial query: "-usesBoundingVolumes" 
> with "YES"), submitting attributes and geometry, whereon renderer 
> replies with whether or not to continue to the current node's 
> children. RK can still do attribute/state optimizations using its 
> internal formats.

Again, this is somewhat what I have in mind. This ensures proper 
decoupling of graph management, rendering code and concrete rendering 
techniques.

The only big showstopper for this approach I can see right now is that 
it will be too slow because of too much OO overhead.

-Phil
--
Philippe C.D. Robert
http://www.nice.ch/~phip