4.2 What is a scenegraph | JAVA 3D Programming | Chapter 4

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 Virtual Universe 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.

There are three basic classes of objects within the scenegraph:

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

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

• Control or influence nodes—Behaviors, 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.

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.

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.

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.