[ODE] Dynamic mesh collision

[Pierre Terdiman]

(ok, list response this time, then)

In short, "forget it" applies to the scenario where you need
penetration-depth-based contact generation between a deformable mesh and a
static mesh. This, I'd forget about.

Now, point-based approximations are fine indeed. Probably.

> Is it difficult to do point-vs-mesh checking? Wouldn't that just be a
> simplification of sphere-vs-mesh?

It's not just like sphere-vs-mesh. If your timestep is too large, the sphere
falls accross the terrain because the collision has been missed (tunnelling
effect, bullet-vs-wall problem, etc). A point would be a sphere with a zero
radius : you'd always go through the terrain, missing most (if not all)
collisions.

Point-vs-mesh is usually resolved using a distance query, looking for the
shortest point-triangle distance. Opcode 1.3 does this, actually. But
distance queries are slower than their collision counterparts. Anyway you
could take advantage of the terrain's nature (heightmap) to use a dedicated
solution. For example, Havok has a "raycast car" that just fires vertical
rays at each tire locations, towards the landscape. Those ray-casts (already
in Opcode) are faster than distance queries. They don't give the "shortest"
distance, but they're good enough for collision response (actually, probably
better). So yes, you could do multiple raycasts starting from each vertex of
the tire. There are many ways to optimize this I guess.

> But problems may arise when I have to
> check a lot of individual points against the same mesh, maybe?

It also gives birth to optimizations, using spatial / temporal coherences,
etc. You can also bound all points with a sphere or a box, do a box-mesh
query, and only perform subsequent point-queries against what was in your
sphere/box. Etc, etc, etc, etc.

- Pierre
www.codercorner.com