Meta Quest 现在是一个目标平台了

能买到的 AR 眼镜还不存在——但已经有数百万人拥有一台头显。RakuAI 现在就在用户所在之处与他们相遇,用同一份体验定义,在眼镜上市时直接延续过去。

上周末临近末尾的一次合作伙伴会面,让下一步该做什么变得显而易见。Raku 最终的产品目标是 AR 眼镜。今天的产品目标也是 AR 眼镜,但我们想要交付的那种 AR 眼镜,还不存在任何人能买到的形态。这个差距是真实的。它也令人沮丧,因为我们想让人们在这个引擎上获得的体验,不应该非得等硬件到位不可。

这个周末,我们用另一种方式弥合了这个差距。这个运行时现在可以在装有 Horizon OS 的 Meta Quest 头显上运行,处于透视 AR 模式,通过 Meta 暴露出来的 OpenXR 图层。Quest 不是我们最终要为之优化的外形规格。它是人们已经拥有的外形规格。

这次落地了什么

三个运行时 PR 以及对应的 SDK 部分:

• 带立体渲染和 6DoF 追踪的 OpenXR/Quest VR 集成
• 面向 Meta Quest 的透视 AR 模式,带合成图层和 alpha 混合
• 针对 Quest 透视 AR 的 Horizon OS 权限文档

SDK 也拿到了相应的工作:C 语言示例扩展支持 Quest VR,带平台自适应的运行时选择;关于 OpenXR 集成的详尽 Meta Quest(Horizon OS)文档;Quest VR 示例支持和 CI 验证;以及一次带平台对比的 Meta Quest 透视 AR 文档梳理。

治理方面完成了 Epic #190:Horizon OS(Meta Quest)OpenXR 支持,外加这次集成的参考文档。治理仓库中的战略文档 PR(#193)整合了本周早些时候一次合作伙伴会面的背景信息。

为什么是 Quest,为什么是现在

两个原因。

Quest 目前是空间计算领域最大的装机量。 如果你想让一个认真的 AR 体验在 2026 年触达有意义规模的受众,Quest 就是那个受众已经拥有的设备。为他们已有的设备构建,能让这个引擎在眼镜级硬件以消费级规模上市之前,先在真实用户身上证明自己。正确的做法就是在用户所在之处与他们相遇。

Quest 的 OpenXR 运行时是一个真正的实现,而不是半吊子规范。 这一点比人们通常认为的更重要。Meta 在 OpenXR 一致性上投入巨大,通过 XR_FB_passthrough 实现透视 AR,通过 XR_FB_foveation 实现注视点渲染,通过 XR_EXT_hand_tracking 实现手部追踪。Quest 暴露出来的这些扩展,正是我们的运行时两周前才开始认真消费的那些扩展。这次集成并非没有成本,但比针对一个一致性较差的 OpenXR 目标要便宜得多。

透视 AR 模式究竟做了什么

Quest 是一个以 VR 为先、在其上加装了透视 AR 模式的设备。这听起来像是一种妥协,在某些方面确实如此。但在另一些方面,它也是一种强制约束,让 Quest 上的 AR 比原本会有的更有纪律。

我们两周前为通用 OpenXR 落地的合成图层管理器,正是让透视功能干净运作的关键。摄像头透视作为一个合成图层进来。我们运行时的虚拟内容作为另一个图层进来,带 alpha 混合,使虚拟内容能正确地与用户透过摄像头看到的真实世界合成在一起。系统叠加层(Meta 自己被唤起时的 UI)则作为第三个图层、以正确的 z 序进来。

alpha 混合是微妙的部分。预乘 alpha 很重要。光照估计很重要。虚拟内容必须根据摄像头显示的环境光进行色彩校正,否则它看起来会不真实地浮在画面上。三周前落地到运行时里的光照估计工作,正是让这个 AR 模式看起来像 AR、而不是像贴在视频画面上的一张平面贴纸的关键。

Horizon OS 的权限问题

对于习惯于桌面 VR 开发的大多数开发者来说,Meta 针对透视 AR 的权限模型比预期的要复杂得多。运行时必须声明正确的清单条目,请求正确的运行时权限,并在用户拒绝其中某一项时优雅降级。周中落地的文档 PR(运行时中的 #149,加上对应的 SDK 文档)旨在让基于 Raku 构建的开发者不会撞上 Meta 出于隐私原因在摄像头画面周围筑起的权限断崖。

隐私这件事很重要。Quest 上的摄像头看到的是用户的家。引擎对这份摄像头画面做的任何事情,都必须是自愿选择加入的、透明的、可审计的。这一点在 Quest 上是真的。在人们于公共场合佩戴的 AR 眼镜上会更加真实。我们这个周末为正确处理 Quest 权限模型所做的工作,会延续到未来每一个更为敏感的部署场景中。

关于合作伙伴会面的背景

关于治理文档 PR 说一句。Meta 的开发者关系团队和我一直在交流。我不会在这个公开博客上总结那些对话的内容,因为这些对话还在进行中。我能说的是,这个周末的工程工作是在他们关心的事情的启发下完成的,而我们一直在采用的”OpenXR 优先”方法,与他们平台的发展方向是一致的。

这个周末在治理仓库里的战略文档整合,记录了会面纪要,以及工程工作是如何回应这些纪要的。这个仓库是私有的;工程回应是公开的。这个周末落地的这些 PR,就是那份公开的成果。

这意味着什么,又不意味着什么

这意味着:一个想在 Raku 上构建 AR 体验的开发者,今天就可以瞄准 Quest,今天就能触达用户。这份体验对于 AR 眼镜的外形规格来说不会是最优的,因为 Quest 不是 AR 眼镜。但这份体验会是 AR 将来会是什么感觉的一个可行预览,而且用户真的能戴上这个硬件。

这不意味着:Raku 现在是”一个 Quest 引擎”了。Raku 是一个跨平台的 AR 运行时,恰好也能在 Quest 上运行。当 AR 眼镜以我们正在优化的那种外形规格上市时,同一个引擎也会运行在其上。Quest 是若干个目标平台之一,而不是那个唯一的目标。

这也不意味着:我们在为 Quest 分叉这个引擎。每一处 Quest 特有的部分,都放在 OpenXR 图层或者 Horizon-OS 特性开关背后。如果一个开发者今天构建了一个能在 Quest 上运行的体验,同一份 .raku 体验定义明天就能加载到 AR 眼镜上,而 SDK 边界之上不需要任何代码改动。

我希望合作伙伴和构建者从中得到什么

如果你在 Meta,并且正在读这篇文章:这个周末的工程工作,是对那场对话的回应。我们想在 2026 年成为面向 Quest 的 AR 体验的认真开发者。OpenXR 相关的工作是基础,接下来的步骤取决于我们自己。

如果你是一名有经验的 Quest 开发者,正在思考 Raku 在原生 Horizon OS 开发之上还能加些什么:答案是 AI 运行时层和跨平台可移植性。存在于引擎内部、运行在仿真步进上的那套 AI 神经系统,无论你交付到 Quest 还是眼镜级硬件,都是同一套。现在基于 Raku 构建,等 AR 眼镜到来时,你会免费获得通往 AR 眼镜的通道。

如果你是一名独立 AR 开发者,正在考虑用哪个引擎来构建:Quest 是你的用户今天就拥有的设备。Raku 对 Quest 的支持截至这个周六都是真实可用的。Unity 绑定和 Unreal 绑定都能与它配合工作。SDK 快速入门包含了 Quest 的设置说明。

整个周末一百一十八次提交。周六晚上,这个引擎多了一个新的目标平台。明天早上继续搭建。