Game Development Reference
F IGURE 7.5
Resolving one contact may resolve another automatically.
order. Once we have handled the first collision, the next contact may have a positive
separating velocity and not need any processing.
There is also another, more subtle problem that doesn't tend to arise in many
particle situations. We could have a situation where we resolve one contact and then
another, but the resolution of the second puts the first contact back into collision, so
we need to re-resolve it. Fortunately it can be shown that for certain types of simu-
lation (particularly those with no friction, although some friction situations can also
work), this looping will eventually settle into a correct answer. We'll not need to loop
around forever, and we'll not end up with a situation where the corrections get bigger
and bigger until the whole simulation explodes. Unfortunately this could take a long
time to reach, and there is no accurate way to estimate how long it will take. To avoid
getting stuck we place a limit on the number of resolutions that can be performed at
The contact resolver we will use follows this algorithm:
1. Calculate the separating velocity of each contact, keeping track of the contact with
the lowest (i.e., most negative) value.
2. If the lowest separating velocity is greater than or equal to zero, then we're done:
exit the algorithm.
3. Process the collision response algorithm for the contact with the lowest separating
4. If we have more iterations, then return to step 1.
The algorithm will automatically reexamine contacts that it has previously resolved,
and it will ignore contacts that are separating. It resolves the most severe collision at
The number of iterations should be at least the number of contacts (to give them
all a chance of getting seen to at least once) and can be greater. For simple particle