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

Andrew Lauritzen (シニア レンダリング プログラマ) / Ola Olsson (シニア レンダリング エンジニア) |
2023年1月26日
こんにちは、Andrew Lauritzen と Ola Olsson です。Unreal Engine 5 のシャドウイングを主に担当するレンダリング エンジニアです。UE5 での作業開始以来、私たちは仮想シャドウ マップ (VSM) を重点的に使用してきました。VSM は「Nanite の仮想化されたジオメトリ」とうまく動作するように設計されており、カメラ付近の小さなジオメトリの詳細から地平線まで、正確なシャドウを効率的にレンダリングできます。

この投稿では、フォートナイト バトルロイヤル チャプター 4 で仮想シャドウ マップがどのように使用されているかについて、最近の技術的改善とコンテンツに関する考慮事項に特に焦点を当てて、いくつかの事柄を掘り下げます。VSM は特に Nanite を念頭に置いて設計されており、Nanite のラスタライズ プロセスと密に連携しています。多くの場合、シャドウの最適化と Nanite のパフォーマンスは直接関係しています。したがって先に進む前に フォートナイト バトル ロイヤル チャプター 4 における Nanite ブログ記事 を読むことをお勧めします。この記事で言及されている手法の多くは、仮想シャドウ マップと等しく重要である上、いくつかの手法については主に仮想シャドウ マップを念頭に置いています。

チャプター 4 では Nanite が多用されていることを考えると、仮想シャドウ マップを使用するのも合理的といえます。従来のシャドウ マップと比較すると、どちらもパフォーマンスと品質が向上しているためです。フォートナイト では、動的な変形とアニメーションが多いことを考慮してアクセラレーション構造を再ビルドしなければなりません。しかしそれを行うとパフォーマンスが低下するため、レイ トレーシング シャドウの使用は現時点では適切とは言えません。さらに、レイ トレーシング シャドウは、詳細度の低いバージョンの Nanite ジオメトリを使用します。これは、一部のエフェクトには適している一方で、直接シャドウイングに適用すると細かいディテールが失われてしまいます。

チャプター 4 では、パフォーマンスと品質だけでなく、シャドウイングの具体的な目標をいくつか設定しました。これについては、以降のセクションで説明します。
 

太陽のシャドウ (ディレクショナル ライト)

主なシーンは屋外であるため、フォートナイト でプレイヤーが見ることになるシャドウの大部分は太陽から生成されます。しかしながら、太陽は最も難しいライトの 1 つでもあります。理想を言うと、プレイヤーから数センチの距離から地平線まで視覚的に一貫したシャドウが必要となります。フォートナイト バトルロイヤル では、このスケールの違いはただ存在するというだけではなく、最初のスカイ ダイビング シーケンスによって示されます。

以前の フォートナイト では、さまざまなシャドウ技術を使用し、パフォーマンスのバランスを取りながらこれらすべてのケースをカバーしようとしました。プレイヤーの近くのシャドウの場合、従来のシャドウ マップ カスケードをいくつか使用していました。それより遠くの場所の場合は、距離フィールド シャドウと、マップのすべてではありませんがほとんどをカバーする単一の「遠方の」カスケードを混在させた形で使用していました。プレイヤー キャラクターは、オブジェクトごとに専用のシャドウ マップを取得していました。スクリーン空間コンタクト シャドウは、これらすべての上に重ねられ、低解像度向けの技術では省略されていた詳細の一部や、遠くにある省略されていたシャドウを補います。

これまでは、このシャドウのテクニックの組み合わせで何とかしていました。しかしこの方法の場合、遠くに低解像度のぼやけたシャドウしか生成できず、テクニックが切り替わるゾーンがしばしば目立っていました。Nanite の視覚的な利点の多くは、詳細レベルの遷移にもたらされる時間的な安定性によりもたらされます。距離が変わるとシャドウが消えたり、ポップしたり、テクニックが切り替わったりする場合、時間的な安定性は損なわれてしまいます。

仮想シャドウ マップによって、これらすべての手法が 1 つの統一されたパスに置き換わります。

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

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

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

単純にいくつか優先順位を調整することで無効化するのを直接抑制しようと思いましたが、これによりページ境界であまりにも多くのアーティファクトが生成されるようになりました。最もコストがかかる方法で遠くのジオメトリをレンダリングする従来のシャドウ マップの場合はこのやり方でうまくいきますが、Nanite および仮想シャドウ マップの場合は、画面上のピクセルに合ったコストになります。その結果、遠くのシャドウは比較的低コストで生成できるようになりました。その中で最もコストがかかるのは、たとえば歩いて木に近づき、それを見上げるといったような状況です。このとき、ジオメトリには十分な一貫性がないことと、オーバードローが大量に発生することにより、シャドウ ページの効率が低下して Nanite のパフォーマンスが低下します。
単にシャドウ ページの更新を調整またはスキップした場合は、カメラの近くにはっきりとアーティファクトが生成されてしまいます。したがって、「ベース ポーズ」でいくつかのオブジェクトをシャドウ ページ キャッシュに描画し、シャドウ ルックアップをそのポーズに再投影しました。これにより、あたかもサーフェスに接着されているかのようにシャドウがアニメートされたオブジェクトに追従するようになり、ライティングのベイクと同様の効果が得られるようになりました。残念ながら、ツリー上の他のオブジェクトのシャドウからセルフ シャドウ部分 (葉から他の葉へのシャドウ) を分離する簡単な方法はありません。

2 つ目の制約は、さらに大きな問題であることが判明しました。フォートナイト は、太陽の方向が継続的にアニメートされる時刻システムを備えています。太陽からのライトを正確に再現するには、ライトの方向が変化したときにキャッシュされたすべてのシャドウ マップ データを破棄する必要がありますが、太陽の動きが速すぎない限り、その辺りが多少いい加減でも問題ありません。しかし、いくつかの要因が重なることにより、仮想シャドウ マップではこの「ごまかし」が難しくなっています。

まず、シャドウ データのローテーションだけではなく、ページがどこに落ちるかといった全体的なパラメータ化も必要になるためです。このエフェクトは、カメラの近くのページの太陽の動きが目に見えて遅い場合でも非常に顕著です。
フォートナイトでは、太陽の動きにより、フレームごとに非常に大きなシャドウ ページ テーブルの変更が発生します。
つまり、少なくともフレーム間でキャッシュ データを再投影する必要が出てきます。それによりオーバーヘッドが増え、せっかくキャッシュで節約した分を食いつぶしてしまいます。密度の高いシャドウ マップの再投影は比較的簡単です。シャドウの端の部分で一部のデータが失われるものの、通常はシャドウが比較的ぼやけていることから小さな問題が目立つことはありません。

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

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

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

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

フォートナイト では常にキャッシングできる状況を維持するのは不可能なため、悪いケースが発生したとしてもパフォーマンス バジェット内に収まる程度までそれを減らす必要があります。これを解決し、60 fps の目標を達成するため、太陽のシャドウの有効解像度の目標を以前のデモの約半分に落としました。この変更により視覚的にも影響が出てしまいますが、それでもシャドウは (前述の比較が示すように) 以前の手法よりも解像度ははるかに高くなります。また、指向性ライトのページはキャッシュしないだろうと考え、ブック キーピングと無効化に伴うオーバーヘッドを削減するためのコントロールを追加しました (r.Shadow.Virtual.Cache.ForceInvalidateDirectional)。

この決定に伴ってトレードオフになる事項は、他のゲームでは異なります。シャドウ マップのキャッシングを停止してシャドウの解像度を下げると、視覚的な悪影響が間違いなく発生します。そのため、他のゲームでは必ずしもこれが最適な方法とは限りません。とはいえ 60 fps で指向性ライトのシャドウ キャッシングがなかったとしても、フォートナイト で達成した品質レベルにはかなり満足しています。

非 Nanite ジオメトリ

太陽のキャッシュを追跡しないとなると、シャドウ マップへのレンダリングの生のパフォーマンスが最も重要になります。仮想シャドウ マップのレンダリングで優れたパフォーマンスを得るには、まずすべてを Nanite で実行する必要があります。Nanite 以外のオブジェクトは、パフォーマンス上大きな問題を引き起こす可能性があります。とりわけ、ポリゴン数が多い場合、物理的に大きい場合、多数の仮想シャドウ マップ ページとオーバーラップしている場合はなおさらです。

フォートナイト には大量のコンテンツがあることから、どれが悪さをしているのかを見つけやすくするために簡単なデバッグ出力を作成しました。r.Shadow.Virtual.NonNanite.NumPageAreaDiagSlots -1 を設定すると、多数のシャドウ マップ ページをカバーしている非 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 以上になるのが一般的です。
(左) ベース ツリー メッシュ (300,000 個以上のポリゴン) | (右) 木のシャドウのプロキシ メッシュ (60,000 個以上のポリゴン)
シャドウのある木の視覚的影響を最小限に抑えるようにプロキシを微調整しています。詳細を削除しすぎると、樹冠のライティング深度の品質が大幅に低下するためです。シャドウ プロキシはシッピング時に詳細が少し失われてしまいますが、2 つの画像を直接比較しなければ目立ちません。
(左) シャドウ プロキシ メッシュを使用したツリー | (右) シャドウ プロキシ メッシュのないツリー
Nanite の「Preserve Area」オプションが追加される前、および Nanite のプログラム可能なラスタライズ最適化の多くが実装される前にシャドウ プロキシの評価を行っています。プロセスの後半で徹底的に再評価を行う時間がなかったためです。さらに、フォートナイト にはすでにシャドウ プロキシ システムが存在しており、Nanite 以外のプラットフォームでは引き続き必要となります。

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

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

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

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

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

フォートナイト では、ビジュアルとパフォーマンスの両方の理由から、草には木や茂みとは異なるアプローチを採用しています。

フォートナイト では以前、他のゲームと同様、草はシャドウ マップにレンダリングしておらず、純粋にスクリーン空間の「コンタクト シャドウ」に依存していました。これまでは、少なくとも部分的には一般的なシャドウ マップの解像度が草の詳細をキャプチャするのに十分ではなかったためです。

新しい Nanite ジオメトリ ベースの草と仮想シャドウ マップを使用してこのプロセスを見直しましたが、最終的には、いくつかの理由からコンタクト シャドウのみ使用することにしました。

そのようにした 1 つ目の理由は、草から投影されるシャドウの暗さを制御することを検討した結果、これは仮想シャドウ マップでは不可能だと判明したためです。これを行う目的は、草を透過する量のシミュレートと、現実よりも若干大きい葉先の補正です。2 つ目の理由は、新しい草は現実のジオメトリであることからすでに視覚的品質が優れており、コンタクト シャドウを機能させる上でより優れた深度バッファを得られたためです。3 つ目の理由は、草を仮想シャドウ マップにレンダリングするパフォーマンス コストが大きくはなかったものの、小さくもなかったためです。

特に大きな花やシダでは、完全な仮想シャドウ マップを使用した方が見栄えが良くなるケースがいくつかあったのですが、全体的には同様の結果が得られ、強度をよりソフトに制御できるスクリーン空間メソッドの方がアーティストには好まれました。視覚的な品質の比較を考慮した結果、仮想シャドウ マップは他の箇所に使用した方がより良い視覚的表現が実現できると判断しました。
(左) 草のシャドウを仮想シャドウ マップで行う場合、レンダリングにコストがかかる上、アート スタイルには粗すぎます。| | (右) スクリーン空間コンタクト シャドウの場合、同様のエフェクトをキャプチャし、強度を下げてより多くの透過をシミュレートできます。

注目すべきもう 1 つの領域は、水面のシャドウです。仮想シャドウ マップは、カメラの深度バッファを分析し、それらのサンプリング位置をライトの座標フレームに投影することによって、どのページが必要かを判断します。単一レイヤーの水やその他の従来からある「フォワード レンダリング」技術は、深度バッファに寄与しません。そのため、特定のカメラ ビューには、水面のルックアップに使用可能な高解像度のシャドウのデータがない場合があります。

必要なデータを仮想シャドウ マップに提供する (さらに、他のシステムとより適切に統合する) ため、水のレンダリング チームと協力して水の「深度プリパス」モードを実装しました。これは、コンソール変数 r.Water.SingleLayer.DepthPrepass 1 を介して有効にできます。このモードを有効にすると、水面もページにマークされて確実に高品質な仮想シャドウ マップを作成できるようになります。

ローカル ライト

フォートナイト では、かなりの数のローカル ライト (スポット ライトとポイント ライトの混合) を使用しています。大きなシーリングライトからランプ、宝箱などの「エフェクト」ライトまで、幅広い用途で使用しています。これらライトにより、シーンが夜のときでもシーンが見やすくなりますが、常に太陽 / 月の指向性ライトと一緒に存在するため、それら両方のバジェットがシャドウ バジェット内に収まっている必要があります。特定のフレームには、通常、カリング後に約 10 個のシャドウ ローカル ライトが存在します。
フォートナイトでは、「エフェクト」ライトで宝箱が目立つようにしています。
仮想シャドウ マップは、品質の観点から以前のソリューションよりも多くの利点があることがすぐにわかりました。まず、従来のシャドウマップで悩みの種だったアーティファクトの偏りが減っている一方で、より多くの詳細をキャプチャします。
(左) シャドウ マップの半暗部が過度にぼやけ、壁にアーティファクトの偏りがあります。| | (右) 仮想シャドウ マップがアーティファクトの修正を行っており、半暗部も可変的です。
第二に、それらはライトの「ソース半径」を使用します。接触点でくっきりと投影され、そこから離れるとソフトになるような、より物理的にリアルなシャドウの半暗部を生成します。このパラメータは以前は無視されていたことから、フォートナイト では多くのライトで適切なソース半径を確認して設定する必要がありました。
(左) シャドウ マップには一様にくっきりしたシャドウがある一方で、細部のシャドウは失われています。| | (右) 仮想シャドウ マップにはエリア ライトの半暗部があり、コンタクトも強調されています。
これらのローカル ライトの能力を発揮するには、それらへのレンダリングと、シーンへの投影とフィルタリングというフレームの 2 つの側面について考える必要があります。これらの領域は両方とも、フォートナイト バトル ロイヤル チャプター 4 でいくらかの作業が必要でした。

ローカル ライト キャッシング

太陽とは異なり、シャドウ マップ キャッシングは フォートナイト のローカル ライトに適していました。多くの場合、ローカル ライトは固定されており、その周囲には比較的静的なジオメトリがあります。くわえて、ここでは遠方のライトのシャドウイングを評価して壁から漏れないようにすることが重要となりますが、フレームごとの更新はそれほど求められません。視覚的な影響がはるかに小さいためです。高解像度の近距離フィールド シャドウ向けの希薄性に対して使用する基本的なメカニズムは、それぞれが少数のシャドウ ピクセルに寄与する多数のライトに対してこれを実行する必要がある場合、コストが高くなってしまいます。

その対策として、ローカル ライトが画面上で小さく、1 つのシャドウ マップ ページ (128 x 128 テクセル) しかカバーできない場合にローカル ライトを「遠方のライト」として分類するためのサポートを追加しました。このモードは、コンソール変数 r.Shadow.Virtual.DistantLightMode 1 で有効にできます。遠方のライトについては、事実上「密な」シャドウ マップであることから、ほとんどのページ テーブル メカニズムを省略しています。さらにこれらのライト (r.Shadow.Virtual.MaxDistantUpdatePerFrame) への更新も減らし、ジオメトリが移動した場合でも更新の間にキャッシュされたページを利用するようにしました。
ローカル ライトの可視化。黄色のライトの球体は「遠方の」ライトとして使用できる程度には十分小さい一方で、青色のライトの球体は完全な仮想シャドウ マップを取得しています。
フォートナイト では、視覚的な問題を最小限に抑えつつフレームごとに更新する遠方のライトの数は 1 つのみにできました。カメラに近いライトは、通常の方法で更新および無効化されたページを含む完全な仮想シャドウ マップを取得しています。

シャドウの投影性能

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

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

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

その結果、特定のライトが仮想シャドウ マップのみを必要とする場合 (およびシャドウ マスクに寄与するライト関数またはその他のパスを使用しない場合) は、単一のパイプライン化された描画呼び出しで実行できるようになり、小さなローカル ライトのパフォーマンスが大幅に向上しました。
(左) 従来のライト ループ (1.56ms) には、GPU バリアとともにライトごとに複数のインターリーブ パスがあるため、GPU がアイドル状態の間はパフォーマンスが浪費されます。| | (右) 最適化された「ワンパス プロジェクション」ライト ループ (1.08 ミリ秒) は、すべてのシャドウイングを前もって計算するため、各ライトはバリアのない単一のパイプライン処理された描画になります。

まとめ

この記事で説明した改善項目に加えて、フォートナイト 以外にも広く適用可能な他のいくつかの一般的な改善事項をエンジンに実装しました。今後も、残りの大まかな改善事項を実装していく予定です。

当初はキャッシングとパフォーマンスに関して懸念を抱えていたものの、フォートナイト バトルロイヤル チャプター 4 における仮想シャドウ マップの外観とパフォーマンスには全体的に非常に満足しています。皆さんにゲームと新しいグラフィックスを楽しんでいただけたら幸いです。そして、他の開発者がこれらの機能を Unreal Engine のゲームでどのように使用するのか、楽しみです。
より詳細な技術情報については、「仮想シャドウ マップのドキュメント」を参照してください。

    今すぐ Unreal Engine を入手しましょう!

    Unreal Engine は、世界で最もオープンで高度な制作ツールです。
    あらゆる機能とソース コード アクセスを完備している Unreal Engine を使用すれば、すぐに制作を開始できます。
    GDC 2024 にオンラインで参加、または直接参加しましょう。
    イベント
    1月17日

    GDC 2024 にオンラインで参加、または直接参加しましょう。

    State of Unreal を視聴すると、Epic やパートナーによる最新ニュースを入手したり技術講演の詳細を確認したり、セッションやラーニング シアターでアイデアや情報を得たりすることができます。
    GDC 2024 にオンラインで参加、または直接参加しましょう。
    イベント

    GDC 2024 にオンラインで参加、または直接参加しましょう。

    State of Unreal を視聴すると、Epic やパートナーによる最新ニュースを入手したり技術講演の詳細を確認したり、セッションやラーニング シアターでアイデアや情報を得たりすることができます。
    今回のテーマは「おす」<br />
Unreal Engine学習向け作品コンテスト、“第21回UE5ぷちコン”開催のお知らせ
    ニュース
    2月16日

    今回のテーマは「おす」
    Unreal Engine学習向け作品コンテスト、“第21回UE5ぷちコン”開催のお知らせ

    株式会社ヒストリアは、Unreal Engine学習向けコンテスト“第21回UE5ぷちコン”を開催、テーマを「おす」と発表いたしました。20224年2月16日(金)~2024年4月7日(日)の期間内に作品エントリーを受け付けております。また、サイドイベント” ぷちコンゲームジャム”をヒストリアオフィスにて開催いたします。
    今回のテーマは「おす」<br />
Unreal Engine学習向け作品コンテスト、“第21回UE5ぷちコン”開催のお知らせ
    ニュース

    今回のテーマは「おす」
    Unreal Engine学習向け作品コンテスト、“第21回UE5ぷちコン”開催のお知らせ

    株式会社ヒストリアは、Unreal Engine学習向けコンテスト“第21回UE5ぷちコン”を開催、テーマを「おす」と発表いたしました。20224年2月16日(金)~2024年4月7日(日)の期間内に作品エントリーを受け付けております。また、サイドイベント” ぷちコンゲームジャム”をヒストリアオフィスにて開催いたします。
    2024年2月の無料の Unreal Engine マーケットプレイス コンテンツ
    ニュース
    2月6日

    2024年2月の無料の Unreal Engine マーケットプレイス コンテンツ

    ファンタジックなインテリア、スタイライズされたクリスタルの鉱山、90年代がよみがえるアセットなど、Unreal Engine マーケットプレイスから 2月の無料3Dアセットが登場しました!
    2024年2月の無料の Unreal Engine マーケットプレイス コンテンツ
    ニュース

    2024年2月の無料の Unreal Engine マーケットプレイス コンテンツ

    ファンタジックなインテリア、スタイライズされたクリスタルの鉱山、90年代がよみがえるアセットなど、Unreal Engine マーケットプレイスから 2月の無料3Dアセットが登場しました!