Game Development Reference
In-Depth Information
Earlier in the chapter, however, we introduced another factor to alter the velocity: the
damping parameter.
The damping parameter is used to remove a bit of velocity at each frame. This is
done by simply multiplying the velocity by the damping factor
p = ˙
˙
pd
+ ¨
pt
[3.5]
where d is the damping for the object.
This form of the equation hides a problem, however. No matter whether we have
a long or a short time interval over which to update, the amount of velocity being
removed is the same. If our frame rate suddenly improves, then there will be more
updates per second and the object will suddenly appear to have more drag. A more
correct version of the equation solves this problem by incorporating the time into the
drag part of the equation:
p = pd t
+ pt
[3.6]
where the damping parameter d is now the proportion of the velocity retained each
second, rather than each frame.
Calculating one floating-point number to the power of another is a slow process
on most modern hardware. If you are simulating a huge number of objects, then it
is normally best to avoid this step. For a particle physics engine designed to simulate
thousands of sparks, for example, use equation 3.5, or even remove damping alto-
gether.
Because we are heading toward an engine designed for simulating a smaller num-
ber of rigid bodies, I will use the full form in this topic, as given in equation 3.6.
A different approach favored by many engine developers is to use equation 3.5 with a
damping value very near to 1—so small that it will not be noticeable to the player but
big enough to be able to solve the numerical instability problem. In this case a varia-
tion in frame rate will not make any visual difference. Drag forces can then be created
and applied as explicit forces that will act on each object (as we'll see in chapter 5).
Unfortunately, this simply moves the problem to another part of the code—the
part where we calculate the size of the drag force. For this reason I prefer to make the
damping parameter more flexible and allow it to be used to simulate visible levels of
drag.
3.3.2
T HE C OMPLETE I NTEGRATOR
We can now implement our integrator unit. The code looks like this:
Excerpt from include/cyclone/precision.h
/** Defines the precision of the power operator. */
#define real_pow powf
Search Nedrilad ::




Custom Search