Hi Sol. To be clear you will actually need two torques, one to start the object rotating, and one to stop it at the desired rotation. Then you need to decide how you want it to accelerate / decelerate.
It’s a bit like asking what force you need to get to the moon: Not much if you don’t mind waiting a long time then smashing into the surface. However if you want to get there in an hour, and to accelerate smoothly you could accelerate at around 13g for 30 minutes, turn-around, then decelerate at the same rate for another half an hour. Same with your torques and rotation. Does that make sense?
So the magnitude of the torque(s) you need depends not only the angle change, but on the time you want it to take (as well as the acceleration / deceleration strategy). The rotation won’t be very “physically correct” if it instantaneously moves from one rotation to another, unless the object has no rotational inertia.
So we must involve time in this, and you need to decide how long you want your rotation to appear to take. On that basis you’re not really working out a torque, but a torque at a given time into the “animation”. What’s the method signature you’re after, would this pattern do?..
/// <summary>
/// Animates the rotation.
/// Performs a realistic torque-driven rotation from one stationary position to another.
/// Half the time is spent accelerating, the other half decelerating.
/// </summary>
/// <returns>The rotation at the elapsed time</returns>
Quaternion AnimateRotation (Vector3 from, Vector3 to, float timeElapsed, float totalTime) {
Quaternion currentRotation;
// I'll write the code if you're stuck
return currentRotation;
}
If your object is 3D, and rotating around more than one axis you’ll need an inertia tensor rather than the simplified “moment of inertia” about one axis (which is just one element of a 3x3 matrix). In which case read-on. If you do go down the inertia tensor route, bear in mind…
- Unity diagonalises them, so “intermediate axis” instability doesn’t work properly (see solution below).
- Adding a 3D collider(s) to a rigidbody gives you access to
rigidbody.inertiaTensor, which is only approximate.
- You’ll have to do your multiplications carefully, again see below.
====
On a related note in case it helps, I got a cool simulation of a phone flipping according to the [40735-flipping-phones.zip|40735]**
I’ll be going through this step-by-step when I add a section to my new game physics course in March 2015. I’ll be removing the cumbersome single and double underscore notation don’t worry!
