gnuDKit.info: RenderKit - questions

> 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.
>
>   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?

>   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)?

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?
>
>   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.
>
>   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.


--
Brent Gulanowski				[email protected]

http://inkubator.idevgames.com/
Working together to make great software.