Ammo.js Soft Body Simulation CPU Performance Cost

This article examines the CPU performance impact of running multiple soft body simulations in ammo.js, the WebAssembly port of the Bullet physics engine. We will explore why soft bodies are computationally demanding, outline expected performance limits on modern hardware, and identify the primary bottlenecks and optimization strategies to maintain a stable 60 FPS in web-based 3D applications.

Why Soft Bodies Are CPU-Intensive

Unlike rigid bodies, which only track a single position and orientation in 3D space, soft bodies (like cloth, ropes, or deformable Jello-like objects) are represented by a network of vertices (nodes) connected by constraints (links/springs).

Every physics step, the CPU must calculate: * The forces acting on every individual node. * The distance constraints between connected nodes (requiring multiple solver iterations to resolve). * Dynamic collision detection for every node against other rigid or soft bodies in the scene.

Because ammo.js runs in the single-threaded environment of the browser (unless manually offloaded to a Web Worker), these calculations directly compete with your graphics rendering and application logic on the main thread.

Expected Performance Cost and Limits

The CPU performance of soft bodies in ammo.js scales non-linearly with the complexity of the meshes. Below is what you can expect on average modern desktop and mobile CPUs:

• Low Complexity (1 to 3 soft bodies, <150 vertices each): Minimal impact. Modern desktop and mid-range mobile CPUs can easily handle this at 60 FPS, utilizing roughly 5% to 15% of a single CPU thread.
• Moderate Complexity (5 to 10 soft bodies, ~200 vertices each): Moderate to high impact. Desktop CPUs will maintain 60 FPS but might see CPU utilization rise to 30-50% on the main thread. Mobile devices will likely experience thermal throttling and frame drops.
• High Complexity (10+ soft bodies or >500 vertices per body): Severe performance degradation. The CPU bottleneck will push frame rates well below 30 FPS, causing noticeable stuttering and input lag as the physics step takes longer than the 16.6ms frame budget.

Key Factors Influencing CPU Overhead

If you are running multiple soft bodies, three main parameters dictate your CPU load:

1. Vertex Count: This is the single largest factor. A soft body with 500 vertices requires exponentially more constraint solving than five soft bodies with 100 vertices each.
2. Solver Iterations: The m_numIterations parameter determines how many times ammo.js tries to resolve constraints per step. High iterations make soft bodies look more realistic and less stretchy, but double the iterations roughly doubles the CPU cost.
3. Collision Types: Soft-to-rigid collisions are relatively cheap. Soft-to-soft collisions (two deformable meshes bumping into each other) are incredibly expensive and will quickly overwhelm the CPU if multiple bodies are interacting simultaneously.

Best Practices for Mitigation

To run multiple soft bodies in ammo.js without destroying your application’s frame rate, implement the following optimizations:

• Use Physics Proxies: Run the soft body simulation on a very low-resolution physics mesh (e.g., 50 vertices), and use skinning or vertex interpolation to deform a high-resolution visual mesh to match it.
• Offload to Web Workers: Run the ammo.js physics loop inside a Web Worker. This moves the heavy calculations to a separate CPU thread, keeping the main thread free for rendering and UI interactions.
• Disable Self-Collision: Avoid enabling self-collision on soft bodies unless absolutely necessary for the visual effect.