100 Primitive Colliders vs. 1 Custom (CPU Overhead)

Hi,

Sorry if this has been answered, but I read the Unity manual on collision, and couldn't find anything about it on Google either.

Would there be any CPU benefit to authoring a single collider mesh that provided the same collision as 100 primitive box colliders? Not a custom collider that simply enveloped the 100 static meshes, but a single COL mesh made up of 100 boxes to be used as collision for static objects placed around the scene. Or are primitive colliders cheap enough that it's negligible?

Thank you for any help.

 

All documents I've read tell you that a group of primitive colliders is always preferable over a mesh collider... however I think we shouldn't take the word "always" as written on stone, I guess there must be a point of balance, in which a mesh collider is more efficient than a bunch of primitive colliders, the problem is that only the people who wrote the code can tell, and as far as I know there's no official document that tells you what is that point. For example if you have a mesh made of 100 triangles that can be approximated by using just 3 box colliders is best to use the primitive colliders, but I don't know if a mesh made of 100 triangles is more efficient that 100 box colliders, and as long as Unity doesn't publish a document telling us how much does it cost each triangle compared with each of the primitive colliders we can only guess. If we knew each triangle in a mesh collider costs the same as X box colliders or Y sphere colliders or Z capsule colliders, we could do the math to make the best decision on each case.

On the other hand you also need to be practical, there's also a point in which you time is better invested doing something else than figuring out where to place the next collider and aligning in properly just to realize you edited the wrong collider.

Also precision if a factor to take into account, if you need you collision detection to be precise you definitively should consider the use of a mesh collider over a set of primitive colliders.

 

for reference also, can do some cool stuff with job system,
https://github.com/LotteMakesStuff/SimplePhysicsDemo
https://twitter.com/LotteMakesStuff/status/964612077708070912

 

Just to be sure, are you referring to Unity's "Mesh Collider" component, or a custom mesh created in a 3D app? It sounds a bit like you're referring to the former, but I'm referring to the latter. Unity's "Mesh Collider" component is expensive on anything but super simple geometry, so I avoid it at all costs (unless the scene isn't intensive, and there's plenty of room for overhead).

Yes, that info seems impossible to find. Logically, it seems it would be more efficient to have a single authored collision mesh, rather than lots of primitive colliders, since it's less collision objects for the CPU to keep track of. But I just don't know enough about how primitive colliders are calculated at runtime.

(Note: For clarity, when I mention 100 colliders, that's for 100 static meshes. The idea I am investigating is if I can author just a single collision mesh for those 100 static meshes, rather than using 100 primitive colliders.)

Actually this is only for when the scene is locked-down, and nothing will change. The pipeline is to export out the scene objects as FBX to Maya, create simple collisions for them, then merge that custom collision mesh into a single object that can then be placed in the static scene, providing the needed coverage, but with far fewer colliders. I guess I'll just have to figure out a good, quick test to see for myself.

Thanks for the reply!

 

Neat! Thanks for the link. Though, the collision I need is purely to prevent the Player from passing through static meshes. Physics would be a luxury

 

my guess would be the 100 colliders. mostly because in typical cases 99 of them could be easily ruled out in the higher level physics collison testing passes. then for any colliders that could possibly interact it would do the more time collison followed by response.

by having a single mesh i believe now everytime you are forcing it to evaluate every triangle everytime. i do not believe there is any spacial sorting applied inside a mesh collider.

but for all things like this you need to profile. start with one. if the results are fast enough move on. if you have enough time then obviously try both and pick the best.

but you need to test your most complex cases. at smaller numbers its possible meshcollider comes out faster. but as you add more areas it would change to seperate colliders.

 

I think you're right. My initial testing so far is showing negligible results. Thanks for the reply!

 

Please enlight me, because as far as I know the only way to plug a mesh made on a external 3D modeling application into the physics engine is by attaching a mesh collider component to it, but if there's a better way to do it, I really want to know it.

 

No, you are correct. Just wanted to confirm we were talking about the same thing. But it's all good. Did some tests, and the results are that Unity's primitive colliders are really cheap.

 

If you don't mind I would like to see some numbers, your findings could be a good starting point for others to solve similar doubts.

 

Let's just say Unity's primitive colliders seem to be hyper optimized. Did a test with 1,000 cubes, each with a box collider. CPU was around 2.1~2.3ms. Then I deleted all 1,000 box colliders, leaving only the cubes, but the CPU time didn't seem to change at all.

 

I don't know if you are being too hasty to draw conclusions here, if you didn't compare performance with your mesh collider, you may be deceiving yourself... maybe the mesh collider is not as expensive as you think. Right now I can't come up with a good benchmark idea, but in order to have a more accurate measurement I would perform some physics interactions and throw some raycast... you don't know the physics engine internals, maybe it just remains idle when it knows there's nothing moving around (that's something I would do if wrote my own physics engine) in such case any collier (mesh or primitive) is optimal.

 

Good points, but for now I'll just stick to primitives. In the middle of a move which is consuming most of my time, so no time to do any in-depth testing at the moment.

 

I find it very unlikely that a single mesh collider would be faster other than maybe in the simplest of cases.
The test would be to take all of his cubes, combine them into one mesh and then add a mesh collider.

The problem here is that the physics engine is going to put some bounds on this.
So even though you may not be inside some of the triangles, you are still in the overall bounds.
So every frame, raycast, etc it will have most likely hit this outer bounds and then have to evaluate the slower triangle tests to check if you have actually hit anything in this mesh.

Where with the individual colliders, assuming they are small and localized, is that in the higher level tests the physics engine can completely skip a whole lot of these. (special data structures) It can do much faster simpler collision tests to eliminate them before even doing the slower box on sphere, box on box tests.
Also sphere and box tests are pretty fast and so I think testing more than a few triangles in a mesh it will be slower.

But having numbers would be better to verify, but using multiple simple colliders is usually the way to go.
Unless maybe you had some really unique setup.

 

Test it, go based on the data not theory. In my game simple convex colliders vs box is basically white noise even with a couple hundred of them, but context matters so just test it yourself.

 

Your right, but looking at his question it was replacing 100 box colliders I am assuming spread out across a level.
With one massive mesh collider.

If you had lots of smaller localized mesh colliders vs other colliders it probably won't make too much of a difference. Because the same high level culling would help eliminate most of the colliders.

 

I am not saying a mesh collider is faster (or could be), what I am saying is that if you don't do a proper benchmark you can draw wrong conclusions. A primitive collider is by all means more efficient than a mesh collider but no one knows the order of magnitude, no doubt a mesh collider is expensive but maybe not as much as you think, however the only way to know for sure is by doing a well thought benchmark.

If you had an accurate measurement, you cloud make more informed and wiser trade offs, for example you cold balance the performance cost of a mesh collider against the effort required to place and align properly each primitive collider, remember we're talking about 100 colliders, doing such job manually may not sound too hard, but believe me, it could become a real nightmare. At some point the (human) effort required to set up an array of primitive colliders overweights the performance cost of a single mesh collider.

 

obviously its 100 primitives.. unless your collision mesh is larger than 600 poyls...

I'm assuming a cube collider AND that the 100 primitives do not collide with themselves

personally, I would go with the 100 boxes, as you can dynamically turn them on/off individually, if you need. I'm assuming everyone is making spaceships...