[ODE] Geometry passing through / timestep size

[Chris Campbell]

The thing with how ode responds to collision is that you need to have
geometries embedded in each other to find a penetration distance. If an
object passes right through another, but is not embedded at the before/after
timesteps, there is no penetration etc.
My suggestion to fix... well... hack this would be:

Keep track of the last position the body was at.
After each timestep, use the lastPos-to-currentPos to check if there was a
collision (not penetration!).
If so { 
      Move the body back to the earliest collision point.
      Make up a contact joint for it, hardcode penetration to a very small
value.
}

This may mean you have to write some of your own collision routines, but it
will cure the passing through problem nicely. Since you only need one
contact for the body (the earliest collision), it's a bit less load on ode's
solver.
There are drawbacks of course. It's a bitch to find that earliest collision
point for anything other than a sphere. Since you always set penetration to
non-zero, bodies will slide slowly down slopes even when the friction should
be keeping them still. Finding the right collision point for moving bodies
which collide during a timestep is... non-trivial.
Anyway the point is that doing this is not suitable all the time. I do it
because my body moves fast, has few collisions and passing through geometry
is not acceptable (pod-racer type game). However where it is reasonable to
place a hard limit on how far a body can move per timestep (walking human)
ode's standard penetration-from-embedded-state is of course best.
Hmm... I still haven't decided how to mix these though, say if pod-racer
collides with human... ouch :)

> -----Original Message-----
> From: Clay Larabie [mailto:c-larabie@rogers.com]
> Sent: Friday, August 02, 2002 1:38 PM
> To: Erwin de Vries; ode@q12.org
> Subject: Re: [ODE] Geometry passing through TriList
> 
> 
> What are your suggestions if I wanted to fix this?
>