Game Development Reference
Taking the dot product of the relative velocity vector, vr , with the unit normal vector
yields the relative velocity in the collision normal direction. If that relative velocity is
less than 0, then the particle and the object are colliding and the code goes on to calculate
the impact force in a manner similar to that described earlier for the particle-to-ground
collisions. The only difference here is that both the particle's and object's masses appear
in the impulse formula. Earlier we assumed the ground was infinitely massive relative
to the particle's mass, so the 1/m term for the ground went to 0, essentially dropping out
of the equation. Refer back to Chapter 5 to recall the impulse formulas.
Once the impact force is calculated, the code backs up the particle by a distance equal
to s , the penetration, along the line of action of the collision normal vector, giving us
what we desire (as shown in Figure 8-7 ).
Now, when you run this simulation you'll see the particles falling down, bouncing off
the obstacles or flowing around them depending on the value you're using for coefficient
of restitution, ultimately bouncing and coming to rest on the ground plane. If you have
a wind speed greater than 0, then the particles will still drift along the ground plane
from left to right.
Tuning is an important part of developing any simulator. Tuning means different things
to different people. For some, tuning is adjusting formulas and coefficients to make your
simulation match some specific “right answer,” while to others tuning is adjusting pa‐
rameters to make the simulation look and behave how you want it to, whether or not
it's technically the right answer. After all, the right answer for a game is that it's fun and
robust. Speaking of robustness, other folks view tuning in the sense of adjusting pa‐
rameters to make the simulation stable. In reality, this is all tuning and you should think
of it as a necessary part of developing your simulation. It's the process by which you
tweak, nudge, and adjust things to make the simulation do what you want it to do.
For example, you can use this same example simulation to model very springy rubber
balls. To achieve this, you'll probably adjust the coefficient of restitution toward a value
approaching 1 and perhaps lower the drag coefficient. The particles will bounce all over
the place with a lot of energy. If, on the other hand, you want to model something along
the lines of mud, then you'll lower the coefficient of restitution and increase the drag
coefficient. There is no right or wrong combination of coefficient of restitution or drag
coefficient to use, so long as you are pleased with the results.
Another aspect you might tune is the number of simulation frames per rendering frame.
You may find the simulation calculations take so long that your resulting animations
are too jerky because you aren't updating the display enough. The converse may be true
in other cases. An important parameter that plays into this is the time step size you take
at each simulation iteration. If the step size is too small, you'll perform a lot of simulation