The OpenGL renderer for Xj3D is designed to utilize a multiprocessor environment.
It borrows heavily from the SGI Performer design and utilitizes an APP, CULL, DRAW
threading split. The goal of this renderer is to provide Xj3D with a low level
rendering API that can be used to experiment with new features. In addition we
expect this API to eventually form the core of a multipipe version of Xj3D that can
be used in CAVE like systems.
The Application Stage
Xj3D is considered the application thread for this design. It maintains its own
VRML SG representation and handles all events and scripting API's. Whenever a
oglSG node needs updating it registers this with the SGManager. Later the SGManager
will call its UpdateListener and allow changes to the oglSG. The application is
responsible for double buffering its data to handle the delayed setting.
The Culling Stage
The culling stage is responsible for preparing an ordered list of nodes to
render for the drawing stage. These nodes will be updated from the change list,
view culled, and state sorted for effecient rendering.
This stage feeds its data to the Drawing stage via a shared que. As objects
are placed on this que they can be rendered. Early implementations will likely
update this que all at once, but its hoped that later optimizations can parsel
work out in a concurrent fashion.
The Drawing Stage
This stage setups the viewing matrices and executes the rendering method on the
nodes specified from the culling stage.
Conceptually the App, Cull and Draw stages can be running on three different
processors and possibily several pipes. The SGManager is responsible for
marshalling the processes. The frameFinished calls to SGManager will block
till the system is ready for further input.
The OpenGL renderer will make use of a thin scenegraph layer overtop openGL.
This layer will provide the ability to deviate from the structure imposed from
the VRML code. This allows optmizations like folding several transforms together
into one transform. Each VRML node will have a pointer to its oglSG reference.
The oglSG will maintain its tree using Weak References, so when all references
from the VRML SG are gone it will magically disappear from the oglSG.
The current implementation of oglSG is a small subset of the Java3D API. We
do not expect to copy the entire Java3D API so this implementation will
likely diverge over time. Ideally this SG will provide one-one mappings to VRML
The openGL renderer implementation includes a set of interesection utilities. These
utilities can be used for picking, selection, terrain following, and ray casting as
well as other tasks. Each node includes a type mask to enable intersection differences
between geometry classes. This enables terrain following applications to treat land
and water differently for some objects.