2
\$\begingroup\$

For components like MeshRenderer, Unity uses two references to mesh through script--mesh, and sharedMesh. My understanding as of yet that setting a "sharedMesh" will affect every GameObject that uses that component, whereas "mesh" alone will only affect a particular instance of that component. Same goes for "material" and "sharedMaterial".

However, for MeshCollider, the only thing available is "sharedMesh". The field "mesh" does not exist. I can work with this, but from a policy standpoint it seems very strange to me. Is there a reason that MeshCollider is treated differently?

I may be overlooking something obvious, but a Google search didn't help me.

\$\endgroup\$

2 Answers 2

2
\$\begingroup\$

The "mesh" property of a MeshFilter, like the "material" property of a renderer, is a convenience for making per-object modifications.

When you read from this property, it checks if it's already duplicated a unique instance of this mesh (or material) and, if not, it copies the current mesh (or material) it's using and hands you that copy, which is now unique to the object you're working with. This means a simple/naive script won't accidentally modify a shared asset used by multiple instances, or muck with source asset files in your project folder.

When you don't want this auto-copy behaviour, you access the sharedMesh (or sharedMaterial) to explicitly acknowledge in the code that the asset might be in use in other places, and accepting responsibility to deal with that yourself.

It's likely that for the MeshCollider case, the developers of the API didn't see making per-object variations of shared physics assets as such a common use case, compared to making purely visual changes to meshes and materials, so they didn't build-in an automatic copy. You can implement this behaviour yourself if you need it by using the Instantiate() method on the sharedMesh.

\$\endgroup\$
1
  • \$\begingroup\$ ...and mesh colliders are a massive expense on the CPU, so forcing shared colission meshes could have been an optimization. \$\endgroup\$ May 25, 2018 at 2:12
1
\$\begingroup\$

Ultimately it's just the name of the variable indicating its intention is to re-use the mesh that's part of the game object/visual representation:

The Mesh Collider builds its collision representation from the Mesh attached to the GameObject, ... Optimization tip: If a Mesh is used only by a Mesh Collider, you can disable Normals in Import Settings, because the physics system doesn’t need them.

Setting this value won't affect every GameObject using the component.

The implication is that changing the mesh of the GameObject would affect the collider (though there appears to be some caveats to that: it won't necessarily take effect straight away).

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .