夢回 2020 VR 開發（下）

前情提要

夢回 2020 VR 開發（上）講完原專案與移植到 XRSPACE 平台，書接上回，這篇要說的是第二次移植的事情。

第二次移植

一個多月前，教授又來消息了，說這次要移植到 Meta Quest 及 HTC Vive Focus 上。

因為要針對兩個平台做發布，而 OpenXR 在 Unity 上相較幾年前成熟多了，所以這次就直接用 OpenXR 加上 XR Interaction Toolkit 封裝來完成裝置溝通。

HTC 跟 Meta 也在 VR 領域打滾多年了，雖然給我的不是最新的機種，但相較 XRSPACE 的一體機還是能體現出不小的落差。

OpenXR

OpenXR 這種開放協定是很好的概念，對於開發者來說只要實作一次就能在不同平台上運行。

由於第一次移植還包含了部分內容更新，所以我也不能直接沿用初代的 SteamVR 來做升級，只能說以前的我真的菜的可以，邏輯實現一堆 🐘 不提，控制器溝通不是透過介面，導致移植綁手綁腳。

簡單來說，Unity 的 XR Toolkit 圍繞著幾個部分：

Interactor / Interactable 來管理互動，算是各種 Caster 的高級實現，互動類型分成
a. Hover：Interactor Cast 到時
b. Select：Interactor 選中時
Locomotion 管理移動（頭顯位移）
底層的 Input Action Mapping 設定，依賴 Unity 現在最推最新的 InputSystem，開發者就不需要針對各裝置設定輸入

把輸入層完成後，把 XRSPACE 版本閹割的內容重新實現、重構基本上就能建置出來測試了。

中控插件

這次移植有個大重點，就是解決之前 VR 使用者的畫面無法被截取出來的問題。

講的是一體機，如果是 PC 端運算的話，顯卡算完畫面，本來就能輸出在原本的螢幕上，而 VR 頭顯就是另一個螢幕罷了。

用之前擷取畫面的解法 Scrcpy 應該是可行，但為了讓非專業人士教育者們也能輕鬆監控使用者畫面，計畫方給出了另一個答案：

用 Unity 插件 FMETP STREAM 把畫面傳到中介軟體上。
基於 LAN，所以如果一對多的情況，你的無線 AP 不能太爛。

一坨 🐘

FMETP STREAM 本身是付費插件，而計畫方重新封裝的版本，我猜應該不是最新版，也有可能是海盜版，單看代碼的底層實現，就是把目標 Texture2D 編碼成 JPG 再透過 Socket(UDP) 傳輸。

稍微有點技術背景的人，應該都看得出來這並不是甚麼困難實現的功能（撇除傳輸效率優化與安全性），何況還限定在區網內，不需要內網穿透的技術。

🤨

這個 FMETP STREAM 已經出到 V6 了，Asset Store 上面賣 800 鎂，尛。。。

也不是說造輪子東西就比較好，但不自己開發維護反倒用高級封裝的插件，還因為是付費插件所以要簽使用同意書，希望教育部的案子有點技術含量似乎變成某種奢侈的想法。

差勁的教學

計畫方提供的教學是讓開發者額外新增一台 Camera，用 targetTexture 的方式取得畫面 RenderTexture，不特別設定的情況應該會多一倍的渲染效能損。

其實插件本身也支持用 Camera.OnImageRender 事件方法，有瞭解過舊版 Post Processing 應該對這個方法不陌生，就是在渲染最後階段拿到 Texture，透過 Graphic.Blit 複製像素到 RenderTexture 上就行了。

這兩個作法差在哪裡？

Camera 指定 targetTexture 本身是讓 Unity 在 GPU 申請一塊 Texture，在相機渲染完畢後，不通過 CPU 直接將結果繪製在這塊 Texture 上；而 Graphic.Blit 同樣也是在 GPU 內把渲染結果繪製在一塊 Texture 上，所以也沒經過 CPU。

所以本質上是一樣的，但多一台相機會多消耗一次渲染性能。

另外值得一說的是，計畫方提供的教學裡面，Encoder 設定最重要的 Async Encode Mode 反倒沒講要開，由於多線程不能使用（我也不知道為甚麼），編碼這種不重要但又有點繁重的任務，沒開非同步直接阻塞。

因為是 CPU 的卡頓，你會發現整體幀數並不低，但物件的旋轉、射線、物理都卡卡的。

Meta Quest 2

沒有甚麼特別的規格，由於普遍性高而且祖克伯夠力，所以 Unity 的 XRToolkit 本身就支持 Quest，不需要經過特別設定，基本上可以直接建置出來跑。

跟 XRSPACE 一樣，雖然是 Android 基底的系統，但你要想使用 Meta 自己重新開發的 Home Launcher，你就要登入 Meta 帳號。

基於資安考量，我壓根不想在不熟悉且不屬於我的裝置上登入任何帳號，所以我無法使用任何 Meta 提供的 Side Load 或是串流來除錯。

好在一切順利，建置完成後，跟之前一樣用 adb install 就可以把 apk 裝到機子上面，跑起來跟在 Editor 環境模擬的結果差不多，所以這個平台很快就完成了。

Vive Focus 3

因為 Vive 有自己的 XR Plugin，所以是在 Meta Quest 平台完成後我才著手處理 Vive Focus 平台，先說個我最不爽的地方：

開發者指引跑得超級慢。。。

雖然教學是寫下載並匯入 unitypackage，但其實新增 UPM Package Source 並透過 Package Manager 匯入比較符合邏輯（在不關心代碼實現的情況下），畢竟開發者指引跑得很慢，我翻的意願不大。

設定好 XR Plug-in Provider 後建置，一樣是詭異的 Home Launcher，所以還是一樣用 adb install 裝上機騷個幾圈，大致上沒問題就不打算再動了。

下個結論

這次兩台機子給我的感覺，Quest 廉價親民，生態較完整，系統也有比較好的使用者體驗；而 Vive 用料比較好，但系統就差強人意。

既然全都是 Android 基底，就應該要來個秦始皇把 VR 的操作環境統一，而不是廠商各玩各的都想著噱錢，用同一個 App 管理器、下載源等等，除了降低換裝置的學習成本，也能讓綁定帳號這件事情變得合理。

總之，不知道以後還會不會碰到 VR 的專案，我也算是靠這個 VR 案子發跡的，各種愛恨情仇，大致上就是這樣。