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

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

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!