Game Development Reference

In-Depth Information

Velocity Mismatches

So far we have talked only about position. Equation 6.5 calculates the force needed

to get the object to its predicted position. Unfortunately it will not get there with

an accurate velocity (although it will often be close). Could this equation end up

increasing the velocity of the object each time, getting faster and faster and exploding

out to infinity?

For damped harmonic motion, when the anchor point is not in motion, the veloc-

ity resulting from performing this kind of prediction will never mount up to achieve

this. The mathematics involved in demonstrating this is complex, so I'll leave it as an

exercise for the skeptical.

Even though we won't get exploding velocities, the mismatch between the result-

ing velocity and the correct velocity causes the spring to behave with an inconsistent

spring constant. Sometimes it will be stiffer than we specified, sometimes it will be

looser. In most cases it is not noticeable, but it is an inescapable consequence of fak-

ing the force in the way we have done.

Interacting with Other Forces

Another major limitation of the faked spring generator is the way it interacts with

other forces.

The previous equations assume that the object is moving freely, not under the

influence of any other forces. The spring force will decrease over the course of the

time interval, because the spring is moving toward its rest length. If we have another

force that is keeping the spring extended or compressed at a constant length, then the

force
will
be constant, and the original force generator will give a perfect result, no

matter what the spring constant is.

We could theoretically incorporate all the other forces into the prediction for the

spring generator, and then it would return exactly the correct force. Unfortunately, to

correctly work out the force, we'd need to know the behavior of all the objects being

simulated. Simulating the behavior of all the objects is, of course, the whole purpose

of the physics engine. So the only way we could get this to work is to put a full physics

engine in the force calculations. This is not practical (in fact, strictly speaking it is

impossible because in that engine we'd need another one, and so on ad infinitum).

For springs that are intended to be kept extended (such as the springs holding up

our rope-bridge earlier in the chapter), faked spring forces will be too small, often

considerably too small. In practice it is best to try to find a blend of techniques to get

the effect you want, using different spring force generators for different objects in the

game.

I have used this faked force generator successfully to model the spring in a char-

acter's hair (and other wobbly body parts). The rest position is given by the original

position of a hair-vertex in the 3D model, and the spring force attracts the actual

drawn vertex to this rest position. As the character moves, her hair bobs naturally.

This method is ideally suited to the problem because the vertices don't have any other

forces on them (a natural “flop” caused by gravity is incorporated by the artist in