Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Last month we began our exploration of Java 3D with static content and small scenes. This month we'll conclude our introduction by delving into loaders for larger scene graphs and giving our worlds behaviors and interactivity. We'll also discuss the interplay between Java 3D and VRML, review the performance characteristics of Java 3D, and set the stage for next month's look at Java OpenGL bindings.
I received several reader questions about the placement of the 3D objects in last month's examples. One reader in particular asked why, when he modified the transform so the cube's z coordinate was positive, he could no longer see the cube. Let's reexamine the example code from last month's Example 3 to learn more about how things are situated in three dimensional space using Java 3D.
The critical line of code from this example is:
The arguments in the
Vector3D constructor are x, y, and z coordinates. The cube is placed by this transform at x = -0.5; y = -0.5; and z = -2.3 (in floating point values, hence the "f" suffixes).
It's critical to note that your viewing location can change. This is determined by the location of the associated
ViewPlatform, which, in turn, is situated in the 3D world using the
TransformGroup above it (actually, using a
Transform3D node to transform the
TransformGroup above it).
Also note that in Example 3, we don't move the
ViewPlatform; we construct all of the view branch using the default constructors, which use an identity
Transform3D node (more on identity later) in the
ViewPlatform. Thus, the
ViewPlatform is located at x = 0.0; y = 0.0; and z = 0.0, the origin of the 3D coordinate system.
And finally, it's important to note that the coordinate system is aligned with your view into it. With the default view branch, the +x axis runs from left to right across the screen and the +y axis runs from bottom to top, which means, using the right-hand rule, that the +z axis runs out of the screen towards you. By default, your view into the world is looking in the -z direction.
Default Java 3D coordinate axes, as seen
from directly in front of the monitor. We are
looking in the -z axis direction, directly into
the monitor. The origin is located in the center
of the x-y plane.
Default Java 3D coordinate axes, as seen from
directly above the front of the monitor. We are
looking in the -y axis direction along the x-y plane.
The +z axis is sticking straight out of the monitor.
Because you're "sitting" at the origin (the view platform is located at 0.0, 0.0, 0.0) looking in the negative-z direction,
anything in the positive-z section of the 3D world is behind you and you can't see it. Don't you just love 3D! (See Resources for more information on
Now, let's return to the issue of the contents of Sun's private jar files. Last month I briefly mentioned that Sun's Java 3D implementation installs both standard Java 3D classes (as specified in the Java 3D API specification) and nonstandard (Sun implementation-specific) classes. These classes are made available in one of several jar archives placed within the new Java 2 platform (formerly known as Java 1.2) extensions directory (see last month's column for more information on this). We discussed the standard classes and jars in sufficient detail last month, but we still have some ground to cover on the Sun-specific ones.
As a reminder, Sun's archives include:
j3daudio.jar, which archives the
com.sun.j3d.audiopackages, described last month
j3dutils.jar, which encapsulates a variety of Sun utility classes in 16 total packages and subpackages underneath
com.sun.j3d(more details in a moment)
j3dutilscontrib.jar, which archives useful utilities contributed by others to Sun's efforts (again, more details in a moment)
When you explode the
j3dutils.jar archive, you see the following subpackages of
j3dutilscontrib.jar reveals these additional
Now that you know the basic layout of Sun's utility class archives, you can delve into them more deeply if you need any of
the functionality they provide. For instance, if you're looking to capture mouse events to control interpolated behaviors,
you need to load in LightWave 3D content. And if you're interested in 3D font support, you should review
com.sun.j3d.utils.font3d more closely.
Please note that while some documentation is provided for these packages in the general Java 3D documentation from Sun, the quality of documentation varies from package to package and from class to class. I recommend that you monitor the java3d-interest mailing list for information on the particular utility classes you need to use.
Interactivity results from being able to program an object to react to certain stimuli. In Java 3D, these behaviors are scheduled when the view platform crosses the stimulus bounds, a region of space defined by the programmer. Bounds assign a spatial scope to objects. There are bounds for both sounds and behaviors in Java 3D.
The advantage of requiring bounds for objects is that the runtime can safely disregard (not render) things that are out of bounds. If you build behaviors into your Java 3D applications, you will be required to set bounds in order to have the Java 3D runtime scheduler prepare your behaviors for execution. The scene graph includes a set of nodes for setting up and scheduling behaviors and bounds. In addition, several of the utilities described above help you to more easily deal with interactivity, including the aptly named "behaviors" subpackages.