javax.media.j3d.doc-files.Rendering.html Maven / Gradle / Ivy
Java 3D API - Execution and Rendering Model
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 describes how an application starts up a
Java 3D
environment, and finally it discusses how the various rendering modes
work within this framework.
Three Major Rendering Modes
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.
Immediate Mode
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 be either used independently or mixed with retained and/or
compiled-retained mode rendering. The immediate-mode API is described
in the "Immediate-Mode Rendering" section.
Retained Mode
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 the speed at which the Java 3D system can render it.
It
can compile object behaviors so that they run at maximum speed when
invoked. It can flatten transformation manipulations and state changes
where possible in the scene graph.
Compiled-Retained Mode
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 it is 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 to ensure 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."
Instantiating the Render Loop
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.
An Application-Level
Perspective
First the application must construct its scene graphs. It does this
by
constructing scene graph nodes and 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 compiles the branch using the BranchGroup's compile
method. Whether 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 for concurrent Java 3D implementations, whenever an
application adds a branch to the active virtual universe, that branch
becomes visible.
Retained and
Compiled-Retained Rendering Modes
This initialization process is identical for retained and
compiled-retained modes. In both modes, the application builds a scene
graph. In compiled-retained mode, the application compiles the scene
graph. Then the application inserts the (possibly compiled) scene graph
into the virtual universe.