Chrome浏览器藏了3年，这个物理引擎让网页游戏帧率翻了4倍

2023年，Google工程师在Chromium代码库提交了一个叫"WebGPU"的接口。当时没人想到，两年后有人用它把学术论文里的物理算法，直接搬进了浏览器。

这不是Demo。是一个叫AVBD的求解器，全称Augmented Vertex Block Descent，2025年刚发表的论文成果。作者把它实现了，开源了，跑在Chrome里。

物理引擎的脏活累活，浏览器以前干不了。

刚体碰撞、软体形变、摩擦计算——这些在传统游戏里靠C++硬怼，在网页端要么阉割，要么卡成PPT。WebGL时代不是没人试过，但计算管线太老，数据在CPU和GPU之间来回搬运，延迟直接吃掉手感。

WebGPU改的是架构。它把GPU计算着色器（Compute Shader）暴露给JavaScript，让物理模拟直接在显存里跑完全程。没有搬运，没有等待，帧时间从16毫秒压到4毫秒以内。

论文算法怎么变成浏览器代码

AVBD的核心思路很刁钻：把物理系统拆成"颜色块"，同颜色的物体并行计算，不同颜色串行依赖。贪心着色算法先给场景里的刚体分色，求解器按颜色批次处理，GPU利用率拉满。

作者复现了论文里的完整管线。从LBVH（线性包围体层次结构）的粗测阶段，到窄相接触流形生成，再到带热启动的约束求解——每一步都对应论文Algorithm 1的具体行号。

热启动（Warm Start）是手感的关键。

上一帧的接触状态缓存下来，下一帧直接复用。玩家感觉不到的那种"粘滞感"，往往就是冷启动时约束求解没收敛导致的。这个实现把接触状态持久化到每个流形里，摩擦计算也跟着稳了。

代码结构很直白：PhysicsEngine.ts里一个主循环，按时间步子调用粗测、细测、约束收集、着色、惯性目标初始化、主迭代、对偶更新、速度重建。八个阶段，每个阶段都有对应的GPU管线。

为什么现在只有Chrome能跑

WebGPU规范2023年定稿，但Safari和Firefox的实现进度落后半年到一年。这个原型明确标注"Chrome only"，不是作者偷懒，是别家浏览器的计算着色器支持还没跟上。

更现实的问题是：这不是即插即用的npm包。想跑起来，得clone仓库、装依赖、本地编译。作者说得很清楚——proof of concept，概念验证。

但概念验证到什么程度？

刚体管线完整跑通，软体原型也在里面。约束类型覆盖接触、关节、弹簧，着色器代码直接写在TypeScript里，用模板字符串插进GPU。调试信息、休眠机制、性能诊断，这些游戏引擎标配的周边功能，作者标了"optional post-processing"，意思是核心算法之外，慢慢补。

浏览器游戏的技术债，有人开始还了

过去十年，网页游戏的技术栈卡在两个极端：要么是轻量级的2D Canvas小游戏，要么是流媒体串流的假网页游戏。真正的3D物理交互，一直是原生应用的领地。

WebGPU+AVBD的组合，把领地边界往后推了一步。不是说要替代Unity或Unreal——那太远了——而是证明浏览器能承载的复杂度，比大多数人想象的高一个数量级。

作者的身份很有意思：产品经理背景，业余做开源图形实验。代码仓库里写着"I ❤ working on advanced web graphics open source experiments"，打赏链接挂在README里。这种个人项目，往往是技术风向的最早信号。

2025年的这篇AVBD论文，本身是针对传统游戏引擎的优化。两个月后就有人把它塞进浏览器，还开源了。学术到工程的转化速度，在WebGPU这个赛道上快得反常。

反常的背后是需求积压。云游戏烧了那么多钱， latency问题始终绕不过去。如果浏览器本身能跑高质量的本地物理模拟，很多场景就不需要串流了——尤其是多人协作、创意工具、可交互叙事这些对延迟敏感的类型。

这个项目现在有多少star？作者没提。但代码的组织方式透露了野心：物理引擎、渲染管线、场景管理，三层解耦。不是一次性Demo，是想长期维护的架构。

浏览器能不能成为下一代游戏开发的主战场？Chrome已经铺好了GPU计算的基础设施，剩下的看物理、音频、网络层能不能跟上。这个AVBD实现，是物理层的第一个扎实脚印。

你会在浏览器里玩一个需要精确物理反馈的射击游戏吗？还是认为原生应用的技术护城河，五年之内都跨不过去？