[ODE] trilist strategy

[Gary R. Van Sickle]

> erwin, i've a question about the way in which trilist collision is used.
>
> geom-to-trilist collision does not make any distinctions between the
> inside and outside of an object, correct? so if a geom penetrates a
> trilist object so far that it no longer intersects with the surface,
> there will be no more contact points generated. if the trilist is the
> floor of your environment, you run the risk of dropping straight through
> it!
>

This was what I was getting at a while back.  What happens if the floor is not a
trilist, but a geom, say a very thin box.  It seems you're implying here that
you *wouldn't* fall through.  If that's what you're saying, could you explain
how that works?

> how can a user work around this limitation? is it a real limitation in
> practice?
>

In many applications (such as mine, "The Great American First-Person-Shooter")
it definitely is.  There's a certain commercial FPS (which shall remain
nameless, I wouldn't want the OPERATION which made it to come down on me in a
FLASH on this POINT ;-)) in which you can walk right through the walls of houses
if the framerate dips a little too low or you're walking a little too fast.
Kinda unsuspends the disbelief a little ;-).  I have to assume that's due to
exactly the issue we're considering here.

The only way I can see to avoid this is to keep at least some previous state
around somewhere in case it's needed for collision resolution.  Note that this
doesn't necessarily imply a binary-search for the "exact" point of collision,
but it's the only way I can see that you can possibly know  for sure if a
collision occurred *at all* between two arbitrary geometries between two
possibly-arbitrary-but-consecutive time steps.

--
Gary R. Van Sickle
Brewer.  Patriot.