Collider types and performance

Optimize CPU performance by selecting the most appropriate collider type for your scene.

Choosing the right collider type directly affects CPU performance. Unity has several collider types, each with different computational costs.

To learn more about Mesh Collider component properties, refer to Mesh collider component reference.

To learn more about collider interactions, refer to Collider interactions.

The following table summarizes the collider types and their performance characteristics in order from most to least performant:

Compound colliders

Compound colliders are formed by parenting multiple primitive colliders, such as Sphere, Box, and Capsule colliders, to a single GameObject with a Rigidbody component. You can use compound colliders, which are comprised of simple components, to approximate complex shapes. Compound colliders are generally more efficient than using a single, complex Mesh Collider for a dynamic object, but they’re more resource-intensive than a single primitive collider.

Use as few primitive colliders as possible within a compound setup to have effective collision detection.

To learn more about compound colliders, refer to Compound colliders.

Use Compound colliders when:

• You have an object whose shape cannot be accurately represented by a single primitive collider.
• You have dynamic objects that require a complex collision shape but must remain performant (as an alternative to a costly convex Mesh Collider).
• You need dynamic concave collision shapes, which a single Mesh Collider on a dynamic Rigidbody cannot do because a single Mesh Collider must be convex.
• You need fine-tuned collision zones for gameplay. For example you have distinct head, torso, or limb hitboxes on a character.

Prepare meshes for mesh colliders

Mesh Collider components require a preprocessing step called “mesh cooking” to convert their geometry into an optimized format for efficient physics calculations. If this cooking occurs at runtime, it can cause significant CPU performance spikes.

To learn more about Mesh Collider components, refer to Mesh colliders.

You can avoid mesh cooking at runtime by doing the following:

• Use Editor-Time cooking (Implicit): The primary way to pre-cook meshes is in the Editor. When you assign a Mesh asset to a Mesh Collider component in the Inspector window and save your scene or prefab, the Editor automatically cooks the mesh for that specific collider instance. The cooked data is then saved with your asset.
• Enable Prebake Collision Meshes in the Player section of the Project Settings: Enable Prebake Collision Meshes to make the Editor proactively find and cook all meshes used by Mesh Collider components in your project during builds, asset imports, and Editor loads. This setting is enabled by default. Prebake Collision Meshes can increase build times and Editor load times as the meshes process. The cooked data is stored, which slightly affects build size if many unique meshes are involved, but the main trade-off is increased build and load duration versus runtime stability. Use Prebake Collision Meshes to prevent unexpected runtime cooking spikes by ensuring most meshes are ready. The recommended best practice is to keep Prebake Collision Meshes enabled as a safety net. Consider disabling Prebake Collision Meshes only if you manually and meticulously manage all mesh cooking. For example, you rely solely on Editor-time instance cooking and Physics.BakeMesh for all dynamic cases and you want to potentially reduce build and Editor processing times.
• Use Physics.BakeMesh: For meshes assigned or procedurally generated at runtime, use Physics.BakeMesh(meshInstanceId, convex, cookingOptions) to explicitly control when cooking occurs. Preferably use Physics.BakeMesh during loading screens or in background threads if you use the job system.

Additional resources

• Unity Profiler
• Managing time and frame rate
• Memory Profiler
• Physics Project Settings
• Mesh collider component reference
• Collider interactions
• Compound colliders
• Mesh colliders