Unity 6.6 让 WebGPU 告别实验阶段，却仍默认关闭
Unity 于 9 月 1 日发布了 Unity 6.6。它是一个“受支持”版本，这意味着在 6.7 到来之前，它享有与 LTS 相同的稳定性承诺，也是 Unity 6 系列迈向该 LTS 之前的最后一站。对于所有面向浏览器发布作品的人来说，最重要的消息来自 Web Graphics 团队一周前发布的文章：“从 Unity 6000.6 开始，WebGPU 图形 API 不再处于实验阶段，现已成为完全受支持的功能。”
自 2025 年初的 6.1 版本起，Unity 就一直将 WebGPU 作为实验性后端运行。我们当时曾报道此事，此后也一直追踪浏览器端的进展，从 Safari 正式支持 WebGPU到所有主流浏览器均已支持。如今，引擎端也终于跟上了。
Unity 官方带你了解 6.6 的新增功能
WebGPU 解锁了哪些功能
WebGPU 对 Unity 尤其重要的原因在于计算着色器。WebGL 2 从未支持计算着色器，因此所有依赖 GPU 计算的 Unity 功能都无法用于 Web 构建。选择 WebGPU 后，Web 构建便可使用 GPU Resident Drawer、GPU 遮挡剔除、时空后处理升频、采用 GPU 模拟粒子的 VFX Graph、自适应探针体积以及计算蒙皮。Unity 在相关文章中展示了两个演示场景：一座密集的风格化小镇 Fantasy Kingdom，以及一个充满 VFX Graph 粒子的飞船内部场景，两者均在浏览器中运行。
VFX Graph 粒子由 GPU 模拟，因此它们过去一直无法在 WebGL 2 上使用。图片：Unity。
此外，Unity 还为那些报告支持 WebGPU、却无法处理完整功能集的硬件提供了较轻量的兼容模式，因此开发者无需执行任何额外操作，同一个构建就能覆盖更多设备。
Unity 刻意没有做什么
WebGPU 并未默认启用。WebGL 2 仍是 Web 构建的默认图形 API。要使用 WebGPU，你需要打开 Web 播放器设置，取消勾选自动选择图形 API，然后将 WebGPU 添加到列表中。Unity 会在运行时按照优先顺序尝试这些 API；如果第一个不可用，就回退到下一个。
WebGPU 必须手动添加到图形 API 列表中。图片：Unity。
文章中提到的两点注意事项，如果被忽略，很可能会让人白白浪费一天。首先，浏览器只会在安全上下文中开放 WebGPU，因此从本地文件或普通 HTTP 主机提供的构建会悄然回退到 WebGL 2，让你疑惑自己的计算功能为何消失。其次，用 Unity 自己的话说：“并非所有报告支持 WebGPU 的设备都能提供一致的体验。”因此，6.6 新增了图形设备过滤功能，通过一组规则，针对已知存在问题的特定浏览器、GPU 或驱动程序强制执行回退。
6.6 其余与 Web 相关的改进主要围绕构建体积和内存展开。在 Chrome 和 Edge 128 或更高版本，以及 Firefox 129 或更高版本中，WebAssembly64 可让浏览器构建寻址最多 16 GB 内存，而不再受原有 4 GB 上限的约束。渐进式资源加载会按场景交付资源，而不是预先一次性下载全部内容，因此玩家可以先从第一个场景开始游玩，其余内容则在后台流式加载。这两项功能都针对 Unity Web 游戏历来难以推广的两个主要原因：体积庞大和内存不足。
此版本的其他更新
在浏览器之外，快速进入运行模式现已成为新项目的默认选项，可在不重新加载域的情况下重新加载场景。Unity 将其描述为向 Unity 7 迁移至 CoreCLR 所做的准备。字典终于可以在 Inspector 中原生序列化。新的构建分析窗口可追踪构建历史和指标，内容目录则可组织本地内容，并集成 Addressables，同时在 Windows 和 Xbox 上支持 DirectStorage。Unity 为着色器改进给出的示例是：将关键字变体转换为动态分支后，构建时间从 1 小时 46 分钟缩短到 32 分钟。
这对 Web 游戏意味着什么
我们直接基于 three.js 和 WebGPU 构建，因此 Unity 将其后端提升为正式支持功能，与其说是一种竞争威胁，不如说是一种印证。浏览器 GPU 计算如今已成为安装量最大引擎中的受支持方案，这意味着会有更多游戏在发布时依赖它，更多玩家会遇到兼容性边缘问题，而浏览器厂商也会承受更大压力去解决这些问题。我们分析过面向游戏时 WebGPU 与 WebGL 的对比，也讨论过适用于 Web 的引擎选择，两篇文章中的建议依然适用：发布时启用 WebGPU 并提供 WebGL 2 回退方案，在真实的低端硬件上进行测试，并把“浏览器说它支持”视为问题的起点，而不是答案。
Unity 在受支持版本中默认关闭 WebGPU 是正确的决定，同时也透露出一个信号：API 已经准备就绪，但设备生态仍不统一，而必须在所有这些设备上运行的引擎，比任何人都更清楚这一点。