Does anybody know about this? Compared to other colliders, does a mesh collider have a greater impact on performance even if it uses the same geometry?
Or are there warnings about mesh collider performance only because people tend to use high resolution meshes for this?
For example, if I use cubes and box colliders for collision with the environment, at each face of the environment, will I end up with 5 times worse performance compared to a mesh collider?, because 5 of 6 quads of the cubes would be unnecessary collision geometry?
Yes, it does. For example, a Sphere Collider is just a math equation, where as a Sphere as MeshCollider would need to test each triangle.
The heaviest impact I observed when using MeshColliders was actually the startup time of a scene. We had a scene that contained many static rocks, with lets say 100 triangles MeshCollider’s each and it took several seconds for the Scene to “Awake”. Once we approximated these MeshColliders with Primitive Colliders, this time went down to pretty much zero and the startup time of the scene was acceptable.
However, this most likely very much depends on your project. I recommend you use Unity’s Profiler to find out how much of a performance impact this has in your project.
Here are a few resources that should help you to get started with the Unity Profiler.
I did think about sphere colliders being able to reduce their calculations to the center point, but I thought that a collider like a box collider could make use of vertex positions as well, possibly resulting in the same impact on performance.
I am familiar with the profiler, though, but I thought that maybe someone here already knows about this so that I don’t run tests with a few hundred / thousands of colliders to see a difference in the profiler.
Concerning profiling a project while the work is in progress, I think it’s best to plan some things ahead so that it’s not necessary to rebuild a lot later on.
EDIT:
Just to make sure, I actually just tested a scene with 1500 cubes that can collide with an object that I moved around, using 1500 box colliders as triggers in one scene and 1500 mesh colliders as convex triggers in the other scene. I was not able to see a difference in physics calculation time, though.
Perhaps because collision detection is normally split in a broad and narrow phase. Where the broad phase is just a very cheap test if the “bounding volume” would intersect with another collider and if it does not, it can be ignored. The narrow phase is performed only on those objects, that passed the broad-phase and is the expensive “detail check”.
The collision test performed in the narrow phase would be what is expensive and different between a BoxCollider and MeshCollider.
Which means, the object that is moving around might only generate one narrow check in your test, which will not make much of a difference, no matter how many other colliders exist in the scene.
If you make that moving collider large enough, that it intersects all the 1500 colliders in that scene (such as a huge “ceiling” that moves up and down to enter and exit all colliders), that would be interesting to find out if it makes a measurable difference.
Alright, I did some further testing. You’re right that increasing the moving object’s volume will result in a measurable difference between box collider and mesh collider components on the trigger objects. There should be about 100-200 collisions per second now, resulting in top spikes of about 1.6ms for box colliders and 2.1ms for mesh colliders, with an overall impact of about 25-50% more time spent on physics calculations for mesh colliders.
I don’t know how a cube would benefit from bounding box optimizations, though. Isn’t the cube itself already the smallest volume that would be used for checking for intersections?
Early rejection checks are often implemented using the extends of an object to create an axis aligned bounding box (or volume), making the check very cheap. Inaccurate as well, but good enough for a first pass to reject many objects that don’t need to be considered for a detail check.
Means if you have a Cube with a size of xyz=100,0.1,0.1 but rotated eg 45 degrees, its bounding box (extends) would be huge, even though the cube itself is just a fine line. If you would have many of such objects, this would be quite inefficient, because they might pass the broad-phase very often, due to their gigantic axis aligned bounding volume.
You’re right. Maybe I should mention that in my tests, I didn’t rotate the cubes at all. So basically, there shouldn’t be any volume difference between a bounding box and the cube itself? Hence, no gain in using said optimization? Of course, unless Unity does some extra calculations using offset values to increase the volume for the first pass checks on small objects (I did scale the cubes down to xyz(0.2,0.2,0.2)).
EDIT:
Also, considering bounding box optimizations, mesh colliders should be quite performant, if you use them on small objects, right? Personally, I tend to use one mesh collider for the whole environment geometry (because of the docs stating something like “use as few mesh colliders as possible”), but considering optimizations, it might actually be more performant to use multiple smaller mesh colliders instead, resulting in just a fraction of specific geometry to calculate.
As long as you don’t collide with a mesh collider’s bounding box, it might be just as performant as a box collider, right?