Can Angular Velocity Accurately Control Ragdoll Limbs in Game Physics?

[MadAce]

TL;DR Summary

Position a game physics object in certain position using angular velocity

I apologize for messy title, but that's as short as I could make it to say all that I wanted.

I also apologize if I'm not using correct math phrases, but I'll try to picture a problem the best I can.

I've been pulling my hair out trying to solve a problem I'm having for couple of months.

The problem:
This is regarding a mod I'm trying to make for a game (Fallout: New Vegas).
I need to find a way to set character's ragdoll limbs into a specific pose using a function that sets an angular velocity to a specific bone on a character.
This function sets (local or worldspace) angular velocity on X, Y and Z axis on any rigid body that is affected by game's physics engine.
Angular velocity in this case is a unit of 2π rad/s or revolutions/second. So if every in-game frame I'm setting velocity on X axis to 5, it will keep rotating that physical rigid object at 5 revs/sec until I stop calling that function while still being affected by other phyical properties like gravity.

Note: This is the only function that's letting me do any kind of rotation of a physical body in game.

What I have currently:
I have an invisible game object that is a copy of character skeleton where I have all animations stored.
Via function I get current local rotation of a bone (it returns X, Y, Z Euler angles) on that invisible skeleton, for example Upper right arm bone (I'll call that variable Anim).
I do the same, but for physical bone on a character ragdoll (variable name Rag).
Then I do the following to get needed angular velocity:

fAngVelX = (fAnimRotX - fRagRotX)
fAngVelY = (fAnimRotY - fRagRotY)
fAngVelZ = (fAnimRotZ - fRagRotZ)

I put those values into function that adds angular velocity to a physical object.
Basically, I'm trying to copy rotation from an animated invisible bone to a physical bone.

And this very simple solution worked. Well, I thought it worked. The solution seemed way too easy.

Problem is clearly visible in this video:


Green "barrel" thingies are the physical bodies, while red ones are static (not affected by game's physics engine). At rest, all rotations are 0, 0, 0 and everything seems to work fine. When I try to set red object to some pose, at the beginning everything seems fine until I reach certain angles at which green body starts going crazy.

I'm sure it's got something to do with how Euler angles work since angles go from 0 to 180 and then jump to -180 and go back to 0 if you keep rotating in the same direction. I also have option to convert Eulers to Quaternions and vice versa, but... Good Lord.

Is there a solution to this issue and is it even possible to do the thing I need with functions I have available?

I'd highly appreciate an answer since it's been bothering me for so long.

And sorry for a long post!

 

[Filip Larsen]

Have you had any progress with your problem since your original post?

While this forum certainly can guide you in regards to Euler angles and quaternions if you still need that, I must say from watching your video looks a bit more like an issue with the physics engine in the game. In general, game physics engines are known to be wonky and requiring special tricks in order to give sensible physics animations, and I seem to recall the Bethesda games to be particularly prone to send ragdolls flying high into the air for no apparent reason.

If you still need help regarding "physics stuff" perhaps you can link to the API you use to set the bone angles?

Later: forgot to mention the dynamics in the video do not look entirely wrong. If you put two barrels on top of each other connected with a single spring on their axis, then any small displacement of the top barrel should make it "swing out" when the stack is rotated. I assume each barrel is a bone and the spring/damper connection is provided by the engine. If so it may be possible to play around with the connection values (spring stiffness / damping coefficient) to get a more smooth animation. Game physics engines are often limited to very simple integration schemes that has to solve equation in real-time, and this makes it difficult to accurately simulate dynamics on timescales faster than the frame interval, e.g. collision are notoriously hard to simulate accurately with using same integration technique as normal single body free fall.

 

[pbuk]

I'm sure it's got something to do with how Euler angles work since angles go from 0 to 180 and then jump to -180 and go back to 0 if you keep rotating in the same direction.

This.

Is there a solution to this issue and is it even possible to do the thing I need with functions I have available?

Yes, use quaternions. That is what they are for.

 

[Filip Larsen]

This.

I understand the setup being the red (physical) and green (non-physical) object are two different objects with angles set in the same way, but only the red one show "wild" animations. If that is indeed so, it seems to me to be less likely to be the angles themselves, but I guess the OP can test this by letting the angles vary continuously only (say -180 to 180 without any large jumps) and then see if the physical object still jerks around. If they don't I guess the discontinuous jumps do mess up the physics.

 

[MadAce]

Thanks for replying! :D

Sadly, no. I still haven't found a solution.

I understand the setup being the red (physical) and green (non-physical) object are two different objects with angles set in the same way, but only the red one show "wild" animations. If that is indeed so, it seems to me to be less likely to be the angles themselves, but I guess the OP can test this by letting the angles vary continuously only (say -180 to 180 without any large jumps) and then see if the physical object still jerks around. If they don't I guess the discontinuous jumps do mess up the physics.

It's the other way around. Red ones are "static", that is, not affected by game physics simulation, while the green ones are simulated by physics engine.

After more testing, it seems that "craziness" starts once any axis goes above 90 (or below -90) degrees and craziness gets higher the higher angle is . For testing purposes, I only rotated them on local X axis while keeping Y and Z at 0. Why would it start at 90 degrees, I have no idea. It makes no sense to me.

If you still need help regarding "physics stuff" perhaps you can link to the API you use to set the bone angles?

Well, I found SetAngularVelocity mentioned here:
https://github.com/jazzisparis/JIP-LN-NVSE/blob/main/internal/havok.h

 

[Filip Larsen]

After more testing, it seems that "craziness" starts once any axis goes above 90 (or below -90) degrees and craziness gets higher the higher angle is . For testing purposes, I only rotated them on local X axis while keeping Y and Z at 0. Why would it start at 90 degrees, I have no idea. It makes no sense to me.

If it is starts at exactly at 90 deg/sec then I agree it is a bit strange and could indicate some ill-formed input or model (I say this without having worked with Havok). If you vary the object parameters, say make the barrels heavier, do you still see the same effect at same angular speed?

To me it still looks like the simulation becomes unstable because it tries to simulate dynamics that is too fast for the given frame rate, but I sadly have no practical pointers for how to fix this in general using Havok. Often in dynamic simulations it is a question of adding enough dampening (if it is a multi-body system), so if you have any control over the joint between the barrels then try get more damping in or less restoring spring stiffness. The reason I mention joints is because you mention ragdoll where I assume the bones have joints with parameters, but I am not sure if the barrels shown in the video actually are modelled as a ragdolls, (i.e. the two green barrels are jointed together) or if they are just two physical objects stacked on top of each other and "held together" via gravity and friction. For the latter I guess the top barrel would not snap back to vertical so that is why I suspect each pair of barrels to be a multibody.

It's the other way around. Red ones are "static", that is, not affected by game physics simulation, while the green ones are simulated by physics engine.

Sorry, got red and green switched around when I wrote that.