Meta Quest 現在是目標平台了

買得到的 AR 眼鏡還不存在——但數百萬人已經擁有一台頭戴裝置。RakuAI 現在能在使用者所在之處與他們相遇,用一份體驗定義,在眼鏡出貨時直接帶著走。

上週稍晚的一場夥伴會議,讓下一步變得顯而易見。Raku 最終的產品目標是 AR 眼鏡。今天的產品目標也是 AR 眼鏡,但我們想要出貨的那種 AR 眼鏡,還不存在於任何人買得到的形式。這道缺口是真實的。它也令人沮喪,因為我們想讓人們在這顆引擎上獲得的體驗,不應該非得等硬體。

這個週末,我們用另一種方式縮小了缺口。這個執行環境現在能在搭載 Horizon OS 的 Meta Quest 頭戴裝置上、以透視 AR 模式、透過 Meta 開放的 OpenXR 層運行。Quest 不是我們最終要為之最佳化的形態。它是人們已經擁有的形態。

落地了什麼

三個執行環境 PR,以及配套的 SDK 部分:

• OpenXR/Quest VR 整合,含立體渲染與 6DoF 追蹤
• Meta Quest 的透視 AR 模式,含合成層與 alpha 混合
• Quest 透視 AR 的 Horizon OS 權限文件

SDK 得到了對應的工作:為 Quest VR 擴充的 C 語言範例,含平台自適應的執行環境選擇;完整的 Meta Quest(Horizon OS)OpenXR 整合文件;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 的權限問題

Meta 的透視 AR 權限模型,比大多數從桌面 VR 過來的開發者預期的更繁複。執行環境必須宣告正確的 manifest 條目、請求正確的執行期權限,並在使用者拒絕其中之一時優雅降級。週中落地的文件 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 眼鏡以我們正在最佳化的形態出貨時,在 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 設定。

整個週末一百一十八個 commit。週六晚上,引擎有了一個新的目標平台。明天早上回去繼續造。