バージョン
menu_open
メモリ使用量を抑えるヒント
メモリプールサイズを、必要な制限内に合うよう減らすことが、困難である場合もあります。以下は、メモリ使用量を抑えるのに役立つ、幾つかのヒントです:
デフォルトのプールメモリ
デフォルトのプールメモリは、サウンド数、メモリにロードしたイベント (メディアではなく、構造のみ) そしてゲームオブジェクトの量に直接影響を受けます。これはプロジェクトがサウンドデザインの実装に必要とするオブジェクトすべてのプロパティを含んでいます。また、すべてのゲームオブジェクトとそれらの関連する情報 (ゲームシンク値、位置、向きなど)も含みます。より多くのバンクをロードすると、より大きなプールが必要になります。必要なサイズは、一つのシナリオ、レベル、マップ、ゲームエリアなどで一度に再生する可能性のあるサウンド数に依存します。このメモリを減らすのを助ける方法は幾つかあります:
- 多数のサウンド構造やイベントを入れた大きいサウンドバンクは、いくつかの小さいサウンドバンクに分割する。ガイダンスとして、Advanced ProfilerのSoundBanksタブを確認して、Default Poolカラムで各SoundBankがDefault プールでどれくらいのメモリを使用しているか確かめることができます。そして必要に応じてSoundBankを動的にロード、アンロードできます。これらの分割は戦略的に考えてください。例えば、ダイアログSoundBankを分割する場合には、単一のキャラクターのすべてのセリフを含むバンクの作成を避けます代わりに、コンテキストに従ってダイアログをグループ化します。
- AK::SoundEngine::ExecuteActionOnEvent API を利用して、イベント数を減らす。Play/Stop のペアを単一のPlayイベントに置き換えて、AK::SoundEngine::ExecuteActionOnEvent の "ExecuteActionOnEvent" を呼び出し、Stop ならびに Pause/Resume します (同じ Play イベントになります)。
- ゲームオブジェクトを細かく管理すること。役割が終わったものは、すぐに登録を解除します。全くメリットがない上に、メモリを消費してしまうので、使用しないゲームオブジェクトのプールを生かしたままにしないでください。例えば、NPC が死んだ場合を考えてください。そのゲームオブジェクトの登録を解除します; 何か別のことに再利用しないでください。必要な場合には、新規のものを登録します。基本的な考え方として、数千個のゲームオブジェクトが生きている状態は、多すぎると言えます。
- アクターミキサー (Actor-Mixer) をサウンドを構成するためだけに使用しないこと。フォルダとワークユニットはメモリを消費しませんが、アクターミキサーは消費します。デフォルトでない同様のプロパティを共有する場合には、そのプロパティはそこに一度しか存在しないのでメモリを節約することができます。もちろん、アクターミキサーが、SetVolumeや、SetPitchなどのイベントにレファレンスされるかどうかにもよります。
- 大きい階層は、サイズや複雑性を減らすように努力すること。よくある大きい階層として、「Impact（衝撃）」階層や、「Footstep（足音）」階層などがあります。これらは変数が多いため、サイズが大きくなり、構造のだめのメモリを多く必要とします。このような階層を小さくする方法を、以下にいくつか示します。 変化するのが、単純なプロパティであれば、RTPCを使う（サンプルは同じで、ボリューム、ピッチ、ランダマイザーなどが変わる場合）。 スイッチコンテナ階層を、複数のサウンドバンクに分けることができます。サウンドバンクマネージャでは、Switch コンテナを含む際、すべてのその分岐も含みます。しかし、SoundBank Editor ビューの theGame Sync タブ、または Edit タブで、分岐の幾つかを手作業で除外することができます。例えば、Footstep 階層では、最初の Switch 変数は Surface Type (地面の種類) かもしれません。その場合、Switch を異なるサウンドバンクに分けて、コンテキストによってそれらをロードします。メインの Footstep サウンドバンクには、都市環境のコンクリートや金属の階段など、ゲーム全体で遭遇する地面を含み、他のコンテキストによるサウンドバンクは、ゲーム中の一つのシーン/セクションのみに使用される泥の表面など、特定の地面を含みます
- 「外部ソース」を利用して、Wwise アクターミキサー階層が提供するような多くの制御を必要としないサウンドのオーバーヘッドを減らす。これは通常ボイスオーバーに向いています。
ローワーエンジンプールのメモリ
ローワーエンジンプール（Lower Engine Pool）のメモリは、サウンドの再生に使われます。これには解凍のためのバッファを含み、エフェクトを適用し、オーディオソースをミックスします。一度に再生するサウンドの数に直接影響されます。また、同時に使うエフェクトの合計数や種類にも影響を受けます。削減するには、同時にいくつのサウンドを聞かせたいのかを決める必要があります。ゲームによって、サウンドが10個以上聞こえるシナリオがほとんどないものもあれば、100個のゲームもあります。最悪のケースを考える必要があります。
ガイドラインとして、一部のゲーム (Xbox One) でプロファイリングを行い、次の数値を得ました:
- 1MBで、約42個のボイスを再生
- 2 MB で約96個のボイスを再生 ほぼ比例関係にありますが、どのコーデックを使用しているか、エフェクトの数、およびその他の要素に依存します。例えば、Vorbis コーデックでは、質の設定によりボイスあたりのメモリは50ほど多くなります。一度に170個のサウンドを再生するとします: これは恐らく理解不能で、役に立たないでしょう。しかし、ゲームのために理想的な本当の数字を見るけるための実験が必要です。プロファイラーの Memory タブを利用して、ゲームで複数のシナリオをプロファイルして、リソースでどれくらい使用しているかに留意します。
ローワーエンジンプールのメモリ消費量を削減するには、一度に再生するボイス数を減らす必要があります。それには次を利用します:
-
再生制限（Playback Limits）：Advanced Settingsの設定。例えば、跳弾50弾分のサウンドが聞こえる必要が、本当にあるのか。必要なければ、その数値を例えば15に制限します。
Note: また、バスの数も制限できます。 - Priority (優先度) : Advanced Settingsの設定。例えば、弾丸は、ダイアログほど重要でないとします。そこで、サウンド数が多すぎる場合は、まず弾丸の再生を落します。Playback limits（再生制限）と組み合わせて使います。
- Distance-based Priority Offset（プライオリティの、距離に基づくオフセット）：Advanced Settingsの設定。一般的に、遠くにあるオブジェクトは、近くのものほど重要ではありません。例えば、10m先にある弾丸の音は、もっと近くに弾丸サウンドが15個ある場合は、聞こえる必要がありません。
- Memory threshold (メモリのしきい値) :コード。メモリしきい値という機能があります。サウンドエンジンの様々なメモリプールを初期化する時に、プールの使用率に上限を設けて、超えるとプライオリティ設定に基づいてボイスをキルする（消す）ように設定できます。これで、メモリに固定の使用制限がかかり、メモリ不足（Out of Memory）の状況をほぼ完全に回避できます。なお、メモリにフラグメンテーションが起きるので、全てを使い切ることが不可能なためスタート地点として「0.9」つまり90程度が適切です。
- Below Threshold Behavior（ボリュームしきい値以下の動作）：Advanced Settingsの設定。負荷が最も低い動作（CPU、メモリ）は、「Kill Voice（ボイスを消す）」です、非ループサウンドに有用です。次に望ましいオプションは、「Send To Virtual（バーチャルボイスリストに送る）」+「Play from beginning（最初から再生）」であり、その次は「Send To Virtual（バーチャルボイスリストに送る）」+「Resume（再開）」、その次は「Send To Virtual」+「Play from elapsed time（経過した時間から再生）」と続きます。最も負荷が高いのは「Continue to play（再生を続ける）」と、「Play from elapsed time（経過した時間から再生）」のオプションです。Wwiseのデフォルト値は「Continue To Play（再生を続ける）」なので。
-
Volume Threshold (ボリュームしきい値) :Project Settingsの設定。これは、小さすぎて聞こえないようなサウンドをキルする（消す）ために使います。この設定と共に使われるのは、閾値以下の動作設定（Below Threshold Behavior）や、遠くに行けば一般的に音が小さくなる減衰（Attenuation）設定です。
Note: プログラム的にボリュームのしきい値をランタイムで変更できます。「ボリュームしきい値以下」の状態により多くのボイスを送るために、より処理が重くなるゲームの箇所でこれを利用できます。 - 使用したコーデック設定への変更 (Conversion Settings)。Vorbis は、オーディオを解凍するために余分なメモリが必要です。異なるパラメータが、必要量を増やしたり、減らしたりします。しかし、代償について注意深く考える必要があります: 異なるコーデックを使用、もまたは低い圧縮率を使用すると、Lower Pool (ロワープール)のメモリ負荷を緩和しますが、バンクにロードすると、メモリに大きなファイルを抱えることになります。 ある場合には、このプールに500 KB を追加したほうが、数MBのオーディオデータを節約し、結果的に全体のオーディオ予算を節約することになります。
- 質を少なく、または低くする。一部のエフェクトは処理に多くのメモリを必要とします。非常に一般的に、利用可能などの場合においてもメモリを多く消費するのが Reverb エフェクトです。現実的には、ゲームは非常に少ない数のリバーブしか同時に実行できません。ルールとしては、4個未満を推奨します。また、リバーブの質を低くする、長さを短くすることは助けになります。
メディアメモリ (サウンドバンク)
サウンドバンク（SoundBank）のメモリ消費は主に、中にあるサウンドデータに起因します。サウンドデータ（メディア）のメモリ消費は、以下のテクニックで抑制できます。
- 多数のサウンド構造やイベントを入れた大きいサウンドバンクは、いくつかの小さいサウンドバンクに分割する。必要に応じて、ロード、アンロードします。
- ディスクからストリーミングするサウンドの数を増やす（サウンドオブジェクトのプロパティ）。レイテンシに敏感なサウンドは、事前にフェッチしたメディアを使うことができ、 PinEventInStreamCache APIを使用して事前にロード、またはオンデマンドのキャッシュにストリームすることができます。
- APIの、PrepareEvent()を使う。
- オーディオの圧縮率を上げる（コンバージョン設定、コーデックなど）。
- サンプルレートを下げる。Automatic Sample Rate Detection（サンプルレート自動検知）機能を検討してみる（Conversion Settings）。 衝撃（Impact）関連のサウンドを、プラグインSoundSeed Impactの同等サウンドに置き換える。複数のバリエーションを含む Random Container を置き換えるのは非常に助けになります。
Note: 時には、非インパクトサウンドが許容できる結果となることもあります。 - 風（Wind）関連のサウンドを、プラグインSoundSeed Wind/Wooshの同等サウンドに置き換える。風のアンビエントサウンドは、ループサウンドであることが多く、メディアスペースをかなりとります。ブレードのヒューという音、 プロペラ、窓を開けた車での風が勢い良く流れる音、換気の騒音、その他はこのプラグインで作り出すことができます。また風とは関係のない応用も考えられます: どのような騒々しい音も作りだすことができます。例: 海の波、または遠くから聞こえる高速道路の音など。