Game Development Reference

In-Depth Information

programmers want CPU cycles for other things, the solver is terminated before it

is completely done, leaving the objects with a slight downward velocity instead of

zero, which is desired for resting contact. This slight downward velocity causes

objects to sink in, and the process is repeated.

To compensate for this behavior, most physics engines use a geometric mea-

sure for each contact point: either penetration depth or separation distance. As

the penetration depth increases, the desired resulting velocity is biased, so that it

is not zero but is actually negative, causing the objects to separate. This translates

to objects being soft instead of rigid, where the softness is defined by how well

the solver managed to solve the problem. This is why most solvers act springy

or squishy when using fewer iterations. Hence, the best way to get rid of the

mushroom is to increase the number of iterations in the solver!

2.5.1 Keeping the Configuration Unchanged

A solver that uses this kind of geometric compensation running at the same step

size and same number of iterations every frame will eventually find an equilib-

rium after a certain number of frames. Understanding that this equilibrium is not

a relaxed state but a very complex ongoing struggle between gravity, penetrat-

ing contacts, and penalty forces is key to stability. Removing or adding even a

single constraint, or changing the number of iterations, will cause the solver to

redistribute the weight and find a new equilibrium, which is a process that usu-

ally takes several frames and causes objects to wiggle. The set of constraints for

a specific scenario is sometimes called its configuration; hence keeping the con-

figuration unchanged from one frame to the next is very important, and we will

revisit this goal throughout the chapter.

2.5.2 Warm Starting

Assuming that the configuration does not change and objects are at rest, the im-

pulses at each contact point will be essentially the same every frame. It seems

kind of unnecessary to recompute the same problem over and over again. This is

where warm starting comes into the picture. Instead of recomputing the impulses

from scratch every time, we can start off with the impulses from the previous

frame and use our solver iterations to refine them instead. Using warm starting

is almost always a good idea. The downside is that we have to remember the

impulses from the last frame, which requires some extra bookkeeping. However,

since most physics engines keep track of pairs anyway, this can usually be added

relatively easily.

I mentioned before that a sequential impulse solver does not add energy but

rather drains energy from a system. This unfortunately no longer holds true if