Collision Detection and Penetration Distance

This topic is 4554 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

I notice a lot of collision systems return the collision normal and the collision point but not the penetration distance. In order to calculate collision response do you HAVE to have the collision distance, or are there other ways of doing it? Do these systems expect the calling code to calculate the penetration distance somehow? Seems like you would be doing the work twice if that was the case.

Share on other sites
You may or may not need the penetration distance depending on how you want to resolve your collion. If you are using a simple method, for example mirroring the velocity and returning the object to it's original position, then you don't.
If you are doing anything where forces will be acting on an objects over time (eg, anything with gravity, or where you expect lots of objects to push each other) then you will need the penetration depth in order to resolve the penetration, while your collision point, velocities, etc, will be used to resolve the final linear and rotational velocities of the objects.

You probably shouldn't be trying to calculate the penetration distance in your collision response code. If you just get your collision detection code to work out the collision point, normal, and penetration depth, and then store them all somewhere for the collision response, then you only have to do the work once.

Share on other sites
To answer your question: Do you HAVE to have the penetration distance?

not at all. You do need to know whether or not you have penetration at the end of the frame, though.

If you have the collision point and collision normal, you have enough to run the impulse through and get a response from the bodies. Of course, finding that collision point and the normal may take some time.

However-- you have to have the position of the bodies *before* the collision, or else you might not be able to clear the bodies from one another.

I strongly recommend that you keep track of each body's original position, and run a 'test update' of updating and checking for collisions. Should you have a collision, resolve it using the original (pre-integration) positions and velocities. This will allow you to have bodies rest on surfaces (body *would* fall, which *would* make it collide, so we reflect the body, which *orginally* wasn't moving, so it acquires 0 velocity into the plane, but picks up full tangential velocity (adjusting for friction).

Fedkiw et. al have a nice paper on the method. Check out Fedkiw's site at:
graphics.stanford.edu/~fedkiw/

best of luck!

Share on other sites
My physics engine does not return the penetration distance, but it does return the T that the collision occurred at. 0 <= T <= 1. My physics engine internally uses this value in order to iteratively bring the T closer and closer to 1. The iterations are fast, by storing a list of all possible pairs of object boundaries to check, and then ordering them based upon time of last collision. This way, iterations are very fast, and I never have penetrations. Objects within epsilon distance from each other are marked as 'touching'. I feel that penetration resolution methods cause problems for objects that remain in full contact with each other. Then again, that method doesn't consume the amount of memory that my method consumes. Eh, oh well. :-D

1. 1
2. 2
Rutin
18
3. 3
4. 4
5. 5
frob
12

• 9
• 21
• 13
• 9
• 17
• Forum Statistics

• Total Topics
632608
• Total Posts
3007391

×