[ODE] penalty method

[Pierre Terdiman]

> > I am
> > talking about David Wu's gdc talk. Has any one actually implemented his
> > method? Not trying to start a fight here, just going through all the
> > alternatives...
>
> I don't know what Mr. Wu had to say, but penalty methods have a built-in
problem
> that is essentially intractable: they, by definition, lead to stiff
systems of
> differential equations.  Collisions and resting contact are either too
squishy
> or your simulation blows up or both.

Penalty methods have a bad reputation indeed. And for pretty good reasons.
But this is not a black-or-white situation where one can simply discard them
completely. Even if I'm alone on that one, I'll say they *are* a good
alternative in particular cases, especially in games. Let me summarize what
I think are the pros and cons.

Cons:
- unstable as soon as you connect bodies with springs
- implementation of resting contacts borders on voodoo magic
- stacked objects and all joints are pretty difficult to handle
- you'll need a small timestep indeed

Pros:
- each iteration is extremely fast
- you can solve each contact on-the-fly, which is great on consoles since it
doesn't require any stack memory (see the recent post about the 10 Mb stack
in VC++. No way you can do that on a console.)
- handle 200~300 simultaneous contacts without any (speed) problem
- you *will* need it anyway as a fallback when the LCP solver fails (that's
what they do in Havok AFAIK)
- they're good enough to handle common game situations, and that's the key
point. Many great games with great physics have been using nothing more than
penalty methods (especially japanese games - on top of my head the last good
example was Wreckless on X-Box)


They're "bad", but sometimes they're the right tool for the job IMHO.

Some lame tests available here (I probably didn't upload the most convincing
scenes anyway) :
http://www.codercorner.com/Rigid.htm

Pierre