Box3D, an open source 3D physics engine

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.