テンポラル スーパー解像度

Unreal Engine で利用できるアンチエイリアス処理オプションの概要について説明します。

テンポラル スーパー解像度 (TSR) は、プラットフォームに依存しない テンポラルのアップスケール処理 です。テンポラル スーパー解像度を使用すると、Unreal Engine で美しい 4K 画像をレンダリングすることができます。高い負荷のかかるレンダリングの演算処理を多数のフレームに分散することで、少ない負荷で画像をレンダリングすることができます。これは、Unreal Engine 4 で実行できるテンポラル アンチエイリアシング アップサンプリング (TAAU) よりも低い内部解像度をレンダリングすることで実現します。

TSR は、次世代ゲームの需要に応える、ネイティブの高品質アップサンプリング手法を提供します。Nanite ジオメトリに必要な忠実度とディテールを実現しながら、Lumen に必要な十分なパフォーマンスを確保するために、はるかに低い解像度でのレンダリング フレームを可能にしました。

次の比較画像は、ネイティブの 4K でレンダリングされたフレームと、1080p の解像度を 4K にアップスケールしたフレームの品質とパフォーマンスの違いを示したものです。TSR により、GPU フレーム時間を半分に削減しながら、ネイティブ 4K 解像度に近い品質の画像を実現しています。

ネイティブ 4K 解像度でレンダリングされた 4K フレーム | フレーム時間:57.50 ミリ秒

1080p 解像度でレンダリングされた 4K フレーム (r.ScreenPercentage=50) | フレーム時間 33.37 ミリ秒

この比較画像では 4K 画像がページ幅に制限されています。圧縮されていない完全な解像度を確認するには、対象を右クリックして、コンピュータに保存し、新しいブラウザ ウィンドウで開いてください。

テンポラル スーパー解像度には次の特性があります。

  • 1080p という低い入力解像度でネイティブ 4K レンダリングの品質に近いフレームをレンダリングできます。

  • 高周波の (詳細な) バックグラウンドに対する「ゴースト」アーティファクトが、Unreal Engine 4 のデフォルトのテンポラル アンチエイリアシング メソッドで表示されていたものよりも削減されます。

  • 複雑度の高いジオメトリでのちらつきが減少しました。

  • 各コンソール プラットフォームでの 動的解像度 スケーリングがサポートされます。

  • D3D11、D3D12、Vulkan、Metal、PlayStation 5、Xbox Series S | X をサポートするあらゆるハードウェアで実行できます。

  • シェーダーは、特に PlayStation 5 と Xbox Series S | X の GPU アーキテクチャに向けて最適化されています。

レンダリング チェーンでは、TSR は被写界深度 (DOF) の後で処理され、その後ではすべてがアップスケールされています。

8-pipeline-tsr.png

TSR のスケーラビリティ

サポート対象プラットフォームでテンポラル スーパー解像度を使用できますが、プロジェクトのニーズに基づいて、各プラットフォームのアップスケール設定をカスタマイズする必要があります。 プロジェクトで TSR を試し、適切にスケーリングする方法の詳細については、次の各セクションを確認してください。

詳細の時間的蓄積の注意点を理解する

低解像度でのレンダリングによって実現する TSR のフレームレートが増加するだけだという欠点と考えるのは、まったく公正ではありません。テンポラル アップスケーラーにも欠点があります。静止画で十分なフレーム時間があれば、どのような、テンポラル アップスケーラーでも同じ結果をレンダリングすることができます。また、他のあらゆるテンポラル アップスケーラーと同様に、TSR は低解像度のフレームを時間をかけて蓄積し、1 つの画像として収束します。また、画像の細部は詳細が十分に蓄積された後に初めて明らかになります。たとえば、ジオメトリの厚みは最初のフレームでは わかりません

r.AntiAliasingMethod 4 | r.Test.SecondaryUpscaleOverride 4 | ScreenPercentage=61

r.AntiAliasingMethod 0 | r.Test.SecondaryUpscaleOverride 4 | ScreenPercentage=61

レンダリング解像度は、スクリーン比率で制御されます。これは、1 フレームで利用可能な情報量を制御します。収束に必要なその他の情報は、レンダリングされるフレームのその他の部分に依存します。つまり、TSR によって表示される情報は、レンダリングされるフレームの解像度だけでなく、フレームレートにも依存しています。これは、詳細が蓄積される速度にフレームレートが影響するためです。

GPU の他にも、TSR に影響するフレームレートを制限する可能性があります。たとえば、リフレッシュ レートが可変ではないモニターでの CPU バウンドや VSync などが挙げられます。

この場合、コンソール コマンド stat tsr が、画像全体に対する TSR の蓄積に影響する可能性のある要素を特定するのに役立ちます。このコマンドを呼び出すと、stat unit を呼び出したときに通常表示される統計情報に加えて、次の 2 つの統計情報が追加されます。TSR feed (TSR フィード)TSR1spp です。

Display stats when calling "stat tsr."

TSR フィード は TSR に供給される 1 秒あたりのピクセル数を示します。これは、TSR がどのくらいのデータ量で全体画像に収束する必要があるかを把握するためのマクロスコピックな重要指標です。TSR フィードは、レンダリング解像度の幅 * レンダリング解像度の高さ * フレームレート = ディスプレイ解像度の幅 * ディスプレイ解像度の高さ * スクリーン比率^2 * フレームレート で求めることができます。この指標のメリットは、ディスプレイの解像度に関係なく、動きのある画像のマクロスコピックな品質を示すことができることです。TSR フィードがどのようにスケールされるかを次に示します。

画面解像度

スクリーン比率

フレームレート

TSR フィード (MP/秒)

4k (3840x2160)

50%

60hz

3840*2160*(50/100)^2*60 = 124.4 MP/秒

4k (3840x2160)

58%

60hz

167.4 MP/秒

4k (3840x2160)

66%

60hz

216.7 MP/秒

4k (3840x2160)

50%

30hz

62.2 MP/秒

4k (3840x2160)

72% = 50% x sqrt(2)

30hz

124.4 MP/秒

1080p (1920x1080)

100%

60hz

124.4 MP/秒

1080p (1920x1080)

72% = sqrt(0.5)

60hz

62.2 MP/秒

1080p (1920x1080)

50%

60hz

31.1 MP/秒

TSR 1spp は TSR の収束率です。これは、TSR が 1 ピクセルあたり 1 サンプルに到達できるデータを確保するのに必要な時間です。TSR 1spp は、詳細をすばやく蓄積する必要のあるオクルージョン解除が有効になっている動きにおいては、特に重要です。これは、TSR 1spp = 1000 / (スクリーン比率^2 * フレームレート) で求めることができます。

スクリーン比率

フレームレート

TSR 収束率

50%

60hz

1000 / ((50/100)^2 * 60) = 66.6 ミリ秒

58%

60hz

49.5 ミリ秒

66%

60hz

38.2 ミリ秒

100%

60hz

16.6 ミリ秒

50%

30hz

133.3 ミリ秒

このデータの使用方法の例を挙げると、スクリーン比率が 50 に設定されている場合、1 ピクセルあたり 1 サンプル以上取得するためには、(50/100)^-2 = 4 フレームが必要になります。各フレームのレンダリングに 16.6 ミリ秒かかる場合、画面上のオクルージョン解除領域が十分なデータを確保するためには、その 4 倍、すなわち、4*16.6 = 66.4 ミリ秒かかります。

TSR のアップスケーリング GPU 負荷

TSR の主な目標は、アップスケールです。GPU 処理の大半は、指定された解像度に基づいてスケールされます。これは、TSR の GPU 負荷の一部が、レンダリング解像度より高いディスプレイ解像度で実行される必要があることに起因します。

tsr-gpucost-1.png

tsr-gpucost-2.png

コンソールに「stat gpu」を入力して、GPU 統計表示を開きます。この統計表示を開いて、プライマリ スクリーン比率を調整し、パフォーマンスの差分を確認できます。古代の谷 サンプル プロジェクトで 100% と 50% のスクリーン比率でレンダリングした例を以下に示します。

~0.79 ミリ秒 (r.ScreenPercentage=100)

~0.43 ミリ秒 (r.ScreenPercentage=50)

クリックしてフルサイズ表示。

クリックしてフルサイズ表示。

TSR の視差ヒューリスティックは、フレームのシーン カラーや透過性ではなく、深度バッファおよびベロシティ バッファに依存します。これは、深度バッファおよびベロシティ バッファが、多くの場合、シーン カラー バッファおよび透過性バッファよりもはるかに早く GPU 上で完了するためです。これにより、TSR 視差ヒューリスティック全体が GPU 上で非同期に計算され、他のレンダリング アルゴリズムで GPU が十分に使用されていないギャップを r.TSR.AsyncCompute=2 で埋めることができます。

PlayStation 5 および Xbox Series X のフォートナイト チャプター 4 では、これにより、バトルロイヤルのパフォーマンス リプレイ全体でパフォーマンスをテストした場合、TSR の GPU の総負荷の約 0.5 ミリ秒が埋め合わされます。リプレイでは、約 0.1 ミリ秒節約されるため、TSR の事実上の負荷は 1.5 ミリ秒になります。また、フレームのレンダリングを完了するためのクリティカル パスである GPU 負荷は 1.1 ミリ秒に短縮されます。

tsr-gpucost-3.png

コンソール変数

[Engine Scalability Settings (エンジンの拡張機能設定)] で、すべてのプラットフォームに対する TSR の品質をスケールします。[Low (低)] から [Cinematic (シネマティック)] の事前定義スケーラビリティ グループを使用します。各グループは、アンチエイリアスを含む各種レンダリング プロパティに影響がある一連のコンソール変数により、定義されます。

[Unreal Engine Root]/Engine/Config」フォルダにある「BaseScalability.ini」ファイルを開くと、スケーラビリティ設定の内容を調べることができます。AntiAliasingQuality セクションを確認すると、使用されているアンチエイリアス品質グループに応じて、TSR がどのようにスケールされるかがわかります。アンチエイリアス品質グループは、「[Your Project Root]\Config\DefaultScalability.ini」の設定を変更することで、自分のプロジェクトに合わせて変更することができます。

プロジェクトに必要な調整の例として、TSR に空間アンチエイリアス アルゴリズムが挙げられます。これは現在のフレームにゴースト エラーが生じる可能性がある、古いデータを回避するために履歴データを除外する必要がある場合は常に使用されます。高解像度または高いフレームレートでレンダリングする必要があるゲーム プロジェクトでは、見えるエイリアシングは除外対象にならないため、このオプションは必要ありません。TSR の履歴データの除外は、r.TSR.RejectionAntiAliasingQuality を使用して制御されます。

テンポラル アップスケーリングの見えない GPU 負荷の増加

テンポラル スーパー解像度と他のテンポラル アップスケールは、レンダラのポストプロセス チェーンの真ん中で処理されます。つまり、モーション ブラーやトーンマッパなどのパスは、TSR の後に実行され、プライマリ スクリーン比率でスケーリングされなくなります。空間アップスケーラー (r.SecondaryScreenPercentage.GameViewport) があるセカンダリ スクリーン比率がない場合、TSR の出力解像度では、レンダリング解像度ではなく、ディスプレイ解像度そのままで実行されます。 TSR がデフォルトで有効になっているため、TSR の後に処理される、パスにおける見えないテンポラル アップスケール負荷の削減に多くの作業を集中させることができます。

モーション ブラー

モーション ブラーの最適化では、低い解像度のテレビでも、常に 2160p バックバッファで表示される、PlayStation 5 と Xbox Series X プラットフォームで、モーション ブラー GPU パフォーマンス負荷が 3 倍改善されています。

  • stat gpu を使用したときに TSR の負荷が増加:

    • モーション ブラーの有効/無効を比較するとき stat gpu を使用すると、TSR の負荷が若干増加することがあります。

    • モーション ブラーが有効であるとき、TSR は、一般に入力解像度で実行される Velocity Flatten (ベロシティ平坦化) パスを引き継ぎます。これは、コンソール コマンド r.MotionBlur.AllowExternalVelocityFlatten を使用してコントロールされ、デフォルトで有効になっています。

    • TSR は半分の解像度でシーン カラーを出力し、大規模な指向性ブラー カーネルが発生することがあるメモリ帯域幅のボトルネックを削減します。これは、コンソール コマンド r.MotionBlur.HalfResInput を使用してコントロールされ、デフォルトで有効になっています。

  • 指向性ブラーでの半分の解像度:

    • ディスプレイ解像度での指向性ブラー処理は、大規模な動きでは解像度が自動で半分になります。この機能を有効にすると、モーション ブラーの VALU 負荷を削減します。

    • コンソール コマンド r.MotionBlur.HalfResGather 1 でこの最適化を有効にします。

  • モーション ブラーの半分および 1/4 の解像度:

    • TSR およびモーション ブラーを半分または 1/4 の解像度で出力できます。これは、すべてのモーション ブラーの後に実行されるガウスおよびコンボリューション ブルーム、レンズフレア、明暗順応 (自動露出)、ローカル露出に対して重要です。

PostProcessQuality スケーラビリティ グループは、「Engine/Config/BaseScalability.ini」のこれらの r.MotionBlur.* の一部をスケールします。

追記

TSR のトラブルシューティング

TSR はテンポラル アップスケーラーであるため、テンポラル アップスケーラーに影響するアーティファクトを診断する必要がある場合があります。出発点として、VisualizeTemporalUpscaler 表示フラグを使用すると、raw 入力および出力バッファを確認することができます。

この表示フラグにアクセスするには、レベル エディタの [Show (表示)] > [Visualize (視覚化)] メニューで テンポラル アップスケーラー (TSR、TAAU、またはサードパーティのプラグイン) を選択します。

vis-temporalupscaler.png

詳細については、「Temporal Upscalers (テンポラル アップスケーラー)」を参照してください。

ピクセルのちらつきを調整する

TSR はテンポラル アップスケーラーであるため、テンポラル アップスケーラーに影響するアーティファクトを診断する必要がある場合があります。出発点として、VisualizeTemporalUpscaler 表示フラグを使用すると、raw 入力および出力バッファを確認することができます。

この表示フラグにアクセスするには、レベル エディタの [Show (表示)] > [Visualize (視覚化)] メニューで テンポラル アップスケーラー (TSR、TAAU、またはサードパーティのプラグイン) を選択します。

tsr-flickering-2.gif

tsr-flickering-1.gif

r.TSR.ShadingRejection.Flickering.Period: 0

r.TSR.ShadingRejection.Flickering.Period: 3 (デフォルト)

スクリーン比率:100

スクリーン比率:100

この TSR の設定は重要です。これは、ピクセルのちらつきを、ピクセル シェーダー アニメーションなどの他の必要な視覚効果と区別する設定であるためです。ただし、重要な違いは、ちらつきはフレームレートに関係なく発生する点です。時間に基づく視覚効果であるため、フレームレートに依存しません。つまり、60hz ではスムーズに見える視覚効果が、24hz などの低いフレームレートでは「ちらついて」見えることがあります。

TSR は GPU パフォーマンスに合わせてスケールするため、アーティストが作成したビジュアルがフレームレートに影響されないことが重要です。このため、プレイヤーのマシンが予想より低いフレームレートで動作している場合、ビジュアルが変わってしまうという意図しない影響が生じることがあります。この問題に対処するため、コンソール コマンド`r.TSR.ShadingRejection.Flickering.Period は、フレームレートが r.TSR.ShadingRejection.Flickering.FrameRateCap で定義されたフレームレート (デフォルトは 60hz) より低い場合に、自動的にちらつきを軽減します。つまり、60hz では安定していたジオメトリの詳細が、より低いフレームレートでは不安定になる可能性があります。この動作はデフォルトで有効になっていますが、r.TSR.ShadingRejection.Flickering.AdjustToFrameRate` でオプト アウトすることができます。

サポートされているプラットフォーム

テンポラル スーパー解像度は、シェーダー モデル 5 をサポートするあらゆるデスクトップ ハードウェアのデスクトップ レンダラで使用できます。テンポラル スーパー解像度は次のプラットフォームでサポートされています。

  • Windows D3D11 SM5、D3D12 SM5、D3D12 SM6 および Vulkan SM5

  • Linux Vulkan SM5

  • Mac Metal SM5

  • PlayStation 5 と Xbox Series S | X

TSR のアップスケール品質と動作はすべての対応プラットフォームでまったく変わりません。ただし、TSR は PlayStation 5 と Xbox Series S | X コンソールで使用される AMD RDNA GPU に対して特に最適化されており、16 ビットの型とパック命令を利用します。

コンソール変数

コンソール変数名

説明

r.TSR.AsyncCompute

非同期コンピューティングで TSR を実行する方法を制御します。一部の TSR パスは以前のパスとオーバーラップしている場合があります。

  • 0 を指定すると、無効になります (デフォルト)。

  • 1 を指定すると、このフレームの任意の中間リソースから完全に独立している非同期計算のみのパス、すなわち ClearPrevTextures と ForwardScatterDepth パス上で実行されます。

  • 2 を指定すると、透過性や被写界深度 (DOF) など、完全に独立しているか、オーバーラップしている可能性のある深度バッファとベロシティ バッファにのみ依存する非同期計算のみのパスで実行されます。クリティカル パス上のパスはすべてグラフィック キューで保持されます。

  • 3 を指定すると、非同期計算ですべてのパスを実行します。

r.TSR.History.R11G11B10

「1」に設定した場合、履歴のビット深度を選択します。この設定では、前のフレームの履歴の再投影とその出力および新しい履歴の書き出しの両方でメモリを節約することで、TSR の UpdateHistory のランタイム パフォーマンスで特に重要なメモリ帯域幅を節約します。r.PostProcessing.PropagateAlpha=1 を使用する場合、この最適化はサポートされません。また、r.TSR.History.ScreenPercentage を 200 に上げると、TSR の履歴の解像度から TSR の出力解像度にダウンスケールするため、TSR 出力のビット深度と比較して、履歴に 2 つの暗黙的なエンコーディング ビットが追加されることにも注意してください。

r.TSR.History.SampleCount

TSR の履歴の各出力ピクセルの最大サンプル数。値が高いほど静止画のハイライトの安定性が向上しますが、ファイアフライなどの VFX の一部のスタイルではゴーストが増えることがあります。TSR.History.Metadata のエンコーディングにより、8 ~ 32 個のサンプルを持つことができます。デフォルトのサンプル数は 16 です。

r.TSR.History.ScreenPercentage

TSR の履歴の解像度の倍率は、出力解像度に基づいています。解像度を上げると TSR のランタイム負荷が増大するものの、再投影の間、履歴に格納された詳細を使用して、より優れたシャープネスと安定性を維持することができます。デフォルトでは、この値は 200 に設定されています。これは、ナイキスト シャノンのサンプリング定理 に基づく特定のプロパティを使用して、履歴に蓄積された詳細のサンプリング レートに対する十分条件を確立するためです。その結果、100 と 200 の間の値のみがサポートされます。この値は、アンチエイリアスのスケーラビリティ グループで制御されます。[Epic] および [Cinematic] の品質レベルでは 200 が使用され、その他では 100 が使用されます。

r.TSR.History.UpdateQuality

TSRHistoryUpdate パスにおける履歴の更新の品質に関するシェーダーの置換を選択します。これは現在、sg.AntiAliasingQuality スケーラビリティ グループによって制御されます。カスタマイズする場合は、各グループの提供内容の詳細について、TSRUpdateHistory.usf の DIM_UPDATE_QUALITY を参照してください。

r.TSR.RejectionAntiAliasingQuality

履歴を除去する必要がある場合に、TSR のビルトインの空間アンチエイリアス技術の品質を制御します。レンダリング解像度がディスプレイ解像度よりはるかに低くない場合は重要ではないものの、この技術は、次の 2 つの理由から、低いレンダリング解像度を隠すために不可欠です。1 つ目の理由は、エイリアシングのスクリーン空間サイズはレンダリング解像度に反比例するためで、2 つ目の理由は、低解像度でレンダリングを行うと、ディスプレイあたり 1 以上のレンダリング ピクセルに達するために多くのフレームが必要になるためです。このオプションは、低スケーラビリティ グループを除くすべてのアンチエイリアス スケーラビリティ グループで、デフォルトで有効になっています。

r.TSR.ShadingRejection.Flickering

TSR の出力が安定しないのは、ほとんどの場合、シェーディング除去の不安定性に起因します。これは、次のようなさまざまな理由で起こる可能性があります。

  • 最も一般的な不安定の原因は、構造化ジオメトリとレンダリング ピクセル グリッドの間のモアレ パターンが、ジッター ピクセル グリッド オフセットにより、フレームごとに変化することです。

  • もう 1 つの原因は、TSR のRejectionHistory パスに適用されている他のメカニズムでは克服できない、時間的履歴のはっきりしない問題によるジオメトリの極端な複雑さにあります。たとえば、フレームで利用可能な詳細の量がまだ履歴にない場合、履歴はどのようにして同一のレンダリングされたフレームを確保することができるのでしょうか?また、履歴がレンダリングされたフレームと大きく異なる場合、履歴はどのようにして詳細を蓄積できるのでしょうか?

このヒューリスティックを有効にすると、TSR.Moire.Luma リソースに格納された透過性描画が連続するフレームで進展する直前のフレームのルミナンスを監視します。常にちらつきが検出され、r.TSR.ShadingRejection.Flickering コンソール変数で定義されたしきい値を定期的に上回る場合、ヒューリスティックはちらつきの振幅に関連付けられているルミナンスの範囲内でゴーストを発生させ、画像を安定させようと試みます。このヒューリスティックの注意事項は、不正なモーション ベクターを含む不透明なジオメトリは、ピクセルがちらつきと同じように見えるため、このヒューリスティックが起動し、影響を受けるジオメトリに望ましくないゴースト エフェクトを発生させる可能性があることです。この場合、VisualizeMotionBlur 表示フラグを使用してモーション ベクターがどのように見えるか、また、VisualizeReprojection 表示フラグを使用してこれらのモーション ベクターが前のフレームをどのように再投影できるかを確認する必要があります。コンソール変数`r.TSR.ShadingRejection.Flickering.Period` を使用して、ピクセルがちらつき、安定化が必要とみなされるフレーム周波数を制御します。たとえば、ちらつき周期を「3」に設定すると、1 フレームあたり 3 以上ルミナンスが変化するピクセルはちらつきとみなされます。

ちらつきとアニメーション ピクセルを区別するうえでのもう 1 つの注意事項は、ちらつきはフレームレートを問わず発生するのに対し、視覚効果は時間に基づいており、フレームレートとは無関係であるということです。つまり、60 fps ではスムーズに見える視覚効果が、24 fps などの低いフレームレートでは「ちらついて」見えることがあります。アーティストが作成した視覚効果でゴーストの発生を避けるため、コンソール変数`r.TSR.ShadingRejection.Flickering.AdjustToFrameRate (デフォルトで有効) では、r.TSR.ShadingRejection.Flickering.FrameRateCap で設定された値より低下する変化を検索します。一方、r.TSR.ShadingRejection.Flickering は、スケーラビリティ設定に基づいて制御され、ローエンドまたはハイエンドの GPU に応じて、このヒューリスティックのオン/オフを切り替えます。また、すべてのプラットフォームで一貫性を保つために、プロジェクトの「DefaultEngine.ini`」でこのコンソール変数を設定することもできます。

このコンソール変数は、[High (高)]、[Epic]、および [Cinematic] レベルのアンチエイリアス スケーラビリティ グループで、デフォルトで有効になっています。

r.TSR.ShadingRejection.Flickering.AdjustToFrameRate

ちらつき周期の設定 (r.TSR.ShadingRejection.Flickering.Period) が、このフレームレートの上限より低い場合に、フレームレートに合わせるかどうか。詳細については、「r.TSR.ShadingRejection.Flickering」を参照してください。

r.TSR.ShadingRejection.Flickering.FrameRateCap

レンダリング フレームレートが低いときに、r.TSR.ShadingRejection.Flickering.Period の自動調整のフレームレートの上限 (hz 単位)。詳細については、「r.TSR.ShadingRejection.Flickering」の項を参照してください。デフォルトでは、これは 60hz に設定されています。

r.TSR.ShadingRejection.Flickering.MaxParallaxVelocity

City サンプル の建物の窓から見えるインテリアなど、視差オクルージョン マッピングを使用する一部のマテリアルでは、多くの場合、この模造されたインテリア ジオメトリのモーション ベクターを正確にレンダリングできません。このため、ちらつきが発生していないにもかかわらず、ヒューリスティックによってちらつきと判断されることがあります。この変数は、ゴーストを発生させないためにヒューリスティックが無効にする必要のあるポイントで r.TSR.ShadingRejection.Flickering.FrameRateCap によって定義されたフレームレートで 1080p ピクセルの視差ベロシティを定義します。

r.TSR.ShadingRejection.Flickering.Period

この周波数以上のルーマ振動をちらつきとみなし、画像を安定させるためにゴーストを発生させる必要があるとみなされるフレーム内のちらつきの周期。詳細については、「r.TSR.ShadingRejection.Flickering」の項を参照してください。デフォルトでは、これは 3 に設定されています。

r.TSR.ShadingRejection.SampleCount

すべてのシェーディングを除去した後の履歴の各出力ピクセルの最大サンプル数。値が低いほど、履歴のシェーディング除去後の画像の鮮明度が高くなりますが、引き換えに、後続のフレームで新たな詳細を蓄積するピクセルの安定性が低下し、ビジュアルが損なわれる可能性があります。デフォルトでは、これは 2.0 に設定されています。

r.TSR.Subpixel.DepthMaxAge

履歴のサブピクセルの深度が自己再投影されるまでの最大時間 (フレーム単位)。デフォルトは 3 フレームです。

r.TSR.Subpixel.IncludeMovingDepth

移動するサブピクセルの詳細の深度に、再投影のためのサブピクセルの深度履歴も含めるかどうか。移動するオブジェクトのベロシティが時折描画されるだけの場合、時間の経過に伴う進展を把握できないため、ほとんどの場合、これは有効にする必要がありません。この設定はデフォルトでは無効です。

r.TSR.Subpixel.Method

Nanite がレンダリングできる詳細の量に関する特別の課題は、メッシュの詳細がレンダリング ピクセルより薄くなる場合があるため、一部のフレームしかレンダリングできないことです。この問題が発生すると、深度バッファとベロシティ バッファのどちらもメッシュの詳細を再投影することはできません。これは、vis SceneDepthZ コマンドで可視化することができます。

この設定は、次のようにサブピクセルの詳細を再投影して破棄する方法を制御します。

  • 0 を指定すると、サブピクセルの詳細が履歴に蓄積されないため、すべてのサブピクセルの機能でゴーストが発生する可能性があります。

  • 1 を指定すると、バックグラウンドの履歴除去により、サブピクセルの詳細が移動時にどれくらいの視差を発生させることができるかを蓄積します。これは、最小限のゴーストが許容されるものの、非常に薄いジオメトリでの画像の安定性は損なわれます。

  • 2 を指定すると、サブピクセルの詳細の最も近い深度を蓄積し、深度バッファとベロシティ バッファに描画されているときでも再投影できるようにします。これは、スタティック ジオメトリでは有効ですが、動くジオメトリではあまり有効ではありません。(これはデフォルトの方法です。)

r.TSR.Velocity.WeightClampingPixelSpeed

寄与するウェイトがクランプされる高周波での出力ピクセルのベロシティを定義します。基本的には、ピクセル ベロシティが r.TSR.Velocity.WeightClampingPixelSpeed より小さくなったときの r.TSR.Velocity.WeightClampingSampleCount のエフェクトを線形補間するための設定です。

r.TSR.Velocity.WeightClampingSampleCount

r.TSR.Velocity.WeightClampingPixelSpeed によって出力ベロシティに到達したときに、履歴をクランプするために、履歴ピクセル内でカウントするサンプル数。値が大きいほど、動きの安定性が向上するものの、各履歴の再投影の連続的な畳み込みにより、さらにブラーが発生します。TSR 履歴のサンプル数は、コンソール コマンド vis TSR.History.Metadata で可視化することができます。なお、これは、出力ピクセルではなく、ピクセル履歴のサンプル数をクランプします。そのため、この値を低くしても、設計上、TSR のスクリーン比率 (r.TSR.History.ScreenPercentage) が高い場合は、それほど顕著な影響はありません。この処理は、この設定に関係なく、追加のランタイム負荷がかかることと引き換えに、詳細の再投影のシャープネスを維持しながら、一方的かつ自動的にこの値を上げることで、より多くの時間的な安定性を確保するために行われます。たとえば、ストーリー主導型のゲームでは、この設定を「4.0」にして「シネマティック」な外観にすることが好まれますが、フォートナイトなどの対戦ゲームでは「2.0」程度に下げる方が好まれる可能性があります。(デフォルトは 4.0f です。)

r.TSR.WaveOps

シェーディング除去ヒューリスティックでウェーブ操作を使用して、畳み込みを高速化するかどうか。シェーディング除去ヒューリスティックの最適化は、シェーダー コンパイラに大きな負荷がかかり、破損や品質低下につながることがあります。

この最適化は、DXC による SPIR-V バックエンドのコンパイル時間に追加され、エディタの起動に時間がかかるため、SPIR-V プラットフォーム (主に Vulkan と Metal) では現在無効になっています。

Unreal Engine のドキュメントを改善するために協力をお願いします!どのような改善を望んでいるかご意見をお聞かせください。
調査に参加する
キャンセル