|
|
 |
 |  | | | | |  | |||
 | ||||||
          |  |  | ||||
|
Contact PhysicsAccuracy and StabiltyIt's quite common in contact physics applications to see objects which should move smoothly or settle down quickly, instead shake, wobble or jump into motion. There are two common causes for this behaviour. 1. The solution is wrong. Or not quite correct. This is common when the iterative scheme for finding the forces either can't reach a solution, or stops too soon. The short answer is to do more iterations - but there will be a speed issue. 2. The properties of the physical system can't be well-modelled at the framerate. One way this happens is if you've put some unrealistic values in your mass matrix (having moments of inertia too small for the object's size and mass is a frequent mistake). Friction can do this as well, if your friction coefficients are large enough that they more-than reverse the object's motion between one frame and the next. Physically realistic friction values will do this in many simulations. Sometimes, programmers will solve No. 2 by having multiple physics iterations for each game frame. Please don't do this, there's almost always a better way. Linked Objects
We've so far covered contacts between single, 6-d.o.f. bodies and a static world. But a lot of games need linked systems of bodies, for instance using a "ragdoll" model for realistic death animations (see Figure 5). There are two approaches you can use here: 1. Treat each part of the hierarchy as a separate body. Then define special contacts between the bodies at the joints. We would have a contact for, say, the hip-joint, which can have positive or negative forces, limits rotation, and acts in all directions. Using this method, you can use the techniques outlined above, but you will probably need a good iterative scheme, as you will be solving for, well, a lot of forces. 2. Treat the whole hierarchy as a single object. The object will have, not 6, but maybe 26 degrees of freedom. Calculating the mass matrix will be a daunting task, but with this method you won't have to worry about limbs stretching and detaching when too-big an impulse is applied. FrictionFriction should be applied between nearly all contacts. Generally, if there is a sideways velocity between the contacting points r1 and r2, dynamic friction is:
where mdynamic
is the coefficient of dynamic friction, Fnormal
is the contact force Nf and Generally, mstatic
is larger than mdynamic -
for example, a car's tyres on tarmac might have a static friction coefficient
of 1.5, and a dynamic friction of 1.2. So you'll get better turning force
if you stay in the static friction zone - or better braking if you don't
lock the wheels. You can see this effect in action in WRC - on tarmac
you can keep the vehicle just on the edge of the static limit, but on
gravel or snow you'll be in the dynamic zone most of the time. Types of ContactI've so far discussed only one geometric type of contact - of a point and a surface. Many games only use this type, but to fully model your objects as polyhedra, you'll need edge-to-edge contacts as well. Then the contact direction N is determined by the cross product of the edge directions. Most of the derivations are a little more involved, but the same principles apply as above. You can also implement curved surfaces. For each contact type (sphere-surface, point-cylinder, I could go on) you'll need an expression for the line of the b matrix (or three lines if you're including static friction). Rolling contacts are particularly tricky for all but the simplest types. Final WordsA good place to start could be an impulse-based system that only ever has one contact at a time. Once you're happy with that, try multiple contacts. With only one or two, you will be able to get away with using the matrix inverse. When you get to having fairly complex systems like the ragdoll, it's worth trying an iteration scheme. For anyone serious about game physics, the place to go next is David Baraff's page [1], where you can download some of the major papers on the subject. Chris Hecker [3] offers a more game-centric summary and a good overview of the field. You should now be well on your way to some rock-solid contact physics, though it's a perilous road. Some programmers have had good results with approximate methods, like the Verlet particle systems described in [4]. Alternatively, there are several middleware packages which effectively provide a plug-in solution for dynamics. Unless you find the cost prohibitive or really want to do something new in physics, these are well worth a look. Game graphics are fairly racing ahead, and if the physics we use can keep pace, creating new and captivating experiences for gamers should be well within our grasp. References[1] David Baraff's homepage: http://www.pixar.com/companyinfo/research/deb/ [2] David Baraff, "Analytical Methods for Dynamic Simulation of Non-penetrating Rigid Bodies", Computer Graphics, Volume 23, Number 3, July 1989. [3] Chris Hecker's homepage: http://www.d6.com/users/checker/dynamics.htm [4] Thomas Jakobsen, "Advanced Character Physics", Gamasutra Game Physics Resource Guide ________________________________________________________
|
|||||||||||||||||||||||
|
|
Resource
Guide 
(17)
is the unit vector in the "scraping direction". Note how even
if the relative velocity is small we can still get a big force, and that
can lead to the stability problem I mentioned earlier.