Java 3D API Specification
Java 3D API Specification
C H A P T E R 11 |
|
The Java 3D Execution and Rendering Model |
Java 3D's execution and rendering model assumes the existence of a VirtualUniverse object and an attached scene graph. This scene graph can be minimal and not noticeable from an application's perspective when using immediate-mode rendering, but it must exist.
Java 3D's execution model intertwines with its rendering modes and with behaviors and their scheduling. This chapter first describes the three rendering modes, then it describes how an application starts up a Java 3D environment, and lastly, it discusses how the various rendering modes work within this framework.
11.1
Three Major Rendering Models
Java 3D supports three different modes for rendering scenes: immediate mode, retained mode, and compiled-retained mode. These three levels of API support represent a potentially large variation in graphics processing speed and in on-the-fly restructuring.
11.1.1
Immediate mode allows maximum flexibility at some cost in rendering speed. The application programmer can either use or ignore the scene graph structure inherent in Java 3D's design. The programmer can choose to draw geometry directly or to define a scene graph. Immediate mode can either be used independently or it can be mixed with retained and/or compiled-retained mode rendering. The immediate mode API is described in Chapter 12, "Immediate Mode Rendering."
11.1.2
Retained mode allows a great deal of the flexibility provided by immediate mode while also providing a substantial increase in rendering speed. All objects defined in the scene graph are accessible and manipulable. The scene graph itself is fully manipulable. The application programmer can rapidly construct the scene graph, create and delete nodes, and instantly "see" the effect of edits. Retained mode also allows maximal access to objects through a general pick capability.
Java 3D's retained mode allows a programmer to construct objects, insert objects into a database, compose objects, and add behaviors to objects.
In retained mode, Java 3D knows that the programmer has defined objects, knows how the programmer has combined those objects into compound objects or scene graphs, and knows what behaviors or actions the programmer has attached to objects in the database. This knowledge allows Java 3D to perform many optimizations. It can construct specialized data structures that hold an object's geometry in a manner that enhances how quickly the Java 3D system can render it. It can compile object behaviors so that they run at maximum speed when invoked. It can flatten transform manipulations and state changes where possible in the scene graph.
11.1.3
Compiled-retained mode allows the Java 3D API to perform an arbitrarily-complex series of optimizations including, but not restricted to, geometry compression, scene graph flattening, geometry grouping, and state change clustering.
Compiled-retained mode provides hooks for end-user manipulation and picking. Pick operations return the closest object (in scene graph space) associated with the picked geometry.
Java 3D's compiled-retained mode ensures effective graphics rendering speed in yet one more way. A programmer can request that Java 3D compile an object or a scene graph. Once compiled, the programmer has minimal access to the internal structure of the object or scene graph. Capability flags provide access to specified components that the application program may need to modify on a continuing basis.
A compiled object or scene graph consists of whatever internal structures Java 3D wishes to create that ensures that objects or scene graphs render at maximal rates. Because Java 3D knows that the majority of the compiled object's or scene graph's components will not change, it can perform an extraordinary number of optimizations including the fusing of multiple objects into one conceptual object, turning an object into compressed geometry, or even breaking an object up into like-kind components and reassembling the like-kind components into new "conceptual objects."
11.2
From an application's perspective, Java 3D's render loop runs continuously. Whenever an application adds a scene branch to the virtual world, that scene branch is instantly visible. This high-level view of the render loop permits concurrent implementations of Java 3D, as well as serial implementations. The remainder of this section describes the Java 3D render loop bootstrap process from a serialized perspective. Differences that would appear in concurrent implementations are noted as well.
11.2.1
Next, the application must construct its scene graphs. It does this by constructing scene graph nodes, component objects and linking them into self-contained trees with a BranchGroup node as a root. The application next must obtain a reference to any constituent nodes or objects within that branch that it may wish to manipulate. It sets the capabilities of all the objects to match their anticipated use and only then does it compile the branch using the BranchGroup's compile method. Whether or not it compiles the branch, the application can add it to the virtual universe by adding the BranchGroup to a Locale object. The application repeats this process for each branch it wishes to create. Note that in the case of a concurrent Java 3D implementation, whenever an application adds a branch to the active virtual universe, that branch becomes visible.
11.2.2
This initialization process is identical for retained and compiled-retained modes. In both cases, the application builds a scene graph. In the case of compiled-retained mode, the application then compiles the scene graph. Then the application inserts the (possibly compiled) scene graph into the virtual universe.
Java 3D API Specification
Copyright © 1997, Sun Microsystems, Inc. All rights reserved.