Rag doll tutorial

Typically you use/write a generic rigid-body physics engine that is able to set up constraints (e.g. hinges) between bodies.

You represent your skeleton with a physics "proxy" - i.e. a simplified structure made by linking boxes/spheres/capsules (i.e. "limbs") with certain constraints (hinges, ball n socket joints etc). This physics proxy does not need to have all the joints that your original skeleton has - it may even behave quite badly if it does.

Then you need to do two things (in a way the hard part):

1. Work out how to initialise your physics proxy based on the current animation state - for blending into ragdoll.

2. Work out how to drive your skeleton (i.e. take over from pre-calculated animation) using the physics proxy.

Some games (flatout) seem to use the actual position/orientation of the "limbs" (e.g. "upper-leg" or "head") to set the position/orientation of skeleton bones, but that can cause problems when the constraints get temporarily violated (I've seen a flatout ragdoll get stretched around 10m!), so I don't like this. I've got good results by just using the angles between "limbs" and skeleton bones to convert from one to the other.

I advise you to steer clear of the Jakobsen/Advanced Character Physics paper, which you will probably get pointed to :) There are some papers around but I don't have anything with me currently (just moved house/jobs). Really you just need to be able to simulate articulated bodies.

I agree with your points though the message makes it sound like the constraints part is pretty trivial. In practice, I think that requires quite a lot of work to even get somewhat decent practical results.

The blending to and from kinematic animation data is not much of a problem once the constraints and RB dynamics are worked out. At least for ragdoll (dead characters) that is. If you want them to move with motor controllers and such, you have some more difficulty.

But to answer the original question, there is good robotics texts that will teach about rigid bodies and constraints. But most game articles and books skip it because it is so difficult. Mr. Rowl gives good advise in saying if you want to write your own physics simulator that can handle joints and springs, start with a rigid body simulator. Worry about the linked systems later. Get a good robust system going first. These are easy to work with and you can add springs between the bodys very easily. Chris Hecker's articles and demos are a good source for this.

For the constraints, there are several methods that certainly merit another thread worth of discussion. The ones I think are worth considering are:

1. Iterative impulse methods - If you have read the Jakobsen stuff, it is similar. Iteratively apply impulses to attempt to enforce constraints. These are pretty easy to set up but in practice IMO seem limited, somewhat inaccurate, and inefficient for serious game work. I found it particularly hard to enforce joint limits without adding extra simple constraints all over. I would be interested in hearing of success stories in actual projects though.

2. Lagrangian multipliers. Chris Hecker has given a GDC talk on this method. I believe this is what many commercial engine use but they are difficult to set up (at least for me) and require a pretty big set of linear system tools.

3. Featherstone's Articulated Body Method. There was a paper from SCEA at GDC 2004 about this and there is a lot of robotics literature. But I think this system really deserves a good article and set of demo apps. Perhaps I will get around to it sometime. If anyone knows of good links, let us know.

There are certainly other options, but those are what I know. Having played with them all, I think 3 is the way to go personally with 1 being the way to get something up and running pretty fast.

For anyone else that have done constrained rigid body systems, what methods have you used?

Brian Mirtich has a nice section in his dissertation on the Featherstone algorithm and he had some code available too.

Quote:

Original post by JeffLander 1. Iterative impulse methods - If you have read the Jakobsen stuff, it is similar. Iteratively apply impulses to attempt to enforce constraints. These are pretty easy to set up but in practice IMO seem limited, somewhat inaccurate, and inefficient for serious game work. I found it particularly hard to enforce joint limits without adding extra simple constraints all over. I would be interested in hearing of success stories in actual projects though.

For information... I implemented this on PS2 (basically a port of my jiggle demo) and the cost was around 12% of a 60Hz frame per ragdoll (using 10 "limbs" per ragdoll), including collision detection - it looked pretty good too - better than other implementations (tho I say so myself!!) because (1) the joint limits _were_ slightly soft and (2) any inaccuracies in the constraints get hidden by using only angles to update the skeleton.

For comparison Havok claims to be able to run 10 ragdolls on PS2 (without indicating the complexity or whether that includes other code etc). About half of my cost was collision detection (fairly complex environments), so my reckoning was that even if I'd implemented a fancy solver it could have only have cut the total cost by a little bit - maybe 25% - at least within the framework I was working in. Also, this ran entirely on the main CPU - not using the vector unit (unlike Havok).

I'm not saying it's the best way for all games, but in the right situation it gives a pretty good tradeoff between quality, execution speed and coding/debugging time.