The other way to handle this is to use multiresolution grids. You place
your objects into your world and "register" them into your own data
structure. Registering them is basically placing the scene graph "piece"
into the grid (and of course you can use a more 3 dimensional octree for
inside). Your sorting tree nodes are bounded by volume. This means that
every object lies within the volume bounded by that node in your tree. You
can quickly and easily find the node in your tree which corresponds to the
location of your moving object. Then when you are about to move that
object, perform the transformation in a dummy transform, and transform a
bounding box you have assigned to that object. Then find the location in
your tree which is handling the space where the transformed object lis being
moved to. Then run through all the registered shapes (recusively if
necessary) and check for overlaps (using the nice bounding methods provided
by Java3d). If there is an overlap, return that information to the moving
routine, which can then "deny" the move or alter direction (bounce).
Obviously you might have solid objects crossing bounding volumes, so you can
either scan sibling nodes, or better yet use a "loose" octree, which creates
its bounds appropriate to the objects. You can also register the same shape
in all the nodes where it crosses.
Fast and you do not get the "post collision" syndrome where you get jerked
backward after entering a solid object.
p.s. I highly recommend the book called Game Programming Gems, published by
Charles River Media and edited by Mark DeLoura. They cover a lot of neat
things like this.
Dave Yazel
----- Original Message -----
From: Justin Couch <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, September 19, 2000 7:42 PM
Subject: Re: [JAVA3D] Collision Detection Challenges
John Wright wrote:
> What I believe most of us are doing in order to have accurate collision
> detection is to use picking to detect collisions. For instance in our
> application the avatar sends out a pickray in the direction it is
> walking *before* it moves to make sure it's a valid move.
This is even more generalised to do terrain following etc too. I've seen
a couple of J3D projects do this on a small scale and it seems to work
quite well.
--
Justin Couch Author, Java Hacker
http://www.vlc.com.au/~justin/ Java 3D FAQ Maintainer
http://www.j3d.org/ J3D.org The Java 3D Community Site
-------------------------------------------------------------------
"Humanism is dead. Animals think, feel; so do machines now.
Neither man nor woman is the measure of all things. Every organism
process data according to its domain, its environment; you, with
all your brains, would be useless in a mouse's universe..."
- Greg Bear, Slant
-------------------------------------------------------------------
===========================================================================
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".
===========================================================================
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".
