Bundles and pre-baked colliders

I'm currently investigating an issue which results in mesh colliders not being availabe at run-time of our game.
We're using the Addressables system extensively to stream our game world in manageable chunks. We package scenes and models separately to reduce data duplication in the scene bundles.

Recently we came across the problem that a lot of mesh colliders don't exist at player runtime. Unity complains in this case, that the mesh is not readable. I assume unity tries to bake the collision meshes at run-time because the pre-baked data for those is not available and we set all our meshes to read/write disabled to reduce memory cost.

We have "Pre-bake collision meshes" enabled in the player settings, but this doesn't seem to be honored when asset bundles are built. I guess that's understandable (how should the pipeline know it should pre-bake a collision mesh for any mesh it is putting into an asset bundle), but I'd like to have an option to pre-bake collision meshes at bundle built-time for selected meshes to reduce memory overhead and computation overhead at runtime.

(Unity 2019.3.0f3 + Addressables 1.6.0)

 

It is definitely broken in 2019.3.0f6, but I couldn't reproduce it anymore in 2019.3.8f1 and also not in 2020.1.0b4 (same addressables version on 2019), so I assume it got fixed along the way even though I can't pinpoint it to a changelog entry.

 

Unfortunately I do see this exact behaviour in 2020.3.23f1 and addressables 1.19.17
Meshcolliders work perfectly while playing in editor, but once built on Android, many objects dont get hit by raycasts anymore.

 

I'm running into this issue with Unity 2021.2.19f1 & Addressables 1.19.19

The mesh has been built in the editor and is saved as a Mesh asset and marked as addressable.
I call Physics.BakeMesh on the asset in the editor but it seems that there is still no CollisionMeshData available for the mesh once it is loaded and assigned to a MeshCollider component.

As @einWikinger mentioned, I imagine the "Pre-bake collision meshes" in the player settings has no way of knowing this mesh is to be used as a collider.

 

After a bit of testing,

If your mesh is used in a MeshCollider component that's part of an addressable prefab then it is properly identified as requiring prebaked collision and works correctly in a build.
If you're creating the MeshCollider/ assigning the mesh to the component in script then then the mesh is never identified as requiring prebaked collision and fails in builds.

Bug reported here - https://fogbugz.unity3d.com/default.asp?1421567_1amtc91ubbunbnej

 

upd 2023. This won't be fixed lol. https://issuetracker.unity3d.com/is...d-if-read-slash-write-setting-is-set-to-false

 

Hmm not sure if this is helpful but had a similar issue where I am using addressables and assetreferneces to mesh and materials and loading objects on the fly as you move around the world. The meshes where saved as separate assets and marked addressable read only. I wanted to assign a mesh collider as well based on the mesh assetreference however ran into this issue where we would get that collider data error i.e. mesh must be read/write (also setting the assetreferenced meshes to read only for memory savings) but even IF you set them to read/write it would still give us a huge hit at that point as it does the physx.bake (and this would be every time the mesh was assigned to the collider even after the first time).

So managed to "fix" it by generating a bunch of prefabs containing only a mesh collider and pointing directly to the same mesh asset then marking that prefab as addressable.

My only thought for why this works is that the prefab, since it is now wired up to the mesh via mesh collider causes unity to prefab the collider data into the mesh when we build the addressables??? After that I do nothing else with those prefabs and do not load them at any point.

Long story short now I get no bake hit when assigning the mesh to the collider in my other addressable script loader and I can mark all my meshes read only.

 

This still works as a workaround and just saved me several DAYS of further banging my head against a wall.