4.3 Java 3D and the scenegraph | JAVA 3D Programming | Cheater 4
4.3 Java 3D and the scenegraph
This section will cover additional
scenegraph elements required by Java 3D to manage and render your scenegraph.
A VirtualUniverse contains at least
one Locale object. A Locale defines a geographical region within your
scenegraph. Locales are covered in depth in chapter 6.
In Java 3D there are two distinct branches
within the scenegraph: scene and view. Up to now we have discussed only the
high−level principles behind the scene side of the scenegraph. The scene branch
contains the application’s scenegraph elements, as discussed in the preceding
examples. The view branch contains a ViewPlatform node and defines scaling,
rotation, and translation information for the view. The view is responsible for
rendering the scene side of the scenegraph. As shown in figure 4.6, the view
attaches to a ViewPlatform and reads position and orientation information from
the Nodes above the ViewPlatform on the view side of the scenegraph.
The view renders into its attached
Canvas3D component. Canvas3D is a GUI component with an associated native
windowing system window.
It is possible to have multiple
ViewPlatforms in a scenegraph. Multiple ViewPlatforms allow you to define
multiple points of view of your scene. By removing the view from a ViewPlatform
and attaching it to a new ViewPlatform you can easily shift between predefined
points of view.
It is also possible to have multiple views
each rendering into multiple Canvas3Ds. For more on these advanced scenegraph
features please refer to chapter 6.
Java 3D can exploit the hierarchical Bounds
information to optimize many scenegraph operations, including rendering. For
example, when the Renderer comes to render an F1 car, if it finds that the
Bounds of the F1 car Group are outside the current view frustum the Renderer
can immediately move on to the next car in the scene. The high−level visibility
test on the F1 car Group has saved the Renderer from performing visibility
tests on the child Nodes of the F1 car Group.
This implies another important
property of a good scenegraph hierarchy: the structure of the scenegraph should
provide as much Bounds information as possible to allow the Renderer to
optimize rendering. As the scenegraph designer you should be cognizant of the
potential Bounds of your scenegraph Nodes. From the full F1 race circuit
example you could see that as you move down the scenegraph hierarchy the Bounds
of the Groups and Nodes become smaller and smaller.
The Grass Group contains everything
within the 3D scene, and as such must always be recursively processed by the
Renderer. The Grass Group will be rendered irrespective of the user’s point of
view of the scene. It would not matter whether the user was riding in−car with
a point of view from one of drivers, was orbiting the circuit in a helicopter,
or had a view from somewhere around the circuit. If the user can see the
virtual world, the Renderer will process the grass Group. Figure 4.7 shows
three sample points of view around the circuit.
The trees Group (figure 4.8) contains
all the trees within the scene. Since the trees are scattered across the
terrain surrounding the race circuit the trees Group will have Bounds that are
close to the size of the grass Group. The trees Group will also usually be
processed by the scenegraph Renderer (as most points of view around the circuit
will intersect trees). Conceivably the viewer of the scene could be positioned
at the periphery of the circuit and facing away from the center of the circuit,
such that their FOV falls outside of the Bounds of the trees Group. Note that
FOV #1 is not such a case. Though viewer #1 cannot see any trees, his FOV does
intersect the trees Group’s Bounds object. Each of the trees within the Trees
Group will have to be tested against FOV #1—even though none of them actually
intersect with FOV #1.
The Circuit Group (figure 4.9)
encloses all of the geometry that composes the circuit roadway. This is still a
large Group and not significantly smaller than the overall grass Group. It is
very unlikely that a viewer of the scene will not be able to view the circuit,
which is the central feature of the application.
The F1 car Group (figure 4.10), on the
other hand, merely has Bounds that enclose the geometry required for an individual
F1 car (a meter by a few meters). It is very likely that a particular F1 car
Group will not intersect a given FOV. It is highly unlikely that a single
viewer will be able to see all of the F1 cars as they race around the circuit.
For example
• FOV #1 intersects with 0 F1 car
Groups
• FOV #2 intersects with 1 F1 car
Group
• FOV #3 intersects with 1 F1 car Group
As there are 10 F1 car Groups in the
scenegraph this represents a considerable saving.
The start light Group (figure 4.11)
will be even smaller than the F1 car Group (less than a cubic meter). It will
rarely intersect with a given FOV, even if we ride in the car with a driver.
None of the FOVs defined on figure 4.7 can see the start light.
Figure 4.12 shows bounding rectangles
for five classes of objects in the racing circuit virtual world. The level of
detail of objects within the world should reflect the theme of the application.
For example, the grass around the circuit would probably be modeled as a simple
rectangular height field with an applied texture image, while the F1 cars
themselves would be complex 3D models composed from hundreds of vertices. On
the other hand, if the application were a landscape design package the grass
and trees may be represented using complex geometry. Some of the most
challenging applications allow the user to control the application at several
levels of detail, dynamically reapportioning the detail within the scene as
appropriate. An excellent example of this is the game “Black and White” by
Lionhead. The game allows the user to zoom out to control entire countries and
to zoom in to view individual character animations and interactions.
Comments
Post a Comment