Applying torques for character animation

[seabert]

Hello,

I've been working on implementing a paper on dynamic data-driven character control. (http://graphics.cs.williams.edu/papers/DynamoVGS06/)
The basic idea is to create rag-dolls and put them in certain positions by applying world space torques, which are computed by comparing the rag-doll's bone orientation and that of the desired position.

For this I created a rag-doll skeleton and a mannequin skeleton (no gravity or momentum) with the desired pose. The way I do it goes as follows:
1) compute the necessary torque for each bone with respect to the desired pose
2) applyAngularImpulse() on each bone

The formula for computing the necessary torque goes like this:
torque = (Desired Orientation - Actual Orientation) + (Desired Angular Velocity - Actual Angular Velocity)
All in world space.
For these I used the Entity's WorldTransform for orientation and the Entity's AngularVelocity property.

The results are not exactly what I expected. The skeleton starts to freak out. Even with dampening set incredibly high, I eventually get errors such as:
Some internal arithmetic has encountered an invalid state. Check for invalid entity momentums, velocities, and positions; propagating NaN's will generally trigger this exception in the getExtremePoint function.
during my space update, when applying forces to the model.

When I manually turn down the torque, it just seems that the force isn't strong enough to get the desired pose.
Here is a screen-shot:

The red doll is the desired pose, the green one the simulated doll. As you can see, the forces on the green doll do not seem strong enough, increasing them will cause instability.

So far I've figured out that:
- the IsAlwaysActive property helps stability a lot (I guess applying impulses to a non active object isn't a good idea)
- when I remove the angularvelocity from the equation, I get quite a limp character but no more bones flying all over the place.


I hope this isn't a little bit too vague but the paper is really not something you explain in a single post, hopefully someone can give any insight as to what I'm doing wrong? Should I be using motor's instead or something?


Many thanks in advance,

Rob

[Norbo]

I would recommend watching the result of the torque calculation and doing sanity checks on it. The instability in this sort of simulation might be noticeable (wobbly, like the dynamo videos), but it shouldn't compound itself into oblivion and NaN's. My first guess would be the orientation-to-torque calculation, but since you say it seems to work better without the angular velocity component, I suppose they're both suspect

Also, I don't know if it is an issue, but note that the WorldTransform/OrientationMatrix/OrientationQuaternion and AngularVelocity properties (amongst others) are buffered. This means that a write to them will not be applied until the next space update. Switching them to their Internal-prefixed counterparts would eliminate this possible issue.

- the IsAlwaysActive property helps stability a lot (I guess applying impulses to a non active object isn't a good idea)

Correct- a sleeping character accumulated impulses won't move, but then when it finally does wake up, it could explode due to the accumulated torque.

Should I be using motor's instead or something?

Using constraint motors would definitely provide a stability boost, though they would be more expensive than simple explicit torque springs and don't map directly to the paper's method (as far as I can tell without actually reading it ) without some work. It should be possible to achieve satisfactory results with the explicit torques approach.

To use Motors, each joint would have a Motor in servo mode and its goal state would need to be set using the current animation pose. It's conceptually simple, though setting up a non-trivial ragdoll with different kinds of motorized joints can be a bit of a pain.

[seabert]

Hi Norbo,

Thank you for the swift reply!

When I was reading your comment I realised that I was not really focussing how I applied the torque. Directly setting AngularVelocity seems to be the key rather than keep adding impulses. The rag doll now pretty smoothly goes into the required position.

The only problem right now though is that the skeleton sometimes starts to shake and the dampening factor isn't sufficient any more. It starts to flip uncontrollably sometimes as the AngularMomentum keeps growing.

I guess I will try to keep tweaking the values a bit in order to get them stable. Any tips on doing it? Dampening really isn't an option I think


Regards,

Rob

[Norbo]

Explosions with springs usually come from underdamped excessive stiffness. If an orientation error causes a significant oscillation, they can start a catastrophic spiral that will blow everything up.

If you can apply critically or overdamped torques, the problem should lessen. I wouldn't recommend using the entity damping to accomplish the damping though (it's formulated in a way that would be difficult to match to the spring system).

If this is the problem, 'solved' motors would definitely have a stability advantage, but it should still be possible to do it with simple torque springs.

Note that writing to the AngularVelocity property is equivalent to applying torques, just as changing LinearVelocity is equivalent to applying linear impulses. The difference is a scaling factor (mass in linear velocity case and the more complicated inertia tensor in the angular case).

[seabert]

Hiya Norbo,

I think my problem had something to do with the internal angular velocity, it seems to be working pretty decently now. The character is still a bit wobbly but I guess part of that is the stances I'm ordering it to do are simply hard to balance in :p

Anyway thank you very much for your help and advice! Once I got a full skeleton + skinning finished I will surely post the results

[JimmyF85]

I would recommend watching the result of the torque calculation and doing sanity checks on it. The instability in this sort of simulation might be noticeable (wobbly, like the dynamo videos), but it shouldn't compound itself into oblivion and NaN's. My first guess would be the orientation-to-torque calculation, but since you say it seems to work better without the angular velocity component, I suppose they're both suspect

Also, I don't know if it is an issue, but note that the WorldTransform/OrientationMatrix/OrientationQuaternion and AngularVelocity properties (amongst others) are buffered. This means that a write to them will not be applied until the next space update. Switching them to their Internal-prefixed counterparts would eliminate this possible issue.

- the IsAlwaysActive property helps stability a lot (I guess applying impulses to a non active object isn't a good idea)

Correct- a sleeping character accumulated impulses won't move, but then when it finally does wake up, it could explode due to the accumulated torque.

Should I be using motor's instead or something?

Using constraint motors would definitely provide a stability boost, though they would be more expensive than simple explicit torque springs and don't map directly to the paper's method (as far as I can tell without actually reading it ) without some work. It should be possible to achieve satisfactory results with the explicit torques approach.

To use Motors, each joint would have a Motor in servo mode and its goal state would need to be set using the current animation pose. It's conceptually simple, though setting up a non-trivial ragdoll with different kinds of motorized joints can be a bit of a pain.

Hi, I am trying to do this as well, what motors should I use? I have tried playing around with the different kinds but I am getting crazy results

[Norbo]

Depending on the type of joint, you can look into the AngularMotor, RevoluteMotor, and TwistMotor.

The AngularMotor is a 3DOF motor that controls relative orientation, the RevoluteMotor can power an axis or hinge (1DOF), and the TwistMotor can be thought of as powering a universal joint (1DOF also).

Motors can be paired with complementary joints, like a RevoluteMotor and RevoluteHingeJoint, to handle the rest of the angular DOFs. Depending on your simulation, you might also be able to get away with just having a single AngularMotor which manages the relative orientation alone.

Complicated articulated things like skeletons can require some work to get the joints initialized properly. If a revolute motor's axis is wrong, for example, it will try to bend the joint in ways that it might not be able to move in (producing all sorts of wonky effects).

[JimmyF85]

Depending on the type of joint, you can look into the AngularMotor, RevoluteMotor, and TwistMotor.

The AngularMotor is a 3DOF motor that controls relative orientation, the RevoluteMotor can power an axis or hinge (1DOF), and the TwistMotor can be thought of as powering a universal joint (1DOF also).

Motors can be paired with complementary joints, like a RevoluteMotor and RevoluteHingeJoint, to handle the rest of the angular DOFs. Depending on your simulation, you might also be able to get away with just having a single AngularMotor which manages the relative orientation alone.

Complicated articulated things like skeletons can require some work to get the joints initialized properly. If a revolute motor's axis is wrong, for example, it will try to bend the joint in ways that it might not be able to move in (producing all sorts of wonky effects).

Thanks for the quick answer.

I should have explained more about my situation

I am building a ragdoll with boxes(head,torso,upper arms, lower arms, upper legs and lower legs). My goal for now is to make it stand up by itself with motors(and keep the balance when throwing things at it), the body is kept together with ball socket joints.

I will play around with AngularMotor and read up about it(unless you think I should use some other motor for this situation).

[Norbo]

I will play around with AngularMotor and read up about it(unless you think I should use some other motor for this situation).

That can work. Although if the motors are soft or turned off, the ragdoll will happily crumple up. Knees will twist and elbows will bend backwards. If the AngularMotors are reasonably stiff at all times, this won't really be an issue. If they aren't, then other constraints like the RevoluteHingeJoint and RevoluteLimit can be added to control non-motorized behavior (and at that point, using the specific appropriate motor may be a good idea).