第5回:VR コンテンツにおけるパフォーマンスの問題とは?

第2回のコラムで、ライトのON/OFFではなく、ライトマップを焼きこむ作業をしたのですが、今回のコラムでは、その理由を説明したいと思います。
今回は2019製品に合わせてリリースされた、Revit Live 2.1と3ds Max Interactive 2.1を利用しています。使用したサンプルのデータはこちらからダウンロード可能です。

皆さんが使っている3ds Max Interactiveがゲームエンジンであるということは、第1回のコラムでご紹介しました。そして、VRコンテンツを表示するソフトの多くは、リアルタイムで3DCGを処理する技術の結晶であるゲームエンジンの技術を利用している場合が多いです。そして、ゲームエンジンへ表示するデータは、3D CADやBIMや3Dのツールで使われるデータの持ち方とは異なる部分が多く、ただファイルを変換するだけでは不十分で、ツール側やゲームエンジン側で何らかの変換(アニメーション、マテリアルなど)が必要となります。そして、オブジェクトの数が多い3D CADやBIMのデータの場合、その変換に手間が掛かり、例え変換できたとしてもその次にデータの重さが問題となってきます。そこで提供されたのがRevit Liveのような製品でした。

ただ、「データが重い」と一言で言っても色々なことが考えられるので、ここでは、VRに特化した意味での「データが重い」を理解する為に、VRをヘッドマウントディスプレイ(以後HMD)に表示する際、どのような形でレンダリングされているのかをまず簡単に説明したいと思います。Revit Liveや3ds Max Interactiveを使ってVRを見る場合、高性能GPUを搭載したハードウェアとHMDを組み合わせて使いますが、その際のレンダリングの更新頻度とその表示画像サイズを見ていきたいと思います。

更新頻度:リフレッシュレート 表示画像サイズ:解像度
HMDの液晶パネルは90Hzで駆動します。つまり、1秒間に90回表示の更新がされていることになります。
90 Frames Per Second(以後、90FPS)
1秒=1000ミリ秒なので、液晶パネルに合わせてGPUやCPUが1回のレンダリングの更新に使える処理時間は約11ミリ秒となります。
1000÷90=11.1111111
これを下回ると、処理が追い付かない状態となり、HMDに表示されて目で見ている情報と、頭の動きに合わせて見れるだろうと脳が期待する情報との間にズレが生じてしまい、結果的に脳が混乱し、「VR酔い」(https://www.moguravr.com/vr-yoi/)と言われる乗り物酔いのような気分が悪くなる症状を訴える方が増えてしまいます。
このVR酔いですが、今まで多くの方の体験をサポートする中で、右目と左目の視力が異なる方がなりやすいように感じたので、体験する方に前もって確認すると良いかもしれません。
90回の更新が必須となるVRの場合、CPUは下記のサイトで8000を超える中程度のものでも十分だと思います。
https://www.cpubenchmark.net/high_end_cpus.html
ですが、VRに表示する処理はGPUでほぼ行われる為、下記のサイトでスコアが10000を超える高性能で、且つVRに特化した最新世代のGPUを選ぶことが必須となります。
https://www.videocardbenchmark.net/high_end_gpus.html
HMDの液晶パネルの解像度ですが、Oculus Rift と HTC Vive は2160 x 1200ピクセル、最近リリースされたHTC Vive Proは 2880 x 1600です。どれも現在、PCのモニターで主流のフルHD(1920×1080)の解像度よりも高くなっています。とはいえ、HMDの場合、目の前数センチの距離で表示されることになり、ピクセルの粗さが目に付き、ぼやけたイメージで見えてしまいます。その為、実際のレンダリング処理では、ターゲットとなるHMDの液晶パネルの1.4倍の解像度の画像(3024×1680や4032×2240)をレンダリングして、その後、実際の解像度に縮小して表示する処理が裏でデフォルトで行われています。下記のサイトで詳しく説明されています。
http://indiegame-japan.com/blog/2016/07/12/post-1130/
因みに、3ds Max Interactiveでは1.6倍、Revit Liveでは1.4倍の解像度で処理していますので、裏では3456×1920や3024×1680、4608×2560や4032×2240のサイズで計算されている、ということになります。ほぼ、4Kですので、フルHDの4倍の画像サイズということになります。

このコラムの読者の方には、3Dのデータをレンダリングしたことのある方も多いと思いますが、レンダリング=時間が掛かる、というイメージが一般的ではないでしょうか?事実、解像度が大きければ大きい程、オブジェクトやライトが大量にあればある程、影や反射や透明やグローバルイルミネーションなどの見え方をリアルにすればしようとする程、レンダリングに時間が掛かる、というのが一般的だと思います。だからこそ、オートデスクは短時間にレンダリングが可能なクラウドレンダリングを提供していたりする訳です。

https://www.autodesk.co.jp/products/rendering/overview

そうした視点で考えると、高解像度の画像を1枚レンダリングするのに11ミリ秒で終わらせることが、どれだけ高い要求なのかお分かり頂けると思います。

長々と説明してきましたが、まとめると、普通にレンダリングしたら重くて1秒間に90回もレンダリングが出来ないような3Dのデータを最適化して、高性能なGPUを使って高解像度の画像を1秒間に90回レンダリングして、HMDで表示してVRで見られるようにすることが出来なければ、VR酔いしにくいコンテンツを作ることはできない、ということになるのです(これでも舌を噛みそうな程に長い説明じゃないか、というのは置いておいて…)。特に、BIMのデータで照明が何百何千と埋め込まれていると、その処理は照明の数に比例して時間が掛かるだけでなく、正しく表示すら出来ない場合もあります。そこで、一番処理負荷の高いものはリアルタイムに処理せず、事前に処理して表示してしまおうというのが、ライトマップを作成する理由の一つとなっています。

では、実行しているVRのコンテンツが90FPSでちゃんと動いているかどうかを確認するにはどうしたらよいのか?という疑問が出てくると思います。HTC Viveの場合、SteamVR側でその機能が提供されています。

[SteamVR] > [設定] > [パフォーマンス] > [フレームタイミングを表示]

でこんな画面が出てきます。

上の段がCPUで、下の段がGPUの毎フレームの処理時間のグラフなのですが、右側を見ると[アイドル](=処理時間が余っている意味)が明るい緑色で表されているのが分かります。その少し左に縦軸に数字が記載されたものがあります。この単位はミリ秒です。つまり、アイドルは11ミリ秒以内であるということが分かります。
VRのコンテンツを実行して、この11ミリ秒の限界を超えて紫や緑や赤のグラフが表示されるような場合は、90FPSに満たない状態となります。

では、このグラフを表示した状態で、Revit Liveでライトマップが焼きこまれていない状態のデータがサンプルデータのZipファイルを解凍した、下記のフォルダ内にありますので、
ARVRColumn5SampleProjects → 20180501 →rac_basic_sample_project_2019-_3D_1-may-2018
Autodesk Liveを起動して、上記フォルダ内の、live.stingray_projectを開き、VRを実行してみて下さい。
デフォルトでは照明がオフになっているので、その状態での、グラフの状態を覚えておいて下さい。使っているGPUの性能に依存するので、結果は様々だと思いますが、今回は2台の環境で試してみました。

GeForce 1060搭載ノートPCの場合:完全に振り切ってしまっています。
GeForce 1080搭載デスクトップPCの場合:11ms以下で処理が完了しています。

続いて、Autodesk LiveでキーボードのLキーを押して照明をオンにします。すると、表示されるグラフが大きく変化して紫が表示される領域が一気に増えるのが分かると思います。アイドルの範囲を超えて、グラフが大きく振れたり、最大14ミリ秒の表示枠を振り切って、全体が紫色で表示される状態になるかもしれません。この状態が90FPS出ていない状態です。HMDを付けて首を左右に振るとスムーズに表示されていないのが分かるはずです。

GeForce 1060搭載ノートPCの場合:相変わらず振り切っています…CPUの処理負荷も増えました。
GeForce 1080搭載デスクトップPCの場合:ライトがONになり、処理負荷がグンと上がる

参考までにですが、こんな時、根本的な解決にはなりませんが一時的な回避策として役に立つよう、SteamVRでは下記の2つの設定がオンになっています。
1.[SteamVR] > [設定] > [開発者] > [非同期再投影]
前フレームの画像をずらして表示するもの

2.[SteamVR] > [設定] > [開発者] > [インターリーブ再投影]
90FPS以下の場合45FPSに半減して表示するもの:その場合、赤い線がグラフに表示される

では、過去のコラムで作成したようなライトマップが焼きこまれたサンプルが、サンプルデータのZipファイルを解凍した、下記のフォルダ内にありますので、
ARVRColumn5SampleProjects → 20180502Lightmap →rac_basic_sample_project_2019-_3D_1-may-2018
Autodesk Liveを起動して、上記フォルダ内の、live.stingray_projectを開き、VRを実行してみて下さい。
見た目が綺麗なライティングが行われているのに、Lキーで照明がオンになった状態程処理落ちしていないはずです。

GeForce 1060搭載ノートPCの場合:むむむ、処理振り切ったままです…
GeForce 1080搭載デスクトップPCの場合:んー、14msには収まっていますが、11msは超えています。

如何でしたでしょうか?なぜライトマップを焼きこむのか、これでお分かりいただけたでしょうか?実はライトマップを焼き込む以外にも、データの最適化の面でパフォーマンスを向上させる様々な要因があるのですが、それはまた別のコラムで紹介しようと思います。一部はこちらのドキュメントにも記載があります。
https://help.autodesk.com/view/Stingray/JPN/?guid=__stingray_help_getting_started_get_started_vr_vr_optimize_html

後は、ハードウェアでパフォーマンスを解決するということも可能です。はい、「金にものを言わせ」、「時間をお金で買う」訳です(笑)。この点もVRにはどんなハードウェアの選択肢があるのか、別の回で紹介しようと思います。

つづく