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