【CEDEC2025】『鉄拳8』Unreal Engine 5 Niagaraによる開発事例と最適化 ～60FPSを守る～

「鉄拳８」VFX開発におけるNiagaraモジュールの実装事例と
膨大なアセットを扱いながら60FPSを維持するためのNiagaraの最適化事例について紹介します。

Niagaraを使って実現可能な表現や、モジュールを拡張実装した具体的な実装例も紹介します。
その中で、60FPSを下回らないためにNiagaraで行った最適化についても紹介します。

※本セッションはUnrealEngine5.2 を利用した事例になります。

Transcript

1. 『鉄拳8』Unreal Engine 5 Niagaraによる開発事例と最適化 ～60FPS を守る～ 株式会社バンダイナムコスタジオ テックスタジオ第１グループ制作１部プログラム１課 木下 領太 TEKKEN 8 & ©Bandai Namco Entertainment Inc.
2. 本公演は写真撮影、SNS投稿可です。 スライドは後日公開予定です。
3. 本スライドはUnrealEngine5.2.1 での内容です。 また、Cascadeの内容は含まれませんのでご了承ください。
4. よろしくお願いします。 株式会社バンダイナムコスタジオ / エンジニア 木下 領太（きのした りょうた） 1999年生まれ。北海道紋別市出身。 2019年に株式会社バンダイナムコスタジオに新卒入社。 「鉄拳８」開発チームで主にNiagaraを利用した リアルタイムVFXのテクニカルサポートや最適化を従事。 ◆鉄拳８で主な使用キャラ アリサ＆ザフィーナ（最高段位は鉄拳王） 自己紹介 https://mombetsu.jp
5. 概要 • リアルタイム破壊表現を物理破壊プラグインを使わずNiagaraで表現した方法 • Niagaraモジュールの実装事例紹介 • 実際に導入しているNiagaraの最適化手法 • まとめ
6. リアルタイム破壊表現を物理破壊プラグインを使わず Niagaraで表現した方法
7. リアルタイム破壊表現を物理破壊プラグインを使わずNiagaraで表現した方法 鉄拳８は“全力”ｘ”破壊“をコンセプトとして掲げています。 しかし、“破壊”を表現するためのリアルタイム破壊は非常に重く、本作では60FPS厳守という大きな課題があります。 そのため、軽量でリアルタイムの破壊表現を行える方法をいくつか検証しました。 大きな課題 60FPS厳守 コンセプトを 満たせる 軽い破壊表現
8. リアルタイム破壊表現を物理破壊プラグインを使わずNiagaraで表現した方法 イマイチ… プラグインの検証 APEX Chaos 5.0EA 4.27 4.26 β版 非推奨 5.0～ 不安定? APEX Chaos その他 ？ 当初の開発環境は、Unreal Engine 4.27～5.0(EA)の間で、リアルタイム破壊をどのプラグインを利用するか 検討していました。 どれかを選定する必要がありましたが、検証の結果どちらも将来的に不安定であることが判明しました。 ・Apex Destruction →UE5.0以降はサポート対象外 ・Chaos Destruction →β版で負荷が高く、さまざまなアセットの置き換えが必要
9. リアルタイム破壊表現を物理破壊プラグインを使わずNiagaraで表現した方法 壁やビルなどの破壊はアニメーションで表現可能なため、リアルタイム破壊が必要なケースは限定的でした。 鉄拳８では床を破壊した時に発生する破片をメインにリアルタイム破壊を採用しています。 ◆採用理由 ・厳密にオブジェクトが成形された状態から破壊するケースが無い ・Niagaraの動きで表現を担保できている ・処理負荷が比較的軽い Niagaraを破壊表現に採用 実際の破壊の様子。煙+デカール+破壊Niagaraで構成 破壊Niagaraがキャラと接触して動いている様子
10. リアルタイム破壊表現を物理破壊プラグインを使わずNiagaraで表現した方法 Niagara Parameter Collectionを使用し、 プレイヤーの判定情報を改良したPoint Force系のモジュールに渡して制御しています。 主な物理挙動はNiagaraのCollisionモジュールで動作し、サイズや質量などの情報はHCSVファイルで管理。 めり込みなどの挙動安定化のために一部モジュールの改造を行っていますが、 基本的な挙動はNiagaraのみで実装可能です。 破壊Niagara概要 形成されたモデルからの破壊と断面のサンプル
11. リアルタイム破壊表現を物理破壊プラグインを使わずNiagaraで表現した方法 HoudiniのFractureノードを使用して、事前にモデルを分割し、破片１つをそれぞれのフレームへ原点配置します。 その後、改造したFluidのVATノードを利用して、各種データを書き出します。 - U: 各種頂点の情報 - V: 破片のIDとして利用（通常はアニメーションフレーム） Niagara ROP より、HCSV(hjson)に各破片ごとに次の情報が書き出されています。 - 破片ID / 位置 / 質量 / コリジョン形状 など 破壊Niagaraのデータ構造 分割 原点に集める 破片の中心座標とID 破片をアニメーションフレームに割り振り （ID＋座標）＋（コリジョン形状＋質量）をマージして破片ごとに設定 頂点情報 破 片 ID UV 破 片 ID 断面UVマスク 破 片 ID
12. リアルタイム破壊表現を物理破壊プラグインを使わずNiagaraで表現した方法 Houdini Niagaraプラグインを有効化後、 HCSVをインポートするとHoudini Point Cache Assetとして読み込みが可能になります。 各種アセットをインポートした後、Fluid VAT用のマテリアルを構築してモジュールでHSVの読み込みを行います。 その後、Dynamic Material Parameterを使用して、 UVのVにIDを渡すことで、破片IDごとに異なるモデルの形成が行われます。 Niagaraとの連携 破 片 ID HSVから位置を読み込む ParticleのIDをVとして割り振り
13. リアルタイム破壊表現を物理破壊プラグインを使わずNiagaraで表現した方法 実際には形成されたモデルから破壊するようなケースはアニメーションで可能なため、 主に以下の２パターンで利用しています。 Houdini側はモデルと分割数を指定するだけのテンプレートを作成し簡単に出力できるようにしています。 実際のリアルタイム破壊の利用箇所 ＋ ＋ VAT Houdiniで破片を作成してVATとHCSVで構成 Houdiniでモデルの分離を行ってVATとHCSVで構成 ＋ ＋ VAT
14. リアルタイム破壊表現を物理破壊プラグインを使わずNiagaraで表現した方法 GENMAJI TEMPLEで落ち葉の数を５倍にした場合 ※実際のゲームとは異なります 挙動を利用した応用編 Niagaraで完結できるようにキャラクターとのインタラクションの仕組みを作成できるため、応用が可能です。 Niagara Parameter Collectionをモジュールに接続するだけで、VATやHCSVは必要ありません。 破片はPoint Forceで動かしていましたが、落ち葉に関しては、追加でカールノイズと上方向への加速度の補正をし ています。
15. Niagaraモジュールの実装事例紹介
16. Niagaraモジュールの実装事例紹介 • ゲームスピードに応じたパーティクルの形状変化 • ゲームスピードに応じたパーティクルの制御 • 遮蔽可能なレンズフレアパーティクル • パーティクル空間の切り替えを、Niagara側で切り替える手法 • 番外編（Niagaraのシェーダー改造） • メッシュ空間の１軸を固定するメッシュビルボード表現
17. Niagaraモジュールの実装事例紹介 ゲームスピードに応じたパーティクルの形状変化 激しい雨をパーティクルで表現する際、細長いパーティクルを使用しています。 しかし、スーパースローで再生すると、細長い形状が際立って悪目立ちすることがありました。 これを解決するためにゲームスピードを取得し、マテリアルや形を自動で切り替えることで、リアルな雨粒に近 い表現を行いました。 形状やレンダラーが速度によって変わる様子 雨の形がリアルタイムに線から粒に変化
18. ゲームスピードに応じたパーティクルの形状変化 モジュール紹介 Delta Time （ゲームスピード）を任意のスケールで0~1に変換し、Lerpで各種パラメータに渡しています。 Floatの値がDynamic Inputの出力されるだけなので、スプライトサイズやVisibility Tagによるレンダラーの変 更など様々な箇所で利用可能です。 このようにNiagaraは任意の値を渡すことによって多様な表現が可能です。 RenderのVisibilityを変更する場合 スプライトサイズを変更する場合 60FPS固定なので1/60で0~1に変換
19. Niagaraモジュールの実装事例紹介 ゲームスピードに応じたパーティクルの制御 速度を好きな倍率で制御できる様子 ゲームはスロー状態ですが、エフェクトは通常速度で再生 演出でスローがかかる場合、エディターと実機の画面で乖離が発生し、調整が難しくなります。 エフェクト側で受け取るDelta Timeを一定の速度に設定することで、調整＋作業を行いやすくしています。 また、ヒットストップなど瞬間的に強いスローがかかる場合、見た目が過剰に停止し、意図しない絵崩れが起きること があります。 このような場合も、速度の下限値を設定することで、受け取るスローの強度を抑えることができます。
20. ゲームスピードに応じたパーティクルの制御 Delta TimeをInputに出して変更できるように改造 Particle側でDelta Timeを利用しているモジュールにも適応 モジュール紹介 Niagara Parameter Collectionに設定したゲームスピード(0.0~1.0)を使って２パターン出力できるよう設計してい ます。 1. NiagaraのDelta Timeの変動値をゲームスピードで相殺し、スローを無視した通常速度のDelta Timeを生成。 2. NiagaraのDelta Timeの変動値をゲームスピードで相殺し、任意の範囲でClampした速度のDelta Timeを生成。
21. Niagaraモジュールの実装事例紹介 遮蔽可能なレンズフレアパーティクル 実際に光が溢れているような疑似レンズフレアエフェクトの表現方法です。 マテリアルのDepth Testをオフにして常に最前面で表示しています。 角度や遮蔽物の判定をモジュールで実装し、テクスチャの切り替えやAlpha濃度を調節しています。 角度制限 or ２か所隠れると消える URBAN SQUARE（夜）のパトカーのヘッドライトがマントで遮蔽される様子
22. 遮蔽可能なレンズフレアパーティクル モジュール紹介 G BufferのDepth情報を利用してカメラ位置と判定位置の距離を比較し、深度チェックを複数のポイントで行っ ています。 また、エンジンの軸変数を使うことによって、任意の軸とカメラ方向に基づく角度判定もモジュール内で実装可 能です。 実際に判定を行っているモジュール例。出力されるBool値を利用してAlphaなどを切り替える
23. Niagaraモジュールの実装事例紹介 パーティクル空間の切り替えをNiagara側で切り替える手法 腕の青いスプライトが途中で追従を解除しています。 座標と回転がLocal⇔Wordになる様子 Niagara側でキャラクターのボーンへのアタッチとデタッチをEmitter単位で制御する方法です。 これにより、アーティストの都合に合わせて調整が可能となり、工数の削減や表現の幅が広がります。 また、一部のパーティクルだけ分離させたい場合など、システム本体のデタッチを行いたくない場合に有効です。
24. パーティクル空間の切り替えをNiagara側で切り替える手法 モジュール紹介 LocalからWorldへ変更 ローカルからワールド空間への切り替え計算で行っています。カーブを使用してタイミングを調整しています。 切り替える直前のPosition、Rotation、Matrixを保存し、位置と回転を再計算して変数に適用しています。 切り替える直前までの情報を保存 座標と回転の再計算と適応
25. 番外編（Niagaraのシェーダー改造） メッシュ空間の１軸を固定するメッシュビルボード表現 Camera Facing時のメッシュパーティクルではシステムの向きでの軸固定しか実装されていません。 FINAL FANTASY XVIの原作再現のためメッシュパーティクルの一定軸のみ固定する機能をエンジン改造で実装しました。 スプライトよりも立体感が増し、１軸が固定されているのでカメラを回転させたときによるフリップ現象が抑えられます。 クライヴのエフェクト表現で主に利用 追加 エンジンのEnumを拡張
26. メッシュ空間の１軸を固定するメッシュビルボード表現 デフォルトだとシステムの軸方向でしか固定できず、カメラによって形状が崩れてしまいますが、 パーティクルのメッシュ軸が基準になるので、全体の形状変化やフリップを抑えることができます。 軸固定の比較 デフォルトのシステムZ軸固定 改造したメッシュZ軸固定
27. メッシュ空間の１軸を固定するメッシュビルボード表現 NiagaraMeshRendererProperties.h enum class ENiagaraMeshLockedAxisSpace ~~ Local_Mesh_X, // X軸固定 Local_Mesh_Y, // Y軸固定 Local_Mesh_Z, // Z軸固定 NiagaraMeshParticleUtils.ush #define PARTICLE_SPACE_MESH_LOCAL_X 3 ~~ NiagaraMeshParticleSRTParams Params.LockedAxisSpace if (Params.LockedAxisSpace == PARTICLE_SPACE_MESH_LOCAL_X)など Niagaraのエンジン改造部分の紹介をします。EnumとShaderの構造体の関係性です。 エンジンコードはDefineの値とEnumの値を比較しているので、以下のコードを拡張しています。 実装紹介
28. メッシュ空間の１軸を固定するメッシュビルボード表現 NiagaraMeshParticleUtils.ush float3x3 NiagaraGetMeshFacingMatrix(FLWCVector3 ParticleSimPosition, NiagaraMeshParticleSRTParams Params, float4 rotation) Const float4 rot = normalize(rotation); ~~ 式省略 ~~ 以下３つはParams.LockedAxisSpaceで分岐する LockedAxis = float3((1.0f - (yy + zz)), (xy + wz), (xz - wy)); // X軸固定 LockedAxis = float3((xy - wz), (1.0f - (xx + zz)), (yz + wx)); // Y軸固定 LockedAxis = float3((xz + wy), (yz - wx), (1.0f - (xx + yy))); // Z軸固定 ~~ LockedAxis = NiagaraWorldToLocalVec(LockedAxis, Params);// 通常 NiagaraMeshParticleSRT NiagaraCalculateMeshParticleSRT(NiagaraMeshParticleSRTParams Params) if (Params.LockedAxisSpace == PARTICLE_SPACE_MESH_LOCAL_X ~~) SRT.Rotation = mul(FacingMat, NiagaraQuatTo3x3(Params.MeshRotation));// メッシュ軸固定の場合 else SRT.Rotation = mul(SRT.Rotation, FacingMat); // 通常 Enumで追加された分岐とメッシュの回転情報はShaderで計算しています。 LockedAxisでシステムの回転情報を渡している箇所の条件を分岐させてメッシュの回転情報を渡すように変更しました。 Rotation→Vectorに変換するモジュールと同じ計算 実装紹介
29. 実際に導入しているNiagaraの最適化手法
30. 前提として
31. 実際に導入しているNiagaraの最適化手法 GPU負荷のレギュレーション おおよそ4.0msがエフェクトの半透明や演出のライトで利用することができる負荷になっています。 60FPS厳守＋固定フレームレートなので、0.1msのオーバーも許容できません。 キャラクター 背景 ライト 16.6ms 4.6ms エフェクト 演出ライト 12ms 屋久島など背景に常に半透明がある場合はより厳しくなる
32. 実際に導入しているNiagaraの最適化手法 • 背景エフェクトのEmitter数の削減 • 同じNiagaraを対戦に影響なく大量に発生させるための最適化 • 呼び出しフレーム分散する • PSOCache • その他の最適化項目
33. 実際に導入しているNiagaraの最適化手法 背景エフェクトのEmitter数の削減 複数同じNiagaraを設置する場合、１つのシステムまとめるとEmitter数が大きく抑えられます。 この手法は、 Emitter数が多ければ多いほど効果的で、CPUやDraw負荷対策になります。 システム１２個と１個の比較。2倍近く負荷が削減されている
34. 背景エフェクトのEmitter数の削減 UserParameterとPartitionParticleの活用 UserParameterに座標を管理する配列を変数として登録することで、モジュールで読み取ることが可能です。 ブループリントやレベル上で変数の値を直接指定できるほか、モジュールを利用して配列の要素数を取得するこ とも可能です。 ～～ カスタムモジュールで配列サイズを取得
35. 背景エフェクトのEmitter数の削減 UserParameterとPartitionParticleの活用 配列サイズを利用して、パーティクルのSpawn数にスケールをかけて１つのEmitter内で完結できるようにします。 パーティクルを分割するグループ属性(Partition Particle)を付与し、それを元に配列のIndexにアクセスして座標 を適応しています。 PartitionのIdで配列にDirect Setし、発生座標を移動させている Particles Per Partitionで何パーティクル毎に分割するか設定
36. 実際に導入しているNiagaraの最適化手法 同じエフェクトを対戦に影響なく大量に発生させるための最適化 相手を壁に貼り付けて連続ヒットさせている様子。同じNiagaraのインスタンスがヒット毎に発生しています。 （ヒットエフェクト＋壁ヒットエフェクト）ｘ８回
37. 同じエフェクトを対戦に影響なく大量に発生させるための最適化 負荷がかかりやすい状況 NiagaraComponent生成 Emitter生成 Particle生成 Emitter生成 Particle生成 Spawnを呼ぶたびに同じ構成のNiagaraが新規で生成されるため、ComponentやEmitterの初期化に負荷がかかります。 さらに、Emitter数も増加するため、CPU負荷が非常に高まり、処理落ちやヒッチが発生しやすくなります。 x 呼び出し数分増える Call Count IncAvg IncMax ExcMax ExcAvg Stat NiagaraSystems
38. 同じエフェクトを対戦に影響なく大量に発生させるための最適化 （ヒットエフェクト＋壁ヒットエフェクト）ｘ８回 Niagaraを使いまわして呼び出している様子。全てWorldパーティクルのためシステムが移動しても問題ありません。 最適化した場合
39. 同じエフェクトを対戦に影響なく大量に発生させるための最適化 初期化と持続負荷の軽減 AutoDestroyで消える前に同じインスタンスが呼ばれた場合、位置を更新して再度アクティブ化させています。 これにより、Emitterの数を1つに抑えられ、初期化コストや持続的な負荷を大幅に軽減できます。 Call Count IncAvg IncMax ExcMax ExcAvg Stat NiagaraSystems 初回のみComponent類を生成 SetActiveでRespawn
40. 実際に導入しているNiagaraの最適化手法 同フレームで複数のNiagaraが呼ばれる場合、ヒッチが起きないように分散させています。 ユーザーの体験を損なわないよう、状況確認が必要な順番で発生させています。 また、Niagara内でも１フレームでのパーティクル発生数を抑えるために、パーティクルの発生も分散する工夫を 行っています。 呼び出しフレーム分散する 強ヒット キャラエフェクト カウンターヒット レイジ状態開始 レイジオーラ 呼び出し順
41. 実際に導入しているNiagaraの最適化手法 同フレームで複数のNiagaraが呼ばれる場合、ヒッチが起きないように分散させています。 ユーザーの体験を損なわないよう、状況確認が必要な順番で発生させています。 また、Niagara内でも１フレームでのパーティクル発生数を抑えるために、パーティクルの発生も分散する工夫を 行っています。 呼び出しフレーム分散する 強ヒット キャラエフェクト カウンターヒット レイジ状態開始 レイジオーラ 呼び出し順 1 2 3 4 5
42. 実際に導入しているNiagaraの最適化手法 PSOCacheのみだとヒッチに対する効果が少々不足していたため、PSOPreCacheを併用して実装しています。 PSOCache Niagaraのみ発生するレベルを作成してPSOを収集しています。その後、PSOを変換してパッケージに含め、 起動時にコンパイルを実行しています。 PSOPreCache UPrimitiveComponent を対象に、PostLoad の実行中にPSOを事前にキャッシュします。 UE5.3以降は更に機能が向上しています。 PSOCache r.PSOPrecache.ProxyCreationWhenPSOReady →描画がかなり遅延するのでオフにしています。 fx.Niagara.Emitter.ComputePSOPrecacheMode →Emitterが完了するまで描画を待ちます。動作優先 ▪PSOPreCache実装例 参考：The Matrix Awakens: An Unreal Engine 5 Experience WindowsEngine.ini r.PSOPrecaching=1 r.PSOPrecache.Resources=1 r.SkipDrawOnPSOPreCaching=0 r.PSOPrecache.ProxyCreationWhenPSOReady=0 r.pso.PrecompileThreadPoolPercentOfHardwareThreads=7 5 r.PSOPrecache.GlobalComputeShaders=1 r.ShaderPipelineCache.BatchSize=35 r.ShaderPipelineCache.BatchTime=14.0f fx.Niagara.Emitter.ComputePSOPrecacheMode=3 Niagaraを発生させてPSOCacheを収集するレベル
43. 実際に導入しているNiagaraの最適化手法 その他Niagaraの最適化項目 • シーケンサーでNiagaraを利用する際の注意事項 • 半透明パーティクルの負荷の影響について • 最適化をチェックするフローおいての確認環境の重要性
44. その他Niagaraの最適化項目 シーケンサーでNiagaraを利用する際の注意事項 シーケンサーにSystem Life Cycleを追加した場合、ForceSoloModeがOn（非同期が解除）になり、 CPU負荷が増加します。 Spawnedで発生タイミング調整のみ行い、UpdateはNiagara側で動作させることで負荷削減になります。 非同期が解除され、ゲームスレッドに大きく負荷がかかっている様子
45. その他Niagaraの最適化項目 半透明パーティクルの負荷の影響について 半透明はエフェクトの最適化項目として必ず通らなければなりません。 よくある負荷原因に加えて、Niagaraならでは可能な最適化手法を紹介します。 どうして… Base Pass Lights Translucency Post Process Scene Frame Shader 持続時間 10.0ms 24.6ms ！ ！ ！
46. 半透明パーティクルの負荷の影響について テクスチャ解像度の最適化 テクスチャ解像度はGPU負荷に大きく影響するため、最優先で最適化すべき要素です。 どのようなパーティクルでも、解像度を最小限に抑えることでパフォーマンスを向上させることができます。 また、解像度が高くインポートされたテクスチャは、テクスチャエディターの設定を使用して解像度を下げることも可能です。 128x128 16x16 距離フェードで消えるので高解像度は不要 元素材の修正をせず、解像度だけ下げれる便利機能
47. >半透明パーティクルの負荷の影響について Distance Cullingでの最適化 鉄拳８では、画面のチラつきを防ぐため、基本的にカメラが近距離の場合はMaterial側でAlphaフェードを行っています。 しかし、半透明の描画は常に行われているため、画面に見えていない状況でもGPUに負荷がかかります。 そこで、NiagaraのRenderer側で一定距離のパーティクルを完全に描画非表示にすることで、半透明のGPU負荷を大幅に 軽減しています。 Alphaフェードのみだと無駄な負荷がかかる Distance Cullingで完全に描画削除 ストーリーモードのGENMAJI TEMPLEステージ デフォルトは無効化状態で 最小距離と最大距離を設定することができます。 =
48. 半透明パーティクルの負荷の影響について メッシュとマテリアルの最適化 Mesh Rendererで利用するStatic MeshはLODが使用できないため、大量のパーティクルを生成するとGPU負荷が上 昇しやすいです。 また、Two Sidedを設定したMaterialは、頂点数が実質的に2倍になるため取り扱いの注意が必要です。 基本的には、頂点数やパーティクル数を減らし、不必要なパーティクルの重なりを軽減して最適化します。 TwoSide:On Alpha:0.05 TwoSide:Of f Alpha:0.1 薄い半透明メッシュが多数描画されることで処理負荷が高くなる例。TwoSideがオンになっており、追加で枚数やAlpha濃度を調整することで解決
49. その他Niagaraの最適化項目 最適化においての確認環境の重要性 キャラクターやステージの切り替え、モーション再生など、開発初期では負荷確認に多くの時間とコストがかかって いました。 そこで、事前に一定の最適化とレギュレーションを適応できるよう、エフェクトの単体確認環境を用意しています。 エフェクト実装 ROM確認 アセット確認 最適化FIX 開発初期 負荷計測 最適化 レギュレーション確認 NG OK アセットを検索・確認 エディタでゲーム確認 VFX班へ修正依頼 GPUProfilerで計測 アセットと原因の特定 エフェクト実装 最適化FIX 確認環境実装後 ROM確認 負荷計測 アセット単体確認 最適化 レギュレーション確認 NG OK GPUProfilerで計測しな くても、基準値内かどう かある程度判別可能に！ アセットをツールで確認 VFX班へ修正依頼 COST
50. 最適化においての確認環境の重要性 エフェクト単体確認環境 事前にエフェクトの負荷や構成を一定のレギュレーション内に抑えられるよう、 テクスチャ解像度やメッシュの頂点数、モジュールの負荷、半透明負荷など確認することができます。 さらに、スケーラビリティによる比較、アセットOpen機能、NiagaraDebuggerの機能を呼び出しなど迅速な確認・修正が可能です。 一部の機能紹介。複数のスケーラビリティは混在できないので、パーティクル数のみ変化
51. 最適化においての確認環境の重要性 エフェクト単体確認環境 他にもキャラクター、ステージ、カスタマイズなど、ジャンルごとに確認できるように拡張し、大幅な業務効率 化を実現できます。 UMGでの実装は非常に簡単で、視覚的にわかりやすい確認環境を作成できるため、おすすめの機能です。
52. まとめ
53. まとめ まとめ • Niagaraでも疑似的な物理表現が可能であり、パフォーマンスも良好。時と場合で選定 • モジュールをフルに活用したNiagaraは様々な表現を追求でき、拡張性が非常に高い • 負荷のレギュレーションは職種問わずプロジェクトとして、共通認識であることが大切 • 最適化をサイクルさせるための環境整備は怠らない。運営型タイトルではより必須 Chaos
54. ご清聴ありがとうございました！
55. 質疑応答