For my work, we make tractor simulators and when we are making the vehicles, we bring the model into unity and start slapping primitive colliders all over it, trying to make them match as closely as possible to the vehicle. Obviously this takes a lot of primitive colliders, as there are a lot of weird shapes and a lot of moving parts on these machines. We only ever have one machine in a simulation at a time as of now. I'm curious if anyone has any idea of (or any idea how to figure out) at what point the large number of primitive colliders becomes less efficient than using a mesh collider?

Disclaimer: I have never used a mesh collider for something like this. and in fact I'm not even positive if it would be one big mesh collider or a bunch of separate mesh colliders, one for each part that moves separately? So feel free to call me stupid and explain. lol. Thanks!

I have worked with using multiple colliders for ‘tiles’ in my new game and honestly a mesh collider can cause worse performance due to the amount of vertices. Why do you need to use multiple colliders for each moving part?

OP said because of the non-convex complicated shape, right? I think it's a very valid question I have no answer to, unfortunately.

Why not simply benchmark it? Measure the performance with either solution and compare.

It depends also on what's colliding with what because even the mesh collider will probably have a convex hull which will be used in the broad culling phase and when it's rejected, it won't cost that much more than a convex primitive collider depending on the complexity of the hull or whatever the engine uses to speed it up (it could be a sphere or anything conservative).

@pcmaster we usually run on a pretty tight budget when making our simulations, so I would have to try to do it inbetween projects some time. But I think you are right that is probably going to be the best way to get a real answer that I know is accurate to our case.

@riptidestudios yes a mesh collider will have more vertices, however you can manually override it so that it does not have the same number of vertices as the model. You would have a high poly visual model but a low poly phsyics model for the mesh, so by doing that you could potentially bridge that gap. We need separate colliders because we are working with complex shapes such as tractor bodies, cabs, blades, buckets, etc. and we are digging through dirt, so they need to be digging in a way that looks realistic.

@garylougheed efficiency aside, I would intuitively think that a mesh collider would be the most accurate, however it doesn't seem to always be true. I'm not sure how exactly that is. Currently the model we use is compound colliders, which is just a bunch of individual colliders that are all children of a parent object with a rigidbody. According to Unity's docs, that seems to be the preferred method. But I'm not sure what the limits are with these recommendations because on some things, like a rounded bucket, we may have nearly 100 colliders on that one object, and that doesn't even include the rest of the machine. That's just the bucket. So we could be looking at 300-600 colliders in all. If we were to use mesh colliders, we'd be talking maybe…10-20 i'd guess?

@garylougheed honestly I had never heard of it before today when I was reading Unity's docs. We don't use any shear transformations so I can't say how that would work out.

ethancodes said:
I'm curious if anyone has any idea of (or any idea how to figure out) at what point the large number of primitive colliders becomes less efficient than using a mesh collider?

I suspect that “it depends on the details” will be the only answer.

How you use them, how many they are, how often they actually collide, they make a difference.

All physics systems have broad phase and narrow phase passes.

If they can tell the two objects are nowhere near each other the detailed test will never be run, so the two would be equal; the cost isn't in computing the final shape of the mesh or primitive, the cost is in evaluating the spatial tree.

If objects are near collision the tests are often an N-squared growth, every object must be tested against every other object. The growth means a large number of easy tests is more compute-expensive than a moderate number of harder tests.

Collision detection is also usually only one part, you want a collision response. You want physics to apply forces, you want hard items to be stable when they interact, you want bounce, you want torque, you want force, you want feedback so you can play effects. Each of those has costs that vary based on what you're simulating.

Games can have many thousand colliders without issue, as long as they're not all in a heap actively colliding together.

Then you've got differences between systems. Is it running in PhysX? Is it on the card or the CPU? Which card or CPU does the user have installed? Each card and each CPU has different cache sizes and different performance.

If you're really needing to figure it out for your specific case, experimentation and empirical data is probably the only way to know for certain.