用 OpenXR 帮助 XR 行业成长——高通和神木是怎么做的-CSDN博客

本文链接：https://blog.csdn.net/XRealityZone/article/details/140842505

高通与 Snapdragon Spaces Platform

高通这个名字，想必大家应该会非常熟悉。作为 Android 阵营芯片市占率遥遥领先的行业引领者，高通也一直对于 XR 领域非常关注。而我们所熟知的 Quest 上所搭载的芯片，就是高通推出的 Snapdragon XR 系列芯片。

尽管主业是芯片制造，但高通公司的想法并不止步于此，为了能够在 XR 领域中获得更多的终端用户，高通发挥出了他作为芯片厂商的天然优势——跨设备兼容，在 2021 年推出了 Snapdragon Spaces XR Development Platform。在这个平台上，只要是基于高通骁龙芯片开发的硬件产品，都可以进一步降低适配成本：不需要自己再完全实现一个 OpenXR Runtime。而上层的应用开发者则都可以基于 Snapdragon Spaces SDK 快速实现 XR 应用开发。

这里，我们提及到了一个新的名词——OpenXR。要想解释清楚 Snapdragon Spaces SDK 是什么，能实现什么，我们就必须要先搞清楚，OpenXR 是什么。

什么是 OpenXR？

如果我们在搜索引擎搜索，或者，直接寻求 ChatGPT 的帮助，大概率我们能够得到的答案是这样：

OpenXR 是由科纳斯组织（Khronos Group）管理的一个工作组，旨在设计一个面向虚拟现实（VR）和增强现实（AR）的标准。Khronos Group 于 2017 年 2 月 27 日在 GDC 2017 期间宣布了 OpenXR。2019 年 7 月 29 日，OpenXR 1.0 由 Khronos Group 在 SIGGRAPH 2019 上向公众发布。2024 年 4 月 15 日，Khronos 发布了 OpenXR 1.1。

很好，看完了上面的解释，可能我们会就像下图一样：

概念性质的东西终归是不好理解，那，一种比较好的理解新事物的方式是，先了解这个事物出现之前，这个世界存在什么问题？那我们不妨先看看，在 OpenXR 出现之前，这个世界是什么样子的。

在 OpenXR 发布（2017）之前，市面上其实已经出现了不少 AR/VR 的产品，例如：

HoloLens，发布年份： 2016 年
HTC Vive，发布年份：2016 年
Oculus Rift，发布年份：2016 年

尽管各家硬件厂商的产品各有不同，但实际上要解决的基本问题都是差不多的。例如，大家首先都要根据硬件设备的传感器，实现 XR 设备的 3DOF 或者 6DOF 的追踪；同时，针对一些拥有手柄的硬件，还需要对手柄实现实时的感知和追踪。

而在上层，针对这些硬件产品，一般会有三种类型的开发者需要进行开发：

游戏引擎开发者：游戏引擎开发者需要将自己的引擎适配到新的硬件产品上
应用开发者：应用开发者一般不会直接使用游戏引擎进行开发，因此也得针对各款设备提供的 SDK 进行针对性的开发
Web 浏览器开发者：由于 Mozila 发布和推动的 WebXR 之前的早期技术——WebVR 的出现，导致浏览器引擎也需要在这些 XR 硬件设备上进行兼容性适配。

但由于各家的硬件不同，在 SDK 的接口设计上，各家都针对同样的事情提供了完全不同的 API。而对于上层的引擎开发者、应用开发者、浏览器开发者而言，就带来了极大的兼容成本，这就形成了下面的局面：

可以想象一下，如果你是一个小小的 “VR 计算器” 应用的开发者，刚刚花了一个月的时间打磨好了自己的 App，当你刚刚在 Quest 上上架了你的 App，接下来，当你想把自己的 App 上架到 Hololens、HTC Vive、MagicLeap 上的时候，发现这些平台提供的 API 都完全不同，相当于是你之前所做的所有工作都几乎要完全重来，如果想要完全上架这些所有的 App，你就需要额外再花四五个月的时间去学习和开发这些平台上的 App，这得是有多崩溃？

于是，为了能够让这个糟糕的局面有所改善，Khronos Group（科纳斯标准联盟）就于 2017 年宣布了 OpenXR ，希望通过统一制定的接口 API，来让上层的开发引擎、直接对接硬件的 XR 开发者、实现 WebXR 的浏览器开发者能够面对同一套 API，减少他们的兼容成本：

那，这个突然出现的 Khronos Group 到底是何方神圣？

Khronos Group 与 OpenXR

Khronos Group 成立于 2000 年，由一群主要的计算机图形和多媒体行业领导者共同创建。其目的是推动开放标准的发展，以解决行业内的技术碎片化问题。可以看得出来，Khronos Group 创办的初衷就是解决 “技术碎片化” 的问题。

在 Khronos Group 成立后，一些我们现在可能耳熟能详公开标准在 Khronos Group 的不断努力下被制定出来：

以上的这些标准中，OpenGL 和 Vulkan 可能是我们相对来说最为熟悉的两个标准了，2020 年之前的 iOS 和 Android 都支持 OpenGL 标准，而 Vulkan 从 2016 年也开始被当做更先进的图形 API 标准被 Android 系统所支持。

Tips

其实，类似这种行业经历一段时间的混乱后，行业内自发形成一个组织定义标准，帮助行业更好的向前发展的例子并不少见。

远的，有 W3C 维护和发布 Web 标准，帮助前端开发者减少对 Chrome、Firefox、IE、Opera 的兼容难度。

近的，有 AOUSD 维护和发布 OpenUSD 规范，从而促进 3D 内容之间的互相兼容。（我们的 XR 世界导览 006 就讲到了 AOUSD 的相关新闻）

于是，在 2017 年的 GDC（Game Developer Conference，世界游戏开发者一年一度的盛会）上，Khronos Group 宣布了他们要发布 OpenXR 的计划，经过两年的讨论和修改，最终在 2019 年的 SIGGRAPH（Special Interest Group on Computer Graphics and Interactive Techniques，计算机图形界的年度盛会）上发布了 OpenXR 1.0。

在 OpenXR 的设计中，将一个 AR/VR 程序所需要基本能力，包括控制器追踪、视图渲染等一系列能力抽象出来了一系列 API（完整的文档可以参见 OpenXR API Reference），这些 API 都以 C 函数的形式进行定义（对应的头文件都在 Github/OpenXR-SDK 中）。并且都以 xr 为开头，例如下面的 xrCreateInstance 就是一个用于创建 OpenXR 实例的“入口函数”：

// Provided by XR_VERSION_1_0
XrResult xrCreateInstance(
    const XrInstanceCreateInfo*                 createInfo,
    XrInstance*                                 instance);

利用这一系列的入口函数，上层的 XR 应用，或者是支持 XR 特性的游戏引擎、浏览器引擎就可以用 C/C++ 等一些可以调用 C 函数的语言来构建自己的应用程序了，类似这样：

// 创建一个 XrInstanceCreateInfo 结构体并初始化
XrInstanceCreateInfo instanceCI{XR_TYPE_INSTANCE_CREATE_INFO};
// 创建 OpenXR 实例
OPENXR_CHECK(xrCreateInstance(&instanceCI, &m_xrInstance), "Failed to create Instance.");

当然上面的这个 xrCreateInstance 的函数只是 OpenXR 茫茫多接口中的典型代表，根据 OpenXR Specification ，我们可以看到 OpenXR 将所有的这些 API 大致分为了：

其他的 API 分类我们暂时不深入展开，比较有意思的是 Extension 这部分，在 OpenXR 的定义中，Extension 被定义为硬件厂商可以选择性实现的 API，而 OpenXR 工作组的成员，都可以在已注册扩展中增加新的内容，我们可以看到这其中有不少业界的 XR 公司。

Tips

如果你对使用 OpenXR 构建一个完整的 XR 应用程序的具体流程感兴趣，你可以前往 OpenXR 工作组官方给出的 openxr-tutorial.com 来具体上手感受一下如何使用这些 API。这个教程建议配合 OpenXR Refrence Guide 和 OpenXR Style Guide 结合进行学习。

而在 OpenXR 实际的工作流程中，一个使用了 OpenXR 的应用程序（例如 Unity、Unreal，或者是支持了 WebXR 的浏览器）在调用这些 OpenXR 的函数时，会通过当前系统中的 OpenXR Loader（其作用是在当前的系统环境中，找到正确的 OpenXR 实现），再通过 OpenXR 所定义的 Layer（可选，类似于各种编程语言的钩子函数或者后端程序中的中间件，可以在底层拦截或者修改一个函数的调用过程），最终调用到硬件所提供的符合 OpenXR 的具体实现，而这个具体实现，我们一般就称之为 OpenXR Runtime。

有了上面的这些讲解，相信 OpenXR 的形象就逐渐在我们的脑海中清晰起来了。而截止目前（2024 年），OpenXR 也获得了业内大部分的公司的支持：

在这些公司的支持下，已经有非常多上层应用开始对 OpenXR 的接口进行适配，从原来直接对接硬件厂商的 API，改为对接 OpenXR 的 API，这些产品包括一些游戏引擎、浏览器、SDK：

Unreal：从 Unreal 4.27 版本开始正式支持 OpenXR
Unity：从 2020 LTS 版本基于 OpenXR Plugin 正式支持 OpenXR
Godot：从 Godot Core 4.0 Alpha 4 版本开始正式支持 OpenXR
Chrome/Edge/Firefox：使用 OpenXR 来作为 WebXR 标准的默认实现方式
Autodesk VRED Library：从 VRED 2023.4 版本开始正式支持 OpenXR

以及一些专业软件和游戏：

Blender
OpenBrush
Meta Horizon Workrooms
Cubism
Minecraft
BeatSaber

而这些针对 OpenXR 进行适配的上层应用，也都可以相对比较低成本的用适配了 OpenXR 的版本来支持以下的这些设备：

回到 Snapdragon Spaces Platoform

在这些设备厂商中，相对比较独特的，就是右下角的高通。作为一家芯片厂商，其实他并不会直接生产一款 XR 设备，而是提供芯片给多家 XR 厂商。现在，我们应该能够理解文章开头提及到的 Snapdragon Spaces Platoform 带来的意义：新的硬件厂商可以直接使用上面的这些引擎、工具，从而大大降低新入场 XR 硬件产品的生态建设成本，如同下图所示：

我们可以在官网的支持设备列表查看到目前 Snapdragon Spaces Platform 所支持的设备：

Tips

我们在 XR 世界导览 016 向大家介绍的索尼的新的 XR 头显——Sony XR HMD SRH-S1，就已经支持了高通的 Snapdragon Spaces Platform，

不只是硬件厂商的适配成本变低了，对于上层的应用开发者来说，只要自己的游戏/应用和某个设备的最新特性绑定程度不深（也就是说，更在乎平台覆盖度），那么使用基于 OpenXR 的 Snapdragon Spaces SDK 也非常简单，以 Unity 为例，只要使用了各个厂商的 OpenXR 版本的 SDK（一般都会自动带上 Unity 的 OpenXR Plugin），我们就可以把大部分的功能在更多的平台进行覆盖，而针对不同的平台，只要在 Unity 的 Player Settings->OpenXR 中开启对应 Feature 即可（具体在 Unity 中引入和设置 Snapdragon Spaces SDK 的步骤，可以参考官方文档）：

例如，如果我们想实现 Dual Render Fusion（双渲染融合）功能，我们只需要在 Unity 的 OpenXR 设置中，在 Snapdragon Spaces（Experimental）这个 OpenXR Feature Groups 中勾选上 Dual Render Fusion（Experimental）这个选项，就完成了绝大多数的项目设置的内容（更加详尽的设置内容，请参照官方文档）：

Tips

Dual Render Fusion 允许一个 Android 应用同时向手机屏幕和手机连接的 AR 眼镜输出画面，从而让用户可以利用手机作为 AR 眼镜的控制器，同时通过 AR 眼镜来观看最终渲染出来的 XR 画面，仿佛 AR 眼镜是手机的天然延伸（一般来说，手机和 AR 眼镜之间都需要一根 USB 线进行连接），如同下图所示：

除此之外，在 Snapdragon Spaces SDK 中，还提供更多的一些 AR 功能，其中相对比较重要的有：

Anchor：锚点追踪，让开发者能够跟踪到现实世界中的位置，从而在应用中可以让虚拟物体锚定现实世界的环境
Image Tracking：图像跟踪，让开发者能够识别到现实世界中的图片并跟踪其位置
Hit Testing：命中测试，让开发者能够检测某个方向是否有实际的平面或物理接触点存在
Plane Detection：平面识别，让开发者能够识别到现实世界中平面的位置以及平面的一些基本信息
HandTracking：第一人称手势识别与手势跟踪，并且还提供了非常精细的 ControlBox、Controller/HandTrackingSwitch、Virtual Force Feedback （VFF）、Snapping、Hand Filtering 等功能
QRCodeTracking：提供了现实空间的二维码识别与追踪，能够让开发者基于二维码以及解析到的二维码信息实现更多的空间锚定功能
Spatial Meshing：提供了获取现实空间环境的空间网格，从而让开发者能够获取到现实空间中环境的具体形状
Camera Frame Access：提供了获取相机画面的功能，从而让开发者能够对相机画面进行进一步的处理

你可能注意到了，这里很多的功能并不是所有的 XR 设备都拥有的，因此上面一些非标准的功能，例如手部追踪，就是基于我们前面看到的 OpenXR Extension 实现的：

另外，以上这些功能，除了使用 Unity， Snapdragon Spaces SDK 也提供了 Unreal 版本的 SDK 供开发者选择。

神木科技：Snapdragon Spaces Platform 在中国的本地化落地

众所周知，一个好的开发者工具如果想要获得更好的落地推广，本地化的开发者社区和生态，以及厂商的支持是必不可少的。Apple 在中国收获的极具创意的开发者群体背后，离不开 Apple 对开发者的大力支持。

Apple 是如此，Snapdragon Spaces Platform 也是如此，为了能够更好的帮助高通在中国推广 Snapdragon Spaces Platform 相关技术，神木科技（Enlight XR）作为高通 XR 中国生态的战略合作伙伴，一直致力于基于高通骁龙 XR 芯片平台和 Snapdragon Spaces 软件框架，成为行业上下游的纽带与桥梁，构建中国 XR 生态系统和行业联盟，为核心行业伙伴和开发者提供技术支持和咨询服务，从而推动基于高通 XR 芯片平台及骁龙 Spaces XR 生态在中国的落地。

具体来说，神木科技首先为中国的开发者提供了本地化的 SDK 文档、本地化的教学视频、以及本地化的 SDK 下载渠道：

例如，我们前面所提及的到 Dual Render Fusion 功能，如果你不习惯查看英文原文的官方文档的话，你就可以直接通过教学视频中的 “Dual Render Fusion 的原理与实现”来跟随讲师的讲述，一步步地了解应该如何设置 Dual Render Fusion 功能的各项参数，以及其背后的技术原理。

结合 OpenXR 提供的核心功能，以及 Snapdragon Spaces SDK 提供的扩展功能，我们就可以非常快速的在兼容设备上实现这些核心功能：

仅有 SDK 的支持并不完全足够，为了让更多的开发者能够上手使用 Snapdragon Spaces Platform 来进行开发，并和行业内的朋友们进行交流，神木也提供了包括应用挑战赛、开发者沙龙、开发者套件申请在内的多项活动内容：

Tips

最近一次的高通技术沙龙将在 2024 年 8 月 3 日（周六）于北京召开，活动现场将会有非常多的资深从业者进行分享，并且也会有非常高质量的闭门交流会，如果你看完上面的知识，想了解了解 Apple Vision Pro 之外的空间计算现状，非常推荐大家去参加一下这个活动。

记得在报名渠道中选择 XR 基地，将勾选渠道和完成问卷的截图发给“XR 基地”公众号后台，即可获得小礼品——少数派礼品三件套😉

如果你想申请 Snapdragon Spaces SDK 的开发套件，可以通过下方的二维码进行申请：

除此之外，校企合作也是技术推广中非常重要的一环，在这方面，神木科技也做出了非常多的努力：

而以上的这些工作，也收获了业内人士的一致认可，目前神木科技的合作伙伴包括：

而在各种展会和行业奖上，神木科技也是硕果累累：

并且，相关的技术也在现实世界得到了非常多的落地应用，例如当红齐天（如果你还没有体验过线下大空间的魅力，推荐你一定要去玩一下试试）：

写在最后

所谓天下大势，合久必分，分久必合，XR 行业经历了 2016 左右百花齐放的时期，也经历了其后长达数年的低谷，对应的技术标准也走过了从分散到松散的统一的时期，令人高兴的是，这个行业里头总是会不断出现新的事物来尝试让更多的人体会到 XR 的神奇，在这个过程中，有像 OpenXR 这样的底层技术标准，有像 Snapdragon Spaces SDK 这样的通用 SDK，也有像神木这样积极推动技术落地的科技公司，这些在不同领域的积极的尝试都在印证着：这个行业还在前进！

OpenXR、高通、神木的故事还在继续，如果你是一个想要投身于 XR 行业，并且想要在高通的平台大展身手的开发者，欢迎你关注“XR 基地”和“神木科技”的官方公众号，随时了解更新的 XR 发展动态！