ノートの端の書き残し

UnityやらC#やら。設計が得意かもしれない。

UE5機能別サンプルを見る Niagara②

nigiri.hatenablog.com

の続きです。ただサンプルを見ていくだけの続きなのでそれほど関連はありませんが。

UE5.1.0
レベル:Nagara_Particles

Simple_GPU_System

カラフルな粒子がファサーッと広がるシステム。

エミッタのプロパティにある黄色いGPUアイコンに注目してください。このアイコンはエミッタが GPU モードであることを知らせます。

たとえば、GPU コリジョンGPU のほうが高性能ですが精度が低く、また特定のレンダラー(たとえばライトレンダラーや リボンレンダラー)は現在 CPU のみとなっています。

GPU シミュレーションの利点は、パーティクル数が多くても GPU で十分処理できることで、欠点は、すでに GPU に大きく依存している場合、代わりに CPU でパーティクルのシミュレーションを行うことが望ましい場合があることです。

さらに

また、PARTICLEスクリプト(緑色の2つのSpawnとUpdateセクション)だけがGPUで実行されることも注目すべき点です。

システムおよびエミッタスクリプト(上記のオレンジと青のシステムおよびエミッタセクション)は、CPUのみで実行されるため、CPUフレンドリーな操作のみに制限されます。例えば、システムおよびエミッタスクリプトはテクスチャをサンプリングしたり、シーン距離フィールドをクエリすることはできません。

パフォーマンス

実際のところエミッタのプロパティからCPUモードに変えてもこのパーティクルの見た目はあんま変わりません。

Niagaraシステムエディタの上部に「パフォーマンス」という項目があるので、それを押すとエミッタ上にパフォーマンスが表示されるようになります。

このNiagaraの場合、GPU設定の方がパーティクル更新が100倍くらい速いことがわかりますね。環境やエミッタの中身次第なところはかなりあると思いますが。

特徴的なモジュール

GPUの話は置いておいて、このNiagaraシステムで見るべきモジュールは

  • エミッタの更新
    • Spawn Burst Instantaneous: 同時にブワッと大量の粒子を出す設定。
  • パーティクル更新
    • Curl Noise Force: Curl Noise(パーリンノイズみたいな連続的なノイズの一種)に従って、座標ごとに粒子に力を加える。風の影響のシミュレーションに最適なノイズと計算なので、こういうファサーッと粒子が広がるシステムにはこれですね。
    • Drag: 速度を漸減させる。今回のケースだと、これが無いと粒子が広く広がりすぎる。
    • Point Attraction Force: 中心に粒子を集めるような力を加える。今回のケースだとDragと似たような役割か?
    • Color: Scaleではない。今回はキーにパーティクルの正規化寿命を取って色を決めてる。色を変えるだけでも何種類かモジュールがある。

SpriteFacing_System

球面にSpriteが貼りついている、ミラーボール?みたいなNiagaraシステム。

Particles.SpriteFacingはパーティクルがどの方向を向くかを制御するベクター変数です。ここではパーティクルと球の中心を結ぶベクトルを作成し、そのベクトルに対してパーティクルの向きを合わせています。 Particles.SpriteFacing と Particles.SpriteAlignment はシミュレーションの座標空間に関係なくワールドスペースのベクトルなので、Sprite Facing and Alignment モジュールは必要に応じて自動的に変換を行います。

さらに

Particles.SpriteFacing は、シミュレーションによって自動的に処理され、特別な意味を持つ唯一のレンダラバインディングではありません。レンダラー(この場合はスタックの一番下にあるスプライトレンダラー)をクリックし、"Bindings "までスクロールダウンします。

パーティクル属性を参照するレンダラーに対して特別な意味を持つパーティクル属性のリストが表示されます。必要に応じて、それぞれを他の属性で上書きすることができます。

パーティクルのパラメータは色々あって、今はSpriteの向きを意味する変数をいじってるよ、ということですね。

特徴的なモジュール

  • パーティクル更新
    • Sprite Facing and Alignment: 名前の通り、Spriiteがどっち向くか。今回のケースでは、ベクトルの引き算で、各粒子からアクタ自身の座標に向いたベクトルを方向にしていますね。コメントにもありますが、この「アクタ自身の座標」はワールド座標で、アクタが動くと変な動きになります。(こんなブログ読んでないで自分で動かしてみよう!)
    • Vortex Velocity: 渦のような動き。そのままですが、どこか中心を決めて、中心の周りを回るような動きに向いたモジュールです。

Blend_Attributes_System

Transient変数は与えられたスタックコンテキスト(Particle Updateなど)に対してのみローカルで、毎フレームゼロから再計算され、フレームからフレームへの値の持続はありません。このため、パーティクルのペイロードに保存され、フレームからフレームへ持続するパーティクル変数とは異なり、メモリとパフォーマンスのコストが発生します。

ここでは、エミッタの原点からの現在の距離を表すトランジェント変数を作成し、それを使って色とスケールのカーブを駆動しています。

要するに、毎フレーム計算しなければいけない値があって、且つ、その値を複数のモジュールで使うなら、1度だけ計算してキャッシュしてそれを使いまわそう、という話ですね。パフォーマンスの話。

特徴的なモジュール

無し!
ただ、モジュールは上から順番に計算されるので、今回のケースだとColorとSprite Size Scaleの上に一時変数の設定モジュールを置く必要があるのが注意でしょうか。順番が不正だとコンパイルが通りません。