Built-in VR から XR Plugin Management へ移行した話

はじめに

この記事は クラスター Advent Calendar 2022 の12/14の分です。

昨日は、shindyuさんの「比較して覚える SwiftUIとJetpack Compose」でした。

こんにちは、クラスターでSoftware Engineerをやっている サンスケ (@sansuke) です!

clusterでは今年2022年の7月にUnity2021へのアップデートを実施しました。

今回はその中で実施した、Built-in VR から XR Plugin Management へ移行した話について紹介しようと思います。

なぜUnity Updateに XR Plugin Management へ移行が必要なのか

Unity 2019まで、VRの開発をするためには各プラットフォームごとに XR Settings という項目を設定する必要がありました。

Unity 2020以降のバージョンでは XR Settings がサポートされなくなり、従来のBuilt-in VRではVRが起動できなくなってしまっていました。

そのため、Unity 2020以降のバージョンでVRを使用するためには、XR Plugin Management への移行が必要になっていました。

移行手順

XR Plugin Management への移行は以下のようなフローで作業を行いました

1. SteamVR Pluginのアップデート
2. XR Plugin Management のインストール
3. エディタ上でエラーなどが起きている箇所の修正
4. クライアントをビルドして、ビルド時のエラーがないかの確認、あれば修正
5. ビルドが成功したら、できたクライアントを触ってみて動作に問題がないかを検証、あれば修正

1は当時clusterで使用していたバージョンではXR Plugin Managementが使用できなかったため、SteamVR Pluginのバージョンを最新にアップデートする必要がありました。

1, 2の細かい手順に関してはここでは省略します。

こちらに関しては、公式のドキュメント や こりんさんの記事が参考になるかと思います。

以下の項目では、3, 4, 5の作業で発生したことについていくつか紹介していきます

VRモード切り替え処理の置き換え

clusterのPC版でVRを起動する際には、入室前にVRを選択してからVRが起動、つまり、ランタイムで動的にVRモードのオンオフの切り替えを行うようになっています。

ここのコードがこれまでXRSettingsに依存した処理になっており、XRSettingsは移行で使えなくなってしまうため、処理の置き換えが必要になりました。

XR Pluginを利用した切り替えでは、XRLoaderというクラスを仲介してデバイスの初期化などを行う形になっており、このクラスを利用して

var loader = XRGeneralSettings.Instance.Manager.activeLoaders.FirstOrDefault();
if (loader != null)
{
    loader.Initialize();
    yield return null; // wait 1frame
    loader.Start();
}

のような形で XRGeneralSettings からアクティブなXRLoaderを初期化することで、VRモードに切り替えることができるようになりました。

マルチプラットフォームの参照解決

clusterでは、Windows、Mac, Android, iOS, Questの5つそれぞれのプラットフォームに対して別々にクライアントのビルドを行っています。（詳しくは12/8のrizumiさんの記事「PC,モバイル,VRに対応したマルチプラットフォームアプリのリリースフロー」を参照ください。）

目に見えるエラーが無くなり、ビルドして確認しようとしたところWindows以外のプラットフォームでビルド時にコンパイルエラーが起きるようになっていました。

この問題は、Windows以外のプラットフォームをビルドする際にもSteamVR Pluginを参照してしまっていることが原因で起きていました。

それまでもビルドする際にSteamVR PluginのNamespaceを参照していて問題はなかったのですが、XR Plugin Managementに移行する際にSteamVR Pluginが参照しているOpenVRのPluginも新しいものに更新されており、その変更起因で他のプラットフォームではコンパイルが通らなくなっているようでした。

これを解決するために、プラットフォームごとのディレクティブをコードに挿入したり、asmdefの参照見直しを行ったりしてWindows環境以外でSteamVR Pluginを参照しないようにすることで各プラットフォームでコンパイルが通るように修正を入れていきました。

ビルドフローの修正

Questに関しては、実はこの移行を行う前からXR Plugin Managementを使用していました。

ただ、その頃PC版のVRモードはXR Plugin Managementを使用していなかったため、Quest版クライアントをビルドするタイミングでプロジェクトの設定をXR Plugin Managementの設定に動的に置き換えるという運用が必要になっていました。

その結果、今回の移行で既にXR Plugin Management用にプロジェクト内の設定を書き換え済みのものに対してQuest版をビルドするタイミングで再度設定を書き換えようとしてコンフリクトが起こってしまい、うまくビルドが走らなくなってしまっていました。

これを解決するために、これまでのQuest版クライアントをビルドするタイミングで設定を書き換えるというビルド時のフローをなくし、既にプロジェクトにある設定を使ってQuest版クライアントをビルドするようビルド時のフローの見直しを行いました。

さいごに

以上、XR Plugin Management へ移行する際に起こったことについて書いてきました。

こうしてみると1つのプラグインを入れ替えるだけでも、コード上の問題から、運用上の問題、マルチプラットフォームなど考えることがとても多いです。

こういったことを考えるのは大変ではありますが、clusterならではの面白いところでもあるのかなと思っています。

明日は @uzzu さんの「なんか書く」です。