I'm no 3D expert but from what little I've read I would think you would have to take the vectors of the objects into consideration, depending on the types of objects that are colliding. If the objects are the type that rebound, once you've done the collision checking they should be moving away from each other and you no longer need to worry about it. If the collision is resulting from, say, a player charging into a wall, you don't really need to do anything since you're collision code should know that the wall is an impassible object.

Maybe I'm totally wrong though! This is just a guess. I really need to get into 3D stuff soon.

One option you might consider is dot product checking: if the objects are going to collide then the dot product of at least one of the objects' velocities with the vector between that object's centre and the other object's centre (ie targetObjectCentre - movingObjectCentre) will be negative. This is the analytical solution, however, and hence not very fast. I believe it is guaranteed to work, however - provided that all your collisions are external - and if you're eliminating as many tests as possible by space sectioning and so on it may be sufficient. For an internal collision (ie one object inside another) it would be necessary to solve for the exact collision point and then use that point instead of targetObjectCentre in the above code.

Anyway.

signing off,
mikey.

I'm using an axis-aligned bounding box collision algorithm to do collision detection for my 3D program, but I'm encountering the following problem. As two objects get very close to each other, they eventually touch, causing the program to think that they are constantly colliding, and sending the program into an infinite loop resolving the collision. What are some options for dealing with objects "touching" each other or keeping two objects from technically touching each other?

Thanks.

The process should be something like the following:

1) Check for overlap, if yes goto 2

2) Issue collision event and re-position one or both of the objects so that they no longer overlap. (This is best done by moving them backwards along their movement vectors to the last point where the overlap test fails)

Asuming the objects are no longer moving, they'll not overlap again, and 1) will yield false on the next test..

The problems most people have with this is caused by floating point in-accuracy, so you might want to use a "very small" value X and replace all floating point equality comparisons

if(f1==f2)

with:

if ( abs(f1-f2)/Niels