待望のUE4新機能 ナイアガラでプログラマブルVFX
•
16 recomendaciones•9,770 vistas
2018年7月13日に行われた「GTMF 2018 TOKYO」で登壇した際に使用した資料です。 https://gtmf.jp/2018/
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a 待望のUE4新機能 ナイアガラでプログラマブルVFX
Similar a 待望のUE4新機能 ナイアガラでプログラマブルVFX (20)
Más de エピック・ゲームズ・ジャパン Epic Games Japan
Más de エピック・ゲームズ・ジャパン Epic Games Japan (20)
待望のUE4新機能 ナイアガラでプログラマブルVFX
- 5. なぜVFXのシステムを 作り直す必要があるのか？ デザインの考え方 ● Unreal Engineは幅広く色々な 業界に使用されている ● 様々な専門家も増えている ● 「我々は全てが分かる訳ではない」 ● 時は金なり
- 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） ● パーティクルのデータは「パラメータマップ」 にすべて保存されている ● すべてが任意になる
- 13. デザインの考え方 たくさんのデータを どのように公開するのか？ ● 大きい議論：グラフ vs スタック ○ UE4内で両方が使用されている ○ グラフは完全にコントロールができる ○ スタックはモジュール化されたビヘイビアを 使えて、読みやすい ○ Niagaraでは、グラフとスタックのハイブリッドを 採用した
- 14. デザインの考え方 モジュール → エミッタ → システム モジュール 基本データ ビヘイビア お互いにスタック可能 「関数を書く」 エミッター モジュールのコンテナー 一つの役割、再利用可能 モジュールのパラメータを ここで変更可能 システム 一つの「エフェクト」として 複数のエミッターを含む 全てオーバーライド可能
- 15. デザインの考え方 モジュール → エミッタ → システム モジュール 基本データ ビヘイビア お互いにスタック可能 「関数を書く」 エミッター モジュールのコンテナー 一つの役割、再利用可能 モジュールのパラメータを ここで変更可能 システム 一つの「エフェクト」として 複数のエミッターを含む 全てオーバーライド可能
- 16. モジュールとモジュールのフロー
- 17. モジュールとモジュールのフロー
- 18. モジュールとモジュールのフロー
- 19. モジュールとモジュールのフロー
- 20. モジュールとモジュールのフロー
- 21. モジュールとモジュールのフロー
- 25. エミッターのスタック
- 26. エミッターのスタック
- 27. エミッターのスタック
- 28. エミッターのスタック
- 29. システムのスタック システム vs. エミッター ● エミッターはシステムを構築する パーツです ● システムはユーザーが定義できる グローバル変数を持っていて、システムの 中にあるすべてのエミッターがそれに アクセスできる ● システムは、シーケンサーを利用して エフェクトのタイミングをコントロールする （ループ、バースト、生成）
- 30. システムのスタック
- 31. システムのスタック
- 32. システムのスタック
- 33. システムのスタック
- 35. オーバーライド（継承） オーバーライド（継承） ● Cascadeのワークフローでは無駄な 作業があった ● 既存のアセットを使い回せないので、 新しいアセットを作る必要があった ● Niagaraでは、すべてをオーバーライド （継承）可能にした
- 37. オーバーライド（継承） 計算式 ● すべてのパラメータがHLSLに 変換されるので計算式も使える ● 様々なネームスペース（パーティクル、 エミッタ、システム）にアクセスができ、 HLSLやVMの関数も利用できる ● 新たにモジュールを作るまでもない 小さな機能を実装するときに便利
- 38. デモ：モジュラーの爆発
- 39. イベント イベント ● データ（Struct）を他のエミッタに渡すことができる ○ IDを使って一つのパーティクルを対象にする ○ システムのすべてのパーティクルを対象にする ○ 新しいパーティクルを生成させて、カスタムなアクションを 起こす
- 40. イベント
- 42. データのインターフェース データの インターフェース ● 任意データへアクセスするための 拡張可能なシステム ● メッシュデータ、オーディオ、 外部のDCCの情報、コードの オブジェクト、テキストの コンテナーなど ● 将来的に、プラグイン化でさらに 柔軟になる予定
- 43. データのインターフェース
- 44. データのインターフェース
- 46. 将来の作業 これからの予定 ● カスタマイズ可能なモジュールのライブラリーを 提供する ● UE4の他の機能や外部のソースからデータを得る ために、新しいデータインターフェースを追加する ● スケーラビリティーとデバッグのためのツールを 増やす