Would ray tracing not be a form of distance based intersection testing though?

Not necessarily. You can have a ray-object algorithm returning just TRUE-FALSE for culling, and a separate ray-object algorithm returning data needed.

However, multiple ray-casting can still lead to missed hits. A "swept volume" method, perhaps using bounding volumes in broad-phase, would likely provide more consistent results.

When used for broad-phase culling, that method can be implemented as a TRUE-FALSE test (faster). Then iterate through the list of hits using a more refined test, calculating the parameters you need (such as distance, hitpoint, surface normals, etc.), and perhaps using more refined shapes for the test - again, depending on what data you need.

I'm gona go with distance based methods, I don't like what I see from intersection methods; might pass over & difficult to create a dependable response.

Problem with distance based methods is calculating distance using linear shapes with rotation & then create a rotation in the collision response.

I'll just have to use spheres to approximate,

cheers

I've implemented both approaches. I was surprised to find that the "intersection method" is far easier to get working in a robust way because it is entirely based on handling overlap. In the other approach overlap is a failure case that you must prevent. This becomes tricky when handling contact, i.e., zero distance intersection.

Preventing "pass through" with the intersection method is usually handled by updating an object using substeps of the total time step based on its velocity and bounding volume size. This impacts performance only for small and fast objects (in which case you can probably get away with raycasting).

Of course implementing your own collision/dynamics rarely makes sense these days. I'm assuming you have a good reason for not using Bullet or some other SDK.

Hi BFG,

my game is all about speed of small objects so the type of scenario you described.

Is distance based not about calculating the distance to an object, using the velocity to determine the time & generating the response for the remain time?

My game is so simple using Bullet is more complicated than rolling my own. Also these Open Source libraries are supported 1 day & dropped the next

Bullet is not getting dropped any time soon. You would have to be doing VERY simple physics for your own approach to be easier than integrating Bullet.

Continuous Collision Detection is the term you are looking for. These are approaches that avoid "tunnelling" when fast moving shapes miss on intersection tests.

It's a very complex area, especially for objects that are translating and rotating

But for very small objects, a raycast is often sufficient. This can be simple to implement against triangle based meshes, harder against implicit shapes like spheres, cones etc.

Cheers Aardvajk,

I will investigate Bullet SDK if I make a next version of my game

Been thinking, going to use Bullet SDK like you guys suggested.

Realized if I roll my own I won't be able to upgrade or update my code easily if I need a new feature.

Cheers for the advice!