This is a pretty good synopsis of the overall features of the different
collision alternatives. I have a couple of comments on this. I'm sending
this to the interest list because some of the comments relate to behaviors
in general.
Behaviours Background
In Java 3D's architecture behaviours act as a
semi-synchronous mechanism for feeding back to a user
information about the state of the scene. For instance
you can use these to wake up a piece of code each
rendered frame, have it makes some changes to the
scenegraph and then go back to sleep again. What happens
in the behaviour is reflected in the next rendered
frame. Here is where users tend to loose the connection
between expectations and code.
Part of the disconnect here is that behaviors should be thought
of as completely asynchronous from the rendering. The only wakeup
crtiterion that gives any flavor of being synchronous is
WakeupOnElapsedFrames(0). Once this is accepted, then it becomes more
clear that the Collision wakeup criterion are asynchronous.
How the above paragraph should be read is: Something
happens in a frame, a behaviour is then notified, it
makes some changes, exits and then the next frame
happens. According to the specification, there is no
guarantee that if the behaviour is called it will effect
the current frame. It is possible that with dual
threads, the current frame start will trigger the
behaviour thread, which will then act independently of
the renderer. How the changes make it from one thread to
the other is not guaranteed. The safest bet approach for
this is that the changes will be visible in the next
frame rather than the current one that we are rendering.
How Collision Behaviours are Triggered
The most important clue from the above behaviour
information is that a frame is rendered while the
behaviours are being called. What that indicates is that
a collision will be detected during the current frame
and your behaviour code will be notified. Effectively
the behaviour here is acting as an Observer pattern
rather than a Command pattern. Something has already
happened and all your code can do is respond to it,
rather than having any ability to control what rendering
code is going to do. The collision has already happened
and now you have to deal with it.
For fast paced rendering such as FPS games, it is quite
possible that your viewpoint could walk straight through
the middle of a wall in a single frame. The collision
with the wall object has already occurred, the rendering
system has rendered this fact and now you are left to
deal with the pieces. In a real game you want to
guarantee that the collision is detected before the
rendering step rather than after or during it - when it
is too late already. The key behaviour keyword here is
"entry". The behaviour notifies you when your viewpoint
has entered the collision area. Assuming an infinitely
thin wall between being inside and outside the collision
area, there is no way you could ever be "just" colliding
in the way that games will show. A single frame could
move you from 0.1 unit outside the collision area to 0.1
unit inside it and you have no way of adjusting for
that. What you really need is the ability to pre-empt
the movement, calculate how far you would be allowed to
move in the next frame and only allow that amount of
movement.
Detection Algorithm
If you want to know how efficient the collision
mechanism, this section details the actual algorithm
used within Sun's implementation of Java 3D. For most
users, it probably won't be useful, but for the high-end
people that want to know how much impact the collision
detection has on the overall performance, read on. The
information here has been gained from several robotics
people asking for further information and the answers
supplied by the Sun engineers. For most general users it
is probably safe to skip this bit and head to the next
section on how to implement a useful Java 3D collision
system.
Wheat and Chaff
Collisions are considered a form of behaviour, so the
first thing that the runtime does is organise the data
in spatial groups. The viewpoint has an activation
region surrounding it, and each of the objects marked as
collidable have a region surrounding them. If these two
areas intersect then these are added to the list of
active areas to watch for. There is no point trying to
detect collisions with an object 1000 units away if you
are only 1 unit wide.
[Image]
Figure 1: The basic collision areas and the user views.
The grey areas are removed from the collision detection
because they do not intersect with the user's view area
To do this first part relatively quickly, J3D uses a
spatially organised tree (which is apparently used for
all geometric operations - behaviour culling, rendering
culling etc) which I suspect is some form of quad tree
(no details have been given). The efficiency is
dependent on how well balanced this tree is ie how well
objects are distributed around the virtual world
relative to the user's position and how many child items
are there.
This description is sort of correct, but let me be a bit more specific.
Collisions are "triggered" as a part of the Behavior system. Each ViewPlatform
has an activation radius. Each behavior has a scheduling region (bounds).
When a behaviors scheduling region intersects with any ViewPlatform's
activation radius, it may be scheduled. Note that all of this is generic
to the behaviors system, and has nothing to do with collisions. I believe
this is what is alluded to in the Figure 1 section above.
Once a behavior is schedulable, its wakeup conditions become active.
Once the behaviors wakeup conditions have been met, while it is schedulable,
it is actually scheduled for execution by the behavior scheduler. So, for
collision, the armed collision (via WakeupOnCollisionXXX()) is only looked
for when its behavior is schedulable. Once the collision is armed and
active, it is tested for collision against all of the geometry in the
scene graph. It is at this stage where we need our spatial hierarchy of
all the geometry in the scene graph. This spatial hierarchy is currently
an axis aligned bounding box tree.
I hope this helps clarify how collision fits into the Java 3D system.
Doug Twilleager
Sun Microsystems
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA3D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
