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

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

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

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

これらはどちらも 4K 画像です。完全に非圧縮の解像度を比較したい場合は、それぞれの画像を右クリックして、コンピュータに保存してください。

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

• 1080p という低い入力解像度でネイティブ 4K レンダリングの品質に近いフレームをレンダリングできます。
• 高周波の (詳細な) バックグラウンドに対する「ゴースト」アーティファクトが、Unreal Engine 4 のデフォルトのアンチエイリアシング手法である、テンポラル アンチエイリアシングで表示されていたものよりも削減されます。
• Nanite を使用してレンダリングされたジオメトリなど、複雑度の高いジオメトリでのちらつきが減少しました。
• 各コンソール プラットフォームでの動的解像度スケーリングがサポートされます。
• D3D11、D3D12、Vulkan、Metal、PlayStation 5、Xbox Series S | X をサポートするあらゆるハードウェアで実行できます。シェーダーは、特に PlayStation 5 と Xbox Series S | X の GPU アーキテクチャに向けて最適化されています。

レンダリング チェーンでは、テンポラル スーパー解像度 (TSR) は被写界深度 (DOF) の後で処理され、その後に続く、モーション ブラー、ブルームなどすべてがアップスケーリングされます。

対応プラットフォーム

TSR は、シェーダー モデル 5 以降をサポートするあらゆるデスクトップ ハードウェアのデスクトップ レンダラで使用できます。このようなデスクトップ レンダラは次のプラットフォームでサポートされています。

• Windows D3D11 SM5、D3D12 SM5 および SM6、D3D12 SM6、Vulkan SM5 および SM6
• Linux Vulkan SM5 および SM6
• Mac Metal SM5 および SM6
• PlayStation 5 と Xbox Series S | X

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

TSR のスケーラビリティ

TSR にはアップスケーリング設定のカスタマイズ オプションが多く含まれているため、プロジェクトのニーズに基づいて各プラットフォームに合わせることができます。次のセクションでは、プロジェクトで TSR を試し、適切にスケーリングする方法の詳細について説明します。

詳細の時間的蓄積の注意点について

通常、すべてのテンポラル アップスケーラーは、その機能の本質的な部分で妥協しており、TSR も例外ではありません。ただし、TSR がより低い解像度でレンダリングすることでフレームレートを向上させることだけを広く周知しても、この技術の動作と制限事項を完全に説明することにはなりません。テンポラル アップスケーリング技術の制限の 1 つは、画像を収束させるために時間をかけて低い解像度のフレームを蓄積させることにより、一部の詳細 (最初のフレームのジオメトリの一部の厚みなど) が、十分な詳細が蓄積された後にしか把握できないという点です。

たとえば、TSR が有効な場合と無効な場合の以下の比較では、フレームが時間をかけて蓄積されたときに、近距離と遠距離のシーンでどれだけの詳細が保持されるかがわかります。

これらの例では、スクリーン比率 61 を使用し、TSR が有効なスクリーンショットではセカンダリ アップスケール (r.Test.SecondaryUpscaleOverride) を 4 に設定しています。

フレームのレンダリング解像度は、スクリーン比率 で制御されます。これは、各フレームで使用可能な情報の量を制御します。収束に必要なその他の情報は、レンダリングされるフレームのその他の部分に依存します。TSR は、レンダリングされるフレームの解像度と、フレームレートの両方に依存しています。これらは、どちらも詳細が蓄積される速度に影響するためです。この動作による主な影響は、フレームが CPU によってバインドされている場合や非可変リフレッシュ レート モニターで VSync が使用されている場合など、フレームレートを制限する GPU 以外からも TSR が影響を受ける可能性があるということです。

エディタでの作業中に、TSR フレームレートの統計情報を使用することで、画像全体に対する TSR の蓄積に影響する可能性のある要素を特定することができます。[Viewport Options (ビューポート オプション)] メニューの [Stat (統計データ)] > [Engine] で、[TSR] の横にあるチェックボックスを設定できます。

または、コンソール コマンド stat tsr を使用して TSR 統計のオン/オフを切り替えることもできます。

TSR stats は、フレーム情報を表示する stat unit などの他の stat コマンドと同様の情報を表示します。ただし、TSR stats では、TSR feed および TSR 1spp の 2 つの追加の統計情報を表示します。

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

TSR フィードがどのようにスケールされるかを次に示します。

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

次の表に、TSR 1spp の収束率を示します。

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

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

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

TSR フレームレート統計情報を使用すると、エディタでの作業中に TSR の画像全体への蓄積に影響を与える可能性のあるものを特定することができます。これを行うには、[Viewport Options] メニューの [Stat] > [Advanced (詳細)] で [GPU] の横にあるボックスをオンにします。

GPU 統計が表示されている状態で、[Viewport Options] メニューの [Screen Percentage (スクリーン比率)] をオーバーライドすると、スクリーン比率 100 % でレンダリングした場合と 50 % でレンダリングした場合のパフォーマンスの違いを確認できます。これにより、アップスケーリングされたディスプレイ解像度が、プロジェクトのパフォーマンスにどのような影響を与えるかを把握することができます。以下に、古代の谷 サンプル プロジェクトを使用してこれを比較した例を示します。

画像をクリックすると、拡大表示されます。

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

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

アンチエイリアスのスケーラビリティ グループ

TSR の GPU 負荷は、スクリーン比率でレンダリングされる画面解像度に応じて変化します。TSR は、SM5 以降に対応するすべての GPU で動作します。ただし、高性能ではない古い GPU の場合、TSR では、GPU ランタイム負荷が合理的である必要があります。これは、TSR が他のサードパーティ製テンポラル アップスケーリング ソリューションと一線を画す方法の 1 つです。つまり、TSR は、アップスケーリング、アンチエイリアス品質、およびランタイム GPU 負荷を、画面のレンダリング解像度とは無関係に制御するための、ユーザー向けのスケーラビリティ コントロールを提供します。[Engine Scalability Settings (エンジンの拡張機能設定)] は、これらのスケーラビリティ オプションのベースラインを提供します。

以下のグラフは、画面のレンダリング解像度とアンチエイリアス品質が、TSR が実行するアップスケーリングのタイプを決定する方法を示しています。スクリーン比率が低いほど、極端なアップスケーリングが必要になりますが、最終的にはコスト効率が高くなります。一方、[High (高)] 以上のスケーラビリティ レベルで 100% を上回るスクリーン比率はスーパーサンプリングが行われ、そこから GPU の負荷が増大します。

スクリーン比率が 50% 未満の極端なアップスケーリングは、4K を超えるディスプレイ解像度をターゲットとする場合か、コンソール プラットフォームでダイナミック解像度を使用する例外的な場合に限り検討してください。

TSR は、[Settings (設定)] > [Engine Scalability Settings] の [Scalability Groups (スケーラビリティ グループ)] ロールアウトにある [Anti-Aliasing (TSR) (アンチエイリアス (TSR))] スケーラビリティ グループで制御されます。

Play-In-Editor (プレイインエディタ) (PIE) を使用している場合、[Engine Scalability Settings] では、[Play-In-Editor 3D Resolution (Play-In-Editor 3D 解像度)] の下に、画面解像度、スクリーン比率、使用中のアクティブなビューポートなどに関する情報が表示されます。PIE 内では、スライダーやパフォーマンス、バランス、品質、ネイティブ解像度に基づいて自動的に調整する下のボタンを使用してスクリーン比率を調整できます。

エディタ ビューポートでは、[Viewport Options] メニューにある [Screen Percentage] 設定で制御された独自のレンダリング解像度を使用することができます。独自のスクリーン比率を設定するには、[Custom Override (カスタム仕様のオーバーライド)] チェックボックスをオンにします。

また、コンソールを使用して、sg.AntiAliasingQuality でアンチエイリアスのスケーラビリティ グループを設定できます。ここで、0 = Low (低)、1 = Medium (中)、2 = High (高)、3 = Epic、4 = Cinematic (シネマティック) 品質です。

「[Unreal Engine Root]/Engine/Config」フォルダにあるコンフィギュレーション ファイル「BaseScalability.ini」には、すべてのスケーラビリティ グループ設定のリストが含まれています。AntiAliasingQuality セクションを確認すると、使用されているアンチエイリアス品質グループに応じて、TSR がどのようにスケールされるかがわかります。各グループには、コンソール変数と値のリストが含まれています。

プロジェクトには、「[Your Project Root]/Config」フォルダに「DefaultScalability.ini」というプロジェクトのコンフィギュレーション ファイルがあります。これらのコンソール変数は、独自のプロジェクトのニーズに合うように変更することができます。 以下は、「BaseScalability.ini」ファイルの High アンチエイリアス品質の値の例です。

[AntiAliasingQuality@3]
r.FXAA.Quality=4
r.TemporalAA.Quality=2
r.TSR.History.R11G11B10=1
r.TSR.History.ScreenPercentage=200
r.TSR.History.UpdateQuality=3
r.TSR.ShadingRejection.Flickering=1
r.TSR.RejectionAntiAliasingQuality=2
r.TSR.Resurrection=1
Copy full snippet

[AntiAliasingQuality@3] r.FXAA.Quality=4 r.TemporalAA.Quality=2 r.TSR.History.R11G11B10=1 r.TSR.History.ScreenPercentage=200 r.TSR.History.UpdateQuality=3 r.TSR.ShadingRejection.Flickering=1 r.TSR.RejectionAntiAliasingQuality=2 r.TSR.Resurrection=1

Unreal Engine の GPU プロファイラ、DumpGPU、またはサードパーティのデバッガなどの GPU デバッガを使用して、TSR のアンチエイリアスのグループを調べることができます。選択された AntiAlaisingQuality グループには、[Scene] > [PostProcessing] > [TemporalSuperResolution] にあるドロー イベントのレンダリング解像度およびディスプレイ解像度が含まれています。

画像をクリックすると、拡大表示されます。

VisualizeTemporalUpscaler 表示フラグを使用している場合、ビューポートの [Show (表示)] > [Visualize (視覚化)] メニューで、左下のビジュアライゼーションに入力と出力、および現在使用されている AntiAliasingQuality グループが表示されます。

必要に応じて、独自のアンチエイリアス スケーラビリティ グループを追加し、それらを別の設定として公開することができます。TSR の設定を他のアンチエイリアス オプションと区別する 1 つの方法は、使用されている手法を示す括弧を追加することです。

独自のプロジェクトでは、これをさらに区別する必要がある場合があります。たとえば、フォートナイトでは、複数のアンチエイリアス手法がサポートされています。その TSR 設定には、[Low]、[Medium]、[High]、[Epic] の画質設定に応じて、それぞれ選択できます。ユーザー インターフェースに公開されるその他のパラメータもあります。

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

TSR は、他のテンポラル アップスケーラーとともに、レンダラのポストプロセス チェーンの真ん中で処理されます。つまり、モーション ブラーやトーンマッパーなどのパスは、TSR の後に実行されるため、プライマリ スクリーン比率でスケーリングされなくなります。空間アップスケーラー (r.SecondaryScreenPercentage.GameViewport) で指定したセカンダリ スクリーン比率がない場合、TSR の出力解像度では、スクリーン比率で設定されたレンダリング解像度ではなく、ディスプレイ解像度で実行されます。

このことにより、そして TSR がデフォルトで有効になっていることにより、TSR の後に処理されるパスにおける見えないテンポラル アップスケーリングの負荷の削減に多くの作業を集中させることができます。

TSR でモーション ブラーを最適化する

モーション ブラーの最適化を組み合わせることで、PlayStation 5 と Xbox Series X で、モーション ブラーの GPU パフォーマンスの負荷が 3 倍向上します。PlayStation 5 と Xbox Series X は、低い解像度のテレビでも、常に 2160p バックバッファで表示されるプラットフォームです。このことを踏まえると、以下を想定することができます。

• 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 の解像度で出力できます。これは、すべてのモーション ブラー パスの後に実行されるガウス被写界深度およびコンボリューション ブルーム、レンズフレア、明暗順応 (自動露出)、ローカル露出で重要です。

ポストプロセス品質 スケーラビリティ グループは、上記のモーション ブラーの値の一部を変更します。これらの値がどのように設定されているかは、「[Your Engine Root]/Engine/Config」フォルダにある「BaseScalability.ini」コンフィギュレーション ファイルで確認できます。

テンポラル スーパー解像度のデバッグ ツール

TSR の主な利点は、純粋に画像処理技術であるということです。つまり、すべての入力と出力が目に見える画像であり、ビルトインのビジュアライザー DumpGPU ビューア、または RenderDoc や PIX など、より一般的に知られているプラットフォーム GPU デバッグ ツールを使用することで、明確に確認することができます。

テンポラル アップスケーラーの入力および出力を視覚化する

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

この表示フラグを有効にするには、ビューポートの [Show] > [Visualize] で [Temporal Upscaler I/O (TSR, TAAU, or third party plugins) (テンポラル アップスケーラー I/O (TSR、TAAU、またはサードパーティ プラグイン))] を選択します。

アンチエイリアス (TSR) グループ品質を [High] に設定したテンポラル アップスケーラー ビジュアライゼーション モード

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

TSR を視覚化する

テンポラル スーパー解像度 (TSR) のビジュアライゼーションは、特定の問題を診断する際に最も役立つ TSR の概要を表示します。また、このビジュアライゼーション モードは、TSR の内部の処理と、画像を安定させるために TSR が実行する作業について詳しく理解するための適切なベースとなります。

この表示フラグには、ビューポートの [Show] > [Visualize] メニューの [Temporal Super Resolution (テンポラル スーパー解像度 (TSR))] を選択することでアクセスできます。

アンチエイリアス (TSR) グループ品質を [High] に設定した TSR ビジュアライゼーション モード

ビジュアライゼーションの色は次のとおりです。

• ピンク は、何らかの要素が無効になっていることを意味します。
• 黄/赤 は、何らかの要素が画質にとって有害であることを意味します。
• 緑 は、何らかの要素が画質にとって有益であることを意味します。

テンポラル スーパー解像度 (TSR) 表示フラグは、さまざまなビジュアライゼーション オプションの概要を示します。コンソール コマンド r.TSR.Visualize を使用すると、以下のいずれかの値を入力することで、これらのビューのいずれかを選択できます。

• -2 は、ビューポートの [Show] メニューでの表示フラグの設定に関係なく、VisualizeTSR ビジュアライゼーションの概要グリッドを表示します。
• -1 は、ビューポートの [Show] メニューでの表示フラグの設定に基づいて、VisualizeTSR の概要グリッドを表示します。
• 0 は履歴に蓄積されたサンプル数を表示します。
• 1 は、深度バッファとベロシティ バッファに基づく視差オクルージョン解除を表示します。
• 2 は、履歴が拒否されるマスクを表示します。
• 3 は履歴がクランプされるマスクを表示します。
• 4 は履歴が復活されるマスクを表示します。
• 5 は復活済みフレームで履歴が復活されるマスクを示します。
• 6 は空間アンチエイリアシングが計算されるマスクを表示します。
• 7 は、ちらつき時間分析ヒューリスティックが有効になっているマスクを表示します。

DumpGPU ビューア

DumpGPU は、プラットフォームに依存しないビルトインの中間 GPU リソース ビューアです。DumpGPU は、TSR がほとんど画像処理であるため、多数のフレームにわたる TSR のアーティファクトの診断に適しています。最小限の設定をすれば、コンソール (`) で DumpGPU を直接使用して、TSR の中間レンダー ターゲットを調査することができます。このためには、以下のコマンドを使用できます。

必要に応じて、これらのコマンドをプロジェクトの「ConsoleVariables.ini」ファイルにコピーできます。

r.DumpGPU.Root="*TemporalSuperResolution*"
r.DumpGPU.FrameCount=30
r.DumpGPU.Stream=1

; Fixes the engine tick rate at a desired frame rate if the dumping process ends up slowing down the frame rate, like t.MaxFPS
r.DumpGPU.FixedTickRate=30
r.DumpGPU.Delay=3
r.DumpGPU.CameraCut=1	
Copy full snippet

r.DumpGPU.Root="*TemporalSuperResolution*" r.DumpGPU.FrameCount=30 r.DumpGPU.Stream=1 ; Fixes the engine tick rate at a desired frame rate if the dumping process ends up slowing down the frame rate, like t.MaxFPS r.DumpGPU.FixedTickRate=30 r.DumpGPU.Delay=3 r.DumpGPU.CameraCut=1

TSR の中間レンダー ターゲットを調査することで、フレームを前方向または後方向に進めることで、キャプチャされたフレーム上でアーティファクトがどのように変化するかを確認できます。

コンソールに r.ResetRenderTargetsExtent と入力することで、ダンプ GPU ストリーミングを高速化して、レンダラの内部レンダー ターゲットをレンダリング解像度に合わせることができます。これは、スクリーン比率でレンダリング解像度を変更する場合に役立ちます。また、[Dynamic Resolution (動的解像度)] が有効になっている場合、レンダリング解像度を r.DynamicRes.TestScreenPercentage でロックできますが、内部レンダー ターゲットのサイズは引き続き r.DynamicRes.MaxScreenPercentage で制御されることに注意してください。

バグ レポートを提出したり、TSR の問題に関するサポートを Epic に依頼したりする場合、ファイルをアップロードするためのダンプ ディレクトリを圧縮するには、7-zip (*.7z) 圧縮ファイルが最適です。

TSR のコンポーネント

TSR は、現世代のコンソールで可能な限り最高の画質を得るために、特定の問題を解決するために設計された多くのさまざまなアルゴリズムで構成されています。

TSR は次のアルゴリズムを使用します。

• 履歴 は、フレーム間で詳細を蓄積、保存、再利用するために機能します。
• 視差ヒューリスティック は、オクルージョン解除時の画質を維持しながら、モーション ベクターを使用して履歴を再投影します。
• シェーディング除去 は、色の変化や透過処理を検出します。また、Nanite がフレームに含める詳細の量のバランスを特定します。
• ちらつき時間解析 は、一部のジオメトリ上のモアレ パターンなどのアーティファクトを低減し、フレームを安定させます。
• 履歴の復活 は、現在のフレームに再び表示されたときに、過去のフレームから格納されたデータを呼び出します。

以下の図に、これらのアルゴリズムが TSR のフレーム出力にどのように反映されるかを示します。

以下のセクションでは、これらの個々のアルゴリズムと、それらがテンポラル アップスケーラーおよびテンポラル スーパー解像度 (TSR) ビジュアライゼーション モードでどのように機能するかを確認します。

TSR 履歴

これはすべての TSR アンチエイリアス スケーラビリティで必須ですが、r.TSR.History.* コンソール コマンドでカスタマイズ可能です。

TSR は時間をかけて詳細を蓄積します。レンダリングされた詳細を時間をかけて集約した統合が、ディスプレイ解像度で履歴内で実行されます。また、TSR は TSR の内部アルゴリズムに固有の履歴に隠された追加のデータも含みます。

レンダリングされたフレームで時間をかけて収集された詳細は、TSR 履歴を構成するために蓄積されます。

TSR ビジュアライゼーション モードを使用している場合、履歴に蓄積されている詳細の量は、左上の [Accumulated Sample Count (累積サンプル数)] 入力に表示されます。画像が緑っぽいほど、より多くの詳細が蓄積されています。赤で表示されている領域は十分なピクセルが蓄積されていないのに対し、緑で表示されている領域は履歴あたりのサンプル数が最大に達しています。履歴あたりのサンプル数は、r.TSR.History.SampleCount でニーズに合わせて調整できます。

[Accumulated Sample Count] 入力を全画面で表示するには、コンソール コマンド `r.TSR.Visualize 0” を使用します。TSR のビジュアライゼーション オプションの詳細については、このページの「TSR を視覚化する」セクションを参照してください。

履歴更新 は、履歴がディスプレイ解像度でレンダリングされるため、TSR の GPU の総負荷に関して最も負荷の高いパスです。

TSR の履歴更新には、コンソール コマンド r.TSR.UpdateHistory で選択可能な次の順列が含まれています。0 は画質が低、1 は中、2 は高、3 は Epic です。これらの画質レベルは、アンチエイリアス (TSR) スケーラビリティ グループの品質設定によって制御されます。各画質レベルの詳細については、「[Unreal Engine Root]/Engine/Shaders/Private」にある「TSRUpdateHistory.usf」ファイルの DIM_UPDATE_QUALITY を参照してください。このファイルで、プロジェクトのニーズに合わせて確認およびカスタマイズを行います。

アンチエイリアスのスケーラビリティ品質を [High] に設定した TSR UpdateHistory を GPUDump ビューアで表示した例。

r.TSR.History.ScreenPercentage=100 の場合、履歴の再投影のブラーに対処するには、r.TSR.Velocity.WeightClampingSampleCount を使用して詳細の蓄積を再度加速させる必要があります。たとえば、フォートナイトのような競合性の高いゲームでは、プロジェクトの「DefaultEngine.ini」コンフィギュレーション ファイルで r.TSR.Velocity.WeightClampingSampleCount を 4.0 (デフォルト) から 2.0 に下げることで、動きのある画像の安定性よりもシャープネスを優先させることができます。

TSR ナイキスト-シャノン履歴

これは、[Epic]、および [Cinematic] レベルの TSR アンチエイリアス スケーラビリティで、デフォルトで有効になっています。これは、コンソール変数 r.TSR.History.ScreenPercentage でコントロールできます。

TSR は、ジオメトリおよびテクスチャの詳細がすぐに使用できる画像にすでに集約されている前のフレームの履歴を再投影します。これは、市場にある他のテンポラル アップスケーラーと同じで、理論上は適切に機能します。

これが実際に動きのある映像に適用されると、現在のフレームと前のフレームのピクセルが一致することはほとんどありません。代わりに、TSR や他のテンポラル アップスケーラーは、前のフレームのピクセルを補間しなければならず、これによりブラーが発生します。TSR は、このカーネルでいくつかのシャープネス処理を行うことで、ピクセルの過剰なブラーを軽減しようと試みますが、フレーム内で半分のピクセルしか移動しない 1 ピクセルの厚さの詳細を変換する問題を解決することはできません。この制限により、ブラーによって詳細がさらに失われ、後でこれらの詳細を回復することができなくなります。

履歴の再投影の結果、テンポラル アップスケーラーは、フレーム内で動きが発生しているときに 1080p で表示すると、540p の解像度であるように見えることがあります。これは、フレーム内で動いている要素がぼやける (ブラーが生じる) という悪評がさらに悪化するだけです。この問題に対処するため、Epic および Cinematic アンチエイリアス スケーラビリティ グループでは、TSR の履歴スクリーン比率 (r.TSR.History.ScreenPercentage) を 200 に設定し、TSR の履歴をディスプレイ解像度の 2 倍で格納します。

このアプローチには、履歴の再投影時に発生するブラーを排除できるメリットがあります。再投影は、ミッチェル-ネトラバリ ダウンサンプル カーネル を介した ナイキスト-シャノン サンプリング定理 を活用します。

履歴再投影時のブラーは、テンポラル アップスケーラーが対処に苦慮していることが知られている問題です。この問題に対処するために、デフォルトの履歴スクリーン比率を上げると、履歴更新の GPU 負荷が 4 倍になり、TSR の GPU 負荷が大幅に増大します。このアプローチは、負荷が生じるため、常識に反しているように思えるかもしれませんが、この場合の考え方は、解像度軸に沿ってモニターのディスプレイ解像度の 2 倍の情報を提供するということです。スーパーサンプリングされた履歴の更新がダウンサンプリングされると、履歴に高いスクリーン比率を使用していない場合よりも、はるかに多くの詳細が保持されます。

200% の履歴のスクリーン比率と、TSR の GPU 総負荷への影響を示すグラフ。

プロジェクトのフレーム バジェットが高すぎるという懸念がある場合、Epic アンチエイリアスのスケーラビリティは GPU 負荷が高くなるため、High (またはそれ以下) のエンジン スケーラビリティ グループを使用することができます。

ナイキスト-シャノンの履歴セットアップは、テンポラル アンチエイリアシング (TAA) を備えた Unreal Engine 4.22 を使用した 2019年の Goodbye Kansas と Deep Forest Films の「Troll」デモ まで遡り、Epic 独自のデモで使用されてきました。これは、テンポラル アップスケーラーを使用するプロジェクトで実証済みの方法です。

視差オクルージョン解除

これはすべての TSR アンチエイリアス スケーラビリティ グループで必須です。

TSR は、視差オクルージョン解除 ヒューリスティックを備えており、カメラに近いフレームの領域の後ろからフレームの領域が見えるようになることで発生するアーティファクトを減らすうえで役立ちます。たとえば、以下のシーンでは、カメラがパンすると、奥にあるビルが手前のビルの後ろから見えてきます。このようなオクルージョン解除により、奥にあるビルが画像を安定させるためにフレームから詳細を蓄積する必要があるため、アーティファクトが生じる可能性があります。

スケーラビリティが Epic (r.AntiAliasingMethod=4、sg.AntiAliasingQuality=3) およびスクリーン比率が 50% に設定されている TSR 。

このヒューリスティックは、テンポラル アップスケーラー ビジュアライゼーション モードで表示可能な現在のフレームの深度バッファおよびベロシティ バッファのみに基づいています。視差オクルージョン解除マスクはこのバッファから生成され、テンポラル スーパー解像度 (TSR) ビジュアライゼーション モードで表示できます。

オクルージョン解除マスクを生成するために TSR のビジュアライゼーション モードで使用される、テンポラル アップスケーラー ビジュアライゼーション モードの深度とベロシティの入力。

シーン内のジオメトリを処理する各コード パスによって一部のオブジェクトのモーション ベクターが計算および描画されることがあり、このことによって、これらのオブジェクトに影響する問題が発生する可能性があることが判明する場合があります。その場合、正しく動作していないジオメトリによって描画されたモーション ベクターを確認する最初のコンポーネントは、TSR の視差ヒューリスティックと生成されたオクルージョン解除マスクです。

このような問題を調査するには、次の TSR ビジュアライゼーションを使用します。これらは、ビューポートの [Show] > [Visualize] メニューでオンに切り替えることができます。

• モーション ブラー (Show VisualizeMotionBlur) は、カメラが動いているときに、モーション ベクターを画面上で矢印として表示します。
  • 矢印がオブジェクトとして正しい方向に向いているかどうかを確認します。
  • 問題のオブジェクトが黄色であることを確認します。これは、モーション ベクターを描画していることを示しています。
• 前のフレームの再投影 (Show VisualizeReprojection) は、現在のフレームと再投影された前のフレームとの差を表示します。
  • 正しく再投影されていないオブジェクトのモーション ベクターは色付きで表示され、その詳細は正しく整列されません。
• テンポラル アップスケーラー I/O (Show VisualizeTemporalUpscaler) は、TSR の入出力の概要を表示します。
• テンポラル スーパー解像度視差オクルージョン解除 (Show VisualizeTSR) は、ベロシティを描画するオブジェクトの背後にある必要のあるオクルージョン解除ビネットを表示します。

アニメーションのワールド位置オフセット

アニメートされるパラメータを持つマテリアルは、頂点アニメーション でワールド位置オフセット (WPO) を使用するマテリアルなど、レンダラの TSR やその他の時間的蓄積で問題を引き起こします。このようなタイプのマテリアルでは、適切なモーション ベクターを取得するために、WPO が現在のフレームと前のフレームを評価する必要があります。WPO ロジックの前フレームの評価には現在のフレームの値しか含まれていないため、前フレームの結果は不正確になります。ベロシティを描画するマテリアルの場合、前のフレームの値を指定することが重要です。

Previous Frame Switch マテリアル ノードは、TSR とモーション ブラーで動作する補正モーション ベクターを生成する方法を提供することで、この問題を解決します。このノードは頂点アニメーションにモーション ブラーを正しく追加し、その過程で TSR がオブジェクトを正しく再投影できるようにします。時間の関数のみであるマテリアルはすでに変更することなく動作しますが、ランタイム時にアニメーションに影響を与える可能性のあるマテリアル パラメータなどの他の変数を考慮することはできません。Previous Frame Switch ノードは、これらのパラメータがマテリアルでどのように変化するかを追跡することで、このタイプの問題を解決します。

考慮すべき追加事項：

• プロジェクト設定の [Output velocities due to vertex deformation (頂点の歪みによる出力速度)] により、WPO を使用するマテリアルは、現在のフレームと前のフレームの二重評価を使用することができます。これにより、アクタが移動していない場合でも、ベロシティ パス中に速度を出力します。この設定はデフォルトでオンになっています。
• プロジェクト設定で [Velocity Pass] が [Write after base pass] に設定されている場合、ドロー コールが追加されるため、パフォーマンス上の負荷が生じる可能性があります。樹木が生い茂る森など、多くのオブジェクトが WPO を使用している場合、パフォーマンス上の負荷が増大します。

この式の設定と使用方法の詳細については、「Utility マテリアル表現式」の「Previous Frame Switch」セクションを参照してください。

シェーディング除去

これはすべての TSR アンチエイリアス スケーラビリティ グループで必須ですが、r.TSR.ShadingRejection.* コンソール変数でカスタマイズ可能です。

TSR の シェーディング除去 ヒューリスティックは、現在のフレームが前のフレームとどの程度一致しているかを特定し、前のフレームを再利用するか、まったく再利用しないかを決定する処理です。

シェーディング除去の入力は、テンポラル アップスケーラー ビジュアライゼーション モードで表示可能で、[Scene Color (シーン カラー)]、[AfterDOF Translucency Color (AfterDOF 透過処理カラー)]、および [Color A (カラー A)] です。出力、つまりフレームのどの程度を除去する必要があるかは、テンポラル スーパー解像度 ビジュアライゼーション モードで [History Rejection (履歴除去)] および [History Clamp (履歴クランプ)] を使用して表示されます。

ディスプレイ解像度 (またはナイキスト-シャノン履歴を使用する場合はさらに高解像度) で実行される履歴の更新は、原理的には単純になり、時間の経過に伴う詳細の統合のみを実行します。また、高速で実行されるため、便利でもあります。

(w:800)

TSR と透過処理

これはすべての TSR アンチエイリアス スケーラビリティ グループで必須です。

透過処理は TSR 特有の問題として扱うことができます。なぜなら任意の数のレイヤーをブレンドして重ねることができるからです。デフォルトでは、半透明マテリアルはベロシティ (速度) を描画しないか、描画しても最大 1 つです。これは、TSR がマテリアルの動きを正確に把握していないため、エッジが必要なだけシャープに見えないことにつながります。

透過処理パス

半透明マテリアルは、被写界深度前、被写界深度後 (デフォルト)、モーション ブラー後など、異なる透過処理パスでレンダリングします。透過処理を使用するサーフェスでよくある問題は、複数の透過オブジェクトが互いに重なっている場合に発生します。これは、深度バッファが、どの透過オブジェクトが他の透過オブジェクトの前に表示される必要があるかを特定できないという、透過処理のソートの問題につながります。

マテリアルの設定では透過処理パスが実行される場所を指定できます。[Translucency (透過処理)] カテゴリの [Translucency pass (透過処理パス)] ドロップダウンを使用して、この半透明マテリアルが発生する場所を選択します。デフォルトでは、半透明マテリアルは [After DOF (DOF 後)] でレンダリングするように設定されています。

TSR では、透過処理を不透明ジオメトリとは異なる方法で処理する必要があります。これは、透過処理がブレンドされる性質を備えているためであり、また、ベロシティを描画することがないためです。TSR のシェーディング除去ヒューリスティックでは、被写界深度後に行われる透過処理を使用します。なぜなら、透過処理はシーンの他のジオメトリとは別に描画されるからです。

以下の図は、レンダリング パイプラインのどこでこれらそれぞれの透過処理パスが実行されるかを示しています。

DumpGPU の出力を開くと、透過処理パスが [Scene (シーン)] > [Translucency] にあります。

画像をクリックすると、拡大表示されます。

DumpGPU コマンドがすべてのフレーム情報をディスクにダンプするのに時間がかかる場合、テンポラル アップスケーラー ビジュアライゼーション モードは AfterDOF ビューを提供します。これは、透過処理が正しい位置に描画されているかどうかの正当性を確認する便利な方法です。

画像をクリックすると、拡大表示されます。

TSR のシェーディング除去ヒューリスティックは、Nanite が提供する詳細の量を維持するために、除去判定を行うための畳み込みの手書きのネットワークを使用して構築されており、これらの畳み込みの大部分は画像の安定性に特化されています。ただし、不正確なモーション ベクターを含むその後の畳み込みでゴーストが発生し、その結果、ゴースト アーティファクトが生成されることがあります。透過処理は多くの場合モーション ベクターを含まないため、被写界深度 (DOF) 後に実行される半透明マテリアルのシェーディング除去は、別のパスで描画され、専用のブラーの畳み込みが追加されます。ゴーストを削減するために、この畳み込みにより、透過処理されたオブジェクトの画像の安定性が若干損なわれます。

以下の図に、Nanite が提供するすべての詳細で画像を安定させるために、TSR の履歴の中でこれらの畳み込みが行われる場所を示します。

透過処理では、望ましいエフェクトを得るために手動での調整が必要になることがあります。たとえば、マテリアルの透過処理パスをショットごとに手動で調整する必要があることは珍しいことではありません。[Auto Before DOF (自動 DOF 前)] (r.Translucency.AutoBeforeDOF) 機能では、被写界深度前パスで焦点距離の後ろに透過処理エフェクトを自動的に描画するため、ショットごとに手動での調整を行う手間を省くことができます。この機能は、デフォルトで有効になっています。

マテリアルの透過処理パスは、意図が明確な場合に限り、調整することを強くお勧めします。この設定を変更すると、半透明マテリアルの外観に影響するだけでなく、予期しないパフォーマンス上の負荷が生じることがあります。デフォルトの AfterDOF を使用することをお勧めします。

値を調整する必要がある場合、コンソール変数は 0 から 1 の間の浮動小数値を取ります。各値は次のとおりです。

• 0.0 は焦点距離を 1 倍に設定します
• 0.5 は焦点距離を 2 倍に設定します
• 1.0 は焦点距離を 100 倍に設定します

マテリアルで透過処理ベロシティを出力する

TSR にはオプティカル フローがないため、透過オブジェクトを動かすとエッジがよりシャープになり、ゴーストの問題ではまったくない場合でも、見苦しく見えることがあります。透過処理を使用するマテリアルには、ベロシティ パスで深度バッファにモーション ベクターを書き込むために、ベロシティを出力するオプションがあります。これは、この設定が有効になっているオブジェクトで、シーン内の透過処理の詳細がどの程度シャープに動いているかを TSR が特定するうえで役立つ出発点です。

[Details] パネルの [Translucency] カテゴリにある [Output Depth and Velocity (奥行きと速度を出力)] ボックスをオンにすることで、マテリアルでのモーション ベクターの出力を有効にすることができます。

以下のシーンの例では、太陽のスプライトに半透明マテリアルの深度とベロシティを出力すると、深度とベロシティを出力しない場合に比べて、目と口の詳細が明確になることがわかります。

テンポラル アップスケーラー ビジュアライゼーション モードを使用すると、vis SceneDepthZ、show VisualizeMotionBlur、show VisualizeReprojection の各ビューで、この設定を検査することができます。

テンポラル アップスケーラー ビジュアライゼーション モードでは、これら 3 つの入力で半透明マテリアルが、有効な [Output Depth and Velocity] 設定からどのように情報を受け取り、最終的な結果を得るかを確認することができます。

透過処理は、ある程度のオパシティでシーン カラーにブレンドされますが、深度バッファとベロシティ バッファは、カラーのようにブレンドすることはできません。深度バッファとベロシティ バッファは、完全に上書きされるか、上書きされないかのどちらかのみです。[Opacity Mask Clip Value (オパシティ マスク クリップ値)] マテリアル設定は、レンダラのマテリアル オパシティを比較するために使用されます。

これは、[Details] パネルの [Material (マテリアル)] > [Advanced (詳細)] カテゴリの [Opacity Mask Clip Value] で設定できます。

デフォルトのオパシティ マスク クリップ値 (0.333) は、半透明マテリアルを使用する視覚効果 (VFX) には必ずしも適していません。深度とベロシティを上書きすると、透明なオブジェクトの後ろに不透明なジオメトリを再投影する場合に悪影響を及ぼすことがあります。このような場合、より高いオパシティ マスク クリップ値を使用して、VFX の最も不透明な領域のみにベロシティを描画すると、透過オブジェクトの背後にある不透明なジオメトリの再投影エラーがはるかに目立たなくなります。

以下の例では、Opacity Mask Clip Value により、[Output Depth and Velocity] 設定が有効か無効な場合の詳細のシャープネスや滑らかさに違いが出ます。

ポストプロセス マテリアルの TSR

TSR と他のアンチエイリアシング技術との間での同一の動作。

ポストプロセス マテリアル によって提供される柔軟性には、独自の条件付き制限があります。これは、TSR はポストプロセス チェーンの途中で発生するためです。マテリアルは、被写界深度 (DOF) の透過処理時および処理後に、シーン カラーのさまざまな位置に挿入されます。

マテリアルは、ポストプロセス マテリアルを含むさまざまな場所でシーン カラーに挿入できます。[Blendable Location (ブレンド可能な位置)] マテリアル設定を使用して、シーン カラーを変更するポストプロセス マテリアルの位置を指定できます。

以下の表は、どの位置で、いつ実行され、どの解像度で実行されるかの概要を把握するうえで役立ちます。以下の表では、例として、[Scene Color Before DOF]、[Scene Color After DOF]、[Translucency After DOF] を使用しています。

テンポラル アップスケーラー ビジュアライゼーション モードは、これらのビューと、それらがパイプラインのどこに該当するかをより適切に理解するのに役立ちます。具体的には、vis SceneColor、vis Translucency.AfterDOF.Color、vis Translucency.AfterDOF.Color A、および vis TSR.Output です。

コマンド DumpGPU を使用すると、GPU のログ ダンプを出力できます。DumpGPU ビューアでログを開くと、マテリアル名を検索してポストプロセス マテリアルの入力と出力がどのようになっているかを確認できます。より制約の多い、より高速なダンプ ログが必要な場合は、r.DumpGPU.Root *PostProcessing* を使用して、ポストプロセス部分のみをダンプするようにログを制限することができます。

画像をクリックすると、拡大表示されます。

空間アンチエイリアス処理

これは、[Medium]、[High]、[Epic]、および [Cinematic] レベルの TSR アンチエイリアスのスケーラビリティ グループで、デフォルトで有効になっています。コンソール コマンド r.TSR.RejectionAntiAliasingQuality を使用して、品質をコントロールできます。

カメラ カットがあった場合や、新しいオブジェクトが画面上に表示されたり、変更されたりする場合など、TSR で処理できるデータが 1 フレーム分のデータしかない場合があります。このため、TSR には空間アンチエイリアス処理のアルゴリズムが組み込まれており、画像の中で最もアンチエイリアスを必要とする領域に対して、より優れたアンチエイリアスを自動的に提供します。

以下の例では、空間アンチエイリアス処理が、フレームの中央付近の岩の端の周囲など、画像の最も必要な領域の品質を向上させるうえでどのように役立つかがわかります。

以下のコマンドを使用して、自分のプロジェクトでこれを自分でテストできます。

r.Test.CameraCut 1
r.Test.SecondaryUpscaleOverride 8
Copy full snippet

r.Test.CameraCut 1 r.Test.SecondaryUpscaleOverride 8

一度設定すれば、コンソール コマンド r.TSR.RejectionAntiAliasingQuality を使用して空間アンチエイリアス処理の品質をテストできます。値を 0 または 1 に設定すると、オフとオンが切り替わります。

テンポラル スーパー解像度 (TSR) ビジュアライゼーション モードには、左下に 空間アンチエイリアシング ビューがあります。コンソール コマンド r.TSR.Visualize 6 を入力することで、全画面で表示することができます。

近傍のエイリアシング検出を担うアルゴリズムは高速近似アンチエイリアシング (FXAA) スタイルのアルゴリズムで、フレームを水平または垂直方向に探索します。このアルゴリズムは、現在フレーム内にある要素の品質を向上させることはできますが、フレームにない情報を作成することはできません。このアルゴリズムの唯一の目的は、履歴収束率に基づいて詳細が蓄積され続ける短時間の間に、十分な詳細が蓄積されていないフレームの領域を低い負荷で隠すことです。

これについては、このページの「詳細の時間的蓄積の注意点について」セクションを参照してください。

TSR のちらつき時間解析

これは、[High]、[Epic]、および [Cinematic] レベルの TSR アンチエイリアスのスケーラビリティ グループで、デフォルトで有効になっています。コンソール コマンド r.TSR.ShadingRejection.Flickering を使用して、品質をコントロールできます。

優れた画質を提供するうえでの重要な要素は、時間をかけて安定性を維持することです。Nanite が生成する詳細の量は、時間的な統合において課題となる可能性があります。

このセクションでは、処理するフレーム内に大量の詳細がある場合に、TSR で画像の安定性を維持しようとする際に発生することがある一般的な問題について見ていきます。これらのセクションでは、TSR で発生する可能性のあるちらつきを分析する方法、それが発生する理由、これらの問題を緩和するために独自のプロジェクトで試すことができる対策について説明します。

モアレ パターン

モアレ パターン は、線が重なったり、画面上で小さい (通常は遠景にある) ために望ましくないパターンが生じたりするなど、詳細の繰り返しでよく発生するアーティファクトです。ゲームでは、この問題は、多くの場合、メッシュに直接詳細を追加するのではなく、テクスチャを使用してジオメトリに詳細を追加することで解決できます。これは、テクスチャが遠景では低解像度のミップマップを使用して、望ましくないアーティファクトを軽減するからです。

Nanite を使用して作成される詳細の量は、特にオブジェクトがグレージング アングルで見ると、まったく不安定な画像になる可能性があります。Epic の GDC 向けのデモ Matrix Awakens で作成された City サンプル プロジェクトがその例として挙げられます。このような環境では、詳細の量が多く、カメラのビューがグレージング アングルになり、オクルージョン解除が発生しやすいため、多くの課題がありました。

左のキャプチャは、画面上に占めるピクセル数がきわめて少ないジオメトリの詳細が多い場合に発生する可能性がある、モアレ パターン タイプのアーティファクトを示しています。TSR でちらつきシェーディング除去を使用すると、このタイプのアーティファクトは、ほぼ解決とまでではないものの、軽減することができます。最初の画像は、このタイプのアーティファクトの最悪のシナリオです。

以下の 2 つのキャプチャを比較すると、TSR のちらつきシェーディング除去が無効になっている場合に、グレージング アングルでどのくらいアーティファクトが発生する可能性があるかと、ちらつきシェーディング除去が有効になっており、ちらつき周期を若干長くした場合に、どのくらいアーティファクトが軽減されるかを確認できます。最初のキャプチャでは、ちらつきシェーディング除去が無効になっていますが、これはこのタイプのアーティファクトの最悪のシナリオです。

これらの各キャプチャは、アンチエイリアスのスケーラビリティ グループ Epic を使用し、フレームレートは 60 Hz です。また、右のキャプチャでは、コンソール コマンド r.TSR.ShadingRejection.Flickering.Period を使用して、デフォルトのちらつき除去期間を 2 (デフォルト) から 3 に増やしています。

このタイプのアーティファクトで発生する主要な問題は、詳細が失われるということです。これは、以下のスクリーンショットのように、アンチエイリアスが無効になっている場合でも発生する可能性があります。

アンチエイリアスを無効にした結果、遠景の建物の側面の詳細が失われた City サンプルのシーン。

このように詳細が失われる理由は、Nanite が特定のフレームで維持する詳細の量にあります。このことは、このシーンでは窓の周りのジオメトリに特に当てはまります。建物の柱の構造によって、ピクセル数が少なくカメラからより遠いジオメトリの詳細が失われるからです。

以下の図は、建物のジオメトリを上面、正面、グレージング アングルの視点で簡略化したものです。上面の視点では、各窓の間に柱があるのがわかります。正面の視点では、これらの窓と柱の間の間隔と、柱が地面から建物の上面まで垂直に配置されている様子がわかります。グレージング アングルの視点では、これらの垂直の柱が遠くから見ると、どのくらい圧縮されて見えるかがわかります。

この建物の詳細の多くと同様に、画像を構成するピクセルはグリッドで構成されており、時間の経過とともに詳細が統合されると、このグリッドはフレームごとに変化します。

その結果、フレームでは数フレームごとに建物の詳細が 1 ピクセルよりも小さくなる場合があります。TSR はこのことを考慮して設計されているため、すべてのフレームに Nanite を使用したサブピクセルの詳細が含まれているわけではありません。つまり、画像のどの部分をあるフレームから次のフレームまで安定させる必要があるかを認識することができます。この場合、建物の柱の部分はフレーム間で動いていてはならず、安定している必要があります。

以下の図は、最初のフレーム (赤) と次のフレーム (褐色) の間でピクセルがどのくらい一致しているかを示しており、安定していると認識されたジオメトリは次のフレームに引き継がれます。

グレージング アングルでは、より小さな構造物の詳細の一部が、他の部分に比べて顕著に目立つようになります。構造物の詳細のアライメントは、現在レンダリングされているピクセルと最終的に一致する可能性があります。つまり、各窓の間の柱ではなく、窓と壁のみが検出されます。

以下の図は、フレーム N (赤) のピクセルとフレーム N+1 (褐色) のピクセルが、グリッドの配置により各フレームで異なる要素が表示され、このようなずれが発生する可能性があることを示しています。

これがフレームで発生するモアレ パターンの原因であり、TSR で解決するのが特に困難な問題です。TSR ではピクセルに同じジオメトリが含まれているかどうか、またはシェーディングの変化が発生しているかどうかを把握する手段を備えていないためです。これに加えて、何が変更されたかを把握するためにジオメトリに依存することだけでなく、フレームのレンダリング解像度も問題になります。

たとえば、レンダリング解像度を下げ、レンダリングされるすべてのピクセルのサンプリング位置の間隔を広げると、建物のジオメトリの詳細がより多様になります。これが、建物の窓、壁、柱になる可能性があります。つまり、TSR がこれがシェーディングの変更ではなく、建物の同じジオメトリであると認識するための、より多くの情報となります。

以下の図では、フレーム N (赤) からフレーム N+1 (褐色) までのピクセル間の区別がより適切に実行されるようになり、これらのピクセルを含む垂直方向に整列したジオメトリでの画像の安定性を維持するうえで役立ちます。

この建物におけるこの特定のエイリアスの問題は、シーンのジオメトリと各フレームでレンダリングされるピクセルで発生する可能性のある一般的なサンプリング問題の一例です。TSR は、レンダリングされるピクセルが時間の経過とともにシーン内の特定のジオメトリに属するかどうか、およびレンダリングされたピクセルをサンプリングする必要があるかどうかを判断します。

画像の安定性は多面的な問題であり、TSR はフレーム内で安定させる必要のある要素を特定する役割を担っています。モアレ パターンを発生させる要因は複数あるため、何を安定させるべきかは TSR の制御に任せることがより適切です。レンダリングされたピクセル グリッドとジオメトリの間にモアレ パターンがない画面の部分でも不安定になることがあります。この例は最悪のシナリオであり、TSR がシェーディングの変化を検出し、緊密に結合された時間的安定性を維持する技術ソリューションとなっている理由です。

時間的履歴の因果関係のジレンマ

TSR で不安定性を引き起こすサンプリングの問題は、モアレ パターンだけではありません。レンダリングされたピクセル グリッドによってサンプリングされる Nanite の詳細が極端に多いという問題もあります。突き詰めていくと、レンダリングされたフレームにある詳細の量が履歴にない場合は、履歴がレンダリングされたフレームと同一になるわけがなく、履歴がレンダリングされたフレームと違い過ぎると、履歴がそのような詳細を蓄積できるはずがないというように堂々巡りになります。

このシェーディング除去の問題を解決しようとすると、画面上で視覚効果が動いているときや、環境でライティングの変化が起きているときなど、同じような状況で不当に多くのゴーストが発生することになります。TSR は、画像を安定させ、この堂々巡りを断ち切るためのさらなる取り組みによって、経時的にこの問題を解決します。

ちらつき輝度測定

モアレ パターンと時間履歴の因果関係のジレンマの両方は、Nanite が画面上で処理できる詳細の量に起因しています。TSR のアンチゴースト メカニズムを妨げる可能性のあるあらゆるタイプのレンダリング アルゴリズムの問題を軽減するために、TSR は、フレーム内の不透明なジオメトリのスナップショットを取得することのみを目的として不透明なライティングの後に追加のパスを挿入します。このパスは TSR.Flickering.Luminance という名称で、その入力はテンポラル アップスケーラー ビジュアライゼーション モードで確認できます。

また、DumpGPU ビューアでも見ることができます。「TSR」を検索し、TSR MeasureFlickeringLuma を選択すると、その出力を調べることができます。

TSR MeasureFlickeringLuma パスは、主にシーン カラーをロー ダイナミック レンジ (LDR) 輝度に変換します。これは最後のライティング パスで実行することもできますが、Unreal Engine がレンダラでサポートするコード パスが大量にあるため、ここでは最後のライティング パスで実行しません。代わりに、スタンドアローン パスとして保持します。

このパスは、ゲームのシッピングの準備をするときに、どのコード パスが使用されているかを確認し、使用されていないコード パスを無効にして最適化する方法として使用できます。たとえば、動的ライティングのみを使用している場合は、ベイクされた静的ライティングを無効にできます。

このスナップショットは、フォグ、雲、単一レイヤー ウォーター、プリディストーションの透過処理、歪み (ディストーション) など、シーン カラー内の他のエフェクトをちらつきとみなすべきか、みなすべきでないかを TSR が把握するうえで役立ちます。これは、シーン カラーと TSR ちらつき輝度スナップショットを比較することで可能になります。

フレームの中央右付近の建物を見ると、ちらつき輝度のビジュアライゼーションでフレーム間でモアレ パターンが変化しているのがわかります。

ちらつき時間解析

TSR は、不透明にライティングされたジオメトリがあるフレームから次のフレームまでにどの程度ちらついているかを把握しているため、ちらつき間の時間が r.TSR.ShadingRejection.Flickering.Period で指定された時間より短くなったときに、時間の経過とともに追跡することができます。このコンソール変数は、ちらつき期間をフレーム単位で測定し、シェーディング除去ヒューリスティックを緩和することで画像を安定させようと試みます。

テンポラル スーパー解像度 ビジュアライゼーション モードを使用すると、シェーディング ヒューリスティックによってちらつきがどれくらい緩和されるかを直接確認できます。

これらすべての入力により、アンチフリッカー (ちらつき防止) ヒューリスティックは、フレーム中央付近の建物の柱や窓のちらつきなどの、画像のちらつきを示す部分に素早く焦点を合わせることができます。出力は、ちらつきが発生している問題の箇所を赤で強調表示します。

CitySample, 5.4、r.TSR.ShadingRejection.Flickering.Period=3、r.TSR.Visualize=7

パフォーマンス上の理由から、ちらつきの時間的解析はピクセルの輝度のみを監視します。これにより、各カラー チャンネルを監視する場合と比較して、負荷を 3 分の 1 に抑えることができます。つまり、このヒューリスティックでは、輝度ではあまりちらつきが発生しないものの、フレームの色要素ではちらつきが発生する可能性があることを意味します。

フレームレートの影響

ちらつきは、時間に基づく視覚効果など、フレームレートに関係なく発生する場合があり、フレームレートに依存しません。つまり、60 Hz ではスムーズに見える視覚効果が、24 Hz くらいの低いフレームレートでは「ちらついて」見えることがあります。このため、TSR は厳密にはフレームレートではなく GPU パフォーマンスに合わせてスケールするため、アーティストが作成したビジュアルがフレームレートに影響されない必要があることが重要です。このため、デバイスまたはプラットフォームが予想より低いフレームレートで動作している場合、ビジュアルが変わってしまうという意図しない結果になることがあります。

この問題に対処するため、コンソール コマンド r.TSR.ShadingRejection.Flickering.Period を使用して、フレームレートが r.TSR.ShadingRejection.Flickering.FrameRateCap で指定されたフレームレート (デフォルトは 60 Hz) より低い場合に、自動的にちらつきを軽減することができます。つまり、60 Hz では安定していたジオメトリの詳細が、より低いフレームレートでは不安定になる可能性があります。この例は、以下のキャプチャで確認できます。

以下のグラフは、フレームレートの上限を 60Hz に設定し、ちらつきとみなされるフレームの期間を 2 フレームに設定したものです。60Hz 以下では、フレームレートが下がるにつれてちらつきが発生しやすくなります。60Hz 以上であれば安定しているとみなされます。

以下のキャプチャは、フレームレートが 30Hz で、前のキャプチャと同じ設定を使用しています。ただし、今回はちらつきのフレームレートの上限 (r.TSR.ShadingRejection.Flickering.FrameRateCap) を 30Hz ではなく 60Hz に設定し、画像を安定させています。

プロジェクトでアンチフリッカーを細かく調整するには以下の手順を実行します。

1. r.TSR.ShadingRejection.Flickering.FrameRateCap を 30Hz や 60Hz などのプロジェクトのターゲット フレームレートに設定します。
2. t.MaxFPS で、エディタのリフレッシュ レート (つまり、FPS) をこの同じフレームレート値 (30 または 60 など) に固定します。
3. r.TSR.ShadingRejection.Flickering.Period で、ちらつき周期を希望の外観にあわせてカスタマイズします。

エディタでこれらの設定を固定したら、「[Your Project's Root]/Config」フォルダ内の「DefaultEngine.ini」ファイルにコピーして、エディタと対象プラットフォーム間で一貫した動作を実現することができます。

このアンチフリッカー動作はデフォルトで有効になっていますが、r.TSR.ShadingRejection.Flickering.AdjustToFrameRate を 0 に設定することで無効にすることができます。ただし、視覚効果を考慮して、無効にしないことを強くお勧めします。

動きや解像度に変化があるアンチエイリアス

このページの モアレ パターン のセクションで前述したように、ピクセル グリッドと Nanite ジオメトリの間で発生するモアレ パターンは、レンダリング解像度に基づいて移動します。また、モアレ パターンは、オブジェクトがカメラに対してフレーム内のどの位置にあるかにも依存します。

たとえば、以下のシーンで、スクリーン比率が 60% から 90% に変更されたときに、建物のちらつきの位置がどのように変化するかを確認してください。また、このシーンでは他に何も動いていないことにも注目してください。

スクリーン比率と、ピクセル グリッドがジオメトリを基準としてシーン内のどこにあるかを把握することは、既存のアンチフリッカー ヒューリスティックの制約事項であるため、重要な注意点です。既存のハードウェアでは、この問題を克服するのに十分役立つ効果的なソリューションはありません。そのため、モアレ パターンが移動すると (それがカメラの移動によるものであれ、レンダリング解像度の変更によるものであれ)、TSR は数フレームにわたって新しい領域のちらつきを検出し、それが本当に安定化を試みる必要のあるちらつきであることを確認します。

以下のキャプチャでは、カメラが引くときに、建物のモアレ パターンが TSR のアンチフリッカー ヒューリスティックの対象となって画像が安定化するまでに数フレームかかっていることに注目してください。また、上の 2 つの例のように、建物の上のモアレ パターンの場所がどのように変わっているかを確認してください。

(r.AntiAliasingMethod=4、sg.AntiAliasingQuality=3、r.TSR.ShadingRejection.Flickering=1、r.TSR.ShadingRejection.Flickering.FrameRateCap=30、r.TSR.ShadingRejection.Flickering.Period=3)

TSR のちらつき時間解析は、動くオブジェクトや、視差の変化が十分に大きいピクセルに対して、ピクセル単位で無効になります。これにより、反射、視差オクルージョン マッピング、視差のある建物の内部など、モーション ベクターを含まない他のコンテンツの問題が軽減されます。

テンポラル スーパー解像度のビジュアライゼーション モードを使用で、[TSR Flickering Analysis] 入力を調べると、移動中に無効になっている画面の部分を確認できます。無効になっているピクセルはフレーム内でピンクで色付けされます。コンソール コマンド r.TSR.Visualize 7 を使用すると、この入力を全画面で表示することができます。

ピクセル アニメーションを含むマテリアル

テクスチャ パニングなどの一部のピクセル シェーダー アニメーションを実行する不透明なマテリアルは、ちらつき周期のしきい値を超えると、TSR でゴーストを引き起こす可能性があるため問題が発生することがあります。これは、移動するピクセル アニメーションにはモーション ベクターがなく、ちらつき時間分析により、不透明ピクセルの色が頻繁に変化していることがわかるからです。

たとえば、以下のキャラクターには、連続的にアニメートされる不透明なマテリアルがあります。テンポラル アップスケーラー ビジュアライゼーション モードの [TSR Flickering Luminance (TSR ちらつき輝度)] 入力は、ちらつき時間分析に変化するマテリアルを反映しません。

これらのピクセルは時間の経過とともに頻繁に変化するため、「ちらつき」として検出され、TSR が画像を安定させようとするため、不要なゴーストが発生します。これは、テンポラル スーパー解像度 (TSR) ビジュアライゼーション モードの [Flickering Temporal Analysis (ちらつき時間分析)] 入力を確認してもわかります。

TSR のちらつき時間分析によるゴーストを防ぐには、問題となる不透明マテリアルを、モーション ベクターで表現されていないピクセル アニメーションを含むマテリアルとしてマークします。マテリアルの [Details] パネルでマテリアルの [Has Pixel Animation] 設定を有効にします。この同じ設定は、[Material Property Overrides (マテリアル プロパティのオーバーライド)] のマテリアル インスタンスでオーバーライドすることもできます。

この設定は、TSR が入力として使用するベロシティ バッファ内のマテリアルを使用するすべてのプリミティブをエンコードします。テンポラル アップスケーラーでは、マテリアルはそのマスクを UMaterial bHasPixelAnimation 入力で表示します。このマスクは、テンポラル スーパー解像度のビジュアライゼーション モードの Flickering Temporal Analysis 入力の一部として使用され、これらのピクセルを無視します。

履歴復活

これは、[Medium]、[High]、[Epic]、および [Cinematic] レベルの TSR アンチエイリアスのスケーラビリティ グループで、デフォルトで有効になっています。r.TSR.Resurrection.* コンソール変数を使用して、品質をコントロールできます。

TSR の履歴復活とは、直前のフレームを使用するか、あるいはさらに前のフレームで現フレームの詳細により厳密に一致するものを履歴から「復活」させるかを決定する処理を指します。この処理は、画像を安定させ、アーティファクトのノイズやゴーストの発生を抑制あるいは防止するためです。こういったゴースト アーティファクトは、オクルージョン、シェーディングの変化、オブジェクトがフレームに収まらないなど、さまざまな理由で以前に蓄積された詳細が破棄されるために発生します。これらの詳細が再び表示されると、TSR はその詳細を再び蓄積しなければならず、その結果ゴースト アーティファクトが発生します。

TSR の復活したフレーム履歴では、現在のフレームとの比較のために、履歴から限られた数のフレームにアクセスできます。履歴復活が無効になっている場合、現在のフレームと再投影される詳細の比較に利用できるのは前のフレームのみです。新しい詳細や欠落した詳細は蓄積される必要があり、これがゴースト アーティファクトの主な原因になります。

TSR 復活が有効な場合、古い永続フレームの履歴は Texture2DArray でメモリに保持されます。この配列は、前のフレーム履歴を格納するために使用されるものと同じです。履歴内で利用可能な最も古い永続フレームが比較され、それが現在のフレームにより正確に一致する場合、直前のフレームの代わりに使用されます。これらのフレームは Texture2DArray に格納され、グローバル シェーダーは前のフレームまたは配列から取得した復活フレームのいずれかを再投影するため、復活履歴の更新にはあまり負荷がかかりません。負荷の大部分は、復活マスクのエッジの追加キャッシュ メモリの帯域幅から生じますが、Texture2DArray の履歴により、テクスチャのフェッチ数は厳密に同じになります。

前のフレームよりも厳密に一致する可能性のあるフレームが複数ある場合、それらは現在のフレームと比較され、該当する場合は、そのフレームが再投影されます。古い永続フレームは、フレーム数と現在のフレームからの間隔に応じて削除され、新しいフレームに置き換えられます。

履歴の復活をオフにした場合とオンにした場合の結果を比較できます。復活の履歴を比較して再投影できない場合、前のフレームが使用され、多くの場合、詳細を再蓄積する必要があり、その過程でゴーストが発生します。これは、アニメーションが武器を交換している下のフレームで特に明確にわかります。

コンソール コマンド r.TSR.Visualize 0 を使用して、ビューポートで Accumulated Samples 入力を全画面で表示します。

テンポラル スーパー解像度ビジュアライゼーション モードの [Resurrection Mask (復活マスク)] 入力と [Resurrected Frame (復活フレーム)] 入力には、現在および前のフレームの復活マスク (緑) で色付けされたフレームの領域と、復活したフレームの境界外にあるために復活が不可能なピクセル (ピンク) が表示されます。

独自のプロジェクトのニーズに合わせて永続的なフレーム履歴の数を構成することができます。これは、次のコンソール変数を使用して実行できます。

• r.TSR.Resurrection.PersistentFrameCount：将来の履歴復活のために記録する永続フレームの数を設定します。これにより、TSR 履歴全体のメモリ フットプリントが増加します。これは 2 以上の 偶 数である必要があります。
• r.TSR.Resurrection.PersistentFrameInterval：将来の履歴復活のために、永続的なフレームを履歴に記録する頻度を (フレーム数で) 設定します。これは、TSR 履歴のメモリ フットプリントには影響しません。これは 1 以上の 奇 数である必要があります。r.TSR.Visualize 5 を使用し、コンテンツに合わせてこれを調整します。

TSR によるゴースト問題のトラブルシューティング

プロジェクト内のゴーストの問題のトラブルシューティングを行うには、次の方法があります。

• TSR がゴーストの原因であるのか、あるいは他の何かが原因であるのかを特定する。

  テンポラル アップスケーラー ビジュアライゼーション モードを使用して、いずれかの入力ビューでゴーストが表示されるかどうかを確認します。表示されている場合は、DumpGPU コマンドとビューアを使用して、TSR でゴーストを引き起こしているシステムを特定します。

  ゴーストの原因が TSR かどうかわからない場合は、別のアンチエイリアス手法に切り替えるか、アンチエイリアスを完全に無効にして、ゴーストが引き続き発生するかどうかを確認します。

• 不正なモーション ベクターはアーティファクトやゴーストを引き起こすか？

  TSR は、モーション ベクターを活用して、不透明なジオメトリを再投影します。ゴーストを防ぐには、オブジェクトの再投影のアライメントを確認することが重要です。多くの場合、モーション ベクターが原因であるため、問題がシーン全体ではなく特定のオブジェクトにあるかどうかを確認することで判断できます。

  場合によっては、雲などの微細な半透明効果、マテリアル設定のベロシティの上書きによって、モーション ベクターの検出の問題が発生することがあります。コンソール コマンド r.Translucency.Velocity 0 を使用すると、これに該当するかどうかをすぐに確認できます。

  ワールド位置オフセットがアニメートされたマテリアル パラメータに基づいているかどうかを確認します。その場合は、Previous Frame Switch ノードに前のフレームの値が提供されていることを確認してください。これをマテリアルで設定する方法については、「Utility マテリアル表現式」を参照してください。

  モーション ベクターの計算には、インスタンスごとの変換モーションの自動ベロシティ ベクターがありません。

• ゴーストは TSR のちらつき時間分析によって引き起こされているか？

  ちらつき時間解析を調査する前に、モーション ベクターが正しいことを完全に確認する必要があります。これを確認しない場合、ちらつきの時間解析はゴーストの原因であると誤解される可能性があります。

  テンポラル スーパー解像度 (TSR) ビジュアライゼーション モードを使用して、ゴーストが発生しているフレームの赤い領域を検索します。テクスチャ パンなどのシェーダー アニメーションを備えた不透明なマテリアルの場合は、マテリアル設定の [Has Pixel Animation (ピクセル アニメーションあり)] が設定されていることを確認します。詳細については、このページの「ピクセル アニメーションを含むマテリアル」セクションを参照してください。

• ゴースト アーティファクトの原因となっているオブジェクトは半透明であるか？

  テンポラル アップスケーラー ビジュアライゼーション モードを使用し、オブジェクトが Translucency.AfterDOF.Color 入力ビューにあることを確認します。TSR のシェーディング除去は、すべてのマテリアルのデフォルトである DOF 後透過処理ではあまり柔軟性が高くありません。これは、デフォルトではベロシティを描画せず、正しく再投影することができないためです。詳細については、このページの「TSR と透過処理」セクションを参照してください。

テンポラル スーパー解像度 (TSR) のよくある質問 (FAQ)

このページで説明するトピックに関するよくある質問とその回答については、「テンポラル スーパー解像度 (TSR) のよくある質問 (FAQ)」を参照してください。

コンソール変数