More collision data

Hi all,

I was thinking about a further improvement to the collision system and that would be to obtain the penetration depth and penetration points on both spatials that have collided.

One definition of penetration points and penetration depth goes like this: The penetration distance dp is the shortest distance that would prevent the two objects from penetrating if one were to translate one of the objects by the distance dp in a suitable direction. The penetration points are the points on each object that just exactly touch the other object after the aforementioned translation has taken place.

Currently, when a collision occurs, i loop N times with each loop having a step size of timeStep/N. Translating the object that has collided towards the penetration surface of the other object by ((afterCollisions - beforeCollision) + afterCollision)/i . Whereby 0 <= i < N (the looping index).

Checking whether the objects have collided again in that loop then finding out the distance between this current position and the position afterCollision (before looping) allows me to find the penetration depth. Then steping forwards intime to the exact point of collision allows me to get the penetration points.

As you probably have gathered, its a long winded way of doing things, not very nice, slow (the number of collision checking per frame), and not accurate as it depends on the size of N. Is there any plans on adding penetration points/depth in the future version of the collision system using mathmatical concepts instead of using convergant sequences?

Thanks, DP

Intresting concept. In general, there are formulas you can use to find the intersection of two moving triangles at a given velocity and direction. I don’t think it can be applied in a generic fashion (not sure). Rather than step sizing an intersection, you could do a binary serach.

Previous frame is totally outside.

This frame is intersecting.

Move to the middle of the two.

Is this one intersecting? If so, you need to move 1/4 out. If not, move 1/4 in. Keep this up and you should have a pretty good answer in probably 8 interations.

Yer, i can do that. However, i really dont want to be doing this with every object in the scene…Think of how many collision checks need to be done every frame! It gets really bad the more objects there are as you probably have guessed.

My current algorithm works fine, its just not fast…neither is the binary search. Im trying to find a way that is faster than it…

I could just find the difference between the two vertices on either trimesh’s and assume that is the depth…but as you can see, its not accurate, and its not the shortest distance that either object has to travel…

I suppose maybe a combinate of maybe 2/3 iterations and the vertex depth have to do…


There are equations that take as input 2 objects, 2 velocity vectors and a time frame. It the calculates what time a collision would occur and what point. This is in Eberly’s stuff, it’s about as efficient as it gets, but it’s complicated math. Some day it will make it into the intersection stuff.

Thinking about it, the verlet integrator will deal with that by itself, there is no need for me to do any of this! :smiley:

The verlet integrator (like in cloth) works by having the difference between two positions (the last and the current). All i need to do is set the old position to be the current one, and project the current position out to the surface, and since the velocity is implicitly given, the object will fly away with the correct velocity! I think…

However, i still need to obtain the penetration depth as that will be used for friction calculation (surfaceTanginalForce.substract(dp)), but as the verlet integrator itself is not accurate, there is no need for the penetration depth to be accurate also (a rough distance between the two vertices should suffice). But thats not till much later, so i can postpone this.