< Zurück | Inhalt | Weiter >

4.2 What is a scenegraph?

A scenegraph is a hierarchical data structure that captures the elements of spatial relationships between objects. Technically a scenegraph is a directed acyclic graph (DAG). Once you think and model an application hierarchically, the 3D graphics API is provided with a much richer set of information to use to optimize rendering. A scenegraph description also enables application developers to apply object−orientated (OO) principles such as abstraction and reuse to their designs.

In Java 3D, the scenegraph is encapsulated within the VirtualUniverse class. The scenegraph is composed of objects derived from the Node class. Every instance of the Node class has one parent Node. Additionally, the scenegraph contains objects derived from the Group class which encapsulates a collection of Node child objects. In this way a hierarchy of Group−derived objects can be created with Node−derived objects attached to the parent Group objects, as shown in figure 4.2.


Figure 4.2 Four Groups with child Nodes. The parent−child relationships allow you to build a scenegraph hierarchy. Note that cycles are not permitted (e.g., Group 3 cannot also have Node 1.1 as a child); hence the scenegraph is a DAG

There are three basic classes of objects within the scenegraph:

Management nodesLocale, BranchGroup, TransformGroup, ViewPlatform, Switch, and so forth. These are predominantly derived from Group and manage a collection of child objects.

Geometry nodesShape3D, Background, and so forth. These objects are derived from Leaf and define visible geometry within the application’s virtual world.

Control or influence nodesBehaviors, Morph, Light, Sound, Clip, and so forth. These define application behavior and are typically not directly related to the geometry used within the application.

BranchGroup and TransformGroup are both Group nodes (i.e., they can contain child Nodes). A TransformGroup also contains translation, scaling, and rotation information that it applied to its child Nodes. The details of the nodes available in Java 3D are presented in later chapters.

For example, consider how one might compose the scenegraph for the F1 car. The car can be roughly anatomized into seven parts (figure 4.3): four wheels, chassis, rear fin, and front stabilizer.


Figure 4.3 Sample scenegraph for the F1 car, plus icons represent unexpanded Groups

Each wheel is composed of spokes, a rim, and a tire. In this way the branch of the scenegraph that defines a wheel—that is, the Wheel Group and its three child Nodes, can be reused and duplicated to create the four wheels required for the F1 car.

The scenegraph also encodes a spatial relationship. When the F1 car is moved, its child Nodes are automatically also moved. For example, the stabilizer might be positioned three meters from the origin of the F1 car in the x direction—this spatial relationship will be preserved irrespective of the position of the F1 car’s origin. If the wheel is rotated about its axis, the spokes, rim and tire will all be automatically rotated.

The scenegraph allows model complexity to be selectively specified. Just as you have chosen to create the Wheel from three subcomponents, you might choose to further decompose the chassis to introduce more detail into the model. You might have the opportunity to reuse scenegraph branches—perhaps other classes of vehicles at the race circuit require tires that are similar to the F1 tires? Perhaps you need to create piles of tires in the pit?

Various 3D graphics file formats (e.g., VRML) allow models to be created that are composed from subcomponents.

Figure 4.4 shows how the F1 car fits into the overall scenegraph for the F1 racing application.


Figure 4.4 Sample scenegraph for the F1 race track application

This scenegraph shown in figure 4.4 embodies the following relationships:

Moving the grass area upon which the racing circuit sits will also move the circuit and the trees around it.

Moving the circuit will move the advertising billboards, people at the circuit, cars on the circuit, straw

bales, and the start light.

Moving a F1 car moves its component parts: stabilizer, rear fin, chassis, and wheels.

Rotating an F1 car’s wheels will rotate the wheel’s spokes, rim, and tire.

By designing the scenegraph with the spatial relationships in mind, scenegraph elements can be easily reused. Perhaps in the future the racetrack application will be expanded to contain two circuits with an animated transition sequence between them. The transition sequence will use a view from a helicopter flying between the circuits.

You’ll need to reuse the circuit scenegraph branch and introduce a new element for the helicopter. Figure 4.5 shows how these elements might be introduced into the original scenegraph.


Figure 4.5 Adding a new circuit and a helicopter to the scenegraph

This formulation reuses the whole circuit branch of the scenegraph. The new circuit will have its own surrounding terrain and trees, as well as all the circuit geometry. You’ll need to move the helicopter independently of the grass for each circuit, so the helicopter Group is added directly into the world Group. Moving the world will move the two circuits as well as the helicopter.