Scene Graph Components

Many different scene graphs have been developed down through the years, and their collective structures can vary quite a bit. However, there is a fair amount of common structures between them in general, and their basic structure can be distilled into a minimal set of unique classes that together make up the nebulous thing we call a scene graph and renderer.

The node types in a scene graph can be split into roughly two categories, Group nodes and Leaf nodes. Interior Group nodes structure the graph into logical groups and Leaf nodes carry the displayable geometry. The few classes that we created for our geometry hierarchy are a good place to start.

Group Nodes

As with our Group class, this is the core container class in the graph and contains a list of child nodes. They can be used for organizing the scene as well as a host of other operations. There can be many different derived types in any given scene graph API. For example:

  • Transform groups store the transformation for child nodes (same as the earlier TransformGroup).

  • Switch groups incorporate a mask or selection to hide or block traversals from particular child graphs. Switches can be used to dynamically change the look of a group of objects in a scene, switching between different sets. One example of this would be to switch from a regular-looking tank group to a damaged-looking tank group when a game tank is damaged. Additional variants of switches include the LOD group, where the group switches between child groups, based on distance to the camera, which changes the displayed geometry to a precreated lower-detail version. Sometimes this LOD action is handled through a behavior instead of an explicit graph-node type.

  • Shared groups are a way to reuse or instance part of a scene graph. This allows for more efficient memory use when creating a more complex scene with numerous objects. In practice, though, it is quite difficult to implement and use correctly, and the idea of instancing is implemented in lesser ways.

Leaf Nodes

Leaf nodes hang at the bottom of the graph and have no children, but they may have other node-specific data and come in many different types.

3D Objects are the most important leaf node type in a scene graph because they specify the geometry objects that are to be rendered. This is analogous to our earlier RenderShape but can also include things such as raster images. A common interface style has proven to be useful and is used with little variation by most current scene graphs. It is based on splitting the data into separate arrays and is close to the OpenGL VertexArray interface, the same as our VertexArraySet class.

Rendering States

Rendering states are parameters of the rendering pipeline that relate to the appearance of an object. These parameters include color, texturing, and materials state as well as others, such as lighting and fog.

Materials are used to define the surface properties of the geometry. The attributes of the materials are mostly direct mappings from the OpenGL material states, that is, emissive, ambient, diffuse, and specular color and shininess.

Render state maintenance and control is one of the areas of greatest variance across different scene graphs.

Bounding Volumes

All nodes in a scene graph have some common attributes, one of them being the bounding volumes. The bounding volume of a node is a simple volume, usually an axis-aligned box or a sphere, that encloses the contents of all the nodes below the current one in the hierarchy. It is used by the scene graph to check the node for visibility and possibly for lighting scope and collision detection. If the bounding volume of the node is outside the visible area, all other nodes below in the hierarchy are also outside of the visible area, thus halting any further processing by the renderer and preventing the objects from being wastefully passed on to OpenGL. For large scenes, this can have a significant impact on rendering speed. See the following Visibility Culling section for more information.

Multithreading

Multithreading is an aspect that is growing in importance, given the current trend in processor designs to support multithreaded applications in the processor core. A number of scene graphs provide simple multithreading support, which allows simultaneous reading or rendering of the scene graph. For many applications, this is fine, but for more demanding applications that use asynchronous simulation threads needing consistent data, strong threading support will need to be built into the scene graph. For games, however, most renderers treat the application update and rendering as a single thread system, even if the game is multithreaded.

The previous nodes define just about everything needed to render rich 3D scenes without actually referencing specific OpenGL functions. Only the lowest-level rendering process actually has OpenGL calls in it, thus successfully abstracting the graphics commands from the developer-level scene graph objects.



Practical Java Game Programming
Practical Java Game Programming (Charles River Media Game Development)
ISBN: 1584503262
EAN: 2147483647
Year: 2003
Pages: 171

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net