8.5. Scene Graphs

by Mike Weiblen

A SCENE GRAPH is a hierarchical data structure containing a description of a scene to be rendered. Rather than explicitly coding a scene to be rendered as OpenGL API calls, an application builds a scene graph, then calls the scene graph rendering engine to do the actual rendering by traversing the data structure. In this way, a scene graph allows a developer to focus on what to draw, rather than on the details of how to draw. In typical terminology, the term scene graph is often used to describe the toolkit for both the data structure itself and the rendering engine that traverses the data structure to render the scene.

Scene graphs make it possible for a developer of visualization applications to leverage the performance of OpenGL without necessarily being an expert in all the details of OpenGL; the scene graph itself encapsulates OpenGL best practices. Because a scene graph is a toolkit layer on top of OpenGL, it raises the programming abstractions closer to the application domain.

As a tree, a scene graph consists of nodes that have one or more children. Since OpenGL state often has a hierarchical nature (such as the model-view matrix stack), that state can easily be mapped to nodes in the tree.

Some of the attributes and benefits of scene graphs:

• Encapsulation of best practices for rendering OpenGL, such as optimized GL state control; optimized internal data representations; and minimal geometry sent for rendering based on camera visibility.

• Implementation of sophisticated rendering architectures for performance, for example, pervasive multithreading, multi-CPU, multigraphics pipe, or synchronized multisystem clustering.

• Definition of the output viewports: For complex display systems such as multiprojector domes, the scene graph can provide support for nonlinear distortion compensation.

• Hierarchical in-memory representation, for example, a tree of nodes with child nodes or a directed acyclic graph (DAG).

• OpenGL state control: By associating GL state with nodes in the graph, the scene graph renderer collects those state requests and applies them efficiently to the OpenGL pipeline. The scene graph can implement a form of lazy state application, by which it avoids forcing state changes down the pipe if no geometry actually requires it for rendering. State can be inherited from parents down to children.

• View culling, by which the spatial position of scene graph nodes are tested against the position of a camera's view volume; only if a node will actually contribute to visible pixels will its geometry be sent to the pipe for rendering. (There is no reason to send vertices to the pipe for geometry that is behind the eyepoint.)

• Instancing of assets: one model of a tire can be referenced four times on a single car; a single car can be instanced many times to create a parking lot full of cars.

The typical application code for a scene graph-based rendering application is conceptually not much more than

at startup, build the scenegraph (loading files from disc, etc)
do forever
{
    update the camera position and other time-varying
    entities in the scene (such as vehicles or particle effects)

    draw the scene
}

Although a scene graph allows a visualization developer to focus on what to draw rather than on the details of how to draw it, that does not mean the developer is isolated from direct OpenGL control: not at allthe developer could define custom rendering methods. But for many common rendering tasks, the scene graph renderer already provides a complete solution and acts as a reusable toolkit for leveraging that capability. As expected from a well-designed toolkit, there are no inviolate rules; if you as the developer really need to do something out of the ordinary, the toolkit provides the avenues necessary.

The palette of nodes available for constructing the scene graph provides ways to apply attributes to be inherited by the children of that node. Here are some examples (certainly not an exhaustive list) of scene graph nodes.

• Parent nodeMultiple child nodes can be attached.

• Transform nodesThe children are transformed by the parent's transformation matrix.

• Switch nodesOnly one child of the parent will be rendered, governed by a switching condition.

• Level-of-detail node (a specialized switch node)Only one child is rendered, according to the distance of the node from the camera.

• Billboard nodeIts children are automatically oriented toward the camera.

• Light nodeOther nodes in the scene are illuminated by lights at the position and with the attributes contained here.

By helping the developer focus on "what" rather than "how," a scene graph can simplify the use of shaders. For example, using the hierarchical nature of a scene graph, a developer can compose a scene that has a shader with default values for uniform variables near the root of the scene graph, so it affects much of the scene. Alternative values for uniform variables attached at lower nodes can specialize the shader for a particular piece of geometry. The scene graph rendering engine can take over the tasks of determining if or when to compile or link the components of the shader and when to actually send updates for uniform variables to the pipeline, depending on visibility.

Several OpenGL scene graph products are currently available. OpenGL Performer (http://www.sgi.com/products/software/performer/), a commercial product available from SGI, has recently included support for OpenGL 2.0 and the OpenGL Shading Language. OpenSceneGraph (or OSG, http://www.openscenegraph.org/) is an open source project that also has recently included support for OpenGL 2.0 and the OpenGL Shading Language. OpenSG (http://www.opensg.org) is another open source OpenGL scene graph. Depending on your application, any one of these could save you a great deal of time and application development effort.