[ODE] penalty method

[Bergen, G.J.A. van den]

The stiffness of the differential equations and the fact that the penalty
forces rely solely on the position of the objects (not the velocities)
demand that you use an integrator that does not amplify its own errors. Wu
uses implicit Euler as integrator, which he claims keeps the system from
exploding. Also, care should be taken not to add energy to the system by
placing exerted springs on interpenetrating contacts, so either you have to
determine the exact time of collision, or you'll have to allow that objects
are interpenetrating to some extent. Inserting exerted springs to a contact
(especially when using non-linear springs) causes your objects to go
ballistic. Penalty methods are mostly useful for spongy objects (See Jeff
Lander's GDM articles). John Nagle is using a (patented) penalty method for
rigid bodies in Animats, but his approach is not really useful for
interactive applications.

Gino  


> -----Original Message-----
> From: Pierre Terdiman [mailto:p.terdiman@wanadoo.fr]
> Sent: Wednesday, October 23, 2002 9:57 AM
> To: ode@q12.org
> Subject: Re: [ODE] penalty method
> 
> 
> > > 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
> 
> 
> _______________________________________________
> ODE mailing list
> ODE@q12.org
> http://q12.org/mailman/listinfo/ode
>