If you're tired of concentrating on the nuts-and-bolts of how to handle 3D rendering, you'll love the new Java^TM 3D graphics API, which is currently under development.

"It handles a much higher level of abstraction," says Henry Sowizral, one of the Java programmers leading the new API effort. "Now, you can think about an object and its placement, rather than its vertices. You'll be able to think more about content, not just the process of drawing content," says Sowizral.

Among the other exciting features in the new API: Sound is now integrated into the API itself, and the API supports interesting new types of sound distribution in 3D scenes. In essence, sound is part of the environment of a scene, and can be handled using environmental control nodes. And it's truly 3D sound, which keeps track of where in a scene a sound is located, and where a person is looking. You can use point sound, which is distributed in an omni-directional 3D arc around you, or you can focus it like a spotlight, so sound drops off rapidly outside of a small cone of focus. So you can build 3D scenes or worlds in which viewers experience sound more realistically.

It's also easier to define and reuse geometry, making it easier to develop consistent, easily reusable or modifiable scenes, so you can write once, view many times, anywhere. It's as easy as pointing to a common node.

The new standard supports OpenGL, Direct 3D, and QuickDraw 3D, so the standard will easily support new video cards that support these standards. And although he doesn't advise it, Sowizral says developers can eschew these standards and "go down to the bare metal."

Another big win in the new standard is the use of compressed geometry, which in early tests has resulted in reducing required disk space, load times, and memory to somewhere between a seventh to a tenth of that required by the original uncompressed geometry. The result: dramatically improved performance.

How it works

Central to the new 3D approach is the scene graph, which describes a scene and separates data from the rendering process, central to achieving a higher level of abstraction. "For instance, nodes don't have draw methods," says Sowizral. "We did it that way to have more control over threads and rendering, so we can optimize for particular machines, rather than trying to do it for all machines at once," he adds.

"Also, to allow us to generalize and carefully specify the machine you're on, we provide you with minimal state inheritance in scene graphs, so up and down the scene graph, only a few transform nodes are there," says Sowizral, who adds that now "state and other inheritance that you think of as being high up in the scene graph are now leaves within a scene graph."

Other key concepts

Think of a scene as being a hierarchy composed of the following things:

Locales. Locales are designed to help you with some of the nastier problems of building virtual worlds. Much of the time, you'd only use one locale, and its origin would be at (0,0,0). But if you wanted to create a scene with buildings on the surface of the earth, but you also wanted to represent earth's position within the solar system, and the solar system's relationship to the Andromeda Galaxy, all in the same virtual world, you would have run into problems with previous rendering schemes. Now you'd specify a locale object that would specify another location.

Leaf nodes. Lower are the leaf nodes, which establish states and geometries. They also specify sounds and where you are in a scene, and they perform behavior. For instance, using the viewPlatform leaf node, you can change positions or locations within a scene, so you can control what people are looking at either through behaviors or through a Web browser, which will be able to keep track of where you are and move you around appropriately within the scene graph.

Group nodes. Lower in the tree than leaf nodes are the group nodes, which are the glue that holds the tree together and compose the scene. These nodes come in two flavors: unordered and ordered. Unordered group nodes are the basic components of a Java 3D scene graph, and they let Java optimize the order in which objects are rendered. (But don't worry that things will appear in a weird order; Sowizral says that because the API uses an implicit Z-buffer, everything will look right as its drawn, except perhaps in mixed mode.) But if, for some reason, you need to be able to control the rendering order, you can use ordered group nodes. You can also use switchNode to choose one of the children and only render that one (you need to know the order of the children to do this). You can also specify the level of detail in which you want to render the scene using lodNode.

Shape nodes. Shape nodes are atomic objects in the 3D API, so you can't get lower-level. They consist of two parts, a geometry and an appearance. You specify geometry by loading it up. You can also bring in 3D text as a different class, and it will be automatically generated. Appearance attributes include the color, material properties such as shininess, texture, and transparency.

Environment control nodes. These specify lighting (ambient, directional, point lighting, spotlights, background color, clipping, and fog).

Component objects. Component objects specify things such as appearance attributes, bounds, geometry, and math components such as quaternions.

If a tree falls...

In Java 3D, an activation region is placed around the view platform, and behaviors have wake-up criteria and activation regions. If you're not within the intersection of these, nothing new will happen.

Activation regions are smaller areas of a scene graph where you're interested in focusing. Wake-up criteria let something happen when a condition has been satisfied. They include things such as getting an AWT event such as a button click. They also include shape collision (two shapes hitting each other), entering or exiting the view platform, time elapsing, frame time elapsing, or behavior posts.

So, if a tree in the middle of the a Java 3D virtual forest, and you're not within the activation region (nobody's there), nothing happens -- the tree doesn't fall, and there's no sound -- because you're not within the activation region or haven't met the criteria. Because of a concept called "execution culling," you don't have to run all of the objects in a large virtual world at the same time. You only execute behaviors in the area of interest -- the activation region -- once the wake-up criteria have been satisfied. Now, isn't that a much simpler answer to that question than all the others that you've heard?

Yet another easy Java answer to one of life's difficult problems, brought to you by JavaSoft.