Unreal Engine のテンポラルスーパー解像度 (TSR) のよくある質問 (FAQ) | Unreal Engine 5.7 ドキュメンテーション

このページでは、テンポラルスーパー解像度 (TSR) に関する FAQ を掲載しています。このページの各セクションは、TSR 技術概要の各セクションに対応しています。詳細な情報や事例については「テンポラルスーパー解像度 (TSR)」を参照してください。

TSR スケーラビリティ

TSR にはアップスケーリング設定のためのカスタマイズが多く含まれており、プロジェクトのニーズに基づいて個々のプラットフォームに合わせられます。TSR スケーラビリティのオプションとその機能の詳細については「テンポラルスーパー解像度 (TSR)」の「TSR スケーラビリティ」セクションを参照してください。

統計データ GPU で、TSR の GPU ランタイム負荷が予想以上に重いのはなぜですか？

TSR は、ディスプレイ解像度にアップスケールする前にエイリアシングをクリーンアップするために、フレーム末尾に近い GPU で実行されます。フレーム上のデータの蓄積に使用される履歴に GPU 永続リソースを割り当てるのはレンダラの最後のコンポーネントです。GPU の動画メモリが不足するようなシナリオでは、TSR は多くの場合、ホスト GPU メモリで割り当てられるべき GPU リソースのパフォーマンスの落とし穴に遭遇する、最初のコンポーネントになります。

GPU でメモリ不足の問題に直面している場合は、GPU クラッシュの発生を誘引している、タイムアウト検出と回復 (TDR) イベントを調整するようにしてください。詳細情報については「Dealing with GPU Crashes (GPU クラッシュの対応)」を参照してください。
TSR が対応できるスクリーンパーセンテージの範囲とは？

TSR シェーダーは、コンソールコマンド r.TSR.History.ScreenPercentage を使用して 25% から 200% までのスクリーンパーセンテージに対応するよう設計されており、それを `r.ScreenPercentage’ と連動させています。以下に例を挙げます。
- r.TSR.History.ScreenPercentage=200 の場合、r.ScreenPercentage=50 から r.ScreenPercentage=200 にフィードされます。
- r.TSR.History.ScreenPercentage=100 の場合、r.ScreenPercentage=25 から r.ScreenPercentage=100 にフィードされます。
TSR フィードと TSR 1spp の履歴に注目すると、TSR がどれだけの情報を持って各フレームと連動しているのかが分かります。
TSR は動的なレンダリング解像度をサポートしていますか？どのプラットフォームに対応していますか？

はい。動的解像度はコンソールプラットフォームで有効であり、サポートされています。ただし、Windows などのデスクトップには対応していません。これは TSR に限ったことではなく、リサーチ中の領域であり、現在はフォートナイトでテスト中です。以下のような現状の問題点があります。
- 動的解像度の目的は、GPU を節約して TSR 履歴の収束率を最大化することではなく、解像度を最大化することです。コンソールとは異なり、デスクトップの GPU ではゲーム以外のプログラムも動作しており、それぞれが独自のフレームレートで動作しています。既存の API では、所望するフレームレートでフレームを完了させる目的で、GPU のヘッドルームを他のプログラムに対してどれだけ残すべきかを知ることは現状不可能です。
- D3D のスワップチェーンで、Vsync を有効にした状態で画面上部を少しティアできる API が欠如しています。これはコンソールでは一般的であり、rhi.PresentThreshold.Top で指定できます。動的解像度が数マイクロ秒遅れて終了するフレームを逃さないことが重要です。弊社のテストでは、コンソールに比べ、サードパーティプログラムの使用のために GPU が先取りされる可能性がある Windows などのデスクトッププラットフォームでこれが頻繁に起こっています。
- GPU は省電力化のためにクロックを動的にスケーリングします。これにより、GPU 負荷を抑えようとして動的解像度が低くなる傾向が強くなります。ここで問題なのは、GPU スケーリングをクエリできる公式の D3D API がないことです。フォートナイトで示されたこの問題を GPU クロック および 動的解像度 の統計データを持つ 統計データ TSR を使用して特定することができたのは、ドライブのバックドア (Microsoft 社の記事『D3DKMTQueryStatistics 関数』を参照) を使用した場合のみです。
TSR は中間フレームを補間または生成しますか？

いいえ。TSR は Unreal Engine のビルトインテンポラルアップスケーラー/超解像度技術です。テンポラルアップスケーリング / 超解像度は、中間フレームを生成する技術とは異なります。このタイプの両技術には多くの関心が集まっているため、情報が明確でないと混乱を招く可能性があります。
TSR はサードパーティのフレーム補間 / 生成と連動できますか？

できます。レンダラと同じように動作します。この種のフレーム補間技術は、テンポラルアップスケーラー以降のポストプロセスチェーンのさらに多くの機能 (モーションブラー、色収差、シャープネス、フィルムグレイン、ブルーム、レンズ汚れ、ローカル露出) とポストプロセスマテリアルを処理しなければなりません。フレーム補間 / 生成プラグインへは、ITemporalUpscaler をセットアップして TSR を置き換えることを必要とせず、ISceneViewExtensions を使って深度およびモーションベクターに自由にアクセスできます。たとえば、テレビメーカーは、放送チャンネル、ストリーミングサービス、物理メディアといったあらゆるビデオフィードまたはゲーム機で、フレーム生成を行います。
フレーム補間 / 生成は TSR にどのような影響を与えますか？

多くのレンダリング技術がそうであるように、フレーム補間 / 生成も GPU 負荷を増やします。TSR などのテンポラルアップスケーラーがディテールを蓄積中に GPU がバインドされて GPU 負荷が増大すると、フレームレートに影響を及ぼす可能性があります。

ゲームの FPS が 55 Hz から 88 Hz まで補間される場合を例として、フレームが乗算されて表示フレーム数が 2 倍になるフレーム補間技術について考えてみましょう。ゲームの新しいフレームレートは有効なフレーム補間を用いて算出され、補間されたゲームの FPS とイコールになります。

たとえば、GameFPS=55 Hz から始まって InterpolatedFPS=88 Hz まで、FrameMultiplier=2 で表示フレーム数が 2 倍になるフレーム補間技術について考えます。InterpolatedGameFPS=FPSInterpolatedFPS/FrameMultiplier=44 Hz とする、有効なフレーム補間を用いて新しいゲームのフレームレートを算出することができます。これは InterpolatedGameFPS/GameFPS=0.8 の乗率でゲームのフレームレートを低下させます。これは直接的にテンポラルアップスケーラーの MP フィードに *0.8 だけ影響し、履歴の収束率を 1/0.8=1.25 だけ増加させます。

これらの結果は TSR フィード および TSR の収束率を示す 統計データ TSR で確認できます。フレーム補間を有効にするとディテールの蓄積スピードにどう影響するかを理解できます。
テンポラルアンチエイリアシング (TAA) またはテンポラルアンチエイリアシングアップスケーリング (TAAU) を改善する予定はありますか？

いいえ。TAA と、その派生である TAAU は前世代コンソールの制約の中で開発されました。開発以来、唯一加わったのは、深刻な色精度の問題がない R11G11B10 を初めて持てるようになった TSR のアビリティです。これにより、古いプラットフォームでさらに多くのメモリ帯域幅のパフォーマンスを節約できるようになり、デフォルトで有効になっているコマンド r.TemporalAA.R11G11B10History で制御できます。自身のプロジェクトでは、アンチエイリアスを低スケーラビリティで使用しても TSR の負荷が大きいローエンドの GPU ユーザーに向けて、D3D11 または D3D12 で TAA を引き続き公開することができます。フォートナイトはこのようなプレイヤーを想定して設定されています。
TSR と他のサードパーティのテンポラルアップスケーラーとの比較は可能ですか？

TSR は Unreal Engine 5 でデフォルト手法ですが、サードパーティのテンポラルアップスケーラーも自身のプロジェクトで容易に利用可能です。5.3 では ITemporalUpscaler インターフェースの制約で、サードパーティのテンポラルアップスケーラー間で切り替えるとクラッシュする可能性がありましたが、その問題は解決されています。ビューポートの [Show (表示)] > [Visualize (可視化)] メニューから [Temporal Upscaler] のビジュアライゼーションを切り替えることができます。このビジュアライザは、Unreal Engine のビルトインかサードパーティ製かを問わず、あらゆるテンポラルアップスケーラーと連動します。このビジュアライザは、同じレンダリングとディスプレイ解像度を使用した、ビルトインとサードパーティ製のアップスケーラーの比較に役立ちます。
TSR にシャープネスパスはありますか？

ありません。私たちは TSR で生成される画像のリファレンスのマッチングのみに目を向けています。ただし、テンポラルアップスケーリングより後に実行されるトーンマッパパスには r.Tonemapper.Shapen で有効にできるオプションのシャープネス処理があります。[Show] > [Visualize] メニューにある [Temporal Upscaler] のビジュアライゼーションでその効果を確認できます。

フォートナイトでは、ゲームが持つ競合性により、すべてのプラットフォームのすべてのテンポラルアップスケーラーで r.Tonemapper.Sharpen=0.5 と設定します。

TSR 履歴

TSR は経時的にディテールを蓄積しています。これらレンダリングされたディテールの経時的な総集計は、ディスプレイ解像度での履歴で行われます。TSR の履歴とその機能の詳細については、「テンポラルスーパー解像度 (TSR)」の「TSR 履歴」セクションを参照してください。

TSR 履歴のサンプル数は履歴のメモリ消費量に影響しますか？

r.TSR.History.SampleCount でサンプル数を高く設定しても TSR 履歴に影響はありません。パフォーマンス上の理由から、TSR ではピクセルのディテールを raw で保持せず、履歴に蓄積/集約されます。履歴のサンプル数は、履歴に占める現フレームの最小寄与率の割合のみを持ちます。これは 1 / 履歴サンプル数で表されます。サンプル数が少ないほど、履歴に占める現フレームの最小寄与率が高くなり、一時的不安定性が高まります。サンプル数が多いほど、現フレームの最小寄与率が低くなり、画像がより安定します。ただし、ゴーストが発生した場合、消滅するまでに時間を要します。

履歴サンプル数は TSR 出力/表示ピクセルあたりです。つまりナイキスト-シャノン履歴で使用する履歴ピクセルあたりの履歴サンプル数はさらに低く、それがテンポラルスーパー解像度 (TSR) のビジュアライゼーションモードの使用時に表示されるものです (VisualizeTSR を表示)。
動作の履歴のウェイトはどのように調整するべきですか？

動作中の履歴のウェイトを設定すると、画像の安定性とシャープネスの間でバランスを取ることができます。たとえば、フォートナイトのような競合性の高いゲームでは、r.TSR.Velocity.WeightClampingSampleCount を下げることで、動作中に画像の安定性よりもシャープネスを優先させることができます。このコンソール変数を r.TSR.History.ScreenPercentage で調整し、100 に設定します。履歴の解像度が高くなると、動きのブラーと安定性の両方が自動的に低下するからです。
アンチエイリアスのスケーラビリティをエピックにした 4K モニターで TSR を実行すると、8K テクスチャをレンダリングしますか？

はい。エピックのアンチエイリアススケーラビリティで 4K モニター上で TSR を実行すると、8K テクスチャが効果的に使用されます。動作中にシャープなビジュアルを必要としないゲームであれば、アンチエイリアスの高スケーラビリティの使用を代わりに検討できます。考慮すべきことは、GPU は昨今のパワフルなものだがモニターは 1080p である場合、履歴の再投影によるディテール損失はより顕著になるということです。このような理由から、TSR のアンチエイリアスのスケーラビリティを、低、中、高、エピックの各画質レベルで公開することはプロジェクトにとってメリットであり、またプレイヤーにとっても自身のハードウェア設定に最適なエクスペリエンスに合わせられる重要な選択肢となります。
プロジェクトでは、200 を超えるスクリーンパーセンテージで TSR 履歴を使用すべきですか？

各軸に 2 倍のピクセル数があれば、履歴のピクセル間の補間を表示ピクセルで隠すには十分であるため必要ありません。200 を上回るスクリーンパーセンテージにすると、レンダリング解像度と履歴解像度の間で、私たちがテストする範囲をはるかに超えるアップスケーリング倍率が発生します。TSR 履歴はすでにスクリーンパーセンテージを 100 と 200 の間で任意にスケーリングしており、スクリーンパーセンテージ 200 の履歴用にダウンサンプリングパスのシェーダー順列があることにご注意ください。ナイキスト-シャノンの必要条件を満たし、ダウンサンプリングをうまく簡略化できる数学的な手法があることがその理由です。必要であれば、TSR 履歴のスクリーンパーセンテージを r.TSR.History.ScreenPercentage で調整することができます。
TSR 履歴のスクリーンパーセンテージを 100% より高くしたいのですが、プライマリのスクリーンパーセンテージに合わせる必要がありますか？

はい。TSR 履歴のスクリーンパーセンテージを 100% より高くしたい場合、TSR 履歴のスクリーンパーセンテージ (r.TSR.History.ScreenPerecentage) はプライマリのもの (r.ScreenPercentage) に合わせる必要があります。合わせていないと、スーパーサンプリングされたレンダリングは履歴の拒絶ブラーを被ります。プロジェクトのフレームバジェットにプライマリのスクリーンパーセンテージを高くする余裕があれば、TSR 履歴のスクリーンパーセンテージに合わせる余裕もできます。
TSR は 8K をレンダリングできますか？

TSR は履歴の更新ができるだけ早くなるように開発および設計されています。コンソールでの 4K レンダリングであれば、画質を良くする視差やシェーディングのヒューリスティックにおける、レンダリング解像度のバジェットに余裕が生まれます。つまり PC であれば、ハイエンド GPU では 4K、ある程度高速な GPU ではもっと低いディスプレイ解像度で、ナイキスト-シャノン履歴のためのバジェットがあるということです。私たちは積極的に 8K をテストしているわけではありません。しかし、アンチエイリアスの品質をなるべく高くしたり、16K 履歴を避けるために TSR 履歴のスクリーンパーセンテージをより低く設定したりしても、問題はないはずです (r.TSR.History.ScreenPerecentage)。

UE では、r.PostProcessing.QuarterResolutionDownsample 2 の使用時に、ポストプロセスチェーンの一部を 8 分の 1 の解像度で実行するための 8K サポート (実験的機能) を備えています。これを r.Bloom.ScreenPercentage 12.5 と組み合わせることで、FFT もこの解像度で実行できます。これらの設定により、r.TSR.History.ScreenPercentage が 100 に等しい場合 (またはアンチエイリアススケーラビリティをエピックで使用する場合)、TSR は 8 分の 1 のサイズで履歴更新のシーンカラーを生成することができます。
ナイキスト-シャノン履歴が動画メモリを使い果たしてクラッシュを引き起こすリスクとなるものは何ですか？

利用できる動画メモリがあれば問題ありません。一方で、利用できる動画メモリがない場合、ドライブが CPU メモリの割り当てを開始するため、パフォーマンスの低下を引き起こします。TSR は GMaxTextureDimensions をチェックし、ハードウェアがピクセル座標にエンコード可能な値 (多くの場合 16384 ピクセル) よりも大きな履歴を割り当てないようにします。TSR はまた、16 ビット VALU シェーダー順列上であっても、23 ビットの仮数の精度を持つように、すべてのテクスチャの UV 座標を 32 ビットの浮動小数点数で計算します。
TSR のナイキスト-シャノン履歴は、パフォーマンスの影響をポストプロセスチェーンに与えますか？

ディスプレイ解像度へのダウンサンプルは TSR 内部で発生するため、ナイキスト-シャノン履歴に従うポストプロセスチェーンへの影響はありません。そのため、それ以降のパスでは、アンチエイリアススケーラビリティ設定のエピックと高の間で解像度の差は見られません。
ナイキスト-シャノン履歴の使用には負荷がかかりそうです。プレイヤーに他の選択肢を提供すべきでしょうか？

Unreal Engine の品質スケールでは、スケーラビリティグループ (低、中、高、エピック) およびシネマティックが使用されており、エピックのスケーラビリティはプレイヤーに提供できる最高のクオリティです。『Steamハードウェア調査』を参照すると、ユーザーの最も一般的なディスプレイ解像度を知ることができ、誰もが 4k モニターを持っているわけではないことも分かります。このことを念頭に置き、ナイキスト-シャノン履歴の品質とパフォーマンスの間のバランスが取れて、TSR で提供されるアンチエイリアスのスケーラビリティでより低いものを使用できる、万能性のある他のオプションを検討するのがお勧めです。たとえば、ユーザーが 1080p モニターを使用している場合、1080p モニターでは履歴の再投影にブラーが生じるため、スクリーンパーセンテージは 540p になり得ます。
TSR 履歴のスクリーンパーセンテージ用に、別の TSR 設定を公開することを検討できますか？

オプションで独自のアンチエイリアススケーラビリティグループを追加し、それらを別の設定として公開することができます。TSR の設定を他のアンチエイリアスオプションと区別する一つの方法は、使用されている手法を指し示す括弧を追加することです。また、自身のプロジェクトのインターフェースで、これをさらに区別することができます。たとえばフォートナイトでは、複数のアンチエイリアス手法がサポートされています。その TSR 設定は、低、中、高、エピックの画質設定に応じて、それぞれ選択できます。TSR 履歴のスクリーンパーセンテージなど、ユーザーインターフェースに公開されるパラメータも追加されています (r.TSR.History.ScreenPercentage)。

TSR 履歴のスクリーンパーセンテージを追加する際は、名前の付け方に配慮してください。「TSR Super Sampling」のような名前は実際的ですが、スクリーンパーセンテージや、スーパーサンプリングを持つサードパーティのテンポラルアップスケーラーと混同される可能性があります。

シェーディング拒否

TSR のシェーディング拒否ヒューリスティックは、現在のフレームが以前にレンダリングされたフレームとどの程度一致しているかを判断し、それを再利用するかどうかを決定する処理です。TSR のシェーディング拒否とその機能の詳細については、「テンポラルスーパー解像度 (TSR)」の「シェーディング拒否」セクションを参照してください。

BlendFinal と ClampBlend が 1 未満のときに TSR ゴーストが発生します。

TSR 開発において可能な限りこの問題を解決しようとしていますが、これは TSR のシェーディング拒否に関する既知の問題です。
ClampBlend を使った履歴拒否の利点は何ですか？

Unreal Engine 4 のテンポラルアンチエイリアシングの大半は、ClampBlend を使った拒否の技術に依存しています。履歴のカラーが入力解像度から大きく外れていないことを確認しつつ、アンチエイリアスされたエッジをいくつか保持するために役立ちます。ただし、ノイズが多いとゴーストが発生するためで、履歴拒否がゴーストを最小化することを目当てにこれを使うことができないのが欠点です。また、テクスチャのディテールをブラーにするため、必要時のみの使用になります。
BlendFinal 使った履歴拒否の利点は何ですか？

BlendFinal を使うと、履歴と比較した現フレームのウェイトの動的コントロールが可能になります。BlendFinal が高いほど、現フレームがより出力を支配することを意味し、履歴が使用されなくなります。BlendFinal が 1 の場合、空間アンチエイリアスによる負荷を埋め合わせるため、履歴の再投影を無効にします。この BlendFinal を使った特殊な手法は、ノイズが多すぎてクランプにアーティファクトのゴーストが発生するようなスクリーン領域での履歴拒否に役立ちます (テンポラルアンチエイリアシングなどで発生する状況)。こちらにも、レンダリング解像度でノイズが目立つというマイナス面があります。

TSR と透過処理

透過処理は TSR 特有の問題として扱うことができます。なぜなら任意のレイヤー数をブレンドしていくつも重ねることができるからです。速度を一切描画しないのでなおさらです。TSR が半透明マテリアルでどのように機能するかの詳細については「テンポラルスーパー解像度 (TSR)」の「TSR と透過処理」セクションを参照してください。

TSR で [ResponsiveAA] 設定を使うのに半透明マテリアルは必要ですか？

[ResponsiveAA] 設定を使うために TSR で半透明マテリアルは必要ありません。この設定はテンポラルアンチエイリアシング (TAA) に役立ちます。これにより、半透明マテリアルを使用する VFX のディテールを TAA が失うのをかなり防ぐことができました。TSR は [Translucency Pass] をデフォルトで [After DOF] に設定することで、半透明マテリアルのこの問題に対処しています。
直接的にシーンカラーに描画してパフォーマンスを節約するには透過処理の [After DOF] を無効にするべきですか？

r.SeparateTranslucency 0 を使用して直接的にシーンカラーに描画すると、コンポジットパスの負荷を取り除いてパフォーマンスを節約できます。ただし、お勧めはしません。TSR の GPU 負荷は、透過処理の [After DOF] を無効にしても少しも軽くなりません。実際に、TSR は個別のコンポジットパスの処理の必要性を省きますが、節約になる唯一のパフォーマンスは、float 型 R16G16B16A16 ピクセルフォーマットではなく、float 型 R11G11B10 に透過を描画することです (r.SceneColorFormat に設定されている場合)。しかし、これは煙雲のような非常に低周波の透明エフェクトをブレンドする際に、量子化問題を起こす傾向にあります。

低品質なエフェクトを持つ「BaseScalabililty.ini」で r.SeparateTranslucency が 0 に設定されていると TSR がシーンの透過処理でゴーストを発生させるという既知の問題が存在します。これを回避するには、TSR を使用する際は常時 r.TSR.ForceSeparateTranslucency を使用し、個別の透過処理パスを強制的に有効にします。
被写界深度 (DOF) に続く透過処理にはさらなるメモリ負担が課されますか？

被写界深度に続く透過処理では、エンジンが中間リソースのメモリをフレーム内で複数回にわたって再利用するため、メモリ負担は増えません。これはレンダリング依存関係グラフ、および一時メモリのアロケータを備える RHI を使って実行されます。r.RDG.TransientAllocator 1 で設定され、デフォルトは有効です。
透過処理の [After DOF] が、フォーカス距離に起因して [Before DOF] に切り替わると、ゴーストが発生するリスクはありますか？

半透明マテリアルに適用されている被写界深度 (DOF) のブラーが、TSR のシェーディング拒否の精度を低下させるノイズを低減しているため、ゴーストが発生する可能性は低いです。それよりも Nanite のディテールの結果としてノイズが発生する可能性があります。

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

ポストプロセスマテリアルは、マテリアルのレンダリングの際にある程度の柔軟性を TSR に与えますが、TSR がポストプロセスのレンダリングチェーンの中間で実行されるのでそれなりの制約はあります。マテリアルは、シーンカラーのさまざまな位置、および被写界深度 (DOF) の透過処理後に挿入されます。TSR のポストプロセスマテリアルの処理方法の詳細については「テンポラルスーパー解像度 (TSR)」の「ポストプロセスマテリアルの TSR」セクションを参照してください。

TSR でセルシェーディングのアウトラインを処理する最適な方法は何ですか？

アウトラインがうまく機能しない場合の主原因は、アウトライン用のモーションベクターの欠如です。ジオメトリがオブジェクトのモーションベクターを中心としたラインをドラッグできるよう、輪郭を描くジオメトリ上でアウトラインをインライン化することを検討してください。アウトラインが途切れて見えないように、ラインは少なくとも一定のピクセルの太さを持つべきです。

キャラクターが走っているような動的オブジェクトであれば、アウトラインはカメラビューに依存するため、その動作はモーションベクターに反映されずにキャラクターのサーフェスで動く傾向があります。[post process material] 設定の [Blendable Location] で 透過処理 [After DOF] にすると、半透明マテリアル用の特別なロジックを利用することができ、モーションベクターが提供されていない場合にゴーストを発生させません。
TSR 後にアンチエイリアスの深度バッファを利用するにはどうすればよいですか？

おそらく可能ではありません。一番の問題はバックバッファにアンチエイリアスを実行できないことです。その理由については、30 メートル離れた背景の、10 メートル離れた街灯で考えてみてください。その 2 つの間の深度にアンチエイリアスを実行すると、深度は 10 メートルから 30 メートルの間のどこかになってしまいます。街灯と建物はつながっていません。このような理由から深度の temporal accumulation (一時的な蓄積) を実装していません。また、深度バッファの不安定性やエイリアシングが誘引するジッターへの懸念から、そういったものを実装する計画もありません。画像にエイリアシングや不安定性を反映させることなく TSR 後にこの結果を具現化することは不可能だと言えます。これを踏まえ、深度を使ったエフェクトは TSR または TAA の前に実行することを推奨します。

ちらつき時間解析

TSR のちらつき時間解析とは、モアレパターンなどのアーティファクトの画像を解析し、遠距離でも幾何学的なディテールの一貫性の維持に努めるもので、可能な限り画像を安定させようともします。TSR のちらつき時間解析の仕組みの詳細については、「テンポラルスーパー解像度 (TSR)」の「ちらつき時間解析」セクションを参照してください。

ちらつきは常に TSR で軽減されるべきですか？

現在のところ、ちらつきの発生源が次の 2 つである場合、TSR 以外で軽減できることが分かっています。
- Lumen グローバルイルミネーションの安定性を損なう原因となる、シーン内の高輝度オブジェクト。
- ジオメトリのエッジが溶接されていない場面で Nanite の簡素化を使用した、ちらつきを誘引する遠方オブジェクト。
[material (マテリアル)] 設定の「ピクセルアニメーションがある」フラグでオブジェクトの描画速度を強制できますか？

[material] 設定の 「ピクセルアニメーションがある」 は、アニメーションがモーションベクターで完全に記述されていると仮定するレンダリングのヒューリスティックを無効にするようマテリアルを強制します。GBuffer に使用可能なビットが欠如していることから、また、この機能が前方レンダリングで使用できるようにするため、この設定は、TSR が再投影のためにすでに読み込んでいる速度バッファにエンコードされます。そのため、このマテリアル設定を有効にする不透明型ジオメトリがたとえ静的であっても、この設定をエンコードするためだけにその静的速度を描画する必要があります。
「ピクセルアニメーションがある」設定は、マテリアルインスタンスにマテリアルシェーダー順列を追加しますか？

[material] 設定の 「ピクセルアニメーションがある」 は、シェーダー順列を使用するマテリアルインスタンスにシェーダー順列を追加しません。この設定は、さらなるシェーダー順列のコンパイルを避けるために、シェーダー順列を使用する、マテリアルが割り当てられているプリミティブに自動的に設定されています。ただしこれは、そのマテリアルスロットの一つに、このフラグが有効になっているマテリアルが一つでも存在するプリミティブで、このプリミティブの該当マテリアルのすべての TSR のちらつき時間分析が無効になることを意味しています。複数のマテリアルスロットを持つもののメッシュの一部でしかマテリアルアニメーションを使用しないような、複雑な形状を持つプリミティブは避けることをお勧めします。

履歴復活

TSR の履歴復活とは、直前のフレームを使用するか、あるいはもっと前のフレームで現フレームの詳細によりよく一致するものを履歴から「復活させる」かを決定する処理を指します。この処理は、画像を安定させ、アーティファクトのノイズやゴーストの発生を抑制あるいは防止するためです。履歴からフレームを復活させる方法の詳細については、「テンポラルスーパー解像度 (TSR)」の「履歴の復活」セクションを参照してください。

なぜ一部のフレームだけが永続的に保存されるのですか？

一部のフレームのみ永続的に保持するのは動画メモリを節約するためです。これは特に、アンチエイリアスのスケーラビリティ設定がエピックまたはシネマティックである場合の、TSR 履歴のスクリーンパーセンテージ (r.TSR.History.ScreenPercentage) が 200 であるナイキスト-シャノン履歴で重要になります。
TSR の履歴復活でメモリ消費量は大きくなりますか？

履歴復活を使用しない場合、TSR には現フレームと前フレームの 2 つの履歴を必要とします (毎フレームで役割が反転)。履歴復活が有効 (r.TSR.Resurrection 1) であれば、2 に TSR 復活の永続フレーム数 (r.TSR.Resurrection.PersistentFrameCount) をプラスした数が履歴数になります。永続フレーム数が 2 フレームであることから、履歴復活のデフォルトで TSR のメモリ消費は 2 倍になります。テンポラルアップスケーラーのビジュアライゼーションモードで、履歴のメモリ消費量を可視化できます。ビューポートのビジュアライゼーションモードは、[Show] > [Visualize] メニュー下で [Temporal Upscaler] を選択することで切り替え可能です。
なぜ最も古い永続フレームにのみ復活を適用するのですか？

最も古い永続フレームにのみ復活を適用するのは、復活にかかる基本 GPU の負荷が理由です。レンダリング解像度の再投影については、前フレームと現フレームを比較するために復活フレームバージョンにも行うものであり、最終的に復活が使用されるかに関係なく毎フレームに実行する必要があります。
なぜ TSR の復活の永続フレームの間隔カウントに制約があるのですか？

ディスプレイ解像度以上で発生するテクスチャの更新履歴パスの命令フェッチを増やすことなく履歴復活をできるだけ最適化するために、TSR は Texture2DArrays を利用しています。そのため、単一のシェーダーが読み込みと書き込みの両方を行わなければならず、シェーダーが同時に読み込めるテクスチャスライスの範囲に制約が生じます。
GPU は永続フレームを維持するために履歴の追加コピーを実行しますか？

いいえ。
復活が予期する場所で起こらないのはなぜですか？

履歴復活には次の 2 つの条件があります。
- 前フレームよりも復活フレームの方が現フレームにより一致している。
- 前フレームが、現フレームと一致していると見なせるほど一致していない。
復活フレームは、これらの条件下で現フレームと比較され、十分に一致すれば使用されます。間接ライティングが多い場面では、現フレームは Lumen から十分なサンプルを得ていない可能性があるため、予期した現フレームの見た目とは異なっていたり、復活フレームの見た目と異なって見えたりすることがあります。このような状況下ではフレームの復活の実行が妨げられることがあります。
TSR の最新の変更を Unreal Engine の以前のバージョンにマージするのはどの程度複雑ですか？

TSR 履歴が Texture2D ではなく Texture2DArray で作られるようになったのは Unreal Engine 5.4 からです。余分な GPU コピーが次のポストプロセスチェーンの Texture2D を出力するのを避けるためにポストプロセスパスにいくつかの変更がなされ、「PostProcessing.cpp」ファイルで新しい FScreenPassTextureSlice を持つ RDG テクスチャで SRV を代わりに受け入れるようになりました。これら変更の多くはすでに Unreal Engine 5.3 に含まれているため、5.4 以降の変更から必要なものを選び、通常の TSR ファイルに入れるだけで済みます。

ポストプロセスチェーンの履歴復活に役立つ、Unreal Engine 5.3 以前のバージョンに対する 5.3 の変更点については以下を参照してください。
Unreal Engine 5.4 でのポストプロセスチェーンの追加の変更点については以下を参照してください。
- https://github.com/EpicGames/UnrealEngine/commit/59a7373ea7bde36706a2f8601ff6d72979624672
履歴復活はコンソールプラットフォーム用に開発されたプロジェクトにシッピングできますか？

Unreal Engine 5.4 の時点で、GPU ランタイム負荷を Unreal Engine 5.1 と同じにして復活ベースの負荷を相殺するために、TSR には十分な最適化が実装されました。これは 60Hz でフォートナイトを擁する 4K コンソールで TSR がシッピングされた場合です。動的解像度のスケールを 60% でロックしたパフォーマンスリプレイをテストで実施しました。その結果、フォートナイトは動的解像度で平均 51% のスクリーンパーセンテージで動作していたのに対し、計測された全体の平均負荷は 0.24 ミリ秒でした。
動いているオブジェクトの復活は可能ですか？

復活は、ディテールを改めてゼロから蓄積する必要頻度を極力減らそうとします。オブジェクトがフレーム内部の何かにオクルードされたりフレーム外に移動したりして画面上にない場合、TSR はオブジェクトの動きを追跡できず、そのディテールを再び蓄積しなければなりません。TSR にはオプティカルフローがないため、現フレームの深度バッファを使って復活フレームのビューと射影行列を用いながら再投影のみを行い、その見た目が現フレームと合っているかどうかを確認します。

オブジェクトが移動していないか、ほとんど移動していなければ、TSR は色が揃わない場合を除いてそれらディテールを復活させます。たとえばフォートナイトの TSR は、ゆっくりと動く草を、たとえ完璧に揃っていなくても復活させることができます。そのため、新しく表示される草の鮮明なディテールは蓄積されているとおりに十分キャプチャできます。シーン内の静的オブジェクトでディテールの欠落が目立つのに対し、動きの速いディテールの場合は画面上で動きがある分だけ復活の欠如に気づきにくくなります。