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