设想一个场景：你刚看完一段酷炫的3D动画，或是玩了一款物理效果惊人的游戏，兴冲冲地想自己试试做点带真实物理的3D内容。你打开搜索引擎，找到Blender，下载安装包——3.2GB。你硬着头皮装完，打开界面，满屏的按钮和面板扑面而来。你关掉了它。
如果你只是想”在浏览器里搭个场景，扔几个方块看它们碰撞弹跳”，这个路径实在太重了。好消息是，越来越多的人正在试图让这扇门变轻。
2026年6月30日，Erin Catto——那个写了Box2D、被无数游戏开发者奉为”物理之神”的男人——宣布了Box3D。它是一个纯粹的3D物理引擎，用C17写成，MIT协议开源。但它和浏览器3D生态的关系，比你想象的要近得多。
Box3D是什么——以及它不是什么
先把澄清摆在前面：Box3D不是一个”打开浏览器就能建模”的工具。它没有GUI编辑器，没有材质球，没有场景视图。它做的事情极其专注：计算刚体之间的碰撞和物理响应。
Box3D是一个3D物理引擎库。你需要调用它的C API来创建物理世界、添加刚体、设置重力，然后每一步调用b3World_Step()让引擎推进模拟。它产出的是一堆更新后的位置、旋转和速度数据——渲染是你自己的事。
那它和浏览器有什么关系？关系在两点：一是它提供的能力恰好是浏览器3D创意工具最缺的那块拼图；二是它已经被社区编译为WebAssembly（含SIMD和多线程），可以在浏览器里直接跑。
Box2D的”3D化”：从2D物理之神到三维世界
Erin Catto这个名字，做游戏开发的人不会陌生。他2004年开始开发Box2D，这个2D物理引擎后来成了独立游戏界的通用语言——《愤怒的小鸟》《泰拉瑞亚》《地狱边境》等等都在用它。Box2D的GitHub仓库有超过8万star，是物理引擎类别里的绝对王者。
但Box2D是2D的。二十年来，每当有人问”Box2D有3D版本吗”，答案都是”没有”。Catto自己也在不同公司（暴雪、Valve、Riot）反复重写3D物理——每次换工作，这些成果就留在前雇主那里。
Box3D改变了这个局面。它是三条血脉的融合：
- Box2D v3.0的核心架构——连续碰撞检测、子步进求解器、图着色并行化、宽SIMD接触求解器
- Valve的Rubikon-Lite——Dirk Gregorius（《半衰期：爱莉克斯》的物理程序员）维护的物理引擎。Catto从Dirk那里fork了Rubikon-Lite，然后逐步用Box2D的数据结构和算法替换了内部实现
- Catto自己为《The Legend of California》做的大量优化——烘焙复合碰撞、超大型世界（用double存坐标）、服务器端物理模拟、流式加载
Lobsters上有位评论者提到一个细节让笔者印象深刻：Box3D的模拟精度高到”连Dzhanibekov效应（网球拍定理/中间轴定理）都会自然出现”。这是物理模型的保真度足够高之后，涌现出的正确行为。
从Unreal出走：为什么顶级物理程序员要自己造引擎
Box3D的诞生有一个”反派”故事——这件事在Catto的博客里写得很直白。
他在Kintsugiyama工作室开发的开放世界生存游戏《The Legend of California》用的是Unreal Engine 5。UE5自带的物理引擎叫Chaos。问题来了：
- Chaos在2024年底之前不支持陀螺力矩（gyroscopic torque），导致细长物体像永动机一样旋转不停
- 砍树系统的碰撞表现糟糕——一棵大树倒在光滑的三角网格地形上，会”瞬移”跳跃。Catto的猜测是Chaos用了某种连续碰撞的fallback方案，但在这种本应简单处理的场景下出了问题
- 游戏需要管理数十万个实体（服务器端），对宽相碰撞检测的性能要求极高
面对这种局面，Catto做了每个顶尖程序员最终都会做的事：自己写一个。他的朋友Dirk Gregorius抛来了橄榄枝——“你可以fork我的Rubikon-Lite，按你的需求改”。
这一改，就改出了Box3D。
这件事的背后逻辑值得琢磨。Unreal Engine是全球装机量最大的商业引擎之一，Epic有数百名引擎工程师。但当你的游戏需求足够特殊（巨型开放世界、服务器权威物理、大量可破坏物），通用引擎的”通用方案”反而成为瓶颈。Catto的选择很明确：“这辆车需要的轮子，市面上没有现成的”。
三条已被验证的使用者路径
Box3D刚发布，但已经有三条明确的使用者路径：
路径一：原生游戏引擎集成。 s&box（Facepunch Studios的游戏平台）、Esoterica（Bobby Anguelov的开源游戏引擎）、Glenn Fiedler的千人太空游戏都已在用Box3D。这些团队把Box3D作为C库直接链接进引擎，走编译型原生路径。
路径二：WebAssembly编译。 社区已有box3d-wasm项目（npm上的box3d包），将Box3D编译为WASM，支持SIMD 128和多线程。这意味着任何Web应用——包括Three.js场景、WebGPU渲染的交互式demo、甚至一个纯前端的3D沙盒——都能嵌入Box3D的物理模拟。在macOS上，库的release构建仅916KB，对Web加载相当友好。
路径三：作为学习参考。 Catto明确表示Box3D会持续维护，文档在逐步完善。对于一个以”代码即文档”为传统的项目（Box2D的源码一直被游戏程序员当作物理编程教材），Box3D的C17源码本身就是一份3D物理的活教材。
WebGPU时代，浏览器3D还缺什么
这里有必要快速解释WebGPU是什么，以及它为什么重要。
WebGPU是W3C制定的新一代浏览器图形与计算API，2026年全球浏览器支持率已达82%（Chrome、Edge、Safari、Samsung Internet均已支持）。它的核心突破在于两点：
-
计算着色器（Compute Shader）。 WebGL只能做渲染——画三角形、贴纹理。WebGPU可以执行通用GPU计算，这意味着粒子系统、布料模拟、流体动力学、AI推理都可以直接在GPU上跑。这对物理模拟的意义巨大：碰撞检测中的宽相查询、约束求解的并行迭代，都可以卸载到GPU。
-
接近原生的GPU访问。 WebGPU的抽象层次对应的是Vulkan、Metal和Direct3D 12这一代原生API。相比之下，WebGL对应的是OpenGL ES 2.0/3.0——一个已经停止演进的规范。WebGPU的管线状态对象、命令缓冲、绑定组等设计，让浏览器里的GPU编程不再是”降级版”。
这两点加起来，意味着浏览器端3D应用的性能天花板被大幅抬高了。Three.js 1.0已经内置WebGPU渲染器，PlayCanvas、Zephyr3D等引擎也纷纷跟进。
但浏览器3D生态还缺一个关键组件：物理引擎。 Three.js有基础的碰撞检测（raycaster），但没有刚体动力学。Ammo.js（Bullet的WASM移植）是目前最常用的Web端物理方案，但Bullet本身已经多年没有重大更新。Cannon.js和它的Rust移植Rapier都有一定用户群，但在功能完备性和社区规模上无法与原生方案的Box3D/Bullet/Jolt相比。
Box3D + WASM的组合，正在填补这个缺口。
零安装的3D创作：理想与现实之间
回到开头那个想试3D却被Blender劝退的普通人。浏览器端的3D创作工具这两年确实在爆发：
- Figuro —— 纯浏览器3D建模，免费，不需要注册
- Womp —— 浏览器端3D建模+3D打印服务
- OpenSketch —— 浏览器里的CAD，支持AI辅助建模
- Mixos —— 浏览器端3D纹理绘制工具
这些工具的共同卖点就是”零安装、打开即用”。它们做到了Figma对Photoshop做的事——把专业工具的入门门槛从”下载安装学习”降到了”点链接”。
但它们都有同一个天花板：物理模拟。 现在的浏览器3D工具能做模型、画贴图、调光照，但你很难在上面做一个”多米诺骨牌倒下”或”积木坍塌”的场景。因为这些场景需要的不是渲染，是物理。
Box3D（通过WASM）加上WebGPU的计算着色器，可以构成一套完整的浏览器端3D物理+渲染管线：GPU做碰撞检测和约束求解，CPU通过WASM做精确的刚体积分，渲染用WebGPU管线直接画到canvas上。这不是科幻——2026年的浏览器已经有能力承载这套架构。
当然，笔者必须坦率地说：浏览器3D的性能上限仍然是硬天花板。 Box3D的WASM版本在SIMD 128加速下，性能大约是原生编译的40%-60%（取决于负载类型）。对于教育演示、原型设计、中小规模场景来说完全够用；但对于一个需要同时模拟数千个刚体和数十万三角形的服务器场景，原生编译仍然是唯一选择。
谦逊声明
本文基于2026年7月公开可获得的信息撰写。Box3D目前标记为alpha阶段（即将发布v0.1），其API、功能和性能特征可能在后续版本中变化。文中关于WASM性能的估算基于社区报告和行业经验，并非精确基准测试结果。笔者与Erin Catto、Kintsugiyama工作室、Valve及文中提及的任何项目均无利益关系。
如果你对Box3D感兴趣，最好的入手方式是直接clone仓库、编译samples、阅读源码——Catto的代码风格以清晰著称，这也是Box2D成为一代程序员物理教材的原因。
参考链接：