Game Development Reference
In-Depth Information
putes the resulting velocities of the objects after colliding and instantly changes their
velocities accordingly. To perform the required calculations, the collision response sys‐
tem requires the objects colliding, of course, the collision points, and the velocities of
those points. Also, each object must have some associated mass and coefficient of res‐
titution, which are likewise used to compute the resulting velocities of the objects after
the collision.
In practice, the collision response system works hand in hand with the collision detec‐
tion system, particularly when dealing with objects that may be penetrating each other.
As we mentioned earlier, in many cases an object penetrating another, such as an object
penetrating a wall or floor, can simply be moved so that it is just touching the wall or
floor. Other cases may be more complicated, and iterative algorithms are used to resolve
the penetration. For example, if penetration is detected, then the simulation may back
up to the previous time step and take a short time step to see if penetration still occurs.
If it does not, the simulation proceeds; otherwise, the simulation takes an even smaller
time step. This process repeats until penetration does not occur. This works fine in many
cases; however, sometimes the penetration is never resolved and the simulation could
get stuck taking smaller and smaller time steps. This failure to resolve could be attributed
to objects that are just outside the collision distance tolerance at one instant, and due
to numerical errors, exceedingly small time steps are required to stay outside of the
distance tolerance. Some programmers simply put an iteration limit in the code to
prevent the simulation from getting stuck, but the consequences in every situation may
be unpredictable. The continuous collision detection approach we mentioned earlier
avoids this sort of problem by predicting the future collision or penetration and dealing
with it ahead of time. Whatever the approach, there will be some back and forth and
data exchange between your collision detection and response systems to avoid excessive
penetration situations.
Additionally, there are situations when an object may come to rest in contact with an‐
other—for example, a box resting on the floor. There are many ways to deal with such
contact situations, one of which is to just allow the impulse-momentum approach to
deal with it. This works just fine in many cases; however, sometimes the objects in resting
contact will jitter with the impulse-momentum approach. One resolution to this jitter‐
ing problem is to put those objects to sleep—that is, if they are found to be colliding,
but their relative velocities are smaller than some tolerance, they are put to sleep. A
related but somewhat more complicated approach is to compute the contact normal
between the object and the floor and set that velocity to 0. This serves as a constraint,
preventing the object from penetrating the floor while still allowing it to slide along the
Force Effectors
Force effectors apply direct or indirect force on the objects in your simulations. Your
physics engine may include several. For example, if your engine allows users to move
Search Nedrilad ::

Custom Search