|
|
CuppoJava wrote:
Thanks for replying Mr.Chapman
I Completely agree with you. ONLY an iterative method will work for the second situation. and ONLY a simultaneous calculation will work for the first situation (the bigger block hitting the two smaller ones). But how do I choose between the two?
But you see the problem now right? I wish I could contact Baraff directly or something, it seems this is an unsolved problem in this field but no one has even mentioned it in their papers.
I believe you can reach David Baraff here: http://www-2.cs.cmu.edu/~baraff/ (see the Pixar email address).
Many times there are no published solutions to problems (that does not mean they have not been solved). After viewing your diagrams, I'm surprised IBF didn't repond with:
THINK OUTSIDE THE BOX
which wouldn't be bad advice. Think of a way to solve the problem so that you get the desired visual result, not thinking about physics per se, just the desired behavior. Write some code, experiment.
As Danny stated, you don't need an LCP solver. Always consider the simplest methods first. You can deal with multiple contacts in (at least) three common (and relatively easy to implement) ways:
1. Apply impulses pairwise and immediately update the momentum for each contact pair's body. Not "exactly accurate" but totally stable and very fast. Perfectly suitable for games.
2. Store all contacts and apply a single, weighted impulse to each body. Can be energy accurate. Weighting based on momentum in the direction of the contact is a good weighting method.
3. Apply just one impulse per contact pair (using the deepest point, first contact point, etc.). Fastest, easiest to implement and perhaps oldest method. This method can jitter for resting objects (unless sleep code is implemented or other trick is used).
Game engines typically combine one of the above methods with a penalty spring or iterator/separator to keep objects from over-penetrating. This will give you plausible behavior for most types of games. Once you are at this stage, you'll find that the problems you listed aren't really problems (you'll also find that your above statement(s) aren't exactly accurate).
If you need perfect or near-perfect response for your example problems (for a specialized, physics-based game where such behavior is required for gameplay (pool/billiards-like game)), you can optimize your physics engine to (for example) sort and propagate, iterate (finite element deformation and restitution: "nothing in real-reality is truly-rigid"), etc. Otherwise, use one of the simpler methods, or invent something new!
(If you don't need a general solution, the problem is often an order of magnitude easier to implement for your specific case(s)).
|
