Technical Questions Regarding Mesh Colliders

Bartalon

So I've been working a lot with mesh colliders and there are a couple of questions I can't manage to find much of an answer for, or at least nothing specific enough.

In regards to mesh colliders:

Do smoothing splits and UVs have anything to do with the efficiency of a custom mesh collider? A simple example would be a crate with a cube as a mesh collider. Would a cube with all smooth normals and no UV seams be more efficient than one with hard edges and UV mapped, or does Unity disregard this information?

My second question has to do with mesh colliders versus primitive colliders. I've heard all over the Unity forums that mesh colliders are always more expensive than primitive colliders, but it seems to be in the context of a mesh using itself as the collider, which obviously that would be more expensive than some primitives.

However, if I can build a custom mesh collider with fewer verts than an assembly of Unity's primitive colliders, would that still be more expensive than just using the primitives? I have heard something about Unity being able to "recognize" primitives better than custom meshes and can therefore render them more efficiently, even if there are more verts comparatively.

Any insight or links to resources is appreciated.

Thanks in advance!

Vailias

1: Uv's etc do not matter to mesh colliders. The collision is performed on a vertex to face basis.
Just think of your collision mesh being always hard edged with no UV mapping internally. You might save a little on the vertex count by keeping it all smooth normals, since that will leave the triangle ordering to the graphics engine, but its not so much that you need to stress over it.

2: primitive collisions aren't calculated against the mesh you see in the editor. The mesh is for your benefit.
The actual collision is done mathematically by volume, which is why primitive collision is always faster than mesh collision, even if you were to have a mesh cube as your collider.

IE I can define if you are colliding with a sphere by 4 numbers.
3 to specify the center, 1 to specify the radius of the sphere.

Eric Chadwick

When I was working with Havok's collision system, their mesh collider was basically a convex hull for each triangle. So it's really accurate, but also really expensive. I wonder if Unity's system does the same thing.

Bartalon

Thanks for the info, it helps considerably.

Vailias wrote: »

The actual collision is done mathematically by volume, which is why primitive collision is always faster than mesh collision, even if you were to have a mesh cube as your collider.

Does this mean a cube mesh from Maya is more expensive than a box collider component? What if the cube from Maya still had all its transform data intact, like scale and rotation?

Vailias

Yes.
A cube mesh collider will be more expensive.

The mesh data is vertices, a triangle list, and an origin. So even though it *is a cube* the collision routine has no way to know that. There may be some engines where you can tag a collision primitive with a certain prefix or something to get the engine to treat it as its mathematical equivalent but I do not believe that unity is one of those, since it provides internal collision primitives which can be used in its prefabs.

So a box mesh, imported as a collision mesh, will wind up being broken up into 12 triangles that the engine will do collision checks against. Depending on what is colliding, and how well the collision routines are done, the number of individual checks might be reduced, but possibly not.
*(I haven't seen unity's source code so there's a little speculation here based on what I've read about efficient collision design.)
So assume you have a mathematical sphere collider (like a ball or a particle or something) that collides with your box.

The game first checks some spacial structure to see what objects might interact in the next game tick, then it checks overall bounds of the two objects that might be colliding to see if there might be a collision, then, assuming there is a boundary collision it resolves to the next layer, the actual collision objects.

For the sphere vs mesh collision, the center point of the sphere has to be transformed into barycentric coordinates for a triangle of the mesh. Then you need to check if the width of the sphere intersects the plane of the triangle.
You need to do that for all 12 triangles. Collision against a mesh only gets more complex from there.

For a mathematical cube vs a mathematical sphere it breaks down to a single check of box extents and position vs sphere radius and position. (Pardon me, I don't recall the exact math right now)

This isn't to say you *shouldn't* use mesh colliders, but use them only when you need polygon accurate collision. If you can use primitives, and get equivalent, or nearly equivalent, results, then do so.

Bartalon

Thanks for all the info Vailias. In regards to the cube thing, what if I set up that cube as a Box Collider component rather than a Mesh Collider? Would it still be more expensive or would Unity be able to use that cube mesh the same as its own box collider object, since all the transformation data is still part of the cube mesh (so Unity knows how to scale and orient it)?

Thanks again.

Vailias

I think what you're asking is if you have a box mesh for your object, like a crate or something, should you use unity's box collider for collision detection?

Yes, if possible, use Unity's Box colliders (or sphere or capsule etc) since they are mathematically calculated. The mesh or wireframe you see in the viewport when the collider is selected is just so that you, the creator, can see it on your screen.

Bartalon

Sorry, let me try to articulate it a bit better.

So I've been making cube meshes in Maya to act as box colliders. I retain the transformation values with the export so when they come into Unity, I add a Box Collider component to each of these cube meshes. The existing xform information lets Unity perfectly scale the Box Colliders to the shape of my cube meshes, at which point I disable the Mesh Renderer component of the original cube mesh (the one from Maya).

I don't suspect so, but is this method more expensive somehow than adding a Box Collider to an empty GameObject and positioning it manually?

rube

maybe more expensive in that you have all those cubes sitting around in memory somewhere.. but in this case your collision is just going of the unity box colliders.

Eric Chadwick

But if you're removing the mesh components, then those verts are not in memory anymore.

Except they're still in the Project, and maybe the build will add them in the asset pack since they're probably all in a big FBX file. Probably not a problem unless you have a ton of them.