フレームエンジンUnreal Engineをレンダリングする方法

Unrealソースコードを探して、 人気のあるゲームがフレームをレンダリングする方法の優れた分析に触発されて（Habré の記事の翻訳 ）、エンジンがフレームをレンダリングする方法を学ぶためにそれと似たようなことをすることも決めました（シーンのパラメーターと設定デフォルト）。



ソースコードにアクセスできるため、レンダラーのソースコードを調べて、それが何をするのかを理解できますが、それはエンジンのかなりの部分であり、レンダリングパスは非常にコンテキストに依存しているため、純粋な低レベルAPI（コードを調べることもあります）空白を埋めます）。



いくつかの静的および動的な小道具、いくつかの光源、ボリューメトリックフォグ、透明なオブジェクト、パーティクルエフェクトを含むシンプルなシーンを作成し、十分な範囲のマテリアルとレンダリング方法を使用しました。



そこで、 RenderDocを介してEditorをスキップし、キャプチャをオンにしました。 おそらくこれは実際のゲームのフレームがどのように見えるかにあまり似ていないかもしれませんが、アンリアルがどのように標準フレームをレンダリングするかのおおよそのアイデアを提供します（設定を変更せず、PCの最大品質を選択しました）：











注：分析は、ビデオプロセッサ情報のキャプチャとレンダラーのソースコード（ バージョン4.17.1 ）に基づいています。 このプロジェクトの前は、Unrealの経験はあまりありませんでした。 私が何かを逃したか、何かを間違えた場合は、コメントで知らせてください。



幸いなことに、Unrealレンダリングコールリストは明確で注釈が付けられているため、作業が簡単になります。 シーンにエンティティ/マテリアルがない場合、またはより低い品質を選択した場合、リストは異なって見える場合があります。 たとえば、パーティクルなしでレンダリングする場合、 ParticleSimulationパスはありません。



SlateUIレンダリングパスには、UIをレンダリングするためにUnreal Editorによって行われたすべてのAPI呼び出しが含まれているため、それをスキップして、 シーンセクションのすべてのパスに焦点を当てます。



粒子シミュレーション



フレームは、 ParticleSimulationパスで始まります。 RGBA32_Float（位置はここに記述されています）およびRGBA16_Float（速度）（および時間/寿命関連データのペア）の2つのターゲットレンダーについて、ビデオプロセッサの粒子の動きとシーン内の各粒子エミッターのその他のプロパティを計算します。 ここでは、たとえば、ターゲットの出力はRGBA32_Floatをレンダリングします。各ピクセルはワールド内のスプライトの位置に対応します。











この場合、シーンに追加したパーティクルエフェクトには、衝突を計算せずにビデオプロセッサでシミュレーションを必要とする2つのエミッタがあるため、対応するレンダリングパスをフレーム作成の初期段階で実行できます。



Zバッファの事前パス



次はPre - Passレンダリングパスです 。これはz-bufferプレビューパスです。 すべての不透明なポリゴンメッシュ（メッシュ）をR24G8デプスバッファーにレンダリングします。











アンリアルでは、深度バッファーにレンダリングするときに、 リバースZバッファー（reverse-Z）が使用されることに注意してください。 これは、ニアプレーンに値1が割り当てられ、ファープレーンに値1が割り当てられることを意味します。これにより、深度範囲に沿った精度が向上し、離れたグリッドのz競合の数が減少します。 レンダーパスの名前は、パスがDBufferバッファーによってトリガーされることを意味します。 これは、Unreal Engineが保留中のデカールをレンダリングするために使用するデカールバッファの名前です。 シーンの深度が必要なので、Zバッファの事前パスがアクティブになります。 ただし、以下で説明するように、Zバッファは他のコンテキストでも使用されます。たとえば、画面空間でのオクルージョンとリフレクションの計算に使用されます。



リスト内の一部のレンダリングパッセージは空です。 たとえば、 ResolveSceneDepthは、ターゲットレンダーをテクスチャとして使用する前に（PCでは必要ありません）、ターゲットレンダーの「深さの解決」を実際に必要とするプラットフォームに必要であると考えています。また、空白のマーカーのように見えるShadowFrustumQueries実際のシャドウオーバーラップテストは次のレンダーパスで実行されるためです。



重複チェック



BeginOcclusionTestsは、フレーム内のすべてのオーバーラップチェックを処理します。 デフォルトでは、Unrealはハードウェアオクルージョンクエリを使用してオーバーラップをチェックします。 つまり、次の3つの段階で実行されます。

1. オーバーラップオブジェクト（たとえば、大きな不透明なメッシュ）として認識されるすべてを深度バッファーにレンダリングします。
2. オーバーラップリクエストを作成して渡し、オーバーラップを定義する小道具をレンダリングします。 これは、zテストとステップ1で作成された深度バッファーを使用して実装されます。クエリは、zテストに合格したピクセル数を返します。つまり、値がゼロの場合、小道具は完全に不透明なグリッドの後ろにあることを意味します。 オーバーラップのために小道具グリッド全体をレンダリングするのはコストがかかる可能性があるため、この小道具のバウンディングボックスを代わりに使用します。 それが見えない場合、小道具も間違いなく見えません。
3. クエリ結果をビデオプロセッサに読み戻し、レンダリングされたピクセルの数に基づいて、レンダリングのために小道具を送信するかどうかを選択できます（たとえ少数のピクセルが表示されていても、小道具をレンダリングする価値がないと判断できます）。

アンリアルは、コンテキストに応じて、さまざまなタイプのオーバーラップリクエストを使用します。











ハードウェアオーバーラップリクエストには欠点があります-ドローコールがわずかです。 これは、オーバーラップを定義するグリッド（またはグリッドグループ）ごとに1つの描画呼び出しを実行するレンダラーが必要であることを意味します。 フレームごとの描画呼び出しの数を大幅に増やし、CPUに読み戻す必要があります。これにより、CPUとビデオプロセッサの間に同期ポイントが追加され、ビデオプロセッサが要求の処理を完了するまでCPUが待機します。 それらはクローン化されたジオメトリにはあまり適していませんが、今のところこれに注意を払いません。



Unrealは、リクエストを使用する他のエンジンと同様に、CPUとビデオプロセッサの同期ポイントの問題を解決します-いくつかのフレームで遅延したリクエストデータを読み取ります。 このアプローチは機能しますが、カメラが高速で移動するときに画面の小道具を「ジャンプ」する問題を追加できます（実際には、境界平行六面体を使用してオーバーラップを切り取るのは控えめであるため、これは深刻な問題ではない可能性があります。実際に表示される前でも表示されます）。 ただし、不必要なレンダリング呼び出しの問題は残り、解決するのはそれほど簡単ではありません。 アンリアルは、クエリを次のようにグループ化することにより、その影響を軽減しようとします。まず、すべての不透明なジオメトリをzバッファにレンダリングします（上記のZバッファの予備パス）。 次に、オーバーラップをチェックする必要のある各プロップに個別のリクエストを渡します。 フレームの最後で、前の（またはさらに早い）フレームから要求データを受信し、小道具の可視性の問題を解決します。 表示されている場合、エンジンは次のフレームでレンダリングするためにマークします。 一方、非表示の場合、エンジンはそれを「グループ化」クエリに追加し、小道具（最大8個のオブジェクト）を境界平行六面体のグループに結合し、それを使用して次のフレームの可視性を決定します。 次のフレームでグループが（全体として）表示されるようになると、エンジンはそれを中断し、個々のリクエストを再度送信します。 カメラとプロップが静止している（またはゆっくりと動いている）場合、このアプローチは必要なオーバーラップリクエストの数を8倍減らします。 重なっている小道具のグループ化（バッチ処理）で気付いた唯一の奇妙な点は、ランダムに見え、小道具同士の空間的な近接性に依存しないことです。



このプロセスは、上記のレンダーパスのリスト内のIndividualQueriesおよびGroupedQueriesトークンと一致します。 前のフレームでエンジンがクエリを作成できなかったため、 GroupedQueriesの一部は空です。



オーバーラップの通過を完了するために、 ShadowFrustumQueriesは、オーバーラップするローカル境界ネットワーク（ポイントまたは方向）のハードウェアリクエストを送信します（キャスティングの名前に反して、影を落としてキャストしません）。 それらが重なっている場合、それらの照明/影の計算を実行することは意味がありません。 （フレームごとにシャドウマップを計算する必要がある）影を落とすシーンに4つのローカル光源が存在するにもかかわらず、 ShadowFrustumQueriesでの描画呼び出しの数は3つです。 これは、ソースの1つの制限ボリュームがカメラのニアプレーンを横切るために発生したのではないかと思われます。そのため、Unrealはそれがまだ見えると信じています。 また、立方体のシャドウマップが計算されるダイナミックライティングの場合、球体を転送してオーバーラップを確認し、











また、Unrealが各オブジェクトの影に対して計算する静的動的ライティング（これについては以下で詳しく説明します）では、ピラミッドが送信されます。











最後に、 PlanarReflectionQueriesは、平面反射を計算するときに実行されるオーバーラップテストを参照すると仮定します （カメラを反射平面の後ろ/前に移動し、グリッドを再描画することによって作成されます）。



Hi-Zバッファー生成



次に、Unrealは16ビット浮動小数点数（R16_Floatテクスチャフォーマット）として保存されたHi-Zバッファー（ HZB SetupMipXXを渡す ）を作成します。 Zバッファーの予備パス中に作成された深度バッファーを入力として受け取り、深度のミップチェーンを作成します（つまり、解像度が徐々に低下します）。 また、便宜上、最初のミップを2のべき乗にリサンプリングするようです：



































前述のように、Unrealは逆Zバッファーを使用するため、ピクセルシェーダーはmin演算子を使用して展開を削減します。



シャドウマップレンダリング



次に、シャドウマップの計算のレンダリングパス（ ShadowDepths ）に従います。











「静止」指向性光源、2つの「可動」点光源、2つの静止点光源、および「静的」点光源をシーンに追加しました。 それらはすべて影を落とします：











静止ソースの場合、レンダラーは静的プロップのシャドウをベイク処理し、動的（移動）プロップのシャドウのみを計算します。 移動するソースの場合、すべておよび各フレームの影を計算します（完全に動的）。 最後に、静的ソースの場合、レンダリング中に表示されないように、ライティングマップのライティング+シャドウをベイク処理します。



指向性光源の場合、3つのスプリットを含むカスケードシャドウマップも追加して、Unrealがそれらを処理する方法を確認しました。 UnrealはシャドウフレームR16_TYPELESS（3つのタイル、各スプリットに1つのタイル）のテクスチャを作成します。これは各フレームでリセットされます（したがって、エンジンは距離に基づくシャドウマップスプリットの引き裂かれた更新を持ちません）。 次に、通過Atlas0の段階で、エンジンはすべての不透明な小道具を対応するシャドウマップタイルにレンダリングします。











上記の呼び出しリストが確認するように、Split0のみがレンダリング用のジオメトリを持っているため、残りのタイルは空です。 シャドウマップは、ピクセルシェーダーを使用せずにレンダリングされます。これにより、シャドウマップの生成速度が2倍になります。 注目に値します：静止光源と移動可能光源の分離は、指向性（指向性）光源では保存されないようです。レンダラーはすべての小道具（静的を含む）をシャドウマップにレンダリングします。



次に、Atlas1パッセージがあります。これは、すべての固定ライトのシャドウマップをレンダリングします。 私のシーンでは、小道具「石」だけが動いている（動的）とマークされています。 固定ソースと動的プロップの場合、Unrealはテクスチャアトラスに保存されているオブジェクトベースのシャドウマップを使用します。 これは、各ソースおよび動的な小道具に対して1つのシャドウマップタイルをレンダリングすることを意味します。











そして最後に、各動的（可動）光源に対して、Unrealは従来の立方体シャドウマップ（ Cubemap XXパス）を作成し、幾何学的シェーダーを使用してレンダリングする立方体の面を選択します（描画呼び出しの回数を減らします）。 その中で、彼は静的/静止プロップのシャドウマップキャッシングを使用して、動的プロップのみをレンダリングします。 CopyCachedShadowMapパッセージは、キャッシュされたキュービックシャドウマップをコピーします。その後、ダイナミックプロップシャドウマップの深さがその上にレンダリングされます。 たとえば、動的光源用のキャッシュされた立方体シャドウマップの面は次のとおりです（CopyCachedShadowMap出力）。











そして、ここで彼女はレンダリングされた動的な小道具「石」と一緒です：











静的ジオメトリのキュービックマップはキャッシュされ、すべてのフレームで作成されるわけではありません。レンダラーは、光源が実際には動いていないことを知っているためです（ただし、Movableとマークされています）。 ソースがアニメーション化されている場合、各フレームレンダラーはすべての静的/静止ジオメトリで「キャッシュされた」キュービックマップをレンダリングし、その後、シャドウマップに動的プロップを追加します（この図は、これを確認するために特別に作成した別のテストからのものです）：











描画呼び出しリストには、静的光源のみがまったく表示されません。 これにより、動的プロップには影響せず、ベイク処理されたライティングマップを介して静的プロップのみに影響することが確認されます。



アドバイスを提供します：シーンに固定光源がある場合は、エディターでプロファイリングを実行する前にすべてのライトをベイクします（少なくとも、ゲームを「スタンドアロン」として起動する理由はわかりません）。 それ以外の場合、Unrealはそれらを動的ソースとして扱い、各オブジェクトに影を使用する代わりに立方体マップを作成するようです。



次に、ライティンググリッドの生成、gバッファの予備通過、ライティングを考慮して、Unrealエンジンでフレームをレンダリングするプロセスの研究を続けます。



照明目的



次に、レンダラーは計算シェーダーに切り替わり、クラスターシェーディングと同様の方法で照明を3Dグリッドにバインドします（ ComputeLightGridパス）。 この照明グリッドを使用して、その位置に応じて表面に影響を与える光源をすばやく特定できます。











通路の名前が示すように、可視照明グリッドの寸法は29x16x32です。 Unrealは、64×64ピクセルのスクリーンスペースタイルと32のZ深度パーツを使用します。 これは、XY照明グリッドの次元数が画面の解像度に依存することを意味します。 さらに、名前から判断して、9つの光源と2つの反射プローブを割り当てます。 反射プローブは、周囲の環境を読み取る位置と半径を持つ「エンティティ」であり、小道具で反射を作成するために使用されます。



ソースコードコンピューティングシェーダー（LightGridInjection.usf）によると、分離は指数関数的に実行されます。つまり、可視空間内の各メッシュセルのzサイズは、カメラからの距離とともに大きくなります。 さらに、座標軸上に配置された各セルの平行六面体を使用して、光源の境界ボリュームの交差を実行します。 光源のインデックスを保存するために、リンクされたリストが使用されます。これは、コンパクトパッセージで連続配列に変換されます。



この照明グリッドは、ボリュームフォグ計算パスで使用され、フォグ、アンビエント反射パス、および半透明レンダリングパスで光散乱を追加します。



別の興味深い事実に気付きました。CullLightsパスは、照明データのUnordered Accessビューをクリアすることから始まりますが、3つのUAVのうち2つだけにClearUnorderedAccessViewUintを使用します。 残りについては、値を手動で設定する計算シェーダーを使用します（上記のリストの最初のDispatch）。 明らかに、1024バイトを超えるバッファの場合、ソースコードはAPIクリーンアップコールを使用する代わりに、コンピュートシェーダーでクリーンアップを使用することを好みます。



体積霧



以下はボリュームフォグの計算であり、計算シェーダーシェーダーを再び使用します。











このパッセージでは、ボリュームテクスチャ内の光の透過性と散乱が計算されて保存されるため、サーフェスの位置のみを使用してフォグを簡単に計算できます。 以前に完成した照明先の通路と同様に、ボリュームは8×8タイルと128の深度グラデーションを使用して、可視性のピラミッドに「適合」します。 深度グラデーションは指数関数的に分布しています。 カメラに近い多数の小さなセルを避けるために、ニアプレーンをわずかに移動します（これは、 Avalanche Studios クラスターシェーディングシステムに似ています ）。



AssassinのCreed IVおよびFrostbiteエンジンのボリュームフォグ（LINK）テクノロジーと同様に、フォグは3つのパスで計算されます。 。 2番目のパス（ LightScattering ）は、各セルの光の散乱と減衰を計算し、影付きの指向性照明、天空照明、およびComputeLightGrid通路の照明のボリュームのテクスチャに割り当てられたローカル光源を組み合わせます。 彼はまた、それ自体が3Dテクスチャである履歴バッファーを使用して、計算シェーダーの出力（ライトスキャッターリング、消滅）にアンチエイリアス（AA）を適用し、グリッドセルの拡散照明の品質を向上させます。 最終パス（ FinalIntegration ）は、Z軸に沿って3Dテクスチャのレイマーチングを実行し、拡散照明と透過性を蓄積して、プロセスの結果を対応するメッシュセルに保存します。



光散乱を伴う完成したボリュームバッファーは次のとおりです。 霧の中に散在する指向性光源と局所光源による光の柱を見ることができます。











Gバッファの事前パス



以下は、遅延レンダリングアーキテクチャで通常使用される、UnrealエンジンのGバッファプリパスの独自バージョンです。 このパッセージは、ライティングとシェーディングのコストのかかる計算中の再描画を減らすために、さまざまなターゲットレンダリングでマテリアルのプロパティをキャッシュするために必要です。











この文章では、すべての不透明な小道具（静的、移動など）が通常レンダリングされます。 Unrealの場合、主に空もレンダリングします！ ほとんどの場合、これは悪い決定です。なぜなら、空は後でカメラに近い他の小道具によって再描画されるからです。つまり、作業は不必要であることがわかります。 ただし、この場合、これは非常に正常です。これは、レンダラーによって以前に実行されたZバッファーの予備パスにより、空の再描画（および少なくとも不透明な小道具の場合は全体の再描画の大部分）がなくなるためです。



以下は、g-bufferが書き込みを事前に渡すターゲットレンダリングのリストです。











デプスバッファはzテストにのみ使用され、zバッファの予備パスで既に満たされているため、レンダラーは何も書き込みません。ただし、レンダラーはステンシルバッファに書き込み、レンダリングされた不透明なジオメトリに属する​​ピクセルをマークします。



g-bufferの内容は、レンダリング設定に依存する場合があります。たとえば、レンダラーがg-bufferに速度を書き込む必要がある場合、GBufferDが必要になり、データが移動します。シーンとレンダリングパスについて、g-bufferには次のスキームがあります。

SceneColorDeferred：間接照明が含まれています	GBufferA：RGB10A2_UNORMとして保存されたワールド空間法線。エンコーディングは使用されていないようです
歪み：さまざまな材料特性（金属性、粗さ、反射強度、シェーディングモデル）	GBufferC：RGBのアルベド、アルファのAO
GBufferE：シェーダーモデルに応じた独自のデータ（例：表面下の色または接線ベクトル）。	GBufferD：ベイクドシェーディングインジケーター
不透明な小道具にタグを付けるためのステンシル

シーン内のすべての不透明な小道具（動く石と空を除く）が、放射照度、影、および表面法線をキャッシュするミップレベルを持つ3つのアトラスから照明情報をサンプリングすることは注目に値します。



























繰り返しになり



ますが、パーティクルシミュレーションは、フレーム内で実行される最初のアクションであり、世界の位置とパーティクルスプライトの速度を記録する通路でした。フレーム内で非常に早い段階で発生するため、レンダラーはビデオプロセッサで衝突を計算するための深度バッファと通常のバッファにアクセスできないため、それを必要とするパーティクルのシミュレーションを返して再実行する必要があります。











レンダリング速度



デフォルトでは、UnrealはR16G16形式の別のバッファーに小道具を移動する速度を書き込みます。将来的には、モーションブラーと、再投影を必要とするすべてのエフェクト（たとえば、一時的なスムージング）に速度が使用されます。このシーンでは、移動オブジェクトとしてマークされているのは石だけなので、スピードバッファにレンダリングされるのはそれだけです。











アンビエントオクルージョン



マテリアルに関するすべての情報を受け取ったレンダラーは、ライティングステージに進む準備をしています。しかし、最初に、彼は最初に画面空間のアンビエントオクルージョンを計算する必要があります。











シーンに遅延デカールはありませんが、ある場合は、空のDeferredDecalsパッセージがg-bufferの一部のマテリアルのプロパティを変更することをお勧めします。画面空間のアンビエントオクルージョンは、解像度の4分の1とフルスクリーンでの2つのパスで計算されます。AmbientOcclusionPS 908×488パスは、AmbientOcclusionSetupパスで作成された1/4解像度の標準バッファー、レンダラーによって以前に作成されたHi-Zバッファー、および深度/標準バッファーがサンプリングされるランダムベクトルテクスチャを使用してAOを計算します。さらに、ランダムベクトルからテクスチャをサンプリングする場合、シェーダーは各フレームに小さな歪みを追加して「スーパーサンプリング」をエミュレートし、AOの品質を徐々に向上させます。











次に、AmbientOcclusionPS 1815×976パスは、AOを使用して全画面、高解像度を計算し、1/4解像度バッファーと組み合わせます。ぼかしパスを使用しなくても、結果は十分良好です。











最後に、フル解像度のAOバッファーがSceneColourDeferredバッファー（前述のGバッファーの一部）に適用されます。これは、これまでのところシーンの間接（周囲）照明を含んでいます。











照明



照明について説明する前に、少し離れて、Unrealが半透明のオブジェクトをどのように照らすかについて簡単に説明する価値があります。半透明の表面を照らすアンリアルのアプローチは、RGBA16_FLOAT形式の64x64x64ボリュームの2つのテクスチャに照明を導入することです。 2つのテクスチャには、各ボリュームセル（TranslucentVolumeXテクスチャ）に到達し、各光源からの光の移動方向に近い球面調和関数（TranslucentVolumeDirXテクスチャ）の形の照明（陰影+弱化）が含まれています。レンダラーは、2組のこのようなテクスチャを保存します。1つは高解像度照明を必要とするカメラに近い小道具用で、もう1つは高解像度照明がそれほど重要ではない遠いオブジェクト用です。同様のアプローチを使用し、つまり、カスケードシャドウマップに記録します。このマップでは、カメラからの距離よりもカメラに近いテクセルが多くなります。



これは、（シェーディングされた）方向性ソースのみを持つカメラの近くの半透明照明のボリュームテクスチャの例です。



















半透明の照明のこれらのボリュームは、不透明なプロップに影響を与えません;それらは、後で半透明のプロップとエフェクト（パーティクルなど）を照らすために使用されます。ただし、それらは照明通路で埋められます。



不透明な小道具の直接照明に戻ると、レンダラーは照明を計算してシーンに適用できるようになりました。多数の光源がある場合、この描画呼び出しのリストは非常に長くなる可能性があります。最も重要な部分のみを展開しました。











光源は2つのグループに処理されNonShadowedLightsとShadowedLights。 NonShadowedLightsグループには、パーティクルエフェクトに使用される光源や、シーン内の非シェーディングの従来の光源など、単純な光源が含まれています。それらの違いは、従来のシーン照明ソースは、レンダリング時に深度境界テストを使用して、おおよその照明量外のピクセルの照明を避けることです。これは、専用のドライバー拡張機能を使用して実装されます。。上記のSceneColourDeferredに照明が蓄積されます。別の違いは、単純な光源が半透明の照明のボリュームにまったく書き込まないことです（ただし、これはレンダラーコードで可能と思われるため、このオプションをどこかでオンにできます）。



興味深いことに、シーン内の非シェーディング（および非静的）可視光源の数が80を超える場合、レンダラーは従来の遅延シェーディングモードからタイル遅延ライティングモードに切り替わります。











この場合、レンダラーはコンピューティングシェーダーを使用してライティングを計算し（このような光源のみ）、定数バッファーを介してライティングデータをシェーダーに渡します（これを指示してくれたwand deに感謝します）。さらに、タイル遅延照明に切り替え、コンピューティングシェーダーを使用して単一パスですべての光源を適用すると、直接照明のみに影響するようです。InjectNonShadowedTranscluscentLightingパスは、すべての光源を半透明の照明のボリュームに個別に追加します（それぞれに対して、個別の描画呼び出しが作成されます）。











ShadowedLightsパッセージは、静止および移動の両方の影を落とすすべての光源を処理します。デフォルトでは、Unrealは3つのステップですべてのシャドウキャスト光源を処理します。











まず、画面空間の影を計算し（ShadowProjectionOnOpaque）、半透明の照明の量に照明の影響を追加し（InjectTranslucentVolume）、最後にシーンの照明を計算します（StandardDeferredLighting）。



前述のように、このシーンでは、指向性照明の場合、Split0のみがシャドウに関する情報を含みます。影の計算結果は、画面のサイズに合わせてRGBA8バッファーに書き込まれます。











次のステップ（InjectTranslucentVolume）は、上記の半透明照明の量の両方の段階の指向性照明の影響を記録します（InjectTranslucentVolumeパスの2つの呼び出し）。最後に、StandardDeferredLightingパスは、スクリーンスペースのシャドウバッファーのマスクによるライティングを計算し、SceneColorDeferredバッファーに書き込みます。



ローカルソースは同じ順序を使用してスクリーンスペースバッファーに影を投影し、半透明の照明の量に照明を追加し、SceneColorDeferredバッファーに書き込まれた照明を計算しているようです。











両方のタイプはほぼ同じ方法で処理されます。移動する/静止したローカルソースの違いは、シフターが半透明の照明の量に影付きの照明を追加することです。もちろん、影の場合、影付きの移動する素材はフィーチャアトラスを使用しませんが、立方体マップ。



すべての光源は、スクリーンスペースのシャドウバッファーの1つのターゲットレンダリングを使用して、各ソースのシャドウに対応する部分をクリアします（これはメモリを節約するために行われると思います）。



ライティングパスが完了すると、SceneColorDeferredにはシーンのすべての累積ダイレクトライティングが含まれます。











レンダラーがグループ化/クラスター化されたデータの構造を事前に作成したという事実（照明割り当てパス）にもかかわらず、不透明なジオメトリの照明照明の段階では使用されず、代わりに各光源の個別のレンダリングを使用する従来の遅延シェーディングを使用することに注意してください。



最後のステップとして、半透明の小道具/効果の照明の歪みを抑えるために、半透明の照明のボリュームがフィルタリングされます（両方の段階で）。











画像空間での照明



次に、画面空間での全画面反射が計算されます（ターゲットレンダリング形式はRGBA16_FLOATです）。











シェーダーは、フレームの先頭で計算されたHi-Zバッファーを使用して、サーフェスの粗さに基づいてレイマーチングするときにHi-Zバッファーのミップレベルを選択することにより、交差の計算を高速化します（つまり、粗いサーフェスのレイトレーシングをより粗くその反射で目に見えない）。最後に、各フレームで、振動がビームの初期位置に追加され、一時的な平滑化と組み合わせて、反射表示の品質が向上します。











シェーダーは前のフレームのターゲットレンダーを使用して、レイマーチング中に衝突が検出されたときに色をサンプリングします。これは、反射のボリュームフォグと反射した透明な小道具（スタチュー）で確認できます。また、椅子の下の右側には、パーティクル効果の痕跡があります。 （正しい衝突を計算するために）透明なサーフェスの正しい深度がないため、反射は通常引き伸ばされますが、多くの場合、効果は非常に説得力があります。



計算シェーダーを使用して、画面の反射がメインターゲットレンダーに適用されます（ReflectionEnvironment pass ）。このシェーダーは、シーン内の2つの反射プローブによってキャプチャされた環境反射も適用します。各プローブの反射は、ミップレベルのキュービックマップに保存されます。











ゲームの開始時にアンビエントリフレクションプローブが生成され、静的/静止ジオメトリのみがキャプチャされます（上記の立方体マップでは、アニメーション化された小道具「石」が欠落していることに注意してください）。



画面スペースに反射が適用されたシーンと環境の反射は、このようになりました。











霧と大気の効果霧と大気の効果



がシーンに含まれている場合、それらは次のとおりです。











最初に、重複する光の柱のマスクが解像度の4分の1で作成されます。これにより、照明ポールが受け取るピクセルが決まります（シーン内の指向性照明にのみ適用されます）。











次に、レンダラーは一時的なスムージングを使用してマスクの品質の改善を開始し、3つのぼかしパスを適用してこのマスクを作成します（マスクはほぼ完全に白だったため、処理する必要がありました）。











このビデオプロセッサのアクションのキャプチャから、ぼかしの前に一時的なAAがマスクに適用される理由は明確ではありません。最終結果の解像度が非常に低いためです。おそらくこれを明確にするために、異なる環境での使用例がさらに必要になります。



フォグとライティングポールをシーンに追加する前に、レンダラーはそれ自体にブレークを与え、メインターゲットレンダーに大気効果（フル解像度）を適用します。











Brunetonの研究と同様に、事前に計算された透過率、照射、および内部散乱を使用した完全な散乱計算のように見えます。











私たちのシーンは部屋の中にあるので、残念ながら、シミュレーションの効果はあまり目立ちません。



最後に、レンダラーはシーン内で指数関数的なフォグと照明ポールを使用します。











シェーダーは、いくつかのnadaパスによって作成されたボリュームフォグボリュームテクスチャを使用し、不透明なジオメトリの位置に基づいてサンプリングします。彼女は、上記で計算した照明柱マスクも適用します。



透明度のレンダリング



不透明な小道具に霧を適用した後、半透明のジオメトリと効果のためにレンダラーが使用されます。











メインのターゲットレンダーの上に通常のアルファブレンディングを使用して、最初にレンダーされる2つのガラス像をシーンに追加しました。











これらの2つの透明な小道具はシーン内の適切な位置にあり、ローカルおよび指向性の光源、周囲の反射、霧などの影響を受けます。 デフォルトでは、レンダラーは高品質シェーダーを使用して透明な小道具をレンダリングします。これは、とりわけ、事前に計算された大気シミュレーションテクスチャ、ベイクされたライトマップからのデータ、半透明の照明のボリューム、指向性およびローカル光源からの照明、ライトプローブの立方体マップをサンプリングします。 これはすべて、照明の計算に使用されます。 ただし、シェーダーがボリュメトリックフォグのボリュームのテクスチャを読み取ることはありませんでした。高さ/距離に基づいてフォグのみを計算しているようです。このパラメーターをどこかで見逃している可能性があります。 大気散乱のような距離依存のフォグは、頂点シェーダーで計算されます。



パーティクルエフェクトレンダラーは、個別のターゲットレンダーに書き込みます（フル解像度）。











透明な小道具と同様に、大気の散乱と霧は頂点シェーダーで計算されます。 さらに、パーティクルシステムの特定の設定により、レンダラーは半透明の照明のボリュームを使用してパーティクルを照らすことができます（ピクセルシェーダーでこれを行う方法の1つを見ました）。



透過処理を完了する前に、レンダラーは屈折を計算するために別のパスを実行します。











透明な小道具と粒子（屈折を提供する必要があります）の両方が再びレンダリングされて、歪みベクトルとともにフル解像度バッファーに書き込まれます。これは後で屈折を計算するために使用されます（ベクトルがより顕著になるように画像を処理しました）。 ステンシルバッファもこのパッセージでアクティブになり、屈折を必要とするピクセルをマークします。











DistortionApplyパス中に、レンダラーはメインターゲットレンダーのコンテンツ（現在のレンダー）と歪みベクトルを読み取り、奇妙な屈折テクスチャを書き込みます。











屈折したピクセルをマークするステンシルバッファがアクティブなので、レンダラーはテクスチャをクリアする必要はありません。



すでに述べたように、屈折の最後のパスは、ステンシルバッファを使用して屈折のテクスチャをメインターゲットレンダーに単純にコピーします。











右側のアームチェアで、まだ適用していないパーティクルによって引き起こされる屈折にすでに気づいているかもしれません。 透明な小道具の場合、屈折は小道具のレンダリング後にレンダリングされます。



次のパッセージ（ BokehDOFRecombine ）は、最終的にシーンにパーティクルを適用します。 これは、パッセージの名前から判断できないほど単純なシェーダーです（おそらく、レンダリング設定に依存します）。











後処理



フレーム処理プロセスの最後の部分には、いくつかの後処理パスが含まれています。これについて簡単に説明します。











シーンを設定するとき、レンダラーは時間的な平滑化、モーションブラー、自動露出、ブルーム、トーンマッピングの計算をメインターゲットレンダーに適用します。



一時的なスムージングUnrealは履歴バッファーを使用してサンプルを徐々に蓄積し、その後2つのパスでレンダリングします。 最初のパスでは、ステンシルバッファーにないピクセル（この場合、これらは一部の粒子です）に、メインターゲットレンダー、履歴バッファー、再投影用の速度バッファーを使用して一時的なAAが適用されます。











次に、ステンシルバッファ内のパーツに対して同様の一時的なAAパスが実行され、スムージングされた完成した画像が作成されます。











一時的なAAのこれら2つのパスの違いは、最初はヒストリバッファーと現在のターゲットレンダー間の混合係数（フィードバック）を使用することです。これは可変であり、ピクセルの照明、ウェイトのレンダラーによって送信される距離などに依存する場合があります。 （パラメータに基づいて）、2番目のパスは0.25の一定の混合係数を使用します。これは、スムージングのある最終ピクセルが主に現在のサンプルで構成されることを意味します。 これは、速度情報のない高速で移動するパーティクルの「ファントム」効果を減らすために行われたと思います。



その後、モーションブラーの作成に続き、レベリングと速度の増加が続きます。











私たちの場合、モーションのブラー効果はあまり目立ちません。なぜなら、カメラは静的で、速度を持つ唯一の動いている小道具は石だからです（そして、動きと一時的なスムージングのためにすでに少しぼやけています）。



自動露出（目の順応）を実装するために、計算シェーダーを使用するレンダラーは、現在のシーンの照明のヒストグラムを作成します。 ヒストグラムは、ピクセルの輝度をグループ化し、各輝度グループに属するピクセルの数を計算します。











このアプローチの利点は、非常に暗いまたは非常に明るい値がある画像の領域を簡単にスキップして、シーンの平均照明のより合理的な近似を作成できることです。 この平均照明を使用して、レンダラーは露出をそれに応じて調整することにより、目の順応を計算できます（明るい画像では露出が低くなり、暗い画像では露出が大きくなります）。



ブルーム効果を実装するには、いくつかの解像度削減パスを使用します。このパスでは、ガウスフィルタリングが使用され、その後、解像度と組み合わせを増加させるいくつかの操作が行われます（露出制御なしで画像がより見やすくなるように画像が変更されます）。











PostProcessCombineLUTsパスでは、ジオメトリシェーダーとかなり長いピクセルシェーダーを使用して、カラースケールルックアップテーブル（ボリュームテクスチャ32x32x32 RGB10A2）を作成します。 ルックアップテーブルは、トーンマッピングの段階で使用されます。











最後のフレームパス（ Tonemapper ）は、以前に計算されたブルームとメインターゲットレンダーを組み合わせ、以前に適応された目の適応を使用して画像の露出を調整し、カラースケールルックアップテーブルを介して色を転送して最終ピクセルカラーを作成します：











まとめると



これはレンダリングの1つの方法にすぎず、多くのパラメーターと設定の影響を受ける可能性があることを強調する必要があります。実際、非常に基本的なことを調べました。



一般に、レンダラーが何をする かではなく、レンダラーが何をするかを見つけたという事実にもかかわらず、これは興味深い活動であることが判明しました。 まだ多くの未調査が残っているので、もう一度このトピックに戻りたいと思います。



Unrealのソースコードは十分に文書化されていませんが、かなり明確でわかりやすいです。 描画呼び出しのリストに従って、それに一致するコードを簡単に見つけることができます。 ただし、多くの場合、ソースコードからシェーダーが何を行うかを理解するのはかなり困難でした。シェーダーでは条件付きコンパイルが積極的に使用されているためです。 パフォーマンスの調査とプロファイリングの利便性のために、処理済みの特別なシェーダー（名前が描画呼び出しのリストに追加される）をコンパイルする準備ができた何らかの中間キャッシュがあると便利です。



デフォルトでは、Unrealレンダラーは高品質の画像の作成に焦点を合わせているようです。 彼はベイキングデータ（環境、照明、ボリュームなど）を積極的に使用し、一時的なスムージングを適用して画質を大幅に向上させます。



シーンに小道具がたくさんあり、それらをブロックする機会があまりない場合（たとえば、多数の大きなオーバーラップオブジェクトがある場合）、オーバーラップを計算するためのパッセージを慎重に検討する必要があります。 さらに、透明な小道具とパーティクルの屈折により、二重レンダリングが発生します。 最後に、多くの固定または移動するローカル光源は、個別にレンダリングされるため、照明ステージに影響します（透明効果とボリューム効果のために照明を追加する際のコストに寄与します）。



結論として、優れたRenderDocツールを提供してくれたBaldurkと、使用、学習、トレーニングのためのUnrealソースコードを公開してくれたEpicに感謝します。