Ammo.js vs Oimo.js Physics Execution Speed

This article compares the raw execution speed of ammo.js and Oimo.js, two prominent 3D physics engines used in web-based game development and simulations. By analyzing the structural differences between a WebAssembly-compiled C++ port (ammo.js) and a lightweight, pure JavaScript engine (Oimo.js), we explain how their execution speeds differ under various simulation workloads.

The Architecture Difference

To understand their execution speeds, you must first understand how both engines are built.

• ammo.js is a direct port of the robust Bullet Physics engine written in C++. It is compiled into JavaScript and WebAssembly (Wasm) using Emscripten.
• Oimo.js is a native, pure JavaScript translation of the OimoPhysics engine, designed specifically for lightweight 3D rigid body simulations.

Raw Execution Speed in Low-Complexity Scenes

For simple scenes with a low number of rigid bodies (under 100 active objects), Oimo.js often matches or even exceeds the execution speed of ammo.js.

Because ammo.js runs inside a WebAssembly memory heap, any interaction between your application’s JavaScript code and the physics engine requires data to be passed across the “JS-to-Wasm boundary.” For simple simulations, the overhead of translating data (like positions and rotations) back and forth across this boundary can be larger than the actual physics calculation time. Oimo.js, being written entirely in JavaScript, avoids this boundary overhead, resulting in faster execution for basic scenes.

Raw Execution Speed in High-Complexity Scenes

When the simulation complexity scales up—featuring hundreds of colliding bodies, complex constraints, or ragdoll physics—ammo.js decisively outperforms Oimo.js.

The WebAssembly execution of ammo.js allows it to perform low-level mathematical computations, such as matrix transformations and collision detection algorithms, at near-native C++ speeds. WebAssembly bypasses the browser’s JavaScript garbage collector and benefits from highly predictable memory layouts.

In contrast, Oimo.js starts to bottleneck as the object count rises. As a pure JavaScript engine, it is subject to runtime optimizations and garbage collection pauses, which can cause sudden drops in frame rate (micro-stuttering) during heavy physics computations.

Feature Set vs. Performance Overhead

The raw speed of these engines is also tied to their feature complexity. Ammo.js is a full-featured physics engine supporting soft bodies, vehicle physics, complex trimesh collisions, and advanced constraints. This extensive feature set makes its codebase much larger, leading to longer initial loading and parsing times.

Oimo.js intentionally limits its feature set to basic rigid body shapes (spheres, boxes, and cylinders). This simplicity allows the engine to run highly optimized, specialized code paths that execute very quickly, provided the simulation remains within the engine’s limitations.

Summary of Speed Characteristics

• Use Oimo.js if your project requires maximum execution speed for simple physics (e.g., basic collisions, rolling spheres) with minimal loading time.
• Use ammo.js if your project demands high-performance scaling for complex environments, numerous interacting objects, or advanced physics simulations where WebAssembly’s raw computational superiority is required.