So what is torque even?

I was creating a simple 2D physics engine and was implementing the angular velocity part when I was hit with the same question countless high schoolers and undergraduates have raised over the millenia. Why is torque defined like this? Why is it a cross product? ^{1 2 3 4 5}

One kind of answer just says that we need to encode the plane of rotation somehow. Alright, but why do it with a cross product? Why not just use a 6-tuple, is it just harder to use, or what?

Also there is another interpretation where people bring in "bivectors". Oh, torque is a wedge product, creating a bivector, which in 3D is equivalent to the cross product. This generalises to dimensions other than 3! The cross product is just a specialization of this generalized formulation of angular momentum!

The bivector interpretation is often presented as a fundamental explanation, but it’s historically and conceptually backward: the cross product came first, and the wedge product was introduced later as a generalization. So it doesn’t explain why torque is formulated this way in the first place — it just tells us how we might describe it in a broader mathematical framework.

The simple explanation I'm going to give is just from first principles. I believe it was taught at some point of time but forgotten by students somewhere during the transition from simple 2D scalar torque to the 3D vectors formulation.

Torque in 2D

Let's first start with torque in 2D. A common way of solving for this is to just imagine 2D as a plane embedded in 3D. So torque is given by

$$\begin{align*} \v\tau &= \v r \times \v F \\ &= (x, y, 0) \times (F_x, F_y, 0) \\ &= (0, 0, xF_y - yF_x) \end{align*}$$

So we define torque in 2D as $xF_y - yF_x$, which again looks really meaningless: what is the physical meaning of multiplying $x$ with the $y$ component of the force? How could that possibly work? Also it's still not explaining why the cross product is there!

This was taught to students at some point of time but immediately forgotten: Torque is the product of the magnitude of the force and the length of the moment arm. The moment arm is found as such: imagine the force vector was a straight line extending from wherever it is being applied all the way into infinity. Draw a perpendicular line from the axis of rotation to this line. This perpendicular line is the moment arm.

How do you find this value? It's the projection of the normal vector of the force onto the vector from the axis to the point of contact. Read that again and make sure it makes sense. How do you calculate this? The normal of $\v F$ is given by $(F_y, -F_x)$ ⁶. The projection (or rather it's just the magnitude we care about) is the dot product:

$$(F_y, -F_x) \cdot \v r = x F_y - y F_x$$

It's like magic. No it's not, it just makes physical sense!

Torque in 3D

Let's extend this reasoning to 3D and see why the cross product makes sense. The rotations we are talking about always occur in a plane. The cross product produces the normal vector of the plane. More specifically, the cross product produces the axis of rotation. As you will see in the next section, this is enough information to tell us how to rotate something.

Wait, what about the magnitude? We know that

$$\abs{\v r \times \v F} = \abs{\v r} \abs{\v F} \sin \theta$$

This gives exactly the length of the moment arm times the magnitude of the force.

Axis angle representation

Now you have some intuition on torque, there is one last question, Why should the plane or the rotation be described by the normal vector?

A consequence of Euler's rotation theorem ⁷ is that any rotation can be represented with just one angle and one axis. This is probably the simplest representation of the rotation since it also takes into account the circular symmetry of the problem.

Consider representing rotations instead with the instantaneous velocity $\v v_\perp$. This would never be more optimal in Cartesian coordinates: a constant $\v \omega = (0, 0, 1)$ would require something similar to $\v v_\perp = (\cos t, \sin t, 0)$ to mean the same thing. The only way to simplify this is to switch to polar coordinates, and then you would just get a less efficient form of $\v \omega$ anyway.

Another problem is that this only gives an instantaneous velocity and you still need to integrate it to get the final rotation. For game engines that use numerical integration this is not good: for example a first order Euler's method continually updates $\v r = \v r + \v v_\perp \deltat$ each frame. The results of approximating a circular motion with linear pieces like this is, as you can expect, not very good.

Another way is a rotation matrix, be it from Rodrigues formula or some other way. This is actually fine, but it is very cumbersome to work with, and it is essentially an uncompressed $\v \omega$, so why would we?

Torque in physics engines

Because this started out as a random post while I was writing a simple physics engine I will write a small section on how physics engines typically work with torque. You will see that it's not hard at all! Furthermore, note that it does not have the compounding errors problem we see with $\v v_\perp$, since the positions never depend on position information from previous time steps.

From torque we can get the angular velocity $\v \omega$.

$$\dv{\v \omega}{t} = \v \alpha = I^{-1} \v \tau$$

Here $I$ is the inertia tensor; it exists because some things don't rotate simply where you push them. Imagine you are in a zero-G environment, and you push the top left corner of a floating book. The book is not going to just tumble back to front, it will also rotate left to right. Let's just ignore how it's calculated for now.

Quaternions are extensions of complex numbers. Therefore we also have magical things like the extension of Euler's formula⁸: we can create quaternions like

$$\v q = \exp{\frac{\theta}{2} \v u}$$

and it encodes a rotation of $\theta$ angles around the axis $\v u$. The rotation of a vector $\v v$ by $\v q$ is given simply by $\v q \v v \v q^{-1}$. So our interest now lies upon finding a way of updating $\v q$.

Now notice that

$$\begin{align*} \dv{\v q}{t} &= \frac{\theta}{2} \v u \exp{\frac{\theta}{2} \v u} \\ &= \frac{\v \omega}{2} \v q \end{align*}$$

The solution to this differential equation is ⁹

$$\begin{align*} \v q(t) &= \v q_0 \exp{\frac{\v \omega}{2} t} \end{align*}$$

In most game engines this is approximated by a first order Taylor series of the exponential function; at each time step you perform the update $\v q = \v q + \v \omega / 2 \deltat$. And then for all vertexes in the object you just perform a $\v q \v v \v q^{-1}$ to get their rotated position. Wow, amazing. So all we need to do is pretty much just a vector sum each step ¹⁰!