為什么 PICO Unreal OpenXR Plugin 1.5版本至關重要？
（中國AI網 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 官方。
Khronos 發布 OpenXR 1.1 以進一步簡化跨平臺 XR 開發
OpenXR 1.1 版本整體介紹
PICO OS：PICO作為OpenXR標準化組織工作組的一員，PICO相關同事積極參與OpenXR標準化的建設，并且率先支持了1.1版本，支持眾多主流擴展，在功能完備性，性能及穩定性方面表現出色。
PICO 參加 OpenXR LIVE 2024
PICO 正式支持 OpenXR 1.1 標準
用 OpenXR 構建一個全新的生態系統
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 發布 Native XR SDK v3.0.0：原生 XR 開發重大更新
雖然這樣做可以滿足PICO特有能力的快速迭代及交付，但是不得不承認，缺少工作組及不同廠商的意見及review，難免會出現一些SDK設計上的”小瑕疵”，例如，”兩個接口合并成一個接口更好”，”用枚舉比用布爾值更容易擴展”等等。但好在這些PICO特有能力的功能，兼容及穩定性是有保障的。并且PICO會將認為可以提交OpenXR官方的部分PICO特有能力，轉換成BD擴展進行OpenXR的官方提交及審核。得益于流程的完善，目前BD擴展的發布周期可以縮短至2至4個月。
XR_BD_body_tracking
XR_BD_spatial_anchor
結合上面提到的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層就出現了分化，當然這在簡單的預覽場景中可以滿足大部分需求。
