パーティクルが何か他のものと衝突するときのパーティクル シミュレーションにおいてなど、Niagara でオーディオ エフェクトを再生する場合、Niagara から直接これを行う方法が何通りかあります。

それぞれの方法にはメリットとデメリットがあります。以下が簡単な概要です。

Play Audio モジュールを使用する

一度限りのサウンド エフェクト の場合、Niagara からサウンド エフェクトを再生する最も簡単な方法は Play Audio モジュールを使用することです。パーティクル コリジョンへの反応など、イベント駆動型エフェクトに役立ちます。低負荷のソリューションです。

1. Play Audio モジュールをエミッターに追加します。

2. [Sound to Play (再生サウンド)] のドロップダウンからサウンドを選択します。

3. PlayAudio の条件を設定します。

ピッチ、ボリュームなどに設定された値を使って、一度限りのファイヤー アンド フォーゲット エフェクトを発行します。エフェクトがトリガーされた後は変更や停止はできません。パーティクル シミュレーションが停止しても再生し続けます。

Play Audio モジュール
メリット	デメリット
パフォーマンスが最も良いソリューション (メモリと CPU の両方の使用に対して)	サウンドの最低が開始すると、ボリュームやピッチなどのサウンド プロパティは固定されます。
Easiest to set up	サウンドは、パーティクルが移動すると時間経過と共に位置を更新することはできません。

Audio Module のサンプル

1. GitHub から Unreal Engine ソースコードをダウンロード して開きます。

2. コンテンツ ブラウザでフィルタリング機能を使って Play Audio を検索します。

3. PlayAudio Example をダブルクリックして Niagara システム のコンテンツを開きます。

Play Persistent Audio モジュールを使用する

このモジュールは Play Audio と類似していますが、スポーンされた各サウンド エフェクトを保持するので、時間経過と共に更新することができます。

このモジュールには、サウンド キュー パラメータのフェーディングや設定などの高度な機能もあります。ただし、この方法では動作に (Play Persistent Audio と Update Persistent Audio の 2 つのモジュールが必要なため、最初の方法よりも設定に少し注意が必要です。

オーディオ プレイヤー データ インターフェースをエミッター属性として作成し、それをモジュールにバインドすることができます。 上のスクリーンショットでは、Emitter.CustomPlayer リファレンスは両方のモジュールにあります。

EMITTER の横のチェーンの記号は、それらが既存の属性を参照していることを示しています。

デフォルトでは、それぞれのモジュールは他のモジュールとは共有することができない独自のオブジェクトを作成します。 モジュールで同じオブジェクトを使用する場合は、エミッターまたはシステム スポーン スクリプトでオブジェクトを作成してから、モジュールでそれを参照する必要があります。

Play Persistent Audio モジュールの動き方を確認するには、機能別サンプル ファイルで フィルタリング を使って Play Audio を検索し、 [PlayAudio Example] をダブルクリックして開きます。

[Play Persistent Audio] をダブルクリックして ノードグラフ を開きます。

この方法は、サウンドがパーティクルの位置とともに移動する必要がある場合など、シミュレーション中にサウンドのプロパティを変更する必要がある場合に役立ちます。

Play Persistent Audio モジュール
メリット	デメリット
実行時にボリューム、ピッチ、位置、回転を変更する	設定がより複雑
サウンド キュー パラメータを設定し、シミュレーションの停止時にサウンドを終了する	Play Audio よりもパフォーマンスが劣る
カメラ距離に応じてサウンドをフィルタリングする

Audio Component Renderer を使用する

Audio Component Renderer を使用して、オーディオ コンポーネントをスポーンすることができます。

オーディオ コンポーネントを完全に制御することができるため、非常に柔軟なアプローチですが、パーティクル シミュレーションの Play Audio モジュールから機能 (フェーディングや距離ベースのフィルタリングなど) を再実装する必要があります。また、最初にカスタム オーディオ コンポーネントを作成せずにサウンド キューを設定することもサポートしていません。

モジュールが十分な制御を提供しない特別なユースケースを除いて、コンポーネントレンダラーを推奨しません。

Audio Component Renderer
メリット	デメリット
柔軟性が高い	不足機能が多い
オーディオをより細かく制御する	パフォーマンスが低い
	サウンド キュー パラメータを設定できない

パーティクル データをブループリントにエクスポートする

他のアプローチがニーズに対して柔軟に対応できない場合は、パーティクル データをブループリントまたは C++ にエクスポートし、そこにオーディオ ロジックを実装することができます。

そのためには Export Particle Data インターフェースを使用します。機能別サンプル プロジェクトの例を見るには、コンテンツ ブラウザで「export particle」を検索します。

ExportParticleDataExample をダブルクリックして、パーティクル シミュレーションからデータをエクスポートする方法に関する詳細な説明を表示します。

データ エクスポート インターフェースのメリットの 1 つは、GPU エミッター上でも動作することです。必要なデータをブループリントに入れれば、オーディオ再生だけでなく、ポストプロセスやユーザー インターフェース ウィジェットなど、いくつでもコンポーネントを操作することもできます。

これがオーディオを再生する最も柔軟な方法ですが、同時に最も遅く、最も設定が複雑です。さらにエクスポートできるデータ量にも制限があり、オーディオ コンポーネントとパーティクル データ間のマッピングが必要です。

パーティクル データをブループリントにエクスポートする
メリット	デメリット
*最も柔軟性が高い	最もパフォーマンスが低い
GPU で動作する	すべてのモジュール機能をブループリント ロジックに再実装する必要がある
	設定が複雑