Game Development Reference
This generator applies to only one object because it contains the data for the ob-
ject's size and volume. One instance could be given to multiple objects with the same
size and volume, floating in the same liquid, but it is probably best to create a new
instance per object to avoid confusion.
S TIFF S PRINGS
In real life almost everything acts as a spring. If a rock falls onto the ground, the
ground gives a little, like a very stiff spring. With a model of spring behavior we could
simulate anything. Collisions between objects could be modeled in a similar way to
the buoyancy force: the objects would be allowed to pass into one another (called
“interpenetration”), and a spring force would push them back out again.
With the correct spring parameters for each object, this method would give us
perfect collisions. It is called the “penalty” method and has been used in many physics
simulators, including several used in games.
If life were so simple, however, this topic could be two hundred pages shorter.
In fact, to avoid having everything in a game look really spongy as things bounce
around on soggy springs, we have to increase the spring constant so that it is very
high. If you try to do that, and run the engine, you will see everything go haywire:
objects will almost instantly disappear off to infinity, and your program may even
crash with numerical errors. This is the problem of stiff springs, and it makes penalty
methods almost useless for our needs.
T HE P ROBLEM OF S TIFF S PRINGS
To understand why stiff springs cause problems we need to break down the behavior
of a spring into short time steps. Figure 6.4 shows a spring's behavior over several time
steps. In the first step, the spring is extended, and we calculate the force at that point.
The force is applied to the end of the spring using the update function from chap-
p = p
+ p t
F IGURE 6.4
A non-stiff spring over time.