フォートナイト バトルロイヤル チャプター 4 の仮想シャドウ マップ

仮想シャドウ マップのキャッシュに関する考慮事項

仮想シャドウ マップは品質要件を満たすものの、過去の Lumen in the Land of Nanite と The Matrix Awakens: An Unreal Engine 5 Experience のデモでは、良好なパフォーマンスを得るために、シャドウ マップ ページのキャッシュに大きく頼っています。フォートナイト では、これら以前のデモよりも高いパフォーマンス レベルを目標としているだけでなく、大量の変形をアニメートしていること (主に木) と、太陽が絶え間なく移動していることから、シャドウ マップをキャッシュする能力が大幅に低下しています。

まず、「最適化された WPO」フラグの使用など、アニメートしたジオメトリによる無効化を減らすのに役立つ多くの改善を実装しました (Nanite ブログ記事 で解説しています)。これは役に立ちましたが、目標を達成するには不十分でした。

単純にいくつか優先順位を調整することで無効化するのを直接抑制しようと思いましたが、これによりページ境界であまりにも多くのアーティファクトが生成されるようになりました。最もコストがかかる方法で遠くのジオメトリをレンダリングする従来のシャドウ マップの場合はこのやり方でうまくいきますが、Nanite および仮想シャドウ マップの場合は、画面上のピクセルに合ったコストになります。その結果、遠くのシャドウは比較的低コストで生成できるようになりました。その中で最もコストがかかるのは、たとえば歩いて木に近づき、それを見上げるといったような状況です。このとき、ジオメトリには十分な一貫性がないことと、オーバードローが大量に発生することにより、シャドウ ページの効率が低下して Nanite のパフォーマンスが低下します。

つまり、少なくともフレーム間でキャッシュ データを再投影する必要が出てきます。それによりオーバーヘッドが増え、せっかくキャッシュで節約した分を食いつぶしてしまいます。密度の高いシャドウ マップの再投影は比較的簡単です。シャドウの端の部分で一部のデータが失われるものの、通常はシャドウが比較的ぼやけていることから小さな問題が目立つことはありません。

残念ながら、仮想シャドウ マップではカバーするすべてのソース ページが前のフレームでマップされている場合にのみ、新しいページを再構築できます。そうでないと、部分的に無効なシャドウ ページをキャッシュすることになるからです。仮想シャドウ マップは、概念的には密度の高いシャドウ データに大きな「穴」を作って密度を下げることで効率性を大幅に向上させています。これにより、再利用するキャッシュ ページの量がさらに減少します。

また仮想シャドウ マップは通常、従来のシャドウ マップよりも解像度が高く、よりシャープなフィルタリングを使用します。そのため、問題や不正確さが視覚的により目立つようになり、ぼかしによってごまかしにくくなります。最後に、無効化した場合は木のようなノイズの多いオブジェクトでデータに非常に多くの穴があり、再構築できるページはほとんどなくなるので、再投影する際にも最悪です。

こうした問題があることと一般的に悪いケースの発生率が高いことから、フォートナイト では太陽とシャドウの扱い方を変えることにしました。

キャッシュされていない太陽のシャドウ

最も大きな負荷をかけていたものの 1 つで、まず見つけたのはランドスケープです。したがって、主に仮想シャドウ マップのパフォーマンスを改善するために単純な Nanite ランドスケープのサポートを追加しました。それにより、問題を効果的に排除することができました。

フォートナイト バトルロイヤル チャプター 4 では、ジオメトリの大部分を Nanite に変換できたので、シャドウ パフォーマンスも大幅に向上しています。Nanite 以外のシャドウ キャスティング オブジェクト (特にプレイヤー モデル) はまだいくつかあります。しかし、数は少なくサイズも小さいため、一般的にパフォーマンスの問題は発生しません。

さまざまなボリューム エフェクトをサポートするために、仮想シャドウ マップは「粗いページ」と呼ばれる錐台全体をカバーする非常に低解像度のマップも維持しています。 したがって、Nanite の素晴らしい LOD により、粗いページのレンダリングが効率的になります。ただし以前のリリースでは、非 Nanite のジオメトリは主に不必要な頂点処理が原因で、大きく変動するオーバーヘッドを引き起こしていました。この問題を軽減するために、小さいオブジェクトのフィルタリングを粗いページに追加しました。この機能を有効にすることで、フォートナイト をシッピングできるようになりました。これは Unreal Engine 5.1 でもデフォルトで有効になっています。

フォリッジ

フォートナイト バトルロイヤル チャプター 4 における主要な視覚的改善事項はフォリッジでした。パフォーマンス上、これが主な懸念事項の 1 つでした。

キャッシュされていないシャドウのレンダリング パフォーマンスには、メイン ビューで行ったことと多くの点で同じ最適化を施しています。これは Nanite ブログ記事 で説明されています。アルファ テストを削除したことと、ワールド位置オフセット関数の負荷を可能な限り下げたことがシャドウ パフォーマンスに最も影響を与えました (大部分は フォートナイト で事前に計算されています)。これらの非常に詳細な Nanite メッシュの使用コストはすでに高いのですが、メッシュ クラスタが複数のシャドウ クリップマップ レベルにまたがっている場合、メッシュ クラスタを数回ラスタライズしなければならないこともあります。

シャドウ パス (ライトではなく、メイン カメラの位置に相対的) には、ワールド位置オフセットの距離カリングを実装しています。メイン ビューとの一貫性を維持するためと、パフォーマンスを多少改善させるためです。

フォートナイト では、すでにチャプター 4 以前でも「シャドウ プロキシ」システムを使用していました。しかし当初は、シャドウ パスで完全な 300,000 個以上のポリゴン ツリー メッシュを使用した状態でシャドウのパフォーマンス バジェットを達成できるかどうか確信が持てませんでした。シャドウには通常、プライマリ ビューよりも小さいフレーム バジェットが割り当てられますが、同じような (場合によってはそれ以上の) ピクセル数がレンダリングされるためです。ツリー アクタに 2 つのスタティックメッシュ コンポーネントを配置することで、シャドウ プロキシを実装しました。1 つ目は「キャスト シャドウ」を無効にしたメイン ビュー用で、2 つ目は「非表示にしているシャドウをキャスト」を有効にしたシャドウ プロキシ用の非表示のコンポーネントです。

チャプター 4 の場合、シャドウ プロキシ メッシュは依然としてかなり複雑です。三角ポリゴン数は 60,000 以上になるのが一般的です。

Nanite の「Preserve Area」オプションが追加される前、および Nanite のプログラム可能なラスタライズ最適化の多くが実装される前にシャドウ プロキシの評価を行っています。プロセスの後半で徹底的に再評価を行う時間がなかったためです。さらに、フォートナイト にはすでにシャドウ プロキシ システムが存在しており、Nanite 以外のプラットフォームでは引き続き必要となります。

とはいえ、今後パフォーマンスを改善するために必ずしもシャドウ プロキシが必要であるとは思っていません。直感とは反対に、Nanite はこれらの範囲で両方のメッシュに対して同じ三角ポリゴンの密度をターゲットにするため、遠く (または中くらいの距離) のフォリッジのパフォーマンスに大きな違いはありません。Nanite シャドウ プロキシが重要になるのは、木がカメラに非常に近い場合のみです。この場合、プロキシによってシャドウ パスでレンダリングされるジオメトリックな詳細がわずかに少なくなります。

チャプター 4 の後に概念実証を何度か行いましたが、その結果、「アーティストが生成するシャドウ プロキシ メッシュはもはや必要ない」とかなり確信を持てるようになりました。そして、これらのメッシュ上で選択した Nanite の詳細レベルをクランプできれば、同様のパフォーマンスと品質を得られることでしょう。その機能が本当に必要かどうかは、シャドウ プロキシの最初の評価後に行われた他のすべての最適化を考慮した上で、引き続き検討します。

木に対して行った主な品質改善項目としてもう 1 つご紹介したいのは、(フォートナイト の木の葉に使用される) サブサーフェス マテリアルのシャドウ タームを別の方法で評価したことです。通常これらのマテリアルは、ライトに面する葉には標準的な濃いシャドウ タームを、葉の透過処理のおおまかな近似値としては背面にソフト フォールオフを使用します。

以前使用していた方法では、シャドウが非常にぼやけていたことから、この詳細によって大きな違いは生まれませんでした。仮想シャドウ マップを使用すると、いくつかの新しいアーティファクトが発生することがわかりました。これらの木の葉をジオメトリックな法線ではなく「球面状」の法線が操作することで、シェーディング効果を和らげているためです。これにより、シェーディング法線が後ろ向きから前向きに反転し、関連するシャドウ タームが切り替わって連続性が失われていました。

この対策と、シャドウ タームでも全体的にソフトな外観を実現するため、シェーディング法線に関係なく、大まかな透過フォールオフを含む単一のタームを使用する代替のサブサーフェス シャドウ モードを実装しました。さらに内部で散乱している印象を与えるために、マテリアルの不透明度に基づいてシャドウ フィルタリング コーンを適宜広げています。この新しいモードは r.Shadow.Virtual.SubsurfaceShadowMode 1 で有効にできます。将来のエンジン バージョンでは、この設定がデフォルトになる可能性があります。

水

第二に、それらはライトの「ソース半径」を使用します。接触点でくっきりと投影され、そこから離れるとソフトになるような、より物理的にリアルなシャドウの半暗部を生成します。このパラメータは以前は無視されていたことから、フォートナイト では多くのライトで適切なソース半径を確認して設定する必要がありました。

フォートナイト では、視覚的な問題を最小限に抑えつつフレームごとに更新する遠方のライトの数は 1 つのみにできました。カメラに近いライトは、通常の方法で更新および無効化されたページを含む完全な仮想シャドウ マップを取得しています。

シャドウの投影性能

各ライトからのシャドウイングを評価および適用する際、ライト ループではシャドウのパフォーマンスに関わる重要な問題がもう 1 つ発生していました。小さなローカル ライトです。この問題は長い間存在していました。これらライトの影響を受けるピクセル数は比較的少数でしたが、ライトごとに複数のパスを実行しており、それらの間に依存関係があることから、GPU が十分に活用されていなかったのです。

この昔からある問題に対しても、仮想シャドウ マップには対策ツールがあります。Unreal Engine 5 にあるオプションの「ワンパス プロジェクション」モードがこの解決に役立ちます。しかし、クラスタ シェーディングに対してのみの使用に限られていました。残念ながら、クラスタ化されたシェーディングを有効にする場合、フォートナイト ではパフォーマンスが低下し、モードの利点のほとんどが失われてしまいました。Unreal Engine 5.1 では、この 2 つを切り離し、クラスタ化されたシェーディングなしでワンパス プロジェクションを有効にできるようにしました。

「ワンパス プロジェクション」がアクティブな場合 (r.Shadow.Virtual.OnePassProjection 1)、ローカル ライトのシャドウイングは前もって単一のパスで実行され、結果はライティングでシャドウイング計算をインターリーブするのではなく、一時バッファに格納されます。さらに、内部ループではなく前もって実行されるように、他のいくつかのパス (透過処理ボリュームの注入) をリファクタリングしました。

その結果、特定のライトが仮想シャドウ マップのみを必要とする場合 (およびシャドウ マスクに寄与するライト関数またはその他のパスを使用しない場合) は、単一のパイプライン化された描画呼び出しで実行できるようになり、小さなローカル ライトのパフォーマンスが大幅に向上しました。

より詳細な技術情報については、「仮想シャドウ マップのドキュメント」を参照してください。