Hi Guys,

I've been reading about 3d collision detection, 1st time doing it, I see there are intersection & distance based methods. What do you recommend? Any suggestions?

cheers

It depends on the complexity of what you are colliding with. If the object is a simple low poly mesh you can get away with polygon intersection methods. For anything with lots of polygons you should probably use a bounding box or sphere, or have a separate low poly collision mesh. In my game most things are square so it makes collisions simple...
Bear in mind any collision mechanism based on polygon interception is generally quite computationally expensive compared to bounding boxes.

Hi braindigitalis,

problem with using square shapes is calculating the collision points & appropriate collision response including rotations, this is quite complex would you agree?

problem with using square shapes is calculating the collision points & appropriate collision response including rotations, this is quite complex would you agree?

Your original post asked about collision detection techniques. Collision response is an entirely different subject than collision detection, though the collision data needed for desired collision response routines dictates how collision detection is performed. For some purposes, a YES-NO intersection test between bounding volumes is quite sufficient.

What do you recommend? Any suggestions?

First: determine what data you need to perform whatever collision response or physics calcs you want. There are several collision/physics engines available (Bullet, ODE, etc.), or you can roll your own.

Cheers Buckeye,

intersection techniques seem like a hack to me, don't think they can provide an accurate collision point due to objects moving at different linear & angular velocities, distance based seems the way to go but seems like the maths is more complex

Intersection techniques are reliable and accurate. They work by taking a dot product of the normal if i remember correctly (i don't retain the maths, i write the function once and remember the function name). This is slow and relies on having correct winding order of polygons, but this shouldn't be a problem as winding order is important for other things such as back face culling etc. It certainly is not a hack and is mathematically proven and works, the problem is just the time taken to do it with high polygon count models...

For most applications a discrete collision system works fine, meaning you do nothing to predict a collision within the next frame and avoid all overlap, instead you check at each frame what objects overlap and by how much then correct the overlap and do any slides and bouncing as necessary.

Some terminology that might be useful in google searches
Separating axis theorem - States that two concave shapes do not overlap if there exists a plane that can fit between the two shapes
Minimum translation vector - When two shapes overlap, this vector is the shortest vector used to offset one of the shapes to correct the overlap

Each pair of shapes will need different code to test for overlap. You will need one function for sphere box collision, another for sphere triangle, and another for triangle box.

What if the 2 objects are moving so fast the collision is not detected?

Intersection won't detect it

Are you referring objects moving at velocities where the velocity of the first object is more than the dimensions of the second object so it would appear to "pass through" it? If so you could use a traced ray tracing it's path and see what the ray intersects. Several rays would make it more reliable if necessary...

Yeah I meant "pass through" like you said. Would ray tracing not be a form of distance based intersection testing though?