Unreal Engine 5 ドキュメントは Epic Developer Community に移動しました

以前、モーション ブラーは、スタティックな環境を撮影する一般的なケースに干渉するため、無効になっていました。物理カメラの公開されたセンサーは、カメラの移動に従って、インナー フラスタムに自然にぼかしを発生させます。nDisplay においてモーション ブラーをネイティブで有効にすると、最終的な映像でブラーが不適切に増幅され、インナー フラスタムは追跡されるカメラの動きによってレンダリングにブラーを伴い、物理カメラでは表示にブラーが生じたインナー フラスタムが撮影されていました。

しかし、LED ウォールではモーション ブラーをレンダリングすることが望ましい場合があります。以下に例を示します。

• ウォールに表示されるコンテンツがアニメーションを伴う場合 (仮想環境内でアニメートされた車両やキャラクターなど)。

• プロセス ショット を撮影する場合。この場合、仮想環境自体がセットのアクタやプロップを基準とするモーションを伴います。プロセス ショットの一般的な例としては、アクタが車に乗っていて、背景が動いているように見えるものがあります。この場合、物理カメラとプロップの車両は肉眼的な並進運動を伴わないため、LED ウォールにブラーをレンダリングする必要があります。

nDisplay では、カメラの動作追跡によるブラーを減算することで、モーション ブラーを伴うインナー フラスタムをレンダリングするソリューションが提供されるようになりました。たとえば、プロセス ショットにカメラのパンが含まれる場合、背景の移動が高速に表示される場合でもインナー フラスタムに追加のブラーを作成しません。

プロセス ショット: ステージの移動とワールドの移動

プロセス ショットのシーンを準備するには、次の 2 つのアプローチを取ることができます。

• ステージを移動する :nDisplay Root アクタが環境内を移動します。

• ワールドを移動する :nDisplay Root アクタを中心として環境全体が移動します。

各アプローチにユースケースがあります。最適な選択肢は、プロジェクトのニーズによって異なります。

ステージを移動する

このアプローチの場合、nDisplay Root アクタは、車両の肉眼的動きを表すパスを使用してアニメートされている必要があります。もう一方のアプローチと比べて、環境を移動可能にする変更をすることなく使用でき、こちらの方が設定が簡単です。

このアプローチには、次のようないくつかのデメリットがあります。

• 各テイクは、アニメーション再生のタイミングに合わせて慎重に演出する必要がある。

• モーション パスをクローズド ループにすることができない限り、最後のフレームと最初のフレームの間で再生のリセット部分がわかりやすい。

• テイクが長くなればなるほど、作成しなければならない環境が増える。

• カメラの肉眼的な並進運動が原点から遠すぎる場合、単精度浮動小数点形式の制限により、Unreal のレンダリングが不安的になる可能性がある。

ワールドを移動する

このアプローチでは、Unreal のワールド空間内にバーチャル ステージを固定したままで維持し、その周囲の環境をアニメートします。車両の外側に汎用のビジュアルのモーションが単に必要な場合、これは柔軟なアプローチになる可能性があります。

このケースでは、特に車両のモーション パスが単純な場合、多数のトリックを導入できます。たとえば、バーチャル ステージを中心としてベルト コンベアのようにして環境のブロックを動かし、再利用できます。これによって再生を無限に行えば、カメラのショットに干渉は生じません。

車両のパスの方向がより定まっていて環境が移動可能に設計されている場合、車両のアニメーションを別途作成し、環境の親であるルート トランスフォームに対して反転させることもできます。

このアプローチのデメリットは、カスタムのシーンのセットアップと、完全に移動可能なダイナミックなコンテンツおよびライトが必要なことです。

制限事項

物理カメラには、モーション ブラーを伴う LED ウォール コンテンツのキャプチャに根本的な制限事項があります。

たとえば、移動している実物の車両のカメラがワールド内の固定されたスポット (車両が通り過ぎていく標識など) を追跡するためにパニングしたとすると、実世界ではキャプチャされた映像にブラーは生じません。LED ステージでは、どのような場合でもパニングするカメラの表示にブラーが発生するため、これを 行うことはできません。