13.3.4 Collision detection
The ability to detect collisions in the virtual world is an important building block for
some of the more advanced UI techniques, such as PTF, the walk-around navigation
technique, and active relational feedback. In all of these, the system is required to
detect the presence of objects in relation to some target object and to act accordingly.
Collision detection in its most general form can also serve as the basis for spatial
change detection, which is a basic requirement for PWO and other visualization techniques,
where view and object motion detection is required.
Collision behavior
The Java 3D collision model is built on the behavior model, and it folds in some of the
concepts established in the picking model. As in picking, geometry bounds are used,
and both bounds and geometry intersection are used. As you may recall from
chapter 11, collision bounds can also be used for colliding. Collision detection uses an
ordinary Behavior object, with special wakeup criteria for collisions that make it a collision
detector. Keep in mind that, because you are using a behavior, you still have to
view-activate it even though the collision you are trying to detect may have nothing to
do with the view. A scheduling bounds with infinite radius might come in handy.
Collision criteria
The spatial conditions for performing the collision detection are established through
behavior wakeup criteria. The WakeupOnCollisionEntry and WakeupOnCollisionExit
criteria discretely detect when a collision condition begins and ends,
respectively. The WakeupOnCollisionMovement criterion continuously detects
when motion occurs between objects that are in collision. The constructors for all
three of these criteria are the same. They allow a single collision arming object to be
specified. Unlike in picking, the arming object can be a leaf shape or a group node.
The constructor also lets you say whether you want collision detection to occur based
on bounds or geometry intersection, with the default being bounds colliding.
Collision targets
A collision event is triggered when the collision wakeup criteria occur with respect to
some triggering object, which can be the result of the triggering, the arming, or both
objects having moved. For an object to serve as a triggering target it must be set collidable
using the Node. setCollidable method. The collidable capability parallels
that for picking, even down to the "feature" where leaf shapes can be set noncollidable
from a group, but they can only be set collidable from the leaf itself.
There are a number of inconsistencies in the collision model when you start comparing
the arming object versus the triggering object. For example, although the arming
object can be a leaf shape or a group node, the triggering object will always be a
leaf shape node. And, only triggering objects can be set collidable; arming objects are
always collidable.
Collision reporting
Collision uses a reporting scheme somewhat similar to that used for picking. Collisions
are reported for both the arming and triggering objects by means of
SceneGraphPath objects, which can be obtained from the behavior's collision wakeup
criteria. Similar to picking, there is a Node. ENABLE_ COLLISION_ REPORTING
capability, which is separate from collidability. Note, however, that collision reporting
only works for the triggering object's SceneGraphPath hit result; the one for the arming
object will always contain just the arming object.
Collision dynamics
Both the collision enter and exit criteria exhibit a type of hysteresis effect where the
first triggering object will cause the behavior to fire, but a second triggering object
won't cause the behavior to fire unless all triggering conditions have first been cleared.
For example, for a collision enter criterion, when an arming object encounters the
first triggering object, the behavior will fire. If while still colliding with the first
object, it encounters a second object, the second object will not cause the behavior to
fire a second time. To make the behavior fire again, the arming object has to first be
clear of all other objects, whether triggering or not. The bottom line is that a given
collision detector can detect only a single collision at a time. This limitation is further
reinforced by the fact that the API returns only a single SceneGraphPath hit result,
not an array of them as in picking.
Because of what appears to be a serious bug in behavior scheduling involving
movement detection in general, the collision movement criterion doesn't work. When
a collision occurs it fires continuously, whether or not there is movement. The implications
of this on the framework are far-reaching, and this accounts for the reason that
behaviors aren't generally used in it except for input sensors (and even then they are
not really needed).
Collision problems
Besides the problems already mentioned, there are a number of outright mysteries surrounding
collision. For example, if bounds colliding is specified, and the collision
bounds is set on the trigger object, then the collision bounds will be used, but only if it
is smaller than the automatically generated geometric bounds of the trigger shape.
With geometric colliding, sometimes the trigger and arming geometry is used, and
sometimes only the trigger's geometry is used. Also, geometry colliding will sometimes
fail to work depending on the relative sizes of autocomputed bounds of the arming
and triggering shapes. More inconsistencies arise if a group is used for the arming
object instead of a leaf. Keep in mind that this information was obtained through
empirical evidence, and collision seems to be rather sensitive to how it is configured.
To say that collision and bounds have problems is an understatement. With the
inconsistencies and vagueness of the API concerning these two areas, the problems
described here concerning collision, and all the problems with setting and computing
geometry bounds, create a real mess. It is no small wonder that tutorials have tried to
steer clear of collision and even picking.
New on the Java Boutique:
New Review:
Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling
API boasts simplicity, ease-of-integration, a well-rounded feature
set, and it's free!
New Applet:
Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA
sequences into three useful formats.
Elsewhere on internet.com:
WebDeveloper Java
Lots of Java information on webdeveloper.com
WDVL Java
Thorough Java resource at the Web Developer's Virtual Library.
ScriptSearch Java
Hundreds of free Java code files to download.
jGuru: Your View of the Java Universe
Customizable portal with online training, FAQs, regular news updates, and tutorials.
| 
