Google XR Blocks 0.22.0：桌面模拟器初步支持 WebGPURenderer

来源：Google XR Blocks 官方仓库 release notes 原文链接：https://github.com/google/xrblocks/releases

结论先行

Google 的 WebXR 开发库 XR Blocks 发布 0.22.0（2026-10-10）。这一版的关键词是 WebGPURenderer 的初步支持：

  • three.js 的 THREE.WebGPURenderer 首次可以在 XR Blocks 的桌面模拟器中运行；
  • 模拟器合成器改为通过中间渲染目标渲染，SimulatorCamera、深度管线与深度遮挡都已接受 WebGPURenderer，depthmap 示例跑在 WebGPU 上；
  • 但空间 UI 尚不支持 WebGPURenderer——面板、卡片、文本输入框仍走旧渲染器。

官方对这件事的定性写得很直白："this is initial simulator support, not end-to-end coverage"（这是模拟器层面的初步支持，不是端到端覆盖）。

这个自我限定本身就是这条新闻里最有价值的信息。 它说明 WebGPU 在 WebXR 场景里的落地，目前卡在"渲染能跑通"和"整个 UI 体系能跑通"之间——而空间 UI 恰恰是 XR 应用的门面。

XR Blocks 的 Gemini 破冰助手示例：空间中悬浮一块 UI 面板显示棋盘，面板下方是提问「What's a good strategy for this game?」与回复区域，画面中可见手部追踪

来源说明

本文以 XR Blocks 官方 v0.22.0 release notes 为主要来源（2026-10-10），并参考了中文媒体（VR陀螺、映维网）的编译报道，以及官方仓库此前几个版本的 release notes 作为背景。

需要注意：官方 release notes 中没有给出任何帧率、延迟或设备兼容性数据。中文报道里出现的"端侧"表述来自官方 release notes 的用词，不是实测结果。

要点解读

1. WebGPU 支持到什么程度：逐条拆解官方原文

官方 release notes 对这一项的说明包含几个具体的技术点，值得逐条看：

官方原文要点含义
THREE.WebGPURenderer 现在能在桌面模拟器运行支持范围是桌面模拟器，不是头显设备
模拟器合成器通过中间渲染目标渲染（SimulatorCompositor，统一的 Simulator.renderFrame）合成逻辑做了改造，不是简单换个渲染器
reticle 使用 TSL NodeMaterial准星这类基础元素改用 three.js 的节点材质体系
SimulatorCamera、深度管线、深度遮挡都接受 WebGPURenderer深度相关模块已适配——这是 XR 里遮挡关系正确的前提
depthmap 示例跑在 WebGPU 上有一个可运行的验证用例
空间 UI 尚不支持 WebGPURenderer面板、卡片、文本输入框仍用旧渲染器

为什么"深度遮挡已适配"和"空间 UI 未支持"要放在一起看：深度遮挡解决的是"虚拟物体被真实物体挡住"这类空间正确性问题，属于渲染底层；空间 UI 是应用层。底层通了、应用层没通，意味着现在用 WebGPURenderer 能渲染出正确的三维场景，但没法用官方那套 UI 组件搭界面。

2. 端侧 AI 一口气加了七项

0.22.0 的另一个重头是端侧 AI 示例，数量不少：

能力说明
Gemma 4 助手结合空间场景上下文回答问题，支持 markdown 格式回复
端侧超分辨率在设备上做图像放大
EfficientSAM 圈选搜索在画面中圈选物体进行搜索；objects3d 管线从 SlimSAM 换成基于 LiteRT 的 EfficientSAM-Ti
离线空间字幕与翻译对空间场景做描述与翻译，不依赖网络
交互式 Teachable Machines可交互的机器学习演示
照片转 3D 重建从照片重建三维
单目度量深度从单张相机照片生成世界对齐的深度信息

"全部在设备上跑"是这个清单的共同点，也是它和云端 AI 路线的根本分野。对 XR 设备来说这个选择很实际——头显的算力和散热都紧张，但网络往返的延迟对空间交互又是致命的。

XR Blocks 的球池示例：手部直接抓取并抛掷彩色小球，展示基于手部追踪的物理交互

3. 空间 UI 与模拟器的升级

  • 空间 UI：新增滚动视图与可编辑文本框，卡片可以从边角调整尺寸；
  • 模拟器：新增昼夜光照模式与独立的性能分析工具；
  • 其他：ArUco 标记追踪（用于虚实物体定位）、Roomcraft 示例加入跨设备协作。

值得一提的是空间 UI 体系的历史：它在 v0.20.0（2026-08-10）作为破坏性变更引入，基于 @pmndrs/uikit 构建，提供 UICard、UIPanel、UIButton、UISlider 等一套保留式（retained）组件。也就是说这套 UI 框架上线才两个月，本身还在快速迭代中——这解释了为什么它没能和 WebGPURenderer 同步适配。

4. 工具链现代化：three.js 升到 r186

这一版做了一轮仓库级的工具链升级：

项目变化
three.js升级到 r186
构建工具Rollup → Rolldown
代码检查ESLint → Oxlint
TypeScript升级到 TypeScript 7
Gemini 调用从 generateContent 迁移到 Interactions API
默认模型改为 gemini-3.8-flash

Rolldown 和 Oxlint 这两个迁移值得单独注意：它们分别是 Rollup 与 ESLint 的 Rust 重写版本。一个由 Google 维护的 XR 库整体切到 Rust 工具链，是一个信号——前端构建工具的性能竞赛已经影响到了官方库的选型。

5. 官方没说的部分

  • 没有帧率数据：WebGPURenderer 在模拟器里跑得比 WebGL 快还是慢，官方没给数字；
  • 没有设备兼容性说明：支持范围明确写的是"桌面模拟器"，真机（头显）上的情况未提及；
  • 没有说明空间 UI 何时适配：只说了"尚不支持"，没给时间表；
  • 端侧 AI 的性能未知：七项能力都没给延迟或内存占用数据。

本站判断

第一，这是一次"方向确认"而非"能力交付"。 WebGPURenderer 能在模拟器跑通，证明 three.js 的 WebGPU 路径在 XR 场景里技术上可行；但官方自己划出的"非端到端"边界说明，现在还不是把它用在生产项目的时机。

第二，对做 Web3D 的人来说，值得关注的是 three.js 的 WebGPU 后端又多了一个验证场景。 three.js 从 r150 引入 WebGPURenderer 至今，社区验证主要集中在普通网页场景。XR 场景对渲染的要求更苛刻（双目、高帧率、低延迟、深度正确性），它能跑通本身就是对 WebGPU 后端成熟度的一次压力测试。

第三，注意 XR Blocks 的迭代节奏。 从 8 月 4 日的 v0.19.0 到 10 月 10 日的 v0.22.0，两个多月发了四个版本，其中 v0.20.0 还是破坏性变更。这个库现在处于高速演进期，接口不稳定，适合做技术预研，不适合做长期依赖。

第四，端侧 AI 那七项比 WebGPU 支持更值得琢磨。 它们回答了一个 XR 应用的实际问题：在没有稳定网络的环境里，空间交互的智能能力从哪来。Gemma 4 助手结合空间上下文、EfficientSAM 圈选搜索、单目度量深度——这些能力如果能稳定跑在头显上，会改变 XR 应用的交互设计方式。当然，"能不能稳定跑"目前还没有公开数据支撑。

第五，给做交付的人一个提醒。 XR Blocks 是 Google 的开源项目，但开源不等于可依赖。它的版本号还在 0.x，接口在变，能力边界由官方自己划定且尚未完成。把它当作观察窗口和技术储备是合适的，把它写进项目技术选型则太早。

参考来源

  1. XR Blocks 官方仓库 release notes：v0.22.0（2026-10-10）
  2. XR Blocks 官方仓库：https://github.com/google/xrblocks
  3. 中文报道：VR陀螺《Google XR Blocks 0.22.0发布：初步支持WebGPU，新增Gemma 4端侧AI及空间交互功能》（2026-10-12）
  4. 中文报道：映维网 Nweon《谷歌将WebGPU引入XR Blocks，但其自家空间UI尚无法使用》（2026-10-12）
  5. 历史版本参考：v0.20.0（2026-08-10，引入基于 @pmndrs/uikit 的空间 UI）、v0.21.0（2026-08-25，跨平台 WebXR 稳定性）