Box3D, an open source 3D physics engine

Original Article ↗ Hacker News Discussion ↗

An open-source release of Box3D, a new C-based 3D physics engine from the creator of Box2D, is drawing strong interest from game developers who value its small size, clean C API, and cross-platform determinism for networking and replay. Commenters compare it with established engines like PhysX, Havok, Bullet, Jolt, and Rapier, noting that robust, modern open 3D physics libraries are still relatively rare and that Box3D could become a key option for both native and WebAssembly games. The conversation also revisits Box2D’s legacy—from indie games and ML benchmarks to Angry Birds—and raises recurring questions about how fairly open-source maintainers are rewarded when their work underpins highly profitable products.

Ecosystem and Comparisons

  • Box3D is welcomed as a rare new open-source 3D physics engine, joining ODE, Bullet, Newton Dynamics, Jolt, PhysX, Havok, Rapier, and others.
  • Several posters compare robustness and speed: PhysX is described as very robust and stable, with Havok slightly faster but with different accuracy trade-offs.
  • Jolt is praised for web support and incremental snapshotting that helps deterministic netcode.
  • Some are eager to compare Box3D directly with Jolt, given both have strong production pedigrees.

Box2D Legacy and Evolution

  • Box2D is widely remembered as foundational for many 2D indie games, Flash-era titles, and RL benchmarks (e.g., classic Gym environments).
  • Experiences are mixed: many found it pleasant and high quality; others felt it aged poorly for arcade-style games, large worlds, or soft/deformable bodies.
  • The recent rewrite into C (Box2D 3.x / Box2C) is noted as a significant improvement, but still perceived by some as lacking soft-body tooling and easy “escape hatches” for non-realistic platformer physics.

Determinism and Networking

  • Box3D’s documentation explicitly states it is designed to be deterministic across platforms and thread counts, and includes a recording/replay mechanism.
  • This is highlighted as a major advantage for rollback netcode and networked physics, contrasting with difficulties using Unity/PhysX deterministically.
  • Some argue that for tightly scoped physics-centric games (e.g., billiards), writing a custom physics simulation may still be preferable.

Use Cases, Web, and Bindings

  • Box3D’s C API and small binary size are seen as ideal for ergonomic language bindings (e.g., Odin) and for compiling to WebAssembly.
  • The thread catalogs multiple JS/WASM physics engines (ammo.js, cannon.js, oimo.js, rapier.js, jolt.js, physx/havok wasm) and related wrappers.

Industry Context and Valve

  • Box3D originated from a fork of a Valve-related physics engine, and similar optimizations are said to appear in internal engines used in upcoming Valve titles.
  • S&box reportedly switched from Source 2 physics to Box3D, reinforcing its perceived production readiness.
  • Thread contains playful speculation about future Valve games, treating the new engine as circumstantial evidence.

Licensing, Credit, and Fairness Debate

  • A story about a blockbuster game using Box2D without initial credit triggers a long debate on open-source fairness.
  • One side stresses that MIT-style licenses legally require only attribution, not payment; the other insists that large commercial beneficiaries have a moral obligation to support key dependencies financially.
  • This leads to broader reflection on whether permissive licenses underserve maintainers, and mentions of dual-licensing and copyleft (e.g., AGPL) as alternatives.

General Sentiment and Caveats

  • Overall sentiment toward Box3D is strongly positive: people praise prior work, code quality, and are excited to adopt it in engines, web games, and VR projects.
  • At the same time, posters caution that rigid-body physics remains a difficult domain, with many open problems in collision handling and solver tuning, and that no single engine fits all gameplay needs.