Hello,
I’m currently making a coin game and I’m having a problem with my Physics.Simulate since it causes lag from time to time. Would using multiple box colliders to outline a coin be more expensive rather than using one mesh collider?
The mesh collider option will be the most expensive option of the colliders…so I would opt to use the more efficient built in primitive colliders.
I wish there was a cylinder primitive, but there isn’t in Unity.
You will have to see how many primitive colliders you need to get the accuracy you want, then test the performance against a mesh collider.
There will be a point at which it is more efficient to use a mesh collider, but this will vary from case to case. You have to test your case to know which is best for you.
It would be interesting to find out your results though…
2 Likes
Thanks for the replies guys.
Yeah same thing I thought, though I’m wondering if the more triangles/polys (dunno w/c is the right term) the more expensive mesh colliders become, because I observed that when I bumped down the triangle count of my coin, the mesh collider also decreases in triangles (I think?).
I’ll try to test it out later.
@wintermute
The mesh collider is really expensive… and it based off the mesh itself. So yeah, if you lower the triangle count on the model you will also lower the triangle count of the mesh. You could try using a sphere collider and scale it to fit closer to the coins width. Its obviously not going to be as accurate but its def cheaper then a mesh collider.
But moonjump is right… there will be a point of diminishing returns if your building compound collisions with multiple colliders on a single mesh.
Lower the triangle count. BTW who said that a cylinder collider would be fast? Capsule is faster then Cylinder - just saying
I didn’t say a cylinder collider would be fast, just that it would be nice to have one if it was possible. A capsule collider maybe faster, but is no use if it doesn’t fit the object.
1 Like
No, you can use a high-poly mesh for display, and a low-poly mesh for collision.
–Eric
3 Likes
Turns out the mesh collider is much more expensive than the combination of box colliders.
Oh I didn’t know that. Can you please explain how?
Edit : I might have found the answer. http://answers.unity3d.com/questions/43823/using-lower-poly-colliders.html
Thanks for mentioning it
1 Like
Some additional suggestion:
You might have to change the Project settings for Time.
Had a game with 30 FPS in the making and was able to get rid of physics lags with Fixed Timestep 0.03 (30 FPS) and Max, Allowed Timestep 0.1.
The default values are 0.02 and 0.33 I guess.
Thanks for the suggestion, but I already have 0.03 on fixed timestep 
I think we’ve just discovered that scaling certain primitives can only affect the dimensions of size in equal proportions. That is, you can’t distort a sphere primitive into a flattened sphere, changing the scale of any one axis will only grow / shrink the entire sphere. Would be interested if anyone knows that this is wrong or there’s a work around, would be really useful…
Of course the plane and quad primitives seem to scale axes independently, so I guess it’s case by case.
Even though this thread is long dead might be useful for someone else…
Primitives like sphere collider, capsule etc might have a specific, cheap, way to check for collision. A sphere for example is simple to check collision with, eg a point by just checking the distance. If you were to scale it on one axis the calculations would be a lot more complex and that would be another primitive.
What actually happens is that you project a primitive to an axis and if there is no axis where the objects intersect then there is no collision. Very simplified but that is the essence of it anyway
Most answers to questions on MeshColliders efficiency basically say stay away from them, or statements such as …only use them for ground surfaces… or when no other choice.
So(Eric), are you proposing that if the (mesh)Collider associated to a gameObject is set to a mesh(with minimal triangles such as a quad) that is adequate to detect realistic collisions for that object, it is wise to optimize and use a meshCollider instead of a primitive? …and by implication this applies mostly if not entirely to flat surfaces where the traingles count can be low! …as opposed to flat surfaces that are comprised of subMeshes(as when a need for multiple materials), or flat surfaces that may have a complex shape. Thank you for any clarifications.
1 Like
I flatten spheres at will as oblong as needed in any direction! Are you referring to the collider’s size itself not the object’s, or is is on a platform where spheres cannot be flattened, or a particular version!?
Bump old thread.
Unity-devs, please, answer - is it Performance-wise to replace Convex Mesh Collider with Box, with Analogic form multiple Box Colliders?
I’m talking about thausands of static colliders
This is not entirely easy to answer without knowing more of your case. If you would replace one mesh collider with one box then the answer is quite easy, the box has 6 faces and each of them needs to be checked (this is a gross simplification BTW) and if your mesh collider has more then yes it will be quicker to check against the box. Also the box has some optimizations that can be done so is faster then a mexh collider in box form. I do not know if these optimizations are done in Unity, I just assume so.
If you instead replace each convex collider with several boxes it is harder to give a straight answer. You probably need to profile both cases and see where you end up in a few different test cases. I actually don’t know what the overhead of having multiple box colliders on an object is and if there can be efficient culling of colliders within one game object but there is at least a theoretical possibility that the sweep and prune run by the physics engine might be more efficient for an object with several small boxes than one large mesh, but the opposite may also be true…
I hope this makes some sense. Also keep in mind I do not know anything of the actual implementation of the physics engine in Unity, only how they can be built in general
Thanks for quick Answer, but nope. Nothing new, sorry.
BEFORE
- 15 700 000 static MeshCollider vertexes
- 800 000 dynamic MeshCollider vertexes
- 18 000 Mesh Colliders
- 27 000 total all Typed static Colliders
ADD: MeshColliders Variate 164 - 2 000 (beds, barrels, fences), 6 000 - 12 000 ( trucks, bikes , towers), 12 000 - 45 000 (building parts) vertexes
AFTER
- 11 500 000 static MeshCollider vertexes
- NO Dynamic MeshCollider vertexes
- 9 500 Mesh Colliders
- 98 000 total all Typed static Colliders
ADD: when possible, primitive colliders placed on same GameObject.
Prefab result screenshots sticked:
*Later would be info from Profiling in Build.
*By sight - meshColliders where better, unfortunatly
Ahh, now I understand better! What is probably happening is that when using a single meshcollider it can be easily determined that it is NOT included in a collision by checking against its bounding box(BB). This it doesn’t cause too much overhead unless there are a lot of collisions going on. Maybe several primitive colliders on one object do not add up to one bounding box, leading to the engine checking against one BB for each collider.
If you have a very dynamic environment with lots of collisions going on your results could be the opposite as resolving collision against a complex mesh is much more expensive than against a primitive
Our world is almost full static, for example 30-40 cars where static with 12k MeshCollider, and only 1-2 Cars where dynamic, in test - were not at all.
Number of contacts in profiler was 5-15 always, and didn’t changed.
Lots of dynamic barrels where frezzed at start and always manualy freezed when far from player or if stoped movement
I dont think that MeshColliders work this way, cause BB are very rough, but collision works more accurate. But principe isn’t important,
I need answer - what is more performance-wise?
- 27k mesh colliders with 16 mln vertex
or
- 98k primitive colliders
as I see in profiler - this isn’t important at all, even with such big worlds
1 Like