4.1 Overview | JAVA 3D Programming | Chapter 4

4.1 Overview

Your application’s 3D virtual world contains geometric objects with which the user interacts. In Java 3D this virtual world is called the VirtualUniverse, the top−level class that contains all the elements that you define within your virtual world. In addition, the VirtualUniverse contains nongeometric objects that control or influence the world. Lights are a good example of this type of object. In a 3D environment, one cannot see a Light, but one can see the effect of the Light within its zone of influence.

A concrete example helps to describe some of the details. Imagine a virtual world that models a Formula 1 Grand Prix race (figure 4.1). The model is a simplification of reality. It contains:

• 3 Williams F1 cars

• 2 Ferrari F1 cars

• 3 McLaren F1 cars

• 2 Jordan F1 cars

• 1,000 trees

300 pine

300 oak

400 spruce

• 100 pit crew 43

• 100 marshals

• 60 advertising billboards

20 for a sport channel

20 for a car part manufacturer

20 for a cigarette manufacturer

• 200 straw bales

• 1 racing circuit

• 1 start light

• 1 grass area upon which the race track is situated

Taking a quick sum of the elements we see there are 1,473 objects in this Virtual Universe. However, there are only 16 different types of objects. So, if you had the luxury of a team of 3D graphics artists and modelers, you could send the list away and a few weeks later receive 16 VRML format (for example) 3D graphics files. In fact, one might even define classes and subclasses, breaking the objects into cars, trees, people, billboards, bales, start light, racing circuit, and grass and hence require only eight classes. In this case the 3D graphics artists will produce a single F1 racecar model that can be customized (using color for example) to create the three subclasses McLaren, Williams, and Ferrari.

You should now be wondering how, with 1,473 distinct objects in your scenegraph and only eight classes of objects, you can organize the objects in your world so that you minimize memory overhead and rendering time but maximize programming flexibility.

You should also be aware that some of the objects within the world are dynamic:

• F1 cars

• Pit crew and marshals

Some of the objects are static:

• Straw bales

• Trees

• Billboards

• Race track

• Start light

• Grass

It is important to note in this context that “static” means “does not move relative to the circuit,” or “does not move relative to the grass area upon which the circuit sits.” It does not mean that the items are static relative to the center of the universe or even (potentially) relative to the center of the Earth.

So, static and dynamic in this example have defined movement relationships between the items listed and the circuit. You should also therefore think about the spatial relationships between a class of items and all other classes of items. For example, the circuit never moves relative to the grass and maybe the straw bales are always situated 25 meters in front of a billboard; or you model groups of trees in which there was a fixed spatial relationship between the trees within each group.

Some of the objects have appearances that change:

• Dynamically

  Start light (red to green)

• Statically

   F1 cars (Williams, McLaren, or Ferrari insignia)

   People (either pit crew or marshal uniforms)

   Trees (pine, oak, or spruce graphic)

Assume that you are using a low−level graphics API that can only render triangles, points, and lines at a given x, y, z coordinate.

Your primitive rendering loop might look like:

1. Run some control logic.

2. Update the x, y, z position of dynamic triangles.

3. Update the appearance of triangles whose appearance changes dynamically.

 4. Draw the triangles.

5. Go to next frame.

It should be obvious that this approach does not exploit much of the information about the structure of the world that you developed initially. The rendering API has no concept of an object and it has no concept of spatial (or otherwise) relationships between objects. This is analogous to sending your initial list of 1,473 objects to the graphics artists and making them do all the work.

What you need is a data structure that you can use both to describe the relationships between objects and exploit to optimize your rendering and memory requirements. Read on.