Game Development Reference
In-Depth Information
2.4 The Curse of Rotations
Since rotation is the mother of most linearization problems, it deserves some spe-
cial attention. One fun experiment we can try is to make the inertia tensor for
all objects infinite and see how that affects our simulation. The inertia tensor can
roughly be described as an object's willingness to rotate and is often specified
as its inverse, so setting all values to zero typically means rotations will be com-
pletely disabled. You will be surprised how stable those stacks become and how
nicely most scenarios just work. Unfortunately, asking the producer if it is okay
to skip rotations will most likely not be a good idea, but what we can learn is that
the more inertia we add, the less rotation will occur, problems with linearization
will decrease, and the simulation will get more stable.
The problem is especially relevant on long, thin rods. So if you experience
instability with such objects, try increasing the inertia, especially on the axis along
the rod (compute inertia as if the rod was thicker). Increasing inertia will make
objects look heavy and add a perceived slow-motion effect, so you might want to
take it easy, but it can be a lifesaver and is surprisingly hard to spot.
2.5 Solver
Just to freshen up our memory without getting into technical detail, the solver
is responsible for computing the next valid state of a dynamic system, taking
into account various constraints. Now, since games need to be responsive, this
computation has to be fast, and the most popular way of doing that is using an
iterative method called sequential impulse . The concept is really simple: given a
handful of constraints, satisfy each one of them, one at a time, and when the last
one is done, start over again from the beginning and do another round until it is
“good enough,” where good enough often means, “Sorry man, we are out of time,
let's just leave it here.”
What is really interesting, from a debugging perspective, is how this early
termination of a sequential impulse solver can affect the energy of the system.
Stopping before we are done will not add energy to the system, it will drain en-
ergy. This means it is really hard to blame the solver itself for energy being added
to the system.
When you implement a sequential impulse solver with early termination,
stacked, resting objects tend to sink into each other. Let's investigate why this is
happening: at each frame, gravity causes an acceleration that increases an object's
downward velocity. Contact generation creates a set of points and at each contact,
the solver tries to maintain a zero-relative velocity. However, since greedy game