How is angular drag applied to a Rigidbody in Unity? (How is angular damping applied in PhysX?)

Unity Engine
1

I’m predicting where a GameObject’s transform.forward will be in X number of FixedUpdate() calls.

I got it 100% accurate when the Rigidbody’s angular drag is 0 but if it’s for example the default 0.05 I get somewhat close accuracy but not 100% correct. The error also gets larger the further into the future I’m trying to predict where the transform.forward will be.

Here is how I reduce the angular velocity of the Rigidbody right now:

Vector3 rigidbodyAngularVelocity = GetComponent<Rigidbody>().angularVelocity;
float rigidbodyAngularDrag = GetComponent<Rigidbody>().angularDrag;

...

float dragForceMagnitude = Mathf.Pow(rigidbodyAngularVelocity.magnitude, 2) * rigidbodyAngularDrag;
Vector3 dragForceVector = dragForceMagnitude * rigidbodyAngularVelocity.normalized * -1;
rigidbodyAngularVelocity += dragForceVector * Time.fixedDeltaTime;

However it seems like this isn’t exactly how PhysX is applying the angular drag (or angular damping as they call it).

So my question is what is their calculation formula? (In programmer terms, please.)

I know that angular drag is the problem because if I set it to 0 I get correct predictions no matter how far into the future I try to predict. I’m also aware of the workaround of setting angular drag to 0 on the Rigidbody and then applying angular drag myself in the FixedUpdate() but I don’t want to have to modify the Physics only to predict them…

I’m willing to accept a non-accurate prediction just as long as I know I’m using the same calculations that PhysX is using (errors due to float rounding limitations etc is fine). I’ve searched around a lot and can’t find them… Just the code above (from non-official sources) and it doesn’t give accurate results so I’m guessing it’s just someone’s guess on a forum.

2

After many tests I’ve determined that this highly advanced formula reveals the secrets to PhysX’s angular dampening:

Vector3 rigidbodyAngularVelocity = GetComponent<Rigidbody>().angularVelocity * Time.fixedDeltaTime;
float rigidbodyAngularDrag = GetComponent<Rigidbody>().angularDrag * Time.fixedDeltaTime;

...

if (rigidbodyAngularDrag>1) {
   rigidbodyAngularVelocity = Vector3.zero;
} else if (rigidbodyAngularDrag>0) {
   rigidbodyAngularVelocity -= rigidbodyAngularDrag * rigidbodyAngularVelocity;
}

Simple as that. Notice that if your Rigidbody has a angular drag higher than or equal to the number of FixedUpdate() calls per second in your game the Rigidbody will always stop spinning immediately (rigidbodyAngularDrag becomes 1 or greater).

Now, I’m not completely sure if this really is PhysX/Unity’s way of applying angular dampening but it’s what I get closest results with even when predicting 30 seconds into the future. The prediction is not 100% but it’s close enough for me to believe that float limitations or other stuff that can’t really be controlled is the cause of the mismatch. It also makes sense for the physics engine to avoid expensive Mathf.Pow() calls so yeah, this is probably a wrap folks.

Please post if you have anything else to add, especially corrections. I’ve already noticed that this thread comes up when searching the net for “how does unity apply angular drag to gameobjects” or similar so it’d be nice to put as much info on the subject as possible here.

5 Likes
3

I don’t know what physx is doing internally, but normally I do this for drag-like behaviour in my own code:

velocity *= Mathf.Exp(-drag * Time.deltaTime);

Time.deltaTime is anyway fixed in this case, but this works better than your approach for varying frame rates (but there’s still some precision error compared to analytic solving).

4

Time.deltaTime is never “fixed” even if you restrict fps to any amount, it’s never fixed…

5

This is assuming you use the code in FixedUpdate, where Time.deltaTime is equals Time.fixedDeltaTime. The “exp” formula results stay more predictable when changing the physics time step (eg. during development). It’s not meant to work for real varying frame rates like in Update().

This would be the same code, with unambiguous deltaTime and more context:

void FixedUpdate()
{
    velocity *= Mathf.Exp(-drag * Time.fixedDeltaTime);
}
1 Like
6

I was just saying that Time.deltaTime is never equal to Time.fixedDeltaTime, not even if you use it in FixedUpdate…
Maybe the language barrier is messing what you’re trying to say.
From Unity documentation, FixedUpdate is executed approximately 1/fixedTimeStep amount of times per seconds, that means, your fixed update can be called twice before another update loop is called, but fixed update will execute the amount of times needed per second, but isn’t fixed to work in correlation with update loop.

7

Assuming that X will remain constant. Could you not just do an example run and get a value of where the fwd is at that X time. Then create an empty game object, make it a child of your parent and point it at the final X orientation of where fwd was pointing. Then when you need to predict where fwd will be just query where the empty game object is pointing. Not sure if that would satisfy your requirement.

8

That not true afaik, it doesn’t care where its called, it will return the time from the last visual frame.

9

I always assumed that’s the case, based on what’s written in the documentation. Maybe I misread the docs?
There it says:

https://docs.unity3d.com/ScriptReference/Time-fixedDeltaTime.html

2 Likes
10

I stand corrected.

How does it know where its called from?

1 Like
11

ShadyGuy’s post is correct, but angular drag values above 1 are also fine. From PhysX’s documentation on damping:

So the logic would be:

rigidbody.angularVelocity *= Mathf.Clamp01(1f - angularDrag * Time.fixedDeltaTime);

This means that angularDrag can be a value above 1 (say 5). For a Time.fixedDeltaTime of .02, this gives:

rigidbody.angularVelocity *= Mathf.Clamp01(1f - 5f * .02);

Which is the same as running the following on every physics timestep:

rigidbody.angularVelocity *= .9f;
1 Like