PICO发布Unreal OpenXR Plugin 1.5版本解决开发者兼容性问题
（映维网Nweon 2025年07月10日）Unreal Engine 开发者在使用 PICO 设备开发时，常常面临 PXR Plugin 和 OpenXR Plugin 的抉择。这两个插件不能共存，但在基础功能上似乎“都能用”。所以，为何仍需坚持推进 OpenXR 路线？
日前，PICO的鲍晨曦结合历史背景、技术难点、解决方案与新版亮点，撰文说明了 UE PICO OpenXR Plugin 1.5 版本为何至关重要：
痛点
虚幻引擎的OpenXR模块从UE4中首次支持到UE5很长一段时间，存在大量Bug，这些Bug的根因一方面在虚幻引擎内，一方面在设备厂商运行时内。
PICO很多特有能力在OpenXR插件中并未提供，导致开发者在开发中，无法满足某些功能的开发和使用。
为什么会有以上两个问题？
原因
痛点1:
首先我们来看第一个问题，这个问题主要因为，OpenXR 在早期标准尚未相对成熟时，很多接口行为定义并不明确，不同厂商的理解和实现各异，常导致“这边能跑，那边出错”的问题。
从下图我们可以看出，在没有OpenXR之前，引擎XR模块的及Native SDK的设计、调用与实现，全由硬件厂商自己维护，就像PXR Plugin和OVR Plugin，如果出现问题，厂商全可以自行快速解决并修复。然而到了OpenXR SDK中，由于大家均基于一套通用标准来实现，SDK 核心部分的接入方和实现方完全分开。引擎决定不了厂商的实现，厂商决定不了引擎的调用，并且SDK的设计不再受某单一厂商控制，OpenXR SDK标准的制定和完善则是需要多方共同进行长期的讨论。原来厂商可以自己完成一件事，现在需要三方来完成，OpenXR使用方，OpenXR标准制定方，OpenXR实现方。
痛点2：
对于PICO特有的能力，按照OpenXR规范的共建流程，通过BD扩展提交官方审议的周期，在早期非常长。一个私有能力的API设计不再像以前，只要能满足厂商自己的使用需求就可以发布，在以厂商扩展提交到OpenXR工作组以后，需要各方进行严格的审查工作，也就是说这些API不是你想设计成什么样就是什么样，需要充分兼容OpenXR的框架结构。在收到建设性意见后还需要重新设计修改再提交。这导致PICO大量特有能力短期内无法在OpenXR SDK中快速支持并发布给PICO开发者使用。
由于核心的HMD和Input模块的实现转移到虚幻引擎内部，虽然虚幻引擎提供给了厂商扩展核心模块的接口插件能力，但是早期这部分插件能力并不完善。这意味着，即使我有某个扩展可以提供PICO特有能力，但该扩展一旦依赖核心模块的某些修改才可以使能的话，我们也无法在虚幻引擎非源码版内给开发者提供。
解决方案
针对痛点1：
OpenXR SDK 标准化：近两年OpenXR SDK标准化工作逐渐加速，各个厂商积极参与标准化建设。包括日常线上会议，代码review，流程建设，问题讨论，线下会议，自动化测试，配套工具及文档的完善等等。从1.0版本迭代至1.1版本，细化及完善了OpenXR spec中各种技术说明。这使得各个厂商及上下游在支持OpenXR SDK的时候，有着更加清晰的接入标准，并配合相应的CTS测试及Validation校验，充分保障了OpenXR SDK的正确集成与实现。具体参考 OpenXR 官方。
PICO OS：PICO作为OpenXR标准化组织工作组的一员，PICO相关同事积极参与OpenXR标准化的建设，并且率先支持了1.1版本，支持众多主流扩展，在功能完备性，性能及稳定性方面表现出色。
UE OpenXR模块：虚幻引擎同样作为OpenXR工作组成员之一，积极参与OpenXR标准化的共建，在最新的UE 5.6版本中全面兼容OpenXR1.1，并不断完善OpenXR相关模块以及配套的工具。Unreal Engine Public Roadmap
在GitHub上可以看到OpenXR核心模块持续迭代优化，同时PICO相关同事积极参与UE OpenXR模块共建，开源贡献众多bug修复及Feature支持。使得虚幻引擎与PICO更加兼容，UE OpenXR相关模块更加健壮。
针对痛点2：
对于PICO特有能力，PICO率先采用扩展独立维护及发布策略，这些能力在PICO内部严格按照OpenXR SDK的标准及框架设计，唯一区别是这些能力并不会提交OpenXR官方，从而省去了OpenXR官方审核及发布的时间限制。
虽然这样做可以满足PICO特有能力的快速迭代及交付，但是不得不承认，缺少工作组及不同厂商的意见及review，难免会出现一些SDK设计上的”小瑕疵”，例如，”两个接口合并成一个接口更好”，”用枚举比用布尔值更容易扩展”等等。但好在这些PICO特有能力的功能，兼容及稳定性是有保障的。并且PICO会将认为可以提交OpenXR官方的部分PICO特有能力，转换成BD扩展进行OpenXR的官方提交及审核。得益于流程的完善，目前BD扩展的发布周期可以缩短至2至4个月。
结合上面提到的PICO在虚幻引擎GitHub的OpenXR模块共建及开源贡献，使得新的OpenXR extension Plugin框架可以允许外接补充插件更好地扩展厂商特有能力。同时欢迎广大开发者积极参与共建虚幻引擎。
//\Engine\Plugins\Runtime\OpenXR\Source\OpenXRHMD\Public\IOpenXRExtensionPlugin.hclass IOpenXRExtensionPlugin : public IModularFeature{public: //... virtual const void* OnBeginSession(XrSession InSession, const void* InNext) { return InNext; } //... // OpenXRHMD::OnBeginSimulation_GameThread virtual void* OnWaitFrame(XrSession InSession, void* InNext) { return InNext; } //... // FOpenXRHMD::OnFinishRendering_RHIThread virtual const void* OnEndProjectionLayer_RHIThread(XrSession InSession, int32 InLayerIndex, const void* InNext, XrCompositionLayerFlags& OutFlags) { PRAGMA_DISABLE_DEPRECATION_WARNINGS return OnEndProjectionLayer(InSession, InLayerIndex, InNext, OutFlags); PRAGMA_ENABLE_DEPRECATION_WARNINGS } //...};小结
通过上述方案及各方的努力，才有了今天的1.5版本。OpenXR标准更加完善，虚幻引擎OpenXR模块更稳定，更易扩展，PICO特有能力通过PICO扩建及BD扩展在插件中提供，PICO Runtime全面兼容OpenXR SDK。同样在友商Meta的UE插件中，也可以看到其正在转向支持虚幻引擎的OpenXR框架从OVR框架。
UENUM(BlueprintType)enum class EOculusXRXrApi : uint8{ OVRPluginOpenXR = 0 UMETA(DisplayName = "Oculus OVRPlugin + OpenXR backend (current recommended)", ToolTip = "Oculus plugin integration using OpenXR backend on both Mobile and PC. All new features will ship on backend for the forseeable future."), NativeOpenXR = 1 UMETA(DisplayName = "Epic Native OpenXR with Oculus vendor extensions", ToolTip = "Disable Legacy Oculus in favor of the native OpenXR implementation, with Oculus vendor extensions. Must enable the OpenXR plugin. This will be where Epic focuses XR development going forward. Oculus OpenXR extensions may be moved into a separate plugin (or plugins) in the future to improve modularity. The features supported by OpenXR are listed in the OpenXR specification on khronos.org, and the features supported by a given runtime can be verified with the \"OpenXR Explorer\" application on GitHub."),};
亮点
支持UE5.6及后续版本适配策略优化
标准loader：1.5版本支持最新的5.6引擎，并且兼容5.6官方新增的两大功能（Passthrough和1.1）。具体可参考开发者文档。并且从5.6开始，官方引擎内正式支持OpenXR在Android上的标准Loader，这意味着，如果您不需要PICO特有能力（不在OpenXR spec内的能力 + 在spec中的PICO能力但虚幻引擎官方未支持的），那么您只需要下载一个官方版的虚幻引擎，打包安卓，即可运行在PICO设备上（不仅是PICO，任何支持OpenXR的Android平台），无需安装PICO OpenXR Plugin（该插件相当于OpenXR核心插件的补充插件，提供PICO相关扩展能力）。
快速兼容：原来PICO插件支持虚幻引擎版本的策略是，某个版本发布后，PICO再进行集中适配，大概2至4个月后，PICO插件才支持新版虚幻引擎，但是正如上述所说，未来新版本无论您装不装PICO插件，新版本天然支持PICO设备，所以我们会把兼容适配工作提前，这意味着，例如未来，UE5.7发布后，可能在2至4周内，PICO就会发布PICO OpenXR扩展插件。依赖PICO-Fork源码引擎的Feature的适配，同样也会提前。
版本规划：由于UE5引擎现在仍处在早期版本，并不像4.24至4.27，这几个版本可能在基础稳定性和兼容方便并不会有质的差异，但是UE5早期阶段，每个新版本都会快速迭代，优化以及修复上个版本的大量问题，所以我们建议您的项目在UE5早期能切到新版本就切换到新版本使用，所以我们插件维护的版本可能会从原来的3个版本缩短至1个或2个版本（即PICO新功能仅在最新的虚幻引擎1到2个版本上支持）。
支持原PXR插件中核心能力
核心功能：在1.5之前，我们仅支持OpenXR spec中已有的能力，几乎没有PICO特有能力，仅在上半年1.4版本中，新增BD BodyTracking。但是在1.5版本中我们通过PICO+BD扩展，将原PXR Plugin中大量PICO特色能力迁移至了OpenXR SDK。参考Native指南，例如：
BodyTracking：全身动捕，返回全身骨骼节点姿态信息等。
MotionTracking：独立追踪，将PICO传感器用作单独的追踪节点设备。
ExpandDevice：扩展外设，允许开发者外接自定义的硬件设备。
AdaptiveResolution：动态分辨率，可根据GPU负载动态或者手动设置ViewPort尺寸。
EyeTracking：返回更多的眼球追踪数据，例如瞳孔信息，开合状态等。
MRC：混合现实录制，虚实人像结合，第三视角录制玩家游玩游戏的场景。
其他：颜色矩阵，安全区相关，手柄电量，MR等。
删繁就简：同时我们废弃了原有PXR SDK中大量无用，冗余以及复杂难用的功能，旨在希望可以在OpenXR SDK中提供简洁易用稳定的功能。您可能注意到仍有一些PXR中的特色能力未迁移至OpenXR，例如FaceTracking、PHF震动等，这些能力我们可能会考虑废弃，也可能会重构优化再迁移，一旦评估完成需要迁移，我们会尽快在OpenXR SDK中提供。如果您发现某些能力您特别需要但是未迁移至OpenXR中的，可以与我们的技术支持联系反馈。
跨平台
All for one, one for all：基于OpenXR 框架开发的应用，意味着您打包一个apk，可以同时装到PICO和Quest以及其他支持OpenXR的设备上。
插件平权：在以前，例如您开发Quest只能使用Quest插件，开发者PICO只能使用PICO插件，这些插件不能同时启用，切换插件意味着您需要使用类似宏的技术手段隔离您的上层实现，但是现在，理论上，只要是基于UE OpenXR 框架提供的各厂商扩展插件，那么您是可以同时开启并且不会冲突的。
插件复用混用：基于上述，例如如果您同时开了PICO OpenXR插件和Meta OpenXR插件，那么这两个插件中提供的能力您全都可以接入，我可以上一个接口调用PICO的，下一个接口调用Meta的，这时候您会问，那么功能都可以在两个设备上运行么？答案是：只要这个功能对应的extension在对应的平台上支持那么您就可以使用。参考Runtime support matrix。例如，假如在Meta和PICO的插件内都支持了XR_EXT_user_presence 扩展，那么您不管使用Meta插件提供的蓝图接口，还是PICO插件中该动能的蓝图，接口，在两个设备上都支持，因为两个设备都支持该扩展。对于各应用厂商的扩展，OpenXR并未限制只能该厂商使用，所以您可以看到例如在PICO上我们提供Passthrough特效的能力，就是通过XR_FB_passthrough扩展实现的，这意味着您如果只开了PICO插件，即使您没开Meta插件，您的应用的vst效果同样可以在Meta上生效，是不是很神奇！
一致的性能：正如文章最开头所说，引擎的XR HMD模块和Input模块是各厂商自己提供的，也就是从接口层和接口调用层，应用之间就出现了差异，开发者在多平台开发的时候，如果发现性能有差异，这部分差异，有可能在引擎插件层，有可能在设备驱动层，但是现在基于OpenXR，您的应用在上层完全基于一套代码逻辑和框架，在相同扩展能力启用的情况下，如果出现性能问题，那么很容易定位到是硬件设备驱动的差异导致的。这更利于开发者定位问题。
PC串流：不仅仅是可以跨越不同厂商的Android设备，对于不同操作系统的设备，OpenXR应用仍然同样适用上述所有规则，享有所有便利。这意味这，未来在PICO上，您的应用只需要1套代码加1个插件，那么您既可以通过PC串流实时预览，也可以打包安卓在设备上独立运行。甚至，您的工程可以同时输出一个exe和一个apk，不需要做任何修改，PC上也可以直接运行，安卓上也可以直接运行。不管是实时预览还是Package均1套插件即可完成。那您可能会问，功能都一样么？还是那句话：只要支持对应的扩展，就支持该功能。当然PICO PC串流中对OpenXR扩展的支持进度，可能略慢于移动端。
同时这里回答一个历史问题，在PXR Plugin中开发者PC预览会使用一个叫Preview Tool的单独插件，该插件虽然可以完成预览的能力，但是相比上述OpenXR的能力，还是有些差异，因为Preview Tool和PXR Plugin本质是两套XR HMD和Input框架加两套Native SDK（PXR SDK和串流SDK），也就是意味着，表象上您看到PC上的效果跟安卓上的效果类似，但是实际并不是百分百可靠，因为从SDK层就出现了分化，当然这在简单的预览场景中可以满足大部分需求。
