Unreal Engine 5 Niagaraにおける実践的な最適化とスケーラビリティ【CEDEC 2023】

そもそもスケーラビリティって何？ 本講演では、スケーラビリティは 処理負荷の制御をデバイスに応じて柔軟に対応す る仕組み、といった解釈

本講演は、「Unreal Engine 5.3」に基づいて解説をしていきます。 内容には5.3から入る機能が含まれておりますので、あらかじめご了承ください。

パフォーマンスチェックリストの活用について 最適化のお話

Niagaraを使ってゲーム開発をしていくにあたって、制作中や制作後に確認を推奨す る項目をまとめたもの、という位置づけ

チェックするものは、大きくは２つに分けられます。 Niagara Systemアセット全体に一律で影響するもの。 それと、各エミッターごとに設定可能なもののパフォーマンスチェックリスト

Niagara EditorのSystem Overviewにある、青色のノード

Niagara Systemが移動しないなら、Require Current Frame DataをOFFにしましょう。

もしNiagara Systemが移動しないなら、「Require Current Frame Data」をOFFにす ることで無駄な計算が減ります。 System Propertiesの中のPerformanceにあります。

比較を用意 たとえば、キャラクターにアタッチされていて腕の上を流れるようにパーティクル を動かしているもの. Require Current Frame DataをOFFにすると、左のほうはわずかに遅れてエフェクト がキャラクターに追従しますので違和感が発生します。 このフラグをOFFにできるかどうかは実際に目で画面を確認して決定するのが良い。 背景に置かれたたき火とか、着弾エフェクトとかはOFFにしやすい。

System Fixed Boundsを確認

バウンズに関して。 このBoundsが画面外に出たときにエフェクトのカリングの処理に入り、負荷軽減が されます。 固定値のほうが余計なバウンズの再計算が入らず処理が軽くなりますので、固定に できるものは固定にしてしまいましょう。

NiagaraエディタでSystemをのぞき込んでください。 BoundsはEmitter単位でも設定可能なのですが、できるだけSytem単位で一括に制御 するほうがカリング計算の負荷が低くなります。 SystemのFixed BoundsがONのときは、EmitterのBoundsは設定できず、無視されま す。個別にBoundsを設定する場合はSystemのFixed Boundsのチェックをはずしてく ださい。

３つめは、Warmupの値を確認

Warmupとは、エフェクトの発生時に任意の時間を空回しした状態でエフェクトをス タートする機能で １フレームでその任意の時間ぶんの計算をするのでけっこう重いです。 無駄に数値が入っていないか確認しましょう。

４つめ。 Effect typeが適切かどうか確認をしましょう。

Effect Typeというのは、Niagara Effect Typeという名前のアセットを指します。 Niagara SystemのSystem PropertiesにあるSystemにセットして使います。 作成中のNiagara Systemアセットの特質に合わせて、このEffect Typeを正しく入れ てあげる必要があります。

Effect Typeアセットは、画面のようにFXのAdvancedの中で作成できます。

デフォルトのエフェクトタイプを設定する場所は、アンリアルエディタのProject Settingsの、PluginsにあるNiagaraの中に見つけることができます。 画面赤枠のところ

そしてEffect Typeの中でValidation Rulesというのが設定できるのですが、Invalid Effect TypeとしておくとNiagaraシステムのほうでエラーを出して製作者に適切なエ フェクトタイプを設定してもらえるよう、気づかせることができます。 Validationについては後ほど.

Effect Typeアセットの中身について。 カリングの際のふるまいやカリング距離設定などをスケーラビリティ込みで設定す る、など。

フォートナイトの例。数値が多いので、一部だけを切り出してみました。 一般的なアーティストはこの中を見ることなく、ファイル名だけで適切なエフェク トタイプを設定できるようにしておくのがよいと思います。

ただ、どのエフェクトタイプにも当てはまらない例外的なスケーラビリティを持っ たエフェクトもあるはず。 そういった場合はそれ専用のエフェクトタイプを作ってもよいのですが、 Niagara Editor内のScalabilityを使うことで、エフェクトごとの設定が可能。 Niagaraアセット内の設定はエフェクトタイプの設定をオーバーライドする形。 Scalabilityに関しては後ほどさらに説明。

Emitterごとのパフォーマンスチェックリスト

EmitterはSystem OverView上にある茶色いやつ

１つめ。 Emitter Stateが不必要に “Self ”に設定されていないか

EmitterのEmitter StateにはLife Cycleを制御する場所がありますが、個別に細かく設 定しなくてよい場合がけっこうある。 例えば、Loop Delayを使っておらずシンプルにバーストや無限ループするエフェク トなど。

個々のエミッターを制御するよりNiagaraシステム全体で制御するほうが軽いので、 一度Systemに切り替えて目でみてみて、変化がないならばLife Cycle ModeをSystem に切り替えてみてください。

Interpolated SpawningがOFFにできるかどうか

各エミッターのEmitter Propertiesの中にあります。 高いスポーンレート、不安定なフレームレート、高速で移動するエミッターに対し て、よりスムーズなスポーンを実現するが、そのぶんのコストがかかる。

動画のように、エミッターの高速移動時、この機能の重要性を顕著にみることがで きる。 このように不適切な見た目を回避することができるので、Interpolated Spawningは ONになった状態のエミッターが多い。 しかし背景に置かれるエフェクトなどはInterpolated SpawningをOFFにできる場合が あるはず。

ただし、エミッターが高速に動いていなくてもOFFにできない場合あり。 「Particle Spawn」のInitialize Particleで設定したパーティクルのサイズや、カラーを 「Particle Update」のScale Sprite SizeやScale Colorモジュールで、カーブなどを使 ってアニメーションする際に、パーティクルの発生時点、つまり時間軸がゼロのと きにInitializeの初期値と一致しない場合 。 画面ではカーブの時間軸がゼロの時点で縦軸の値、つまりスケールがゼロになって いますので、発生時点のサイズと一致していません。 こういったときにInterpolated SpawningをOFFにすると、画面左側にある動画の、右 部分のパーティクルのような、不自然な挙動になります。

逆にいうと、時間軸ゼロのときにParticle Spawnのサイズと一致していれば大丈夫、 ということ。 左側のOFFにしてよいケースでは、時間軸、つまり縦軸がゼロのときのスケールが １でUniform Curve Scaleも1.0ですので、この場合はInterpolated SpawningをOFFに しても不自然なアニメーションにはなりません。

パーティクルが1つしかない場合、Particlesの代わりにEmitterを使用する。

パーティクルの表現をParticle SpawnやParticle Updateを使わずに行う、ということ。 たとえばランプのグローとか１つのスプライトを発生させる場合やライトレンダラ ーを使って１つだけライトを出す場合など、Particleの計算ではなくEmitterとして処 理することで少し軽くなる、というもの。

Emitterの一番下、Renderの項目にあるRendererにこの設定をする場所があります。 このSource ModeのところをParticleからEmitterに切り替えることで、Emitter単位で の制御に切り替わります。

Source ModeをEmitterに切り替えると、レンダラーのバインディングが全てParticles からEmitterに変更されます。 例えば、色を変更したい場合。Particles.Colorという名前のパラメータで色の制御を していたものは、Emitter.Colorというパラメータに対して行うことでスプライトなど の色変更が行われます。

つまり、通常はParticle SpawnやParticle Updateでパラメータ制御をしていましたが、 こんな感じで、Emitter SpawnとEmitter Updateにセットして制御することになりま す。 発生するパーティクルが１つしかないときはEmitterに切り替えるだけで無料で軽く できますので、ぜひご検討を。

４つめ。 位置のアニメーションをしないなら「Solve Forces and Velocity」を使用しない。

エミッターの持つパーティクルがポジションのアニメーションをしないケースは 多々あると思います。 例えばランプの光や何かの表面にただ散乱させているパーティクル、スケールだけ で動きを表現しているものなど。 こういったものはSolve Forces and Velocityモジュールを持つ必要がありません。 これはけっこう忘れがちですが、ちゃんと消しておいたほうがいいです。

パフォーマンスチェックリストの話はここまでで、ここからはエミッターの マージについて

実はNiagaraでのエフェクト作成において、エミッターをマージすることは負荷軽減 に大きな効果を発揮しますので超重要だったりします。 フォートナイトの大きめの爆発エフェクトの例。 左はアクティブになるエミッターの数が１８。それを１１個になるまでマージした 状態が右図。 どのようにマージするかは後ほどお話しますが、まずはその結果から。

アンリアルエンジンにはNiagara Debuggerという、Niagaraエフェクトのさまざまな 情報をリアルタイムに見ることができるツールがあります ほぼ同じエフェクトを出すのに、エミッターをマージするだけでこのような効果を 得られます。

Niagara Debuggerの使用に関しまして、１つ注意点があります、というかバグがあ ります。 複数の異なるNiagara Systemを表示している際、たとえば２つのエフェクトの負荷 を比較したいのに、それらの負荷が入れ替わって表示されることがあります。 これはグラフだけでなくNiagara Debuggerでパフォーマンスを数値で見ても同じ問 題が出ています。 この不具合はNiagaraチームに報告はしていますが、対応待ちという状態であること をご理解いただけますと幸いです。 現時点での対策としては、同時に複数の異なるNiagara Systemを表示せずに数値を 見る、ということになると思います。 ひと目で比較して見られないのは制限としてつらいところではあるのですが、この 手段なら正しい負荷の数値を見ることができます。 ２つを比較したい場合、Auto ActivateをOn,OFFして切り替えるか、シーンに１こ置 いて確認したら消し、次に別のNiagara Systemを置いて確認、といった具合です。

どうやってエミッターをマージして減らせばいいのか。 ここでは４つのエミッターマージの手法を紹介します。

GroupとVisibility Tagを使う方法

先日、フォートナイト内で泥の実装があったんですが、その際にバイクのタイヤか ら出るトゲトゲの煙みたいなものを泥に対応させる際に使いました。 マージをしないと、対応したい物理サーフェイスのぶんだけエミッターが増える。 ここでは２つを切り替えるだけですが、これが５個６個と増えたらエミッターだら けになって大変。 まずEmitter UpdateのSpawnでUserパラメータから入力されるIDをSpawnGroupとし ています。 ブループリントなどからサーフェイスのIDなどをUser Parameterを使って入力し、 その数値をそのままSpawn Groupとしている、ということです。

このエミッターにはレンダラーが２つあるのが見えます。 泥のレンダラーはRender Visibilityを1として、それ以外のものは0という形にしてい ます。

そして、Groupを使ってVisibility Tagを切り替えます。グループはUser Parameterの IDに依存させている状態です。ここでは泥のIDが１としています。 Mask Int by Spawn GroupというDynamic Inputを使用して、泥のグループ１をマスク し、マスクされたときはVisibility Tagが1、それ以外のときは0になるようにしていま す。 お見せしているものは対応するフィジカルサーフェイスは２つだけですが、３つ４ つと種類を増やすことができます。その場合はMask Int by Spawn Groupを使わず、 Ifで分岐させるのが手っ取り早いと思います。

マージの方法２つめ。 RendererのBindingsを使う。

これは爆発発生時のフラッシュのエミッターですが、２つの要素を１つのエミッタ ーに内包。 まず、MeshレンダラーとSpriteレンダラーを使っているので、それぞれは違うパラ メータでスケールを与えることができますので、そのあたりはそのまま使います。 ただ色は何もしなければ共通になりますので、レンダラーごとに調整するために Color2というパラメータを作成して分けてあげています。 Particles.Color2というパラメータを作り、片方のレンダラーのColor Bindingに作っ たColor2を適用して値を調整するだけ。 仮にレンダラーがどちらもSpriteであったとしたら、Scale２といったパラメータを 作ってあげることで問題なし。

Source Modeを併用する手法

これは２つのエミッターを１つにまとめる際にのみ使用。 エミッターが持つ２つのレンダラーのSource Modeが別々の場合、２つの要素を１つ のエミッターで制御できます。 Source Modeは、パフォーマンスチェックリストのところで１つのパーティクルだけ 発生させる際にEmitterだけ使ってレンダリングできる、と説明したもの。 マゼンタの枠がSource ModeがEmitterで、オレンジ色の球体を生成し、緑の枠が横 に伸びるアナモルフィックレンズフレアのような青い光を扱っており、これはパー ティクル側で制御している、ということです。

４つめ。 Partition ParticlesとArrayを使ってエミッターをマージ

Partition Particleというのは,スポーンしたパーティクルを任意のパーティションに分 けて、それぞれを別のパラメータで制御したりするときに便利なモジュール。 画面右がモジュールの持つパラメータ。 Number of Partitionsで５つのパーティションに分けられている状態。

パーティションに分けられた情報というのは、Particles Partition Particles Partitionと いうパラメータで取得。 このインデックスごとに違う値を与えるために、まる２番のようにArrayを使います。 画面はAdd Vectorのコーンのアクシスを５つに分けて、パーティクルが違う方向に 飛ぶようにしている例。

結果はこんな感じで、一例ですが、火花のエフェクトに使っています。 通常は、このようなエフェクトを作る際にGPUパーティクルの場合、Sample Particles from Other Emitterを使って親子関係のように、左側のエミッターのパーテ ィクルの位置に基づいて右側のエミッターで火花のパーティクルをたくさん発生さ せるのですが、Partition ParticlesとArrayをうまく使うと、エミッター１つでまかな うことができます。 他にもUser ParameterでインプットされたIDをもとにそれぞれのIDに別々のカラー を与えたりとか、使い方は様々。

実際に軽くなっているのか。 Niagara Editor内でおおまかな負荷予測が可能。 Niagara Editor内で、Preview画面の Showの中にあるInstruction Countsにチェックを 入れるとPreview画面に現れます。 Niagaraの各エミッターのスクリプトの大きさを見る、という感覚。 さまざまな要因が絡むのでここで明確な負荷は見られないのですが、数値が小さい ほど良い、くらいの感覚で。

ちなみに、GPUパーティクルを扱うエミッターが２つだったのを１つにしたら、こ んな感じに。 マージ前 合計941 マージ後 656 30％ちょっと数値が低い。３割軽くなるというわけではない。 マージした場合、していない場合の比較をするのには参考になるはず。

火花のほう、負荷をNiagara Debuggerでも見るてみると２割ほど軽くなっている。 右上はGPU Computeのパフォーマンス表示でこちらもマージしたほうが軽くなって いる。

４つの方法を紹介しましたが、これらを複合して３つや４つのエミッターを１つに まとめたりも、やろうと思えば可能。 Emitterのマージは処理負荷軽減には非常に有効なので、基本的にエミッターを減ら すほどよいのですが、マージすると１つ１つのエミッター内が複雑怪奇になってい く、というデメリットがある。

１つのエミッターで中央の煙とリングの煙が別々に制御されている例。 つまり２つに分けていたエミッターを１つにマージした状態。 この例では、SpawnGroupとマスクを使ってこれらの制御を分離しているが、それぞ れパラメータは２つずつになるうえ、それがあちこちに散らばっているため、制作 者以外の人が後から探して調整するのは少し困難。

これらを緩和をする手段があります。 Emitter Summaryで2つのコントロールを整理・分離しておくと、後からコントロー ルするのが楽になる。 UE5.3からは以前よりも感覚的にEmitter Summaryを編集できるようになっています ので、エミッタを扱いやすくするためにぜひ使ってみてください。特に自分以外の 人にデータを扱ってもらったりする場合などに大変有用。

大事な点ですので復唱。 エミッターのマージは負荷軽減に有効ですが、エミッター内のパラメータが複雑に なるので、使いまわすことや後々の修正を考慮して、ぜひEmitter Summaryの機能を 使って触るパラメータの整理整頓をすることを推奨します。

まだUE5.3ではエクスペリメンタルの状態ですが、Data Channelsについても少し。 最適化に貢献できる期待が持てる機能紹介。

Data Channels フォートナイトでは着弾などのインパクトで使用。 インパクトおよび同様のエフェクトを単一のより大きな共有の状態にするというか 集約するといったもので、オーバーヘッドを削減し、パフォーマンスを向上。

概要になりますが、エフェクトが発生する際に任意のサイズの島、範囲を作り、そ の範囲で他に発生する任意のNiagaraエフェクトを１つのエフェクトとみなして処理 することができる。

フォートナイトみたいに多数のプレイヤーが同じような場所に一斉に射撃をしたり、 まとまった位置にエフェクトが出る際にそれをまとめてしまうので、データ効率が よくなります。

現状気を付ける点としては、半透明のエフェクトが島の範囲にまとめられると、そ の島が大きい場合にそれ以外のエフェクトとの描画優先が極端に破綻することがあ る。 なので半透明を含むものは島の設定を小さくするなどして対応、といのが現状。 逆に言うと不透明だけのエフェクトをまとめるならかなり大きな島でも大丈夫。

Fortniteのゲーム内VFXにおけるスケーラビリティについて

冒頭でも説明したもの。 スケーラビリティは 処理負荷の制御をデバイスに応じて柔軟に対応する仕組み、と いった解釈で進めている。

動画のほう、フォートナイトの大きめの爆発のエフェクト、スケーラビリティ設定 違いの４つを同時に再生している。 スケーラビリティ設定だけでローエンドからハイエンドまで１つのNiagaraアセット で対応。

Niagaraエディタにはスケーラビリティを設定する専用ビューがある。 Niagaraエディタのメインツールバーの一番右にあるスケーラビリティをクリックす ると、その専用ビューに切り替わる。

こんな感じの画面。 便利な点として、アンリアルエディタのSettingでのスケーラビリティセッティング 変更はコンパイルが入りますが、ここではコンパイルなしで確認できること、 あとは視覚的にどのエミッターが有効、無効か分かるので把握しやすい、という点。 プレビューを切り替えたとき、System Over Viewで赤くなっているエミッターが無 効になっているもの。 右側に出ているのがそのエミッターON,OFFのスケーラビリティ設定。これは選択中 のエミッターがEpicとシネマティクスのときだけONにする、という設定になってい ることを態を示している。

あとは、赤枠はスケーラビリティのオーバーライドなのですが、 Niagaraシステムにセットしたエフェクトタイプによって、そのスケーラビリティの 段階ごとのパーティクル数を調整することができますが、ここでその設定を上書き することもでき、このエフェクトだけはLowでもパーティクルを多めに残したい、と いった細かな設定が可能。 基本的にエフェクトタイプの設定で完了しますが、特殊なエミッターはLowからEpic の設定まで発生パーティクル数を変えたくない、といったことがありますので、無 くてはならない機能。

これらは、先ほど動画でお見せした爆発エフェクトの、４段階のスケーラビリティ を１画面に出したもの。 エミッター数はちょうど２つずつ１段階ごとに減らしている状態。 エミッターをなくしたとしても、見た目に影響が出ないであろうものを優先してス ケーラビリティ設定で削っていく。

もう一度、設定結果の４段階の動画… EPICとHIGHの違いは、ハイエンド用の２D流体の煙があるかないかと、もう１つ分 かりにくいですが、このエミッターのレンダラーが切り替わってHighでは負荷を下 げているエミッタがある。 HIGHとMEDIUMを比べると、とげとげの煙用メッシュのエミッターと、地表の煙な らびにマージしているライトがない。 MEDIUMからLOWではGPUパーティクルの粒とリボンパーティクルの煙をOFFにし ていて、シルエットとして重要なフラッシュ、メイン爆発部分、スプライトのとげ とげ煙だけ残して、とにかくパフォーマンス優先にしつつ最低限、上位のスケーラ ビリティ設定の見た目との差異をなくすよう努めている。 こういった設定のガイドラインはFXチームで共有されていますので、ゲーム的に必 要な記号的エフェクトを消してしまうことはない。（ヒューマンエラーを除く）

最後の項目。 そのほか、最終的なチェック

これまで紹介したもの以外で、ぜひ見ておいてほしいというかNiagara内にとどまら ない最適化のためのチップスのようなもの6つ

１つめ。Niagara Debugger,とても便利。 エフェクトの確認のためにどんどん使っていただきたい。

１つ１つ機能紹介をしたいのですが、今日は時間の都合で概要だけ。 パフォーマンスを見る事ができますが、先に申し上げたとおりバグもありますので、 現状はご注意ください。 エフェクトの持つパラメータの情報を発生させているエフェクトの位置に出せる。 たとえばライフであったりポジションであったり、任意のパラメータを見ることが 出来、自分の作ったパラメータが正しく働いているかなども確認可能。 カメラの前にエフェクトを発生させるデバッグ機能がある。シーンに置いてそこに カメラを持っていくよりも楽。 また、キャラクターにアタッチすることも。 そして、再生中のエフェクトはポーズしたりコマ送りして見たいタイミングのエフ ェクトの状態やパラメータが確認可能。例えばポーズをかけて銃を撃つとかすると、 そのマズルフラッシュがポーズされた状態からはじまり、コマ送りで1フレームずつ 進めて確認、とか。

２つめ。 アンリアルエンジンでは描画負荷を見る機能がありますが、 左図のようにシェーダーの複雑度も見ることができますのでエフェクトの提出前に 確認しましょう。 これはあくまで目安なのであてにならないケースもありますが、スプライトのパー ティクルがCutoutをちゃんと使っているかどうか視認するのにも使えます。

Cutoutの設定はNiagaraのエミッターの、Rendererの中。 適切に調整することで半透明の描画負荷をけっこう減らすことができます。テクス チャにもよりますが、2～3割、半透明の描画面積を節約できたりすることも。

右図はライト数を見るビューですが、エフェクトから発生させているライトの大き さ、数が適切かどうか、データの提出前に確認をしてみてください。 たまにヒューマンエラーで複数のライトが重なっていたり、ライトのレンジが無駄 に大きすぎることがある。 どちらも描画負荷への影響が大きいものなので適切な状態になっていることを確認。

３つめ。 Niagara内ではないですが、Niagaraで扱うStatic Meshのデータに無駄なものが入っ ていないか確認。 画面はDistance Fieldについて、Niagaraから発生するメッシュはDistance Fieldを持 てないので、右下のようにあらかじめ「Distance Field Resolution Scale」をゼロに して適用すると、少しメモリを節約できる。

また、NiagaraのMeshパーティクルはStatic Meshのコリジョンを扱いませんので、 削除。 これもメモリ節約。

UVチャンネルの数も無駄に多くないか確認すべき。 一般的なエフェクト用のモデルは、UVは１つでよいはず。

４つめ。 アセット１つ１つを開いて確認しなくても、ある程度はNiagaraアセットがどんな値 を設定しているかをContent Browserの検索機能で絞り込んでみることができる。 ここでは２つの例を示していますが、Content Browserの検索ボックスに WarmupTime 大なり 0と打ってみてください。そうすると、WarmupTimeに何か値 が入っているNiagaraアセットを一覧できますので探す手間が省ける。 ２つめの例はComponentRendererを持っているかどうか調べるための入力です。 ANDとかORも使える。TypeでNiagara Systemを指定していますが、ブラウザの絞 り込みでNiagara Systemアセット限定にしていた場合は入れなくてもよい。

５つめ。 テクスチャのサイズ、もちろん小さいほうが良いのですが、一般的な２Dのテクスチ ャに限ったことではない。 メモリ節約のためにどのNiagara FXもカールノイズフォースのノイズクオリティ、 コストでHighやUltraを使わないほうが良いです。 多くの場合、Lowで乱流の表現は事足りるはず。 Ultraはテクスチャを使わずリアルタイム計算なので、メモリは使わずとも一番パフ ォーマンスが悪いと言えるので、ゲームではほぼ使わないんじゃないかと。

他にも、通常のテスクチャ以外にVolumeTextureのサイズなど。 64*64*64を使っていたんですが、フォートナイトでは負荷を確認しているTAから注 意がが来た。 32*32*32なら、OK。 すべてはモバイルなどのデバイス性能が弱い環境への配慮のためなので、細かい節 約も重要。 画面右の動画のように、６４サイズと比べると32サイズではぼやけてしまうが、も ともと柔らかい煙の表現ということもありこの変更はアートチェックでも許容され た。どうしても６４サイズでないといけない場合は使用許可が出たりもする。

エミッターの一番下、レンダラーの中にもScalability設定が存在するのですが、これ はレンダラーが複数ある場合に必要なもの。 例えば、スケーラビリティでLOWの時にOFFにしているエミッターがあったとして、 そのエミッターが持つレンダラーの片方は先にMediumでOFFにしてしまいたい、と いったときに。 エミッターが複数のレンダラーを持つ際は、このスケーラビリティ設定も確認を。

Validationを使って特定の条件をつかまえてワーニ ングやエラーとして表示したり、禁止をすること ができる。

プロジェクトごとに禁止 ルールを設けたり、作り 方で気を付けてほしい事 があると思いますが、そ ういったルールを設定し てNiagaraエディタに反 映できる。

これをうまく使うと、不 適切なデータを作ってし まうことが減ります。

NiagaraのValidationルー ルセットはアセット化さ れている。 FXのアドバンスドの中。 デフォルトで用意されて いるルールは現在たしか 12種類だったと思います。

C++で独自ルールを追加していただくこともできます。

このValidationルールを 使用するには、Project Settings Pluginsの Niagara Editorのところ で作成したルールのアセ ットを登録する形。

さいごに簡単なまとめ

Thanks

最後まで目を通していただきありがとうございました。