Game Development Reference
In-Depth Information
2. The interpenetration resolution function that moves objects apart so that they
aren't partially embedded in one another.
3. The resting contact code that sits inside the collision resolution function and
keeps an eye out for contacts that might be resting rather than colliding.
Which of these functions needs calling for a contact depends on its separating
velocity and interpenetration depth. Interpenetration resolution only needs to occur
if the contact has a penetration depth greater than zero. Similarly we might need to
perform interpenetration resolution only, with no collision resolution, if the objects
are interpenetrated but separating.
Regardless of the combination of functions needed, each contact is resolved one
at a time. This is a simplification of the real world. In reality each contact would occur
at a slightly different instant of time, or be spaced out over a range of time. Some con-
tacts would apply their effects in series; others would combine and act simultaneously
on the objects they affect. Some physics engines will try to accurately replicate this,
treating sequential contacts in their correct order and resolving resting contacts all
at the same time. In section 7.3.2, we'll look at an alternative resolution scheme that
honors sequential series. In chapter 18 we'll look at systems to perform simultaneous
resolution of multiple contacts.
For our engine we'd like to keep things simple and do neither. We'd like to resolve
all the contacts one at a time at the end of a frame. We can still get very believable
results with this scheme, with a considerably less complex and error-prone imple-
mentation. To get the best results, however, we need to make sure the contacts are
resolved in the right order.
If an object has two simultaneous contacts, as shown in figure 7.5, then changing its
velocity to resolve one contact may change its separating velocity at the other contact.
In the figure, if we resolve the first contact, then the second contact stops being a
collision at all: it is now separating. If we resolve the second contact only, however, the
first contact still needs to be resolved: the change in velocity isn't enough to save it.
To avoid doing unnecessary work in situations like this, we resolve the most severe
contact first: the contact with the lowest separating velocity (i.e., the most negative).
As well as convenient, this is also the most physically realistic thing we can do. In the
figure, if we compare the behavior of the full three-object situation with the behavior
we'd have if we removed one of the two lower blocks, we would find the final result
to be most similar to the case where we have block A but not block B. In other words,
the most severe collisions tend to dominate the behavior of the simulation. If we have
to prioritize which collisions to handle, it should be those that give the most realism.
Figure 7.5 illustrates a complication in our contact resolution algorithm. If we
handle one collision, then we might change the separating velocity for other contacts.
We can't just sort the contacts by their separating velocity and then handle them in
Search Nedrilad ::

Custom Search