The Java 3D Scene Graph
The idea of using a graph as a way to organize the parts of a 3D scene has been around for a number of years and certainly isn't unique to Java 3D. The general purpose of the scene graph is to contain a complete description of the scene. Figure 10.5 contains a portion of a scene graph. This particular example shows scene elements (LeafNodes) grouped together under a TransformGroup that is the child of a BranchGroup. In most applications, the majority of the work is in making the LeafNodes and adding them to the appropriate TransformGroup. This particular partial scene graph example doesn't show the superstructure elements Locale and Universe that you will encounter later.
Figure 10.5. Portion of a scene graph.
The scene graph also provides several levels of abstraction above the low-level APIs (OpenGL or DirectX). Abstraction is an important object-oriented programming concept that refers to the process of identifying and isolating generalized qualities in a set of objects. In terms of the scene graph, this means that the programmer is now free to think about the content and higher level conceptual aspects of creating the scene rather than the details of rendering or the complexities of managing the low-level geometry primitives because these things have been “abstracted away.”
By virtue of being a scene graph based API, Java 3D provides free cross-platform optimization in terms of development effort. Each individual developer can thus get functionality and optimization in her 3D content without having to worry much about it. These low-level challenges would have previously been a major impediment to our beginning the project in the first place. Moreover, without the abstractions provided for in the scene graph model, we would end up with a platform-specific solution. The optimizations that were developed for one low-level implementation wouldn't necessarily benefit us on the other platform. In many ways, the scene graph is highly similar in nature to a high-level optimizing compiler in that it provides a platform independent API that is optimized for the particular hardware on which it is compiled.
Note
Java 3D performs the best optimizations on scene graphs that are properly organized spatially. It is critical that objects in close proximity moving in synchronization be grouped together.
The scene graph is the central structure of every application written in Java 3D, and it is highly recommended that programmers at least sketch a proposed scene graph prior to beginning programming. This point cannot be emphasized enough. A layout of the organization of the scene graph will both document the application and give the programmer insight into efficiencies that can be gained through better structuring of the model. A large amount of confusion will be avoided through understanding how scene graphs work.
Note
The name scene graph might be a little confusing to some people. We therefore describe the origin of this terminology here. A graph, in this case, refers to the definition used in discrete mathematics. In this sense, a graph attempts to describe a system schematically from the perspective of the states it can enter and the transitions between those states. Note that we worked from the standpoint of a rendering graph in some of our image processing examples from Chapter 6, “Java Advanced Imaging.”
A graph is made from two basic entities: nodes and edges that are arranged in a tree-like structure. Each edge is a pair of nodes. In a family tree, for example, the nodes are the individual people and the edges are the parent-child relationships.
The scene graph is built by instantiating both scene objects (for example, lights, textures, geometries) and special objects for defining the viewing parameters. These two fundamental scene graph branches are added in parallel structures to the scene graph and are known as the content branch and the view branch, respectively. The skill of scene graph design lies in recognizing meaningful groupings within the content subgraph. Generally, the view branch doesn't substantially change from application to application, although it certainly can. However, most of the real work is in describing the content subgraph.
In Java 3D, all nodes and components that can be added to the scene graph are subclasses of SceneGraphObject. All these are accessed and operated on by the set() and get() methods. Other important methods include setUserData() and getUserData(), which can be used to set and get user-defined states for the object, respectively. The SceneGraphObject is covered in more detail in Chapter 11, “Creating and Viewing the Virtual World.”
In Java 3D, both the content and viewing subgraphs are contained in separate holders known as BranchGroups. Each BranchGroup is the root of a branch in the scene graph. BranchGroups are the only objects that can be added to a Locale (a collection of BranchGroups that occupies a high-resolution position within the “universe”). The Locale and VirtualUniverse objects are described next.
Once you understand how to organize content within a scene graph, most of the conceptual hurdles will have been overcome. Far more detail is given about scene graph organization in the next chapter. For now, you should remember that the basic purpose of the scene graph is to organize the view and content subgraphs in a logical and abstracted fashion.