Game Development Reference
pair, we can find the closest points on the edges for that. We can treat the edges as
infinite lines; the result will always be inside the edges, barring round-off errors.
This gives rise to another variant of contact-manifold generation: we can also
only generate one single contact point per frame and have to cache the other
points. We'll have to spend memory on persistent contacts and come up with
an algorithm to cull the points, but that's a fast and viable alternative to generat-
ing the full contact manifold that is used in many of today's commercial physics
engines. It is, unfortunately, out of the scope of this chapter. If for some reason
we only have the separating axis direction (a.k.a. the contact normal), it's pretty
easy to at least find the closest vertex: by scanning all vertices or by using the DK
hierarchy. Although if we have to resort to the DK hierarchy to find the support
vertex, we probably have a high-poly object and just one face won't be enough.
4.6.6 Contact Area Tolerance Angle
To find the part of the shape surface close to the supporting contact plane, we
could start from the feature we have from the collision algorithm, such as the
GJK, EPA, and SAT, and expand to all neighboring features, stopping when we
are getting too far from the supporting plane. We'll end up with a (hopefully
convex) area on each. If a shape is high-poly, we'll have a lot of vertices to deal
with, and if it's a curved or an implicit surface, we'll have a really complicated
surface to deal with.
We really want to detect wide contact areas on both contact shapes for more
stable support in the case of either very long time steps or static configurations
(when the objects are stacked on top of each other and don't move or move very
slowly). In static configuration cases, we expect the supporting shapes (contact
Figure 4.13. Contact area tolerance angle δ Pe : (a) misaligned support features, (b) vertices
strictly inside support cone, and (c) “edge-on” contact.