UE 5.7.4 における r.VelocityOutputPass=0 と DDM_AllOpaqueNoVelocity の挙動について

International 日本語 (Japanese)
, ,
1

UE 5.7.4 の Velocity / Depth Prepass 周りの挙動について確認させてください。

SceneCaptureを用いた表現を実装しているのですが、RenderVelocities パスが必ず実行されてしまう現象を確認しています。

実装している表現では Velocity が不要であるため質問をさせていただきたいです。

<br/>

Renderer の実装を確認したところ、以下のような挙動になっていると理解しています。

<br/>

  • r.VelocityOutputPass のデフォルト値は0であり、Velocity を Depth Pass 中に出力する設定になっている
  • FVelocityRendering::DepthPassCanOutputVelocity() は、r.VelocityOutputPass == 0 かつ MSAA 無効時にtrueを返す
  • FDeferredShadingSceneRenderer::ShouldRenderVelocities() は、DepthPassCanOutputVelocity() がtrueの場合、View 側で実際に Velocity が必要かどうかの判定に入る前にtrueを返す
  • ShouldForceFullDepthPass() が true の場合、FScene::GetEarlyZPassMode() では DepthPassCanOutputVelocity() がtrueのときに DDM_AllOpaqueNoVelocity が選択される
  • DDM_AllOpaqueNoVelocity では、Depth Prepass 側で Depth + Velocity を出力する Primitive がスキップされ、後続の Velocity Pass で残りの Depth を書くように見える
  • その結果、Motion Blur / TAA / TSR などで Velocity を実際には必要としていない場合でも、Depth Prepass を完了させるために RenderVelocities パスが必要になっているように見える

<br/>

この理解は正しいでしょうか？

<br/>

もしこの挙動が意図されたものである場合、Velocity を必要としない表現で追加の RenderVelocities パスを避けるための推奨設定、または安全な回避策はありますでしょうか？

<br/>

r.VelocityOutputPass を1または2に変更することも検討しましたが、以下を懸念しています。

<br/>

  • r.VelocityOutputPass=1 の場合、Base Pass 側に Velocity 出力が追加され、Base Pass の負荷が増える可能性がある
  • r.VelocityOutputPass=2 の場合、Velocity Pass が Base Pass 後に移動し、Async Compute とのスケジューリング上の待ちが発生する可能性がある

<br/>

また、FScene::GetEarlyZPassMode() 内の以下の分岐についても確認したいです。

OutZPassMode = bDepthPassCanOutputVelocity ? DDM_AllOpaqueNoVelocity : DDM_AllOpaque;

DDM_AllOpaqueNoVelocity の名前および実際の挙動を見ると、この分岐が少し直感に反しているように見えます。

<br/>

この分岐は意図された挙動でしょうか？

それとも既知の問題でしょうか？

もし既知の問題であれば、今後の UE バージョンで修正または改善される予定はありますでしょうか？

<br/>

以上です。よろしくお願いいたします。

[Attachment Removed]

2

再現手順
実装に関する質問であるため再現手順はありません。UEを実行し、PIX/UnrealInsightなどで描画パスを調査することで確認可能です。

[Attachment Removed]

3

お世話になっております。

本件事前に詳細を調査頂きありがとうございます。

確認させて頂いたところ今回ご相談頂いている挙動に関しましては記載頂いた内容でお間違いないかと思われますが、

大枠のお答えとしましては、今回の挙動は想定している挙動となっており改善予定などはない状況です。

したがって、Velocity出力の負荷を減らすためには"r.VelocityOutputPass"を0以外に設定し、

必要とする機能(Motion Blur / TAA / TSR / Lumen / SSR / DFAO / Distortion 等）をオフにして頂く形となります。

※懸念されているように処理負荷によって非同期処理のスケジューリングによるデメリットがある可能性はありますが、

既に検討頂いている"r.VelocityOutputPass 2"にして頂くと挙動はシンプルになるかと思います。

各挙動に関して確認させて頂いた内容を以下にまとめさせていただきます。

・ShouldRenderVelocities()判定内の処理について

関数内冒頭のDepthPassCanOutputVelocity()判定でr.VelocityOutputPassが0の場合は、

DepthPass(EarlyZPass)において、Velocityはコストはかかるものの常に出力する事を想定しています。

※設定や実装内のコメントに記載されているようにDepth内の2パス(DepthとVelocity)で完成させる挙動となります。

// r.VelocityOutputPass 0: Renders during the depth pass. This splits the depth pass into 2 phases: with and without velocity
 
// Always render velocity when it is part of the depth pass to avoid dropping things from the depth pass.
// This means that we will pay the cost of velocity in the pass even if we don't really need it according to the view logic below.
// But requiring velocity is by far the most common case.
// And the alternative approach is for the depth pass to also incorporate the logic below to avoid dropping velocity primitives.

・FScene::GetEarlyZPassMode() 内の分岐に関して

EarlyZPassにはいくつか名称のブレがあり少々分かりづらいものとなってしまっていますが、

呼び出し元の関数名がRenderPrepassAndVelocityとあるように、

Depth PrepassとVelocityがセットでEarlyZPass(early depth pass, depth pass)となっています。

bDepthPassCanOutputVelocityで変更されるOutZPassModeに関しては一見わかりづらいのですが、

DDM_AllOpaqueNoVelocityは、“Velocityを持たないOpaqueのDepthを書く指定”、

DDM_AllOpaqueは、“すべてのOpaqueのDepthを書く” というDepthの描画対象を決めるフラグとなっており、

bDepthPassCanOutputVelocityが有効な場合、静的なDepthをDDM_AllOpaqueNoVelocity指定で先に書いた後で、

VelocityPassでVelocityを持つDepthとVelocityを書いて完成させる、という流れとなっています。

※通常のVelocity PassはBasePass以後のものと位置づけられており、

この時の分岐ではDepthパス、またはBaseパスで出力されていない場合にという判断になっています。

// If we are not rendering velocities in depth or base pass then do that here.今回SceneCapture側でオフにしたいとのことで、

現状r.VelocityOutputPass 0のままVelocityのオフを実現する場合は、

各機能の依存性を確認していただいた上で改造いただく形になってしまうかと思われます。

まずはr.VelocityOutputPass 2設定にてパフォーマンス上許容できないかご確認いただけますと幸いです。

お手数おかけしますが、よろしくお願いいたします。

[Attachment Removed]

4

詳細なご回答ありがとうございます！

概ねの理解において、齟齬がないこと承知いたしました。

後は頂いた情報をもとに弊社にて対応の方針を決めていきたいと思います。

[Attachment Removed]

5

ご確認ありがとうございます。対応の参考になれば幸いです！

本件はクローズとさせていただきますが、また何かございましたらお気軽にご相談頂ければと思います。

よろしくお願いいたします。

[Attachment Removed]