WebXRパフォーマンスのベストプラクティス

Meta Questヘッドセットの高パフォーマンスのVRエクスペリエンスを構築することは、難しい仕事です。これは、ネイティブVRアプリをビルドするか、WebXRを使ってそれらをビルドするかによらずそう言えます。一般には、ウェブ上でビルドされたVRエクスペリエンスは、UnityやUnrealなどのネイティブプラットフォーム上でビルドされたエクスペリエンスに比べて、速度やパフォーマンスの点で落ちると考えられています。確かに、ブラウザー内で実行するために多少のオーバーヘッドが生じます。とはいえ、ウェブベースのVRエクスペリエンスが遅いのはたいてい、ブラウザーで実行されるからというよりも、適切に最適化されていないためです。Meta Horizonストアで提供されているネイティブアプリは、優れた表現でスムースに動くように相当の努力が払われています。工夫と創意を凝らせば、ウェブベースのエクスペリエンスでも同じように高速かつ美しいものになり得ます。

以下に一般的なガイダンスと推奨事項を示します。これらは、Meta Questヘッドセットで実行されるWebXRエクスペリエンスについて何を期待できるか妥当な線を定めるのに役立ちます。とはいえ、これらは推奨であって保証ではないという点を強調しておきます。レンダリングパフォーマンスは単純に語れるトピックではありません。一見ささいで微妙な違いがアプリのパフォーマンスにかなりの影響をもたらすことがあるため、これらの推奨事項が自分のアプリに当てはまるかどうかを確実に知るには、テストしてどの程度改善が見られるかを測定する以外にありません。フレーム単位コストは、パフォーマンス最適化を再現可能な方法でテストするための盤石なアプローチです。それは、特定のトレードオフを評価する際に特に重要です。

優れたエクスペリエンスを実現するために、Meta Questヘッドセットは非常に高いフレームレートでレンダリングする必要があり、その表示は高解像度なので、多くのVRエクスペリエンスではフラグメントバウンドやフィルレートバウンドになります。言い換えると、レンダリングするフラグメントの数が多すぎたり、レンダリングするフラグメントのコストが高すぎたりします。できる限り、画面上の各フラグメントや各ピクセルは、1回だけレンダリングするよう最大限の努力を払ってください。それはいつでも可能というわけではありませんが、可能な限りそうしてください。同じフラグメントを複数回レンダリングすることは、しばしばオーバードローと呼ばれます。オーバードロー率の高いフレームとは、同じフラグメントを何度もレンダリングするフレームのことです。

アプリのオーバードロー率を最低限に抑えるための1つの簡単な方法は、カメラの現在の位置と向きを基準にして前面から背面へと不透明オブジェクトをソートするようにすることです。深度テストが有効になっていれば、現在のフレームでレンダリング済みの他の物体によってオクルードされることが分かっているピクセルはGPUですばやくスキップすることができます。前面から背面へとソートすることにより、このオクルージョンが最大化され、GPUがスキップするフラグメントが大幅に増えます。

ウェブ上で人気のある3Dフレームワークの多くでは、この機能がサポートされており、その中には前面から背面へのレンダリングがデフォルトになっているものもあります。そうだとしても、シーンについて分かっている情報に基づいて明示的にソート順を決める余地はあります。例えば、プレイヤーを中心に置いた大きな球面に青空をレンダリングする場合、前面から背面へのソートがデフォルトになっていると混乱が発生する可能性が高くなります。おそらく青空の「位置」がカメラの位置に非常に近くなり、そのために青空が早い段階でレンダリングされ、フレーム内のあらゆるフラグメントに触れることになります。その結果、景色全体が、それらのフラグメントに上書きされることになります。前景物体がすべてレンダリングされた後に空が描画されるよう、空の描画順を手動で設定することが必要かもしれません。

ThreeJSやBabylon.jsなどの人気の高い3Dフレームワークでは、PBRマテリアルがサポートされています。これらのマテリアルを使う際には慎重でなければなりませんが、エクスペリエンスでこれらを利用して優れたエフェクトを得ながら、Meta Questハードウェアで良好なパフォーマンスを達成することは可能です。

前述のように、この場合、前面から背面への順序に関して注意深くあることが重要です。1つのフレームで、あらゆるフラグメントに対して何度も複雑なマテリアルをレンダリングするだけの余裕はないかもしれません。

PBRマテリアルでは、ディフューズ、法線、周囲オクルージョン、粗度など、複数のテクスチャーマップがサポートされています。使うマップが増えるほど、またその解像度が高いほど、GPUの負担も大きくなります。テクスチャー帯域幅(GPUが読み取る必要のあるテクセルの量)がボトルネックになる可能性があります。マップを完全にやめたり、マテリアルマップの一部または全部に低解像度マップを使ったりして、これらのマテリアルのコスト削減のための実験をしてください。

シーンの中のライティングの数(と種類)も、シーンのパフォーマンスに大きく影響することがあります。特にPBRマテリアルを使う場合にはそう言えます。あるオブジェクトに影を落とすライティングを追加するたびに、そのオブジェクトのシェーダーの作業が増えることになります。PBRマテリアルがリアルに見える要因の1つは、複雑な数学モデルを使ってシーン内の各ライティングによる光の効果を計算していることにあります。そのため、ライティングを追加すると、コストも追加される可能性があります。一般に、平行光源(または太陽光線)は、多くの場合コストが最も低く、それに続いて(コストが低い順に)点光源、スポットライト、そして面光源と続きます。PBRマテリアルを多用する場合には、普通、1つの平行光源または1つの点光源に制限するのが良いでしょう。

ライティングの設定が静的(照明の位置と値が変化しない)なら、動的オブジェクトに光を当てる代替手段としてライトプローブを使うことを検討してください。完全に静的な設定の場合(静的照明と静的物体)は、ライティングをライトマップに焼き付けることを検討できます。

リアルタイムシャドウは多くの場合、シーンを光源の観点で1度レンダリングしてシャドウマップを生成した後、視聴者の位置から再度シーンをレンダリングし、シーン内のオブジェクトにシャドウマップを適用することにより実装されます。シャドウマップのレンダリングのために行われるシーンの描画は、ドローコールや三角形のシーン予算に該当するものとしてカウントされます。また、高解像度のシャドウマップにレンダリングする場合、シャドウマップでシャドウを付ける必要のあるフラグメントの数によっては、シーンのフラグメントバウンドの原因となることがあります。シャドウの元になる点光源は特に問題です。たいてい、フレームごとにレンダリングする必要のあるシャドウマップが6つもあるからです。

Meta QuestデバイスのWebXRエクスペリエンスでのテクスチャー圧縮には、KTX 2.0⁠/Basis Universalのアプローチをおすすめします。これによってファイルサイズがJPEGやPNGほど小さくなるわけではないとしても、テクスチャーのメモリーサイズは小さくなり、GPUによるこれらのテクスチャーへのアクセス効率が高くなって、シーンのテクスチャー帯域幅が下がります。

リアルタイムレンダリングでのテクスチャー圧縮についてよく知らない場合は、上記のKTX 2.0のリンクに有用なドキュメントが多数あります。特に、Artist Guide⁠は優れたリファレンスです。さまざまなタイプの圧縮、それぞれの長所と短所、またテクスチャーマップのタイプごとにどのタイプの圧縮が最適なのか分かりやすく説明されています。例えば、ディフューズマップの圧縮では、法線マップで使うものとは異なる圧縮タイプを使いたいと思うでしょう。

透明オブジェクトは、多くの場合、背面から前面へとレンダリングされます。それにより、正しい透明度で見えるようになります。しかしそれはまた、シーン内のフラグメントが複数回レンダリングされることを意味しています。その極端な例はパーティクル効果です。しばしば数多くの大きな透明物体が重なり合うことになり、結果として大量のオーバードローになるからです。

アプリロジックに基づいてフェードアウトする3Dオブジェクトがシーンにある場合、完全にフェードアウトしたなら描画を停止するようにしてください。そうしないと、完全に透明であっても、レンダリングのためにしっかりコストがかかることになります。

Quest 1および2のAdreno GPUには、バッファを黒または白にクリアする際に、ハードウェアレベルの「高速クリア」最適化機能⁠があります。シーンの背景を提供するために消去色を使っているのでなければ、白か黒のいずれかに設定するようにしてください。

VRアプリは非常に高いフレームレートで実行する必要があります。しかし、実際のエクスペリエンスでオブジェクトを更新するレートは、必ずしも同じレートである必要はありません。CPUバウンドの状況では、複数フレームでシーンの更新をばらつかせることにより、これを最適化できます。例えば、1秒に90フレームでレンダリングしているとしても、アニメーションの更新は1秒に30回で十分という場合があるかもしれません。その場合、シーン内のオブジェクトを3つのセットに分け、アニメーションは1フレームで1つのセットだけ更新するようにすれば、フレーム単位のコストをかなり削減できます。似たような最適化は、視聴者から遠く離れた物体の更新頻度を低くすることにも適用できるかもしれません。