Game Development Reference

In-Depth Information

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

each frame.

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

velocity.

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

each iteration.

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