Game Development Reference
In-Depth Information
F IGURE 14.9
Angular resolution causes other problems.
again, or that another part of the object will come into penetration. Figure 14.9 shows
this case. Even a modest rotation of the object can cause another penetration to occur.
For both issues we need to limit the amount of rotation that can be part of our
penetration resolution. Keeping this value small means that our small-rotation as-
sumption is valid, and that we minimize the chance of causing other interpenetra-
tions while resolving one.
The amount of linear and angular motion we want is calculated and stored in four
variables (two for single-body collisions):
linearMove[0]
linearMove[1]
angularMove[0]
angularMove[1]
We can simply check that the values of angularMove are not too great. If they are,
we can transfer some of the burden from them onto the corresponding linearMove
component.
But what is “too great”? This is where we descend into the black art of tuning the
physics engine. I haven't come across a sensible logical argument for choosing any
particular strategy.
Some developers use a fixed amount: not allowing the angular move value to be
greater than 0.5, for example. This works well as long as the objects in the simulation
are all roughly the same size. If some objects are very large, then a suitable limit for
them may be unsuitable for smaller objects, and vice versa.
It is also possible to express the limit in terms of a fraction of a revolution that the
object can make. We could limit the rotation so that the object never turns through
more than 45 , for example. This accounts for differences in size, but it is more com-
plex to work out the equivalent angular move for a specific angle of rotation.
A simple alternative is to scale the angular move by the size of the object (where
the size of the object can be approximated by the magnitude of the relative contact