Game Development Reference
In-Depth Information
return 1;
}
13.3.5
C OLLIDING T WO B OXES
The collision of two boxes is the most complex case we'll consider in detail in this
chapter. Although we're still dealing with a very basic shape, the techniques we need
to handle a pair of boxes are the ones that are used when the shapes to collide are more
complex. At the end of this section we'll look at how the box-box collision algorithm
can be extended to any pair of concave shapes.
There are six possible types of contact between two boxes, as shown in fig-
ure 13.14.
We're trying to avoid face-face and edge-face contacts because they are not stable.
A single contact point between two planes allows the planes to rotate; it is unlikely that
the contact normal will be generated so that it passes through both centers of gravity.
If we use three or four contacts instead, then the resulting contact resolution will give
a visibly more stable result.
We can always replace a face-face contact with up to four point-face or edge-edge
contacts, as shown in figure 13.15. Similarly we can replace face-edge contacts with
up to two point-face or edge-edge contacts.
The remaining two contacts, point-point and point-edge, cannot be replaced
with others. We could add the code to detect these, but neither of them has an obvious
way of calculating the collision normal (there are an infinite number of valid collision
normals for each). We'd need some extra hacked code to get a collision normal.
In systems I've built, I have never bothered to do this for two reasons. First, these
situations are highly unlikely to come up in practice unless deliberately contrived. The
chance of one box colliding with another box perfectly vertex to vertex is very slim
indeed: it's a very small target (point-edge is more likely, but still incredibly rare). Sec-
ond, if we ignore these contacts, an instant later the boxes will interpenetrate slightly.
In this case one of the other contacts (normally a point-face contact) will be gener-
ated, which is handled normally by the physics. The result is physically believable, so
the extra work simply isn't needed.
Ignoring these two types of contact means you can't construct scenarios where
boxes are carefully balanced corner to corner or edge to corner. But since that's hardly
likely to be a high priority in your game design, you can probably save yourself the
work and live with it.
The algorithm for generating contacts between boxes has the same format as that
for a sphere and a box, with one additional step:
1. We perform an early-out test using the principle of separating axes. In this case
the contact generation is complex enough that this is very likely to be worth the
effort.
2. We perform the full collision detection and contact resolution to get a single de-
tected contact between the two boxes.
Search Nedrilad ::




Custom Search