我很高兴地宣布开放源代码的 3D 物理引擎 Box3D 的发布。它现在可以在 GitHub 上获取。Box3D 仓库 你可以将 Box3D 看作是 Box2D 的一个分支，扩展了 3D 游戏所需的许多功能。一些新增内容： - 三角网格碰撞 - 高度场碰撞 - 预计算复合碰撞 Box3D 的核心架构几乎与 Box2D 完全相同。 C API 所有库源代码为 C17 子步求解器 连续碰撞 大型岛屿的图形着色 宽 SIMD 接触求解器 多线程钩子 可选的内部调度程序 支持使用双精度表示位置的大型世界 录制和重放 如果你想看到 Box3D 的实际效果，可以观看这个视频： Box3D 存在的主要原因有两个。但还有很多事情需要解读。所以请稍坐片刻，听我讲。 原因 1：加利福尼亚的传说 我开发 Box3D 的第一个原因是我正在开发的游戏需要它。让我解释一下。 原生 Unreal 物理的问题 自 2022 年以来，我在 Kintsugiyama 开发 The Legend of California 这款游戏。该游戏是基于 Unreal 引擎构建的。我们从 5.0 版本开始。我们对原生物理引擎（称为 Chaos）的实验遇到了一些问题。没有支持模拟陀螺力矩。这意味着细长的形状可以旋转很长时间，保持角速度。例如，看看这段旋转步枪的视频。 2015 年，我开发了一个约 10 行的直插算法，用于将陀螺力矩添加到任何物理引擎，并在游戏开发者大会上进行了演示：演示。因此，我本可以轻松地将此功能添加到 Chaos 求解器中。Epic 在 2024 年底添加了这个功能。然而，这并不是我最大的问题。作为一款生存游戏，我最早开始的事情之一是砍树。倒下的树木移动不规律，在屏幕上瞬移。我的最佳猜测是 Chaos 正在使用某种连续碰撞回退。因此这次模拟是一个大型胶囊在光滑的三角网格上掉落。这种情况应该很容易模拟。另一个因素是 The Legend of California 需要管理大量实体。服务器上存在数十万个实体。我们需要一个快速的广义阶段。这个问题对我们的游戏至关重要，因此将其交给中间件似乎风险太大。我在广义阶段数据结构方面有丰富的经验。我甚至在这方面做过 GDC 演讲。因此，我们的物理技术达到了一个转折点。所有这些因素都在累积，我需要做出决定：尝试修复原生解决方案，还是用外部物理引擎替换它。我考虑过使用已有的开源物理引擎，如 Jolt。作为一名物理程序员，我很自信，我至少可以分叉 Jolt 并获得我们游戏所需的结果。然而，一位好朋友建议了另一个行动方案。 Valve 救援 我的朋友 Dirk Gregorius 是一位杰出的物理程序员，曾在半衰期：Alyx 中发布了一个名为 Rubikon 的自定义物理引擎。Dirk 维护着 Rubikon 的一个爱好/家庭版本。我们称之为“Rubikon-Lite”。他建议我可以分叉 Rubikon-Lite 并根据我的需求进行修改。这就是我所做的。我将 Rubikon-Lite 直接接入 Unreal。效果十分出色！我们得到了陀螺力矩，树木也很好地倒下了。一切都正常运行。在 Unreal 中替换物理引擎的主题可能是一个完整的博客文章（或更多）。我能够捷径而行，是因为：我们使用自己的脚本系统（不是 Blueprint） 我们使用移植到 Unreal 的 Esoterica 动画系统 我们有一个直接与 Box3D 相连接的自定义 ECS Box2D v3.0 有许多我希望带入我的 Rubikon-Lite 分支的优化。 在某个时候，我意识到我需要尽可能保持我的 2D 和 3D 工作相似，以提高效率和理智。因此，我用 Box2D 代码替换了 Rubikon-Lite 中几乎所有的 API、数据结构和算法。幸运的是，2D 和 3D 的数据结构在空间维度上大部分是无差别的。最终，我的 Rubikon-Lite 分支转变为 Box3D。今天，Box3D 仍然在凸包生成和一些碰撞算法中保留了一些 Rubikon-Lite 的代码。其余是来自 Box2D 的代码和我为 Box3D 编写的新代码。在 Valve 方面，Rubikon 继续演变，Dirk 在一个名为 Ragnarok 的新引擎中开发了类似于 Box3D 的优化。期待在未来的 Valve 游戏中看到它。 定制化更好 The Legend of California 是一个雄心勃勃的项目，拥有一个大型开放世界和服务器权限。倒下的树木、布娃娃、体素、酒吧门以及滚动草都是在服务器上模拟的。拥有自定义物理引擎意味着我可以根据我们游戏的需要量身定制功能集和性能。在性能方面，我在优化倒下的树木方面做了很多工作。我们有巨大的红杉树，快速倒在体素地形上。让网格碰撞和 CCD 良好工作是一个巨大的努力。我还在为我们的体素系统快速构建碰撞网格方面做了工作……