In the last installment, we gave a high level overview of rotational energy, momentum and moments of inertia. None of these things are covered in modern “physics” engines. What we call physics engines would better be called “rigid body” engines. This means that we need to devise a way of dealing with these attributes.
Moment of inertia depends on the distribution of the mass relative to the pivot point. This means that you can simply define a number and leave it at that. You have to track your mass distribution. We already have a tool that gets us part of the way there; the 3D mesh from the model(s). If we have a character model and a sword model attacked to a dummy node located at the character’s hand, we have two defined objects and a constant mass, bit the moment of inertia changes every time the character moves. The brute force approach would be to devise a mathematical model – a single equation – to determine the moment of inertia at each. Our swing motion is a smooth motion through an arc and the position and orientation of each mass in that motion results in an and ugly and expensive to solve equation. This is impossibly impractical for each motion permutation, so we’ll impose a couple of tricks.
The Horse can be approximated as a sphere
The above statement means that we don’t need to be exact and we can get away with a lot of approximating. Specifically, we’ll do two things.
We have explicit time slices where we know the exact configuration of the masses in our character/sword system because we have the animation key frame data. We’ll solve I for each key frame only and hand wave/approximate it. This is also how physics engines approximate rigid body motion. They don’t solve Hailtonians or Lagrangians. They step through time slices.
We need to have the mass distribution of each object. It is right there in the 3D mesh and we can pull it out with an algorithm. We can even go a step further and reduce that mesh shape to a collection of points representing the mass distribution of the object. The moment of inertia for a point mass is simply its mass times the distance from the axis of rotation. This makes for a speedy calculation.
The leftmost image is the blade from the sai model that eq2001 put up on turbosquid. The middle is that model with a rough approximation of its mass by individual point masses superimposed. The rightmost image is the resulting “mass cloud”. At each keyframe, we can now easily determine the total moment of inertia. This allows us to calculate such things as angular momentum, kinetic energy of rotation, etc.
In fact, we can take it a step further. If we agree that a character’s “strength” attribute defines his/her ability to generate torque and that a given character would have a “terminal rotation velocity”, where the motion simply can’t accelerate anymore, then we have a few more tricks up our sleeve. If the motion has not yet reached its terminal velocity, then we can – in principle – shift the keyframes around in time. Weaker characters, or ones wielding heavy weapons, now swing slower than strong characters or ones wielding light weapons. We can call this shifting of keyframes an “animation profile”. It is essentially a list of time/space shifts in the keyframes. This requires a change to the way that clients typically handle animation calls; namely that an additional parameter of the animation profile list.