Announcing Box3D :: Box2D
Jun 30, 2026
Announcing Box3D
I’m happy to announce the release of Box3D, an open source 3D physics engine. It is now available on GitHub.
Box3D repository
You can think of Box3D as a fork of Box2D, extended with many features needed for 3D games. Some additions:
Triangle mesh collision
Height-field collision
Baked compound collision
The core architecture of Box3D remains almost identical to Box2D.
C API
All library source is C17
Sub-stepping solver
Continuous collision
Graph coloring for large islands
Wide SIMD contact solver
Multi-threading hooks
Optional internal scheduler
Large world support with doubles for position
Recording and replay
If you want to see Box3D in action, watch this video:
There are two main reasons Box3D exists. But there is a lot to unpack. So stay awhile, and listen.
Reason 1: The Legend of California
The first reason I developed Box3D is that the game I’ve been working on needs it. Let me explain.
Problems with native Unreal physics
I’ve been working on The Legend of California at Kintsugiyama since 2022. This game is built using the Unreal engine. We started with version 5.0. Our experiments with the native physics engine (called Chaos) had some problems. There was no support for simulating gyroscopic torques. This means slender shapes could spin for a long time, conserving angular velocity. For example, see this video of a spinning rifle.
In 2015 I developed a ~10 line drop-in algorithm for adding gyroscopic torques to any physics engine and presented it at the Game Developer Conference: presentation. So I could have easily added this feature to the Chaos solver. Epic added this feature in late 2024.
However, that was not my biggest problem. Being a survival game, one of the first things I worked on was chopping down trees. The falling trees moved erratically, teleporting around the screen. My best guess is that Chaos was using some sort of continuous collision fallback. This simulation was a large capsule falling on a smooth triangle mesh. This scenario should have been easy to simulate.
Another factor is that The Legend of California needs to manage a lot of entities. Hundreds of thousands of entities exist on the server. We need a fast broad-phase for this. This is so central to our game that it seemed risky to hand this off to middleware. I have a lot of experience working on broad-phase data structures. I even did a GDC presentation on the topic.
So we reached a pivot point with our physics tech. All these factors were adding up and I needed to make a decision: try to fix the native solution or replace it with an outside physics engine.
I was considering using an existing open source physics engine, such as Jolt. Being a physics programmer, I was pretty confident that I could at least fork Jolt and get the outcomes we need for our game. However, a good friend suggested another course of action.
Valve to the rescue
My friend Dirk Gregorius is an accomplished physics programmer, having shipped a custom physics engine in Half-Life: Alyx called Rubikon. Dirk maintains a hobby/home version of Rubikon. Let’s call this “Rubikon-Lite”. He suggested that I could fork Rubikon-Lite and modify it to my needs.
So that’s what I did. I hooked Rubikon-Lite directly into Unreal. It worked great! We got gyroscopic torques and trees fell nicely. Everything just worked.
The topic of replacing the physics engine in Unreal is likely a whole blog post (or more) on its own. I was able to make a few shortcuts because:
we use our own scripting system (not Blueprint)
we use the Esoterica animation system ported to Unreal
we have a custom ECS that hooks to Box3D directly
Box2D v3.0 had many optimizations I wanted to bring into my Rubikon-Lite fork. At some point I realized I needed to keep my 2D and 3D efforts as similar as possible, for efficiency and sanity. So I replaced almost all the APIs, data structures, and algorithms in Rubikon-Lite with Box2D code. Fortunately, the data structures for 2D and 3D are largely indifferent to spatial dimensions.
Eventually my Rubikon-Lite fork transformed into Box3D. Today Box3D still has some Rubikon-Lite code in the convex hull generation and some collision algorithms. The rest is code from Box2D and new code I wrote for Box3D.
On the Valve side, Rubikon continues to evolve and Dirk has developed optimizations (similar to those in Box3D) in a new engine called Ragnarok. Look for that in future Valve games.
Custom is better
The Legend of California is an ambitious project with a large open world and server authority. Falling trees, ragdolls, voxels, saloon doors, and tumbleweeds are all simulated on the server. Having a custom physics engine means I can tailor the feature set and performance to the needs of our game.
For performance, I’ve done a lot of work to optimize for falling trees. We have huge redwood trees that fall fast onto a voxel...