Revisiting the Java 3D Scene Graph
As discussed in the introduction to the 3D Visualization section in Chapter 10, the scene graph is the organizational structure for all Java 3D programs. It is worth the effort for you to develop a well thought out scene graph before beginning to code an application. At the very least, the scene graph will serve as documentation for the design. But just as importantly, the scene graph can guide the programmer's conceptual approach to the application. As a designer gains competence, the scene graph also serves as a way to see the optimization and grouping strategies that are always important considerations in any 3D application.
A Java 3D program, like a program developed in any other scene graph based API, is a collection of nodes and their relationships. (Recall the terminology of discrete mathematics, nodes and edges from Chapter 10, “3D Graphics, Virtual Reality, and Visualization.”) For now, we will say these elements are organized in the form of a tree (they are actually directed acyclic graphs, which will be described later in the chapter). Implicit in the tree design are parent-child relationships; the children are attached to the parents and live below them within the tree structure (see Figure 11.1). The practical implication of this is that the parents' states are carried through to their children.
Because the tree is such a good analogy, we will continue with it. Java 3D includes nodes, called Group nodes, which serve as the major branches of the tree. Like a branch, a Group will typically contain more branches that eventually lead to a termination point (called a Leaf node). The scene graph acts as the organizing structure for a Java 3D application and is also useful as documentation. In Figure 11.1, groups are indicated by circles and leaves by triangles.
Like trees you would see in your own backyard, scene graph trees have a wide variety of branching patterns, some intricate and others pretty simple. There are some (but not many) restrictions on what types of branches can be added where. The complexity of the tree naturally builds from the base, but the majority of the work in developing Java 3D applications is in developing a particular branch, the content branch. Java 3D's ease of content creation is an important advance because it brings an entire class of scientists, engineers, and artists into the world of 3D and Web3D.
Returning to our analogy of the tree, we move up (increasing in detail) from the base. The first major functional division of the tree is into the two branches: the content subgraph and the view subgraph. Both the content and view subgraphs are represented by a special Group object known as a BranchGroup. Later, you will see that the BranchGroup has some special properties. The details of developing the content and view subgraphs are discussed later in this chapter. For now, we will consider the different types of branches that we can use to organize the scene graph.
Java 3D Group Nodes: The Branches
Six fundamental ways to group scene graph elements in Java 3D are listed in Table 11.1. The listed classes are used to organize the elements in Java 3D scene graphs. All these grouping classes extend the abstract class Group.
The classes in Table 11.1 inherit two important qualities from Group: 1) each can have one (and only one) parent, and 2) each can have any number of children.
Three of these classes (BranchGroup, Switch, and TransformGroup) are used extensively in most applications, whereas the remaining three (OrderedGroup, SharedGroup, and DecalGroup) have more specialized uses that are described later in this chapter.
Leaf Nodes
In addition to Group nodes (the branches), Java 3D contains a second type of node called a Leaf node (the leaves). The difference is that while Group nodes act to organize the scene, the Leaf nodes represent specific elements in the scene such as lights, sounds, and shapes and behaviors (a major part of Chapter 12, “Interaction with the Virtual World,” and partially covered in this chapter).
Leaf nodes are the lowest level constructs in the scene graph. They have no children and exactly one parent. The Leaf node class itself is abstract; therefore, the programmer would never instantiate a Leaf node object directly. From a conceptual scene graph design standpoint, it is important to recognize which objects are subclasses of the Leaf node class and which are subclasses of Group node.
Directed Acyclic Graph
Although we have been using the analogy of a tree to describe the organization of a scene graph, we should make it clear that Java 3D, as well as other scene graph APIs, are really a special kind of graph structure called a directed acyclic graph (DAG). Two major distinctions exist between a DAG and other types of graphs. These differences are reflected in the terms directed and acyclic.
The directed graph, or digraph, has a fairly long history of use in logic, perhaps even dating back to Aristotle himself. A digraph can be thought of in terms of a series of one-way streets. The key concept to keep in mind is that although a graph is like a map of a neighborhood, a directed graph represents a particular route through that neighborhood. This distinction will become clearer as you progress through this chapter. In terms of the scene graph, it means that a unique path can be drawn from the trunk of the tree to each of the Leaf nodes that eventually terminates the branching patterns. This path is often referred to as a scene graph path.
The term acyclic refers to the complete absence of loops within the scene graph structure. In simple terms, you cannot take a path that starts and ends at the same node. This restriction usually isn't an issue in most applications; however in certain circumstances, it does come into play. In the interest of simplicity, we will not concern ourselves with these situations here except to note that they are forbidden.
Following a Scene Graph Path
As mentioned previously, it is important to realize that because we are dealing with a DAG, a unique path can be drawn from the root of the scene graph to any Leaf node in the scene graph. The presence of a unique scene graph path enables a number of important advantages in rendering optimization and is particularly useful in the area of object picking, a major topic of Chapter 10, in the section on “User Interaction in 3D Space.” The important concept to understand now is that each unique scene graph path specifies the state attributes of the Leaf node at the termination of the path. As you will see throughout this chapter, a Leaf node can have numerous state attributes including location, orientation, color, and so on. Each Leaf Node's attributes represent the accumulation of acquired attributes as the scene graph path is traversed.
One of the important jobs of the Java 3D renderer is to determine the most efficient order in which to render the set of Leaf objects. This type of rendering optimization is precisely the advantage of a scene graph based API. Note that it is possible to specify a programmer defined rendering order using an OrderedGroup, discussed in the section “OrderedGroups” later in this chapter; however, this is only useful in certain rare circumstances and is generally ill-advised unless the application absolutely requires the use of OrderedGroup.