Positioning and Moving the User's ViewpointThe user's viewpoint (sometimes called the application camera) is positioned by the view branch part of the scene graph; its main elements are shown in Figure 24-3. Figure 24-3. The view branch subgraphYou haven't seen the view branch much up to now since it's been built automatically when I've used the SimpleUniverse utility class to create the scene graph. However, I need to attach the gun-in-hand image to the viewpoint and move it around in response to user key presses. The viewpoint is represented by the ViewPlatform node in Figure 24-3 (the triangle) and is repositioned by applying transforms to the TG node above it (TG is short for TRansformGroup). It's possible to add extra TRansformGroups above the ViewPlatform node to implement more complex forms of movements, but I don't need to do that in this example. A shape is attached to the viewpoint by storing it in a Java 3D PlatformGeometry node and connecting it to the TRansformGroup above the ViewPlatform. This is the how I'll place the gun-in-hand image in front of the viewpoint. SimpleUniverse offers access to the view branch via several utility classes: Viewer, ViewingPlatform, PlatformGeometry, and others. You've seen ViewingPlatform used several times to move the viewer's starting position. Viewpoint BehaviorsJava 3D contains several classes that can affect the viewpoint. In previous examples, I've employed an OrbitBehavior object attached to the ViewingPlatform to convert mouse presses into viewpoint movements (see the end of Chapter 15, for instance). Here's an example using OrbitBehavior: OrbitBehavior orbit = new OrbitBehavior(c, OrbitBehavior.REVERSE_ALL); orbit.setSchedulingBounds(bounds); ViewingPlatform vp = su.getViewingPlatform( ); vp.setViewPlatformBehavior(orbit); The behavior is attached to ViewingPlatform with the setViewPlatformBehavior( ) method. ViewingPlatform hides ViewPlatform and its transformGroup and is represented by the rectangle around those nodes in Figure 24-3. When the orbit behavior is linked to the ViewingPlatform, it's being connected to the TRansformGroup. OrbitBehavior is a member of a set of classes for implementing behaviors that affect the transformGroup above ViewPlatform. The hierarchy is shown in Figure 24-4. Figure 24-4. ViewPlatformBehavior and subclassesViewPlatformBehavior is an abstract class that supports basic functionality; it's a subclass of Behavior. ViewPlatformAWTBehavior catches AWT events and places them in a queue. While pending events or mouse motion are occurring, the behavior will wake up every frame and call processAWTEvents( ) and integrateTransforms( ). WandViewBehavior manipulates the transform using a motion-tracked wand or mouse equipped with a six-degrees-of-freedom (6DOF) sensor.
OrbitBehavior is mouse-driven, but FPShooter3D allows the user to control the viewpoint using key presses. Another Java 3D utility class, KeyNavigatorBehavior, does just that. It responds to the arrow keys, +, -, page up, page down, utilizes key presses and releases, and the elapsed time between these key presses. KeyNavigatorBehavior makes use of KeyNavigator, yet another utility class.
A typical invocation of KeyNavigatorBehavior: TransformGroup vpTrans = su.getViewingPlatform( ).getViewPlatformTransform( ); KeyNavigatorBehavior keybehavior = new KeyNavigatorBehavior(vpTrans); keybehavior.setSchedulingBounds(bounds); scene.addChild (keybehavior); KeyNavigatorBehavior extends Behavior, so it requires the ViewPlatform TransformGroup to be explicitly passed to it. The behavior can be linked to any node in the scene graph, and not just the ViewPlatform's TRansformGroup.
KeyNavigatorBehavior is a good choice for programs that need keyboard-based navigation but offers too much functionality for this application. I'll use KeyBehavior later to build a keyboard navigator from the ground up. |