> For the complete documentation index, see [llms.txt](https://megacrush.gitbook.io/megacrush-unity-assets/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://megacrush.gitbook.io/megacrush-unity-assets/runtime-navmesh-baker/runtime-navmesh-baker-user-manual/frequently-asked-questions/use-primitive-colliders-instead-of-mesh-colliders.md).

# Use Primitive Colliders instead of Mesh Colliders

## Mesh Colliders and Read/Write Access

The simple version is:\
to bake a navmesh at runtime, Unity requires **read/write access** to any meshes that are used by **Mesh Colliders** in your scene.

***

### Best Practices

* **Use primitive colliders whenever possible**\
  Box, Capsule, and Sphere Colliders are cheaper, faster, and do not require mesh read/write access. This is the best option for floors, walls, props, and most gameplay geometry.
* **Use Mesh Colliders sparingly**\
  If you need complex geometry baked from a Mesh Collider:
  * Make sure the mesh asset has **Read/Write Enabled** in the import settings.
  * Avoid using static batching on those meshes (batched meshes are not readable).
* **DynamicNavMeshSurface Defaults (v1.3.0+)**\
  When a `DynamicNavMeshSurface` is registered with the service, it is automatically configured to use **Physics Colliders** collection mode. This avoids most read/write issues by default.
  * If you explicitly switch a surface to **Render Meshes**, Unity will again require read/write enabled meshes.
  * This is only recommended for advanced cases where colliders aren’t available or sufficient.

***

### Performance Note

* Primitive colliders are faster to simulate **and** faster to bake.
* Mesh colliders not only require extra memory (read/write), but also increase bake times.
* For large, repeating environments, consider **using modular colliders** instead of a single large Mesh Collider.