At what point does a mesh collider become more efficient than a group of primitive colliders?

[The docs] say that mesh colliders require more resources to compute than box colliders, but there has to be a cutoff at some point.

I found [this post], where the user claims to have reduced 53,361 simple colliders to 441 complex colliders, for a massive performance boost. We could say that a complex mesh collider is more efficient than 121 primitive colliders, but I think the switch happens before that.

[This post from 2011] touches on the issue, but does not provide any conclusive numbers.

While this is far from accurate, I'd like a set of "rules" like this:

• 5 box colliders (40 vertices total) are generally more efficient than one mesh collider with 40 vertices
  
• 10 box colliders (80 vertices total) are about as efficient as one mesh collider at 80 vertices
• Any mesh collider above 80 vertices will usually be more efficient than an equivalent number of box colliders

Does anybody understand the math, and know how these things are calculated?

 

Primitives have "shortcut calculations" behind them. Because of their simple/predictable geometry the engine can use cheaper algorithms. With mesh colliders the engine cannot take shortcuts.

Fastest way to know is to try.

You're going to be looking at the Profiler, specifically the Physics section. Watch it while play testing. It will be immediately obvious if your complex colliders are more efficient than a jumble of primitives. These stats will show you in pretty plain english how your setup performs. General rule of thumb here is the lower numbers (ms) are better.

Always always always use the simplest thing you can get away with. If a single box collider can be used for the span of a highly detailed wall that doesn't have too much depth to it, do that. Otherwise, ask yourself straight up: Do I NEED the added depth of collision? If yes, give your complex mesh a trial run against a primitive mash.

There's nothing wrong with using mesh colliders, you just need to realize how many more surfaces must now be accounted for. Sooooo, if you're trying to make a bumpy object out of a bunch of cube corners, you'll probably be saving lots of surface area, as well as lots of colliders, by using a mesh collider.

I promise you, put together like 4 different test scenarios of comparing efficiency and you'll earn an innate sense of what just works better, and what's easier to do.
Also, whether the mesh is concave or convex makes some difference to performance. And only convex mesh colliders can be used for Triggers

Also, don't use a model's own mesh as the mesh collider, unless the model has a very low poly count. You should always try to make a low-poly "physics model" for the high-poly model. The physics model will need to estimate the high-poly model as close as possible, while keeping the polygon count as low as possible.

If you don't want to go learn the math then this is less about knowing the math and more about developing your "physics engine common sense". And good news! That takes more experience than it does reading

 

Thanks to @Plystire for the great answer above. I've come to Unity from a much older game engine where physics performance was a really serious challenge, and wanted to share some tips from that perspective for the benefit of the OP and others:

• What @Plystire says about a low-poly physics mesh is spot-on, and makes a real difference, especially since many mesh colliders are not guaranteed to be a convex hull. Note that Unity has a checkbox for "Convex" on mesh colliders, because in this special case there are significant math shortcuts allowed internally.
• I have had great success using Pro Builder with Blender to create low-poly collision meshes for Unity. There are two ways I have approached this:
  • Sometimes I've used Pro Builder to make a low-poly prototype, which I then export to an OBJ format and import into Blender as a starting point for my final mesh. Instead of discarding the original Pro Builder mesh, I keep it (and possibly slightly refine it), then use that as a manually-specified mesh for the MeshCollider component.
  • You can also create the detailed model in Blender without collision, then manually use Pro Builder to approximate it once the visible mesh is in your scene in Unity. This can be either easy or very tedious, depending on the nature of the visible model and how accurate you need the collision mesh to be.
• The first of the above methods has the distinct advantage of flowing nicely into a very common developer workflow, starting with a "white box" prototype of the scene.
• As an alternative to Pro Builder as a specific tool, the above workflow can also be done entirely within Blender. As a matter of fact, I just did that yesterday working on a complex cave model. I created a model with about 6K polygons (it's a fairly large cavern) to share with the team for prototyping, then once we finalized the design, kept a copy of that as the collision mesh and refined a the visible mesh to about 10X as many polygons.
• If appropriately textured, a medium-poly or low-poly collision mesh might also be useful as a LOD mesh for the visible render.

 

As I know there is no continnous collision dettectio for dynamic MeshColliders.
This should be taken into consideration when going this route.