Box2D 宣布推出 Box3D

背景

Box2D 是 Erin Catto 开发的经典 2D 物理引擎，被广泛应用于各类游戏和模拟项目中。其简洁的架构、清晰的 C API 以及稳定的求解器设计，使其成为游戏物理领域最具影响力的开源项目之一。然而，在 3D 物理引擎方面，社区长期缺乏一个与 Box2D 设计哲学一脉相承、代码风格一致的开源选择。

Box3D 的作者是一位自 2004 年起就从事游戏物理引擎开发的资深程序员，曾参与多个商业项目，并在 GDC（Game Developers Conference）上发表过关于陀螺力矩算法和宽阶段数据结构的演讲。他自 2022 年起在 Kintsugiyama 工作室开发一款名为《The Legend of California》的生存类游戏，使用 Unreal Engine 5.0 构建。在项目推进过程中，团队逐渐发现 Unreal 原生物理引擎 Chaos 无法满足游戏的核心需求，这成为 Box3D 诞生的直接契机。

核心内容

Box3D 是一个开源的 3D 物理引擎，现已在 GitHub 上公开发布。从定位上说，Box3D 可以被视为 Box2D 的一个 fork，并在此基础上扩展了大量 3D 游戏所需的功能。

与 Box2D 的关系

Box3D 的核心架构与 Box2D 几乎完全一致。这种一致性并非偶然——作者明确表示，他刻意将 2D 和 3D 的代码库保持高度相似，以降低维护成本并减少心智负担。Box3D 继承了 Box2D v3.0 的诸多优化成果，包括：

• C API：保持与 Box2D 一致的纯 C 接口风格
• C17 标准：所有库源码使用 C17 编写
• 子步求解器（Sub-stepping solver）：提升模拟稳定性
• 连续碰撞检测（Continuous collision）：防止高速物体穿透
• 图着色（Graph coloring）：用于处理大型岛屿（islands）的并行求解
• 宽 SIMD 接触求解器（Wide SIMD contact solver）：利用 SIMD 指令加速接触求解
• 多线程钩子（Multi-threading hooks）：提供多线程扩展能力
• 可选内部调度器（Optional internal scheduler）：灵活的任务调度机制
• 大世界支持（Large world support）：位置使用双精度浮点数（doubles）
• 录制与回放（Recording and replay）：支持模拟过程的记录和复现

新增的 3D 功能

相比 Box2D，Box3D 新增了三项关键的 3D 碰撞能力：

• 三角形网格碰撞（Triangle mesh collision）：支持任意三角形网格之间的碰撞检测
• 高度场碰撞（Height-field collision）：针对地形高度场的专用碰撞处理
• 烘焙复合碰撞（Baked compound collision）：将多个碰撞形状预处理为优化的复合数据结构，一次性加载，大幅减少内存开销和运行时创建开销

诞生原因一：《The Legend of California》的需求

作者开发 Box3D 的第一个原因，是他正在开发的生存游戏《The Legend of California》对物理引擎有非常特殊的需求。

Chaos 引擎的问题

《The Legend of California》使用 Unreal Engine 5.0 构建，最初采用 Unreal 的原生物理引擎 Chaos。但团队在实验中发现了多个严重问题：

1. 陀螺力矩缺失：Chaos 不支持陀螺力矩（gyroscopic torques）的模拟。这意味着细长形状的物体可以长时间保持旋转，角速度几乎不会衰减。作者展示了一段视频中，一支步枪在空转了很长时间后仍不停歇。作者本人在 2015 年 GDC 上曾提出过一个仅约 10 行的即插即用算法，可以为任意物理引擎添加陀螺力矩支持，理论上他可以轻松将此功能加入 Chaos 求解器。但 Epic 直到 2024 年底才正式加入这一特性。

2. 树木倒塌模拟异常：作为生存游戏，砍树是核心玩法之一。但倒塌的树木运动极不稳定，在屏幕上"瞬移"。作者推测 Chaos 使用了某种连续碰撞回退（continuous collision fallback）机制。模拟场景其实很简单——一个大型胶囊体落在光滑的三角形网格上——本应不难模拟。

3. 大规模实体管理：《The Legend of California》的服务器端需要管理数十万个实体，因此需要一个高效的宽阶段（broad-phase）碰撞检测数据结构。作者在这一领域经验丰富，甚至做过相关 GDC 演讲。将如此核心的模块交给中间件，风险太大。

转向 Rubikon-Lite

面对这些问题，作者面临一个关键决策：是尝试修复 Chaos，还是替换为外部物理引擎。他考虑过使用 Jolt 等现有开源物理引擎，但好友 Dirk Gregorius 给出了另一个建议。

Dirk Gregorius 是一位资深物理程序员，曾在《Half-Life: Alyx》中交付了名为 Rubikon 的自定义物理引擎。他维护着一个 hobby 版本，作者称之为"Rubikon-Lite"。Dirk 建议作者 fork Rubikon-Lite 并按需修改。

作者采纳了这个建议，将 Rubikon-Lite 直接接入 Unreal，效果非常好——陀螺力矩正常工作，树木倒塌模拟也变得自然。

从 Rubikon-Lite 到 Box3D

在将 Rubikon-Lite 接入 Unreal 的过程中，作者利用了几个有利条件：团队使用自研脚本系统（非 Blueprint）、使用移植到 Unreal 的 Esoterica 动画系统、以及一个直接对接物理引擎的自定义 ECS（实体组件系统）。

随后，Box2D v3.0 的诸多优化让作者希望将其引入自己的 Rubikon-Lite fork。但他很快意识到，必须将 2D 和 3D 的代码库保持尽可能相似，否则维护成本将难以承受。于是，他几乎将 Rubikon-Lite 的所有 API、数据结构和算法替换为 Box2D 的代码。由于 2D 和 3D 的数据结构在空间维度上具有高度的同构性，这一替换出奇地顺利。

最终，Rubikon-Lite fork 演变为 Box3D。目前 Box3D 中仍保留部分 Rubikon-Lite 代码，主要集中在凸包生成（convex hull generation）和一些碰撞算法上，其余部分来自 Box2D 以及作者为 Box3D 新编写的代码。