Nonconvex manifolds may require additional contacts

[RossNordby]

The narrowphase currently assumes manifolds have a maximum of 4 contacts. This is perfectly fine for convex manifolds, but it is unlikely that a constraint based on 4 contacts will be able to handle all the necessary degrees of freedom in a complex nonconvex pair.

One pathological example: a mesh with 6 spikes with one point touching each face of a cube. While a use-maximum-penetration-depth heuristic could be used to retroactively stop the worst penetration and stop the cube from falling through the mesh, there will always be some spike which lacks a contact. Any force pushing in that direction will not be counteracted until that spike's contact is included in the reduced manifold.

The actual impact should be tested. If the behavior is not acceptable, there are some obvious options:

1. Allow more contacts in nonconvex manifolds. For example, 8 contacts may be sufficient to eliminate noticeable issues in all practical cases. The end result depends heavily on the heuristics chosen to reduce the many submanifolds.
2. Allow arbitrarily many submanifolds per pair. This is the v1 solution, and it's not great. It either sacrifices SIMD occupancy or explodes the number of constraint batches.

My guess for now is that 4 contact manifolds will work most of the time, even for complex nonconvexes, and that 6-8 contact manifolds will suffice for the remaining cases. The heuristic tuning is a little worrisome- high quality heuristics that take into account constrained directions might be too expensive.

[RossNordby]

As of the alpha, the infrastructure exists to create up to 8 contacts per nonconvex pair. The contact reduction mechanism (constrainedness heuristic) appears to work pretty well.

I did, however, arbitrarily limit the number of output contacts to 4 for now, just to see how far that can go. If no one runs into some pathological case that simply requires more contacts, this is a nice performance win.

[RossNordby]

After some extra work on nonconvex reduction heuristics in the beta version, it works remarkably well. Not quite ready to close the door on more contacts until more representative mesh/compound tests are done, but it's very promising.

[RossNordby]

A few use cases definitely do benefit from additional contacts, so it's likely that the contact cap will be raised. However, it's not good enough to just raise the cap- some cases benefit from a lower cap.

The best solution would be an improved NonconvexReduction heuristic which is able to output an appropriate number of contacts rather than just accepting all candidates up to the limit if available.

[RossNordby]

github, that wasn't intended as a reference shoo

also, the nonconvex reduction heuristic was improved; shipping with 4 contact cap. Seems fine until proven otherwise.