< Zurück | Inhalt | Weiter >

11.1 Introduction

We should start by taking a look at the general Java 3D behavior architecture. What is a behavior anyway?

Just as you can add geometry (Shape3D), transformations (TransformGroup), or lights (Light) to the scenegraph, Java 3D also allows you to add blocks of executable code to the scenegraph. This code is packaged within a class derived from Behavior and is automatically executed by Java 3D in response to a set of criteria. In Java 3D, the criteria for a Behavior being executed are called wake up criteria and are defined using classes derived from WakeUpCondition.

The behavior architecture is based on the following series of events and notifications:

1. Create a Behavior and register its WakeUpCondition.

2. Java 3D enters its Behavior processing loop.

3. Java 3D checks whether the WakeUpCondition for the current Behavior is satisfied.

4. Java 3D calls Behavior.processStimulus if the WakeUpCondition is met.

5. Behavior code executes within processStimulus call.

6. Behavior sets its next WakeUpCondition.

7. The next Behavior is processed by the Behavior processing loop.

The behavior architecture facilitates good application design and code reuse because a scenegraph branch can contain not only the complex geometry for a hierarchical scenegraph element but also the code to control the scenegraph element. For example, an application might define a car that drives around a race−circuit (figure 11.1). The application allows the user to replay a prerecorded racing sequence. Just as the car itself has been decomposed into a hierarchical model, behaviors can also be modeled hierarchically. A Behavior attached to each wheel of the car will rotate the wheel and its child nodes (spokes, etc.), while a Behavior attached to the top−level node of the car allows the entire car to be moved through a prerecorded trajectory using a Behavior to interpolate between positions.


Figure 11.1 A scenegraph branch for the Formula 1 racing car. The branch contains five Behaviors, the first (RotPosPathInterpolator) to replay the car through a recorded trajectory, and four RotationInterpolator Behaviors—one to rotate each wheel

Good, reusable, class design results. Every wheel has the ability to be rotated, while every car on the track can be replayed through a trajectory. The higher level elements in the scenegraph need have no knowledge of these properties of the car object—indeed they can be added and refined as the application is developed.

At least, that’s the goal. As with everything in computers, things are never that simple and some careful design must go into ensuring that your application’s Behaviors can be executed efficiently. Imagine your application with 50 cars, each with four wheels; that comes out to 200 Behaviors to be scheduled, their WakeUp criteria checked, and their processStimulus methods to be called—potentially on every frame. Not a very efficient way to rotate the wheels on the cars! Perhaps a better way would be to create a single Behavior that could rotate every car’s wheels on the circuit—not as architecturally clean a design but a lot more efficient and scaleable.

Section 11.2 on the Behavior class will describe the capabilities of all general Behaviors and show you with the basics of writing your own Behaviors.