1.
プログラマブル VFX
待望のUE4新機能ナイアガラ

2.
Rob
Gray
Developer Relations
Technical Artist

3.
UE4のNiagaraは
4.20でアーリーアクセス！

4.
Niagaraって何?
Unreal Engine 4の
次世代VFXツールセット
デザインの考え方
システムのヒエラルキー
新しいVFXのワークフローと
パラダイム
UI/UXのショーケース
コンテンツの事例

5.
なぜVFXのシステムを
作り直す必要があるのか？
デザインの考え方 ● Unreal Engineは幅広く色々な
業界に使用されている
● 様々な専門家も増えている
● 「我々は全てが分かる訳ではない」
● 時は金なり

6.
デザインの考え方
Cascade:
以前の
パラダイム

7.
デザインの考え方
Cascadeの 利点
○ ビヘイビアをモジュールとして簡単に
追加できる。モジュールはレイヤー、
スタック、インタラクションが可能
○ コードなど分からなくても標準の
ビヘイビアのライブラリーを利用して
エフェクトが作れる
○ スタックの表示が読みやすい

8.
デザインの考え方
Cascadeの 欠点
○ 固定された関数とハードコード化
○ 新しい機能を追加するにはコードが
必要で、パーティクルの負荷が重くなる
○ データ共有はほぼ無理
○ イベントは限られていて使いにくい
○ CPU と GPU のシミュレーションは
大分違う

9.
理想的なシステムは？
● アーティストがすべてをコントロールできる
● 全部がプログラム、カスタマイズ可能
● デバッグ、ビジュアライゼーション、
パフォーマンスのための良いツールが
提供されている
● UE4の他の機能だけでなく、外部の
ソースからの任意データに対応している
やりたいことを邪魔しない
デザインの考え方

10.
データ共有から始まった
● すべてをコントロールするために
データへのアクセスが重要
デザインの考え方
Actor position, delta time, emitter orientation, transforms, loop count, normalized and unnormalized
age, distance to camera, number of particles, execution index, number of instances, XYZ axis
values, owner velocity, loop delay, execution state, system time, collision queries, other particle
positions, velocities, transforms, color, scale, mesh bone or vertex velocities, vertex colors, the list
goes on and on.
すべてを公開する。

11.
デザインの考え方
パーティクルのデータ
● 公開したすべてのパラメータに
アクセスする手段を用意した
● 階層型のデータコンテナーである
ネームスペースを使用した
（例：Emitter.Age、 Particles.Position）
● パーティクルのデータは「パラメータマップ」
にすべて保存されている
● すべてが任意になる

12.
デザインの考え方
任意のデータ
● どんなデータでもパーティクルの
プロパティーとして渡すことが可能です
● 複雑なUstruct、トランスフォームの
マトリクス、Boolのフラグなど、ユーザーは
自由にシミュレーションで利用することが
可能です

13.
デザインの考え方
たくさんのデータを
どのように公開するのか？
● 大きい議論：グラフ vs スタック
○ UE4内で両方が使用されている
○ グラフは完全にコントロールができる
○ スタックはモジュール化されたビヘイビアを
使えて、読みやすい
○ Niagaraでは、グラフとスタックのハイブリッドを
採用した

14.
デザインの考え方
モジュール → エミッタ → システム
モジュール
基本データ
ビヘイビア
お互いにスタック可能
「関数を書く」
エミッター
モジュールのコンテナー
一つの役割、再利用可能
モジュールのパラメータを
ここで変更可能
システム
一つの「エフェクト」として
複数のエミッターを含む
全てオーバーライド可能

15.
デザインの考え方
モジュール → エミッタ → システム
モジュール
基本データ
ビヘイビア
お互いにスタック可能
「関数を書く」
エミッター
モジュールのコンテナー
一つの役割、再利用可能
モジュールのパラメータを
ここで変更可能
システム
一つの「エフェクト」として
複数のエミッターを含む
全てオーバーライド可能

16.
モジュールとモジュールのフロー

17.
モジュールとモジュールのフロー

18.
モジュールとモジュールのフロー

19.
モジュールとモジュールのフロー

20.
モジュールとモジュールのフロー

21.
モジュールとモジュールのフロー

22.
モジュールとモジュールのフロー
最終的に全てはHLSLに変換される

23.
モジュールとモジュールのフロー
最終的に全てはHLSLに変換される
目的：可能な限りCPU
とGPUへ渡すデータの
違いをなくす

24.
モジュールとモジュールのフロー
最終的に全てはHLSLに変換される

25.
エミッターのスタック

26.
エミッターのスタック

27.
エミッターのスタック

28.
エミッターのスタック

29.
システムのスタック
システム vs. エミッター
● エミッターはシステムを構築する
パーツです
● システムはユーザーが定義できる
グローバル変数を持っていて、システムの
中にあるすべてのエミッターがそれに
アクセスできる
● システムは、シーケンサーを利用して
エフェクトのタイミングをコントロールする
（ループ、バースト、生成）

30.
システムのスタック

31.
システムのスタック

32.
システムのスタック

33.
システムのスタック

34.
デモ: モジュール作成と
Attribute Spreadsheet

35.
オーバーライド（継承）
オーバーライド（継承）
● Cascadeのワークフローでは無駄な
作業があった
● 既存のアセットを使い回せないので、
新しいアセットを作る必要があった
● Niagaraでは、すべてをオーバーライド
（継承）可能にした

36.
オーバーライド（継承）
オーバーライド（継承）
● システムですべてのパラメータを
オーバーライドできる。新しい
モジュールを追加でき、
無効化もできる
● エミッタでも可能です（ループ、
バースト、ライフタイム、生成など）

37.
オーバーライド（継承）
計算式
● すべてのパラメータがHLSLに
変換されるので計算式も使える
● 様々なネームスペース（パーティクル、
エミッタ、システム）にアクセスができ、
HLSLやVMの関数も利用できる
● 新たにモジュールを作るまでもない
小さな機能を実装するときに便利

38.
デモ：モジュラーの爆発

39.
イベント
イベント
● データ（Struct）を他のエミッタに渡すことができる
○ IDを使って一つのパーティクルを対象にする
○ システムのすべてのパーティクルを対象にする
○ 新しいパーティクルを生成させて、カスタムなアクションを
起こす

40.
イベント

41.
デモ： Recursion Examples

42.
データのインターフェース
データの
インターフェース
● 任意データへアクセスするための
拡張可能なシステム
● メッシュデータ、オーディオ、
外部のDCCの情報、コードの
オブジェクト、テキストの
コンテナーなど
● 将来的に、プラグイン化でさらに
柔軟になる予定

43.
データのインターフェース

44.
データのインターフェース

45.
デモ：Character Dissolve

46.
将来の作業
これからの予定
● カスタマイズ可能なモジュールのライブラリーを
提供する
● UE4の他の機能や外部のソースからデータを得る
ために、新しいデータインターフェースを追加する
● スケーラビリティーとデバッグのためのツールを
増やす

47.
将来の作業
これからの予定
● ビューポート内のコントロールや
プログラム可能なウィジット
● Cascadeからの変更ツール

48.
将来の作業
Niagaraを使いましょう！
4.20でアーリーアクセス！
プラグインマネジャーで有効にする

49.
将来の作業
Unreal Japan Stream
毎月の第一木曜日

50.
ありがとうございました！
----------------------------------------------------
Rob Gray
Developer Relations
Technical Artist