Creating the Scene


Forward and Inverse Kinematics

Before talking about forward and inverse kinematics, it's useful to review the parent-child relationship utilized by the nodes in a Java 3D scene graph. This hierarchy is particularly important for sequences of TRansformGroup nodes.

Figure 20-6 shows a simple hierarchy made up of a parent and a child transformGroup. The parent holds a translation of (1, 1, 2), and the child a translation of (2, 3, 1). However, from the world's viewpoint, the child's translation will be (3, 4, 3), a combination of the parent and child values. Here, the combination is an addition of the local translations, but it becomes more complicated when introducing rotation and scaling elements.

Figure 20-6. A hierarchy of TransformGroups


In general, the world (or scene) view of a transformGroup is a combination of its translation, rotations, and scaling with those of its ancestors (parent, grandparent, and so on).

This hierarchy is important when developing an articulated figure since each limb contains several TRansformGroups, and the connection of limbs to make the complete figure creates a large hierarchy of TRansformGroups. The consequence is that when a limb is moved (by affecting one of its TRansformGroups), the limbs linked to it as children will also move.

This top-down behavior is at the heart of forward kinematics, one of the standard approaches to animating articulated figures. For example, the rotation of a figure's chest can cause its arms and head to turn even though the bottom and legs remain stationary. From a programming point of view, this means less explicit manipulation of TRansformGroups but requires the arms and head are connected as children to the chest's TRansformGroup.

Forward kinematics is especially useful for movements that originate at the top-level of a figure and ripple down to the lower-level components. An everyday example is moving a figure: the translation is applied to the top-most TRansformGroup, and all the other nodes will move as well.

Forward kinematics is less satisfactory for operations that start at lower-level limbs and should ripple up. For instance, the natural way of having a figure touch an object in the scene is to move its hand to the object's location. As the hand is moved, the arm and torso should follow. Unfortunately, this would require that a child transformGroup be able to influence its ancestors, which is impossible in the parent-child hierarchy used by Java 3D.

This ripple-up animation technique is called inverse kinematics and is a staple of professional animation packages such as Poser, Maya, and 3D Studio Max. Important low-level nodes are designated as end-effectors, and these influence higher-level nodes as they're manipulated. Typically, end-effectors for an articulated human are its hands, feet, and head.

Inverse kinematics has problems specifying top-down effects, so it is often combined with constraints that link end-effectors to other nodes. For instance, when the body moves, the end-effectors can be constrained to stay within a certain distance of the torso.

A good nontechnical introduction to forward and inverse kinematics is Steve Pizel's article "Character Animation: Skeletons and Inverse Kinematics," online at http://www.intel.com/cd/ids/developer/asmo-na/eng/segments/games/resources/modeling/20433.htm.

As far as I know, no Java 3D examples use inverse kinematics. The FAQ at j3d.org contains a few links to discussions of how to implement inverse kinematics in procedural languages (http://www.j3d.org/faq/techniques.html#ik).


Forward Kinematics in Mover3D

The Mover3D application in this chapter creates a figure by linking Limb objects together in a parent/child relationship. As I'll explain in detail, each Limb object is a collection of transfromGroup nodes (and other things) forming a complex hierarchical scene graph.

Limb movement is a matter of translating or rotating transformGroups in a limb, and changes to those nodes will affect all the child nodes below it (i.e., the child Limb objects). In other words, Mover3D uses forward kinematics.



Killer Game Programming in Java
Killer Game Programming in Java
ISBN: 0596007302
EAN: 2147483647
Year: 2006
Pages: 340

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net