01 为什么需要OpenXR?
VR、AR内容开发的一大痛点是缺乏统一的标准,不像PC或移动端,可以做到一次开发多设备使用。如移动端应用基于Android SDK开发后,就可以运行于绝大部分Android手机。
相比之下,AR/VR行业其标准尚处初步发展阶段,各家设备互不兼容,例如基于Oculus SDK开发的应用只能运行于Oculus的设备。这对内容开发者来说,对接不同的设备就要基于不同的SDK对接移植,且不同的设备交互方式不尽统一,移植工作比较繁琐。
为了专门对接不同的AR/VR设备,Khronos组织开发了一套名为OpenXR的框架,该框架对AR/VR设备的能力进行抽象,对外提供一套统一的开发API,不同的开发引擎对该API进行二次封装,形成开发SDK,提供给AR/VR应用开发者使用。
这样的好处是开发者只需关注引擎本身的使用,无需关注设备间差异,复杂的设备和平台兼容将由底层的通用开发框架(OpenXR)来负责。
OpenXR 发展历程
图1 OpenXR演进
OpenXR推出后便引来多家头部AR/VR设备公司的支持,首批有高通、HTC、Oculus、微软、NVIDIA、Epic、Unity、Valve、AMD、Intel、Magic Leap等。
2017年首批加入OpenXR的公司
2021年底加入OpenXR的公司
值得一提的是,2021年11月高通推出了使用OpenXR的Snapdragon Spaces XR开发平台。作为主流的计算处理平台,高通对OpenXR的适配,极大地促进了OpenXR的推广。
02 OpenXR 架构和组成
OpenXR所处的层次
OpenXR处于各开发引擎之下,各厂商的硬件设备之上,起着承上启下的作用,具体情况如下图所示。
图2 OpenXR所处的层次
OpenXR的组成
OpenXR由以下几个部分组成:
① OpenXR Loader(载入器)
② OpenXR API Layers(接口层)
③ OpenXR Runtimes(运行库)
图3 OpenXR结构图
如上OpenXR结构图所示,第三方应用通过载入器使用OpenXR的功能,载入器负责与接口层、运行库交互。运行库负责与AR/VR设备交互并驱动设备提供的功能。载入器根据功能需要,在第三方应用跟运行库之间调配接口层。
接口层用于验证、跟踪、调试被第三方应用调用的接口,也可以添加和修改接口的功能。当SDK接口(命令)被调用时,数据走向如下图所示。
图4 OpenXR数据走向
03 OpenXR 现状和未来
OpenXR的现状与问题
1 开发进展慢
OpenXR自身进展缓慢,2019年7月OpenXR 1.0规范正式发布,2020年7月公布首批Oculus和微软的设备通过一致性测试,2021年3月SteamVR才正式支持。同时,因为需要对接引擎和设备比较多,兼容性也是个问题。
此外,现在还有部分VR设备厂商没有加入OpenXR,也就没有OpenXR的硬件驱动,因此开发者也是无能为力的。
2 OpenXR的支持,巨头有想法
在苹果尚未入局之前,我们充分的理由猜测苹果未来的AR/VR不会去主动适配OpenXR。索尼虽然在OpenXR支持厂家的名单中,但是到目前为止还没有公布具体的支持计划。
3 基于OpenXR,目前开发者仍需要适配不同厂商
理想很丰满,现实很骨感,虽然大量厂商声称已支持OpenXR,但是还没有统一的官方认证机制。
现阶段不同设备的OpenXR适配工作,仍需要AR/VR开发者完成,不利于不同型号设备的OpenXR快速导入。
OpenXR的未来展望
OpenXR的最终目标是将VR/AR应用和头显之间的通信方式标准化。虽然目前OpenXR还存在一些问题,但未来OpenXR仍然会成为XR中间件标准。
一方面,未来VR硬件会逐步趋向稳定,有利于OpenXR统一行业标准。另一方面,VR应用开发引擎非常愿意看到XR中间件标准化,以利于开发流程的简化,比如Steam平台、Unity、UE4、Godot等开发应用引擎。
值得一提的是微软、Meta、高通等XR行业巨头对OpenXR的加持,加快了XR行业标准的统一,特别是微软收购暴雪已经拉开了顶级巨头们元宇宙之战的帷幕。
————————————————
版权声明:本文为CSDN博主「S_DreamLab」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/S_DreamLab/article/details/123407056