Box3D Open-Source 3D Physics Engine Released: A New Work from Box2D Creator Erin Catto

A New Masterpiece from the Creator of Box2D

Erin Catto, a renowned developer in the physics engine space, has officially released Box3D — an open-source 3D physics engine designed for game development and real-time simulation. For anyone working in this field, this is a milestone not to be missed: Catto is the creator of the legendary 2D physics engine Box2D.

Box2D was first released by Erin Catto in 2006, initially as companion sample code for a GDC (Game Developers Conference) talk. It quickly evolved into one of the most widely used 2D physics engines in the industry. Written in C++ and built on an Impulse-based Constraint Solver architecture, its core idea is to model physical constraints — contacts, joints, friction — as impulses (instantaneous forces), solving a Linear Complementarity Problem (LCP) iteratively to satisfy all constraints. Compared to earlier penalty force methods, impulse-based constraint solvers offer far better numerical stability when handling stacked objects and high-speed collisions, avoiding issues like interpenetration or explosive jitter. Catto's GDC 2006 talk systematically laid out this approach, and Box2D brought it to life in engineering form, profoundly shaping physics engine design for over a decade.

Background on Physics Solver Evolution: Physics engine solvers have evolved from penalty force methods and impulse methods to Position Based Dynamics (PBD). PBD, proposed by Müller et al. in 2006, satisfies constraints by directly correcting positions rather than velocities — offering unconditional stability and ease of implementation. It's widely used for cloth and soft-body simulation, and both Unity's DOTS Physics and Unreal's Chaos engine have adopted it. However, PBD is less stable than impulse methods when handling rigid body stacking and precise friction. The more recent XPBD (Extended PBD) addresses this by introducing compliance parameters. Box2D and Box3D continue the impulse constraint solver lineage, giving them a natural advantage in accuracy and stability for rigid body simulation.

Box2D is celebrated for its stability, performance, and clean API design. Unity's 2D physics system directly integrates Box2D, and major frameworks like Cocos2d-x and libGDX use it as their default physics backend. Thousands of commercial games — Angry Birds, Limbo, Candleman — rely on Box2D for physical interaction. For years, Box2D has been the benchmark project in game physics, applied across everything from indie games to commercial engines. Now, Catto has extended his deep expertise in 2D physics simulation into three dimensions with Box3D. This is not just a new technical product — it represents a significant expansion of the open-source physics engine ecosystem.

Core Technical Features of Box3D

Box3D brings several key technical highlights, each addressing a fundamental need in high-performance physics simulation.

Cross-Platform Determinism

Determinism is an extremely important yet notoriously difficult property to achieve in physics engines. Cross-platform determinism means that given the same simulation inputs, running on different operating systems and CPU architectures will produce exactly identical outputs.

Achieving cross-platform floating-point determinism is a well-known engineering challenge. While the IEEE 754 standard governs floating-point arithmetic, differences in CPU architectures (x86, ARM, RISC-V), compiler optimization levels (e.g., whether fused multiply-add FMA instructions are enabled), and OS floating-point precision mode settings can all introduce subtle numerical deviations in the same computation. In physics simulation, these deviations accumulate over time steps and can ultimately produce completely divergent results. Common solutions include: forcing fixed-point arithmetic, restricting to SSE2 instructions while disabling extended precision, and applying strict rounding control to all intermediate results. Box3D solves this within a floating-point framework — a technically demanding feat that reflects Catto's deep engineering expertise.

This feature is critical for:

• Networked multiplayer games: Clients can predict physics states locally, only needing to sync inputs rather than full state data, dramatically reducing network bandwidth;
• Replay systems: Recorded input sequences can be reproduced exactly on any device;
• Debugging and testing: Reproducible simulations make bug tracking far more reliable.

SIMD-Accelerated Contact Solving

Box3D uses SIMD (Single Instruction, Multiple Data) technology for contact solving — one of the most computationally intensive stages in a physics engine, responsible for handling constraints and responses when objects collide.

Two-Phase Collision Detection Architecture: Before contact solving begins, the physics engine must complete collision detection. This is typically split into a Broad Phase and a Narrow Phase. The broad phase uses simplified bounding volumes (such as AABBs) to quickly filter out potentially colliding object pairs, using algorithms like Sweep and Prune or spatial hashing. The narrow phase then performs precise geometric intersection tests on the candidate pairs from the broad phase, using algorithms like GJK (Gilbert-Johnson-Keerthi) and EPA (Expanding Polytope Algorithm). This two-phase design reduces the brute-force O(n²) detection complexity to near O(n log n), which is key to enabling physics engines to handle large numbers of objects.

SIMD is a class of parallel computing instructions provided by modern CPUs. Take the AVX2 instruction set on x86: a single instruction can simultaneously operate on 8 32-bit floating-point numbers, theoretically delivering an 8× throughput improvement. In the contact solving phase, the engine must iteratively solve constraint equations for hundreds or thousands of contact points — exactly the kind of highly regular batch computation that SIMD excels at.

Particularly noteworthy is Box3D's underlying data layout. Traditional engines typically use AoS (Array of Structures), storing all attributes of each object contiguously — convenient for single-object access but unfriendly to SIMD batch processing. Box3D is designed from the ground up with SoA (Structure of Arrays) layout, storing the same attribute of all objects together (all x-coordinates contiguous, all y-coordinates contiguous). This allows SIMD instructions to load the same attribute of multiple objects in one operation and compute in parallel, fully utilizing register width without extra gather operations. This low-level data structure choice often determines whether a physics engine can truly reach the theoretical peak performance of SIMD hardware.

Modern physics engines like Jolt Physics also make heavy use of SIMD optimization, while traditional engines like early versions of Bullet relied primarily on scalar operations. By making SIMD acceleration a core design principle rather than an afterthought, Box3D can simulate more rigid bodies and contact points simultaneously on the same hardware — providing reliable performance for large-scale physics scenes such as debris systems, stacked objects, and complex mechanical structures.

Challenges and Current State of Multithreaded Parallelism: Modern CPU performance gains come primarily from increasing core counts rather than single-core frequency improvements, making multithreaded parallelism a key competitive dimension for physics engines. However, parallelizing physics simulation faces inherent challenges: constraint solving is fundamentally an iterative convergence process, and constraints between adjacent objects have data dependencies that are difficult to parallelize directly. Jolt Physics uses island decomposition to assign independent object groups to different threads, while using SIMD batch processing within each island. PhysX uses GPU parallelism to accelerate large-scale particle and cloth computation. Box3D currently focuses primarily on SIMD single-threaded acceleration, and its multithreaded scaling capability will be a development direction the community continues to watch closely.

Technical Heritage: Merging Box2D and Valve Rubikon

One of Box3D's most compelling aspects is its technical lineage. The project officially acknowledges that it draws from two sources:

• Box2D's mature design: Years of battle-tested solver architecture, stability handling, and API design philosophy;
• Real-world experience from Valve's Rubikon engine: Rubikon is Valve's internally developed physics engine, used in major titles including Dota 2, CS:GO, and Half-Life: Alyx.

Rubikon is the next-generation physics engine Valve developed for the Source 2 engine, replacing the Havok physics middleware used throughout the Source engine era. Understanding this context requires knowing Havok's historical significance: Havok Physics became the de facto standard middleware for AAA games from the early 2000s onward, adopted by hundreds of top titles including Halo, The Elder Scrolls, and Call of Duty. Valve's Source engine (released in 2004 with Half-Life 2) also integrated Havok — the iconic gravity gun physics in Half-Life 2 was built on Havok. However, the licensing costs of commercial middleware, customization limitations, and barriers to deep engine integration led Valve to build Rubikon in-house when developing Source 2.

Evolution of the Commercial Physics Middleware Ecosystem: In the commercial physics middleware space, PhysX is another major player alongside Havok. Originally developed by AGEIA, PhysX was acquired by NVIDIA in 2008 and became central to its GPU-accelerated physics strategy, then open-sourced under the BSD-3 license in 2018. Unreal Engine long used PhysX as its default physics backend, until Epic introduced its own Chaos physics engine in UE5. Chaos is specifically optimized for large-scale destruction simulation and cloth simulation, demonstrating real-time building destruction in games like Fortnite. This trend shows top game studios moving away from commercial middleware toward in-house physics systems — and Box3D's open-source approach gives small and mid-sized teams equal access to top-tier physics technology.

One of Valve's core motivations for building their own physics engine was the pursuit of extreme determinism and performance — especially for Dota 2, a competitive game requiring large numbers of units to physically interact simultaneously. Rubikon demonstrated its ability to handle complex physical interactions in VR environments in Half-Life: Alyx, including precise hand grasping, object stacking, and fluid simulation. Catto himself worked at Valve and was deeply involved in Rubikon's development. This experience allowed him to combine academic-level physics simulation theory with the engineering demands of top-tier commercial games — and that accumulated knowledge is directly reflected in Box3D's design decisions. Box3D essentially brings the real-world experience of an industry-leading commercial engine back to the entire developer community through open source. This path of "commercializing top-tier technology through open source" is especially meaningful for small teams and independent developers.

Why Box3D Deserves Close Attention

Filling a Gap in Open-Source 3D Physics

In the 2D physics space, Box2D is nearly the de facto standard. In 3D, open-source options exist but the landscape remains fragmented. In the current open-source 3D physics engine ecosystem, Bullet Physics has long held a dominant position, widely integrated into tools like Blender and PyBullet — but its codebase carries significant historical baggage and its API design is widely considered unfriendly. Jolt Physics is a rising star in recent years, developed by Jorrit Rouwé, an engineer at Guerrilla Games (Sony's studio behind the Horizon series), and is known for exceptional performance and a modern C++17 code style. Jolt was designed from the start with multi-core parallelism as a core goal, using a Job Graph scheduling system to decompose physics computation into fine-grained parallelizable tasks — far outpacing traditional engines in multi-core scalability. Jolt has been adopted in AAA titles like Horizon Forbidden West, and Godot 4 adopted it as its default physics backend in 2023.

Box3D's arrival creates a new three-way dynamic in the open-source 3D physics engine space: Bullet (historical depth and broad integration), Jolt (multithreaded performance and modern code style), and Box3D (determinism and Catto's technical reputation). Backed by Catto's reputation and Box2D's brand recognition, Box3D is well-positioned to establish a unique competitive advantage in the niche of deterministic physics simulation, rapidly attracting community attention and becoming an important new option in the 3D physics engine landscape.

Architectural Advantages from Determinism

Lockstep is a classic synchronization architecture for networked games. Its core idea: all clients only sync player inputs, and each client independently runs exactly the same game logic locally, ensuring all clients maintain a consistent game state at all times. RTS and MOBA games like StarCraft, Warcraft III, and Honor of Kings all use this architecture.

However, the most troublesome engineering problem with lockstep is desync. In a lockstep model, any deviation in one client's computation from the others causes the game state to irreversibly diverge, ultimately resulting in players seeing completely different game screens. The root causes of desync are often extremely subtle: uninitialized random seeds, logic dependent on system time, non-deterministic hash table traversal order, and the hardest to track down — floating-point precision differences. Physics engine non-determinism is a frequent source of desync, because physics computation involves extensive floating-point iteration where tiny errors can amplify into completely different object positions within dozens of frames. Teams behind mobile games like Honor of Kings have publicly shared their engineering practices for tracking down desync — including building per-frame state hash verification mechanisms and full replay recording for issue reproduction — illustrating just how high the engineering cost can be.

Once a physics engine is introduced into a game and that engine cannot guarantee cross-platform determinism, the lockstep architecture breaks down. Compared to many physics engines that offer no determinism guarantees, Box3D's cross-platform determinism fundamentally eliminates this risk, providing a natural advantage for networked synchronization games. For teams building RTS, fighting, or competitive games using lockstep architecture, this feature can dramatically reduce the design complexity of the networking layer.

The Virtuous Cycle of Open-Source Ecosystems

Being open source means developers can freely read the source code, modify it, and contribute back. For a low-level infrastructure component like a physics engine, auditability and customizability are especially critical. Box3D's open-source release will powerfully drive technical sharing and collaboration across the game and simulation communities.

Summary and Outlook

The release of Box3D is an important milestone in the open-source physics engine landscape. It not only carries forward the excellent traditions of Box2D, but also brings Valve Rubikon's commercial-grade technical experience into the open-source world, equipped with two hardcore features: cross-platform determinism and SIMD acceleration.

For game developers, simulation engineers, and physics engine enthusiasts alike, Box3D is a project well worth deep study and hands-on exploration. With continued community involvement and iterative development, it has the potential to become another widely recognized open-source physics engine benchmark following in Box2D's footsteps. Of course, as a newly released project, its documentation completeness, ecosystem tooling, and long-term stability still need to be proven over time — and we look forward to seeing how it performs in real-world projects.