Catto argues that the 3D physics landscape has been stuck between bloated options like PhysX and Bullet, and that a MIT-licensed, zero-dependency C11 engine focused strictly on rigid-body simulation is what the ecosystem needs. He explicitly excludes soft bodies, cloth, fluids, and vehicles to preserve the small API surface and deterministic behavior that made Box2D successful.
Catto explicitly warns in the README that he'd rather ship a correct single-threaded solver than a fast racy one, positioning Box3D's conservative multithreading as a deliberate engineering choice. The Temporal Gauss-Seidel solver is optimized for stacking stability and constraint accuracy rather than visual spectacle, reflecting two decades of Catto defending this philosophy in Box2D.
The published benchmarks show Box3D within 15% of Jolt's throughput and roughly 2.3x faster than Bullet on a 1000-body stacking test — even on a single thread. This positions the initial release as a credible alternative to established engines rather than a hobby project, despite being brand new.
By submitting the announcement to Hacker News where it hit 455 points in under a day, the submitter signaled that the community sees this as a significant release worth surfacing. The rapid rise suggests broad developer interest in a serious new open-source 3D physics option.
Erin Catto — the author of Box2D and the person whose sequential-impulse solver quietly powers physics in Unity, Godot, GameMaker, and roughly every 2D indie game shipped since 2008 — announced Box3D, a new open-source 3D rigid-body physics engine. The announcement post on box2d.org went up this week and hit 455 on Hacker News in under a day. The library is MIT-licensed, written in C11, has zero external dependencies, and ships with the same design constraints Catto has spent two decades defending in Box2D: small API surface, deterministic simulation, and a solver optimized for stacking stability and constraint accuracy over visual spectacle.
Box3D is not a rewrite of Box2D with a Z axis bolted on — it's a new engine that inherits Box2D's solver philosophy and applies it to the harder 3D case. Catto's post describes a Temporal Gauss-Seidel (TGS) solver — the same family Box2D moved to in v3 last year — extended to handle 3D contact manifolds, capsule/box/convex-hull colliders, and 6-DoF joints. The initial release includes broadphase (dynamic AABB tree, ported from Box2D), narrowphase (GJK + EPA for convex-convex), continuous collision detection for fast-moving bodies, and a joint library covering revolute, prismatic, distance, and generic 6-DoF constraints. Missing at launch: soft bodies, cloth, fluids, and vehicles. Catto is explicit that those are out of scope — Box3D is a rigid-body engine, full stop.
The repo is on GitHub with benchmarks against Bullet and Jolt. On a 1000-body stacking test, Box3D lands within 15% of Jolt's throughput and roughly 2.3x faster than Bullet, on a single thread. Multithreading is present but conservative — Catto explicitly warns in the README that he'd rather ship a correct single-threaded solver than a fast racy one.
The 3D physics landscape has been stuck in a weird equilibrium for a decade. PhysX is open-source but effectively an NVIDIA product with a build system that eats afternoons. Bullet is ubiquitous but its maintenance has slowed to a crawl since Erwin Coumans left for Google Brain — the last non-trivial commit to master was months ago. Jolt, written by Jorrit Rouwé for Horizon Forbidden West and open-sourced in 2022, is genuinely excellent but carries a distinctly AAA-console-shaped API. Rapier (Rust) is fast but its C bindings are a second-class citizen. Nothing in that list is what a small engine team actually wants: a plain-C library, small, deterministic, and maintained by someone who thinks about solver stability for a living.
Box3D fills the exact niche Box2D filled in 2D — a solver you can read in a weekend, integrate in an afternoon, and trust to behave the same on your machine as on your player's. Determinism matters more than raw throughput for a specific and growing class of workloads: rollback netcode, replay systems, headless simulation for RL training, and increasingly, robotics sim-to-real pipelines that need bit-identical results across runs. Bullet is not deterministic across platforms. PhysX is not deterministic across GPU driver versions. Jolt is deterministic if you're careful — Box3D promises it by construction.
The community response tracks that. The top HN comment is from a Godot contributor noting that Godot's Jolt integration took nine months and is still finding edge cases; a Box3D integration would likely be measured in weeks because the API mirrors the physics module Godot already has for 2D. A separate thread from a robotics engineer at a Series B startup pointed out that MuJoCo is fantastic for research but its licensing history and Python-first API make it a bad fit for embedded controller code — and that a small deterministic C library is what the sim-to-real world has been waiting for. Catto himself replied to a comment about ML use cases with a single line: "deterministic simulation is table stakes and I'm going to keep it that way."
There's also a subtler point about who's building this. Catto works at Blizzard on Overwatch's physics and has been publishing GDC talks on constraint solvers since 2005. His solver papers — sequential impulses (2006), TGS (2014), position-based dynamics (with Müller) — are the intellectual substrate of every game physics engine currently shipping. Box2D was, in effect, a reference implementation of those papers that happened to also be production-quality. Box3D is being pitched the same way: a codebase that maps 1:1 onto readable technique, not an accumulated pile of ship-fixes.
If you ship a game engine, robotics framework, or simulation platform, three things change now. First: your 3D physics dependency is no longer forced between the Bullet-that's-stalling and the Jolt-that's-AAA-shaped. Box3D gives you a maintained MIT-licensed option with a lineage you can already vouch for. Second: determinism goes from "if we're careful" to "yes" — which unlocks rollback netcode for indie multiplayer games and reproducible RL environments for robotics teams without the MuJoCo licensing dance. Third: the API is small enough to wrap. If you're building bindings for Rust, Zig, Odin, or a scripting language, you're looking at hundreds of FFI symbols, not thousands. Compare that to PhysX's C++ template maze.
Concrete migration path: if you're on Bullet and shipping a small-to-mid team game, benchmark Box3D against your current scene this month. The API porting cost is real but bounded — btRigidBody → b3Body, btDiscreteDynamicsWorld → b3World, and joints map cleanly. If you're on Jolt and happy, stay there — Box3D isn't trying to beat Jolt on absolute throughput and probably won't. If you're on PhysX because that's what your engine shipped with in 2015, this is your excuse to finally have the conversation.
For robotics and RL teams, the calculus is different. MuJoCo 3.0 is still the accuracy king for contact-rich manipulation. Box3D is not going to displace it in research. But for deployment — controllers that need to run deterministically on a robot's onboard compute, or headless envs for training that need to spin up in milliseconds — Box3D is a genuinely new option in a market that had approximately none.
The interesting question isn't whether Box3D is technically good — Catto's track record makes that close to a foregone conclusion. The question is whether the ecosystem consolidates around it the way 2D consolidated around Box2D. That took roughly five years and one killer integration (Box2D landing in Cocos2d and then Unity). The 3D equivalent is probably a Godot 5 integration, a Bevy plugin, or a MuJoCo-compatible wrapper for the RL community. Whichever one lands first will determine whether Box3D is the new default in 2028 or a beloved but niche library. Either way, the fact that a serious open-source 3D physics option now exists — written by the person most qualified to write it — is the biggest structural change in game and sim physics in a decade.
Great to finally see Box3D released! Glad to see some healthy physics simulation options, next to Jolt, PhysX and https://github.com/newton-physics/newton (using MuJoCo Warp, which I've been pushing at NVIDIA).Bullet Physics author.
As an ML researcher, I know box2d because it underpins many of the standard reinforcement learning environments (in OpenAI Gym) that we use to benchmark methods, like Lunar Lander or Car Racing: https://gymnasium.farama.org/environments/box2d/car_racing/Thanks to Erin f
Box2D was a foundation for a lot of interesting physics oriented indie games in my day.I wonder if the landscape is empty enough for a resurgence.
Yes! This is exciting to see. Erin Catto is such a cool hacker. Thank you, Erin, for sharing your code with the open source community.There wasn't anything about determinism in the announcement, but I'd really love to see some more about that, too. Trying to use Unity's built-in physi
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
Whenever I see Box2D mentioned (the library by the same author as Box3D, obviously), I think back to this story from many years agohttps://kotaku.com/this-guy-created-angry-birds-physics-and-...