プロジェクトの開発段階で、パフォーマンス問題に遭遇することは珍しくありません。原因は様々ですが、ほとんどの場合、同時再生される音の数と直接関係します。ボリュームの演算だけを行うバーチャルボイスに対して、フィジカルボイスは全体的に処理されます（ストリーミング、デコーディング、フィルターなど）。再生する個々のフィジカルボイスが、実際に耳に聞こえるのか、そしてサウンドスケープの一部となっているのかどうか、判断することが重要です。Wwiseはそれぞれの音の意味合い、重要性は判断できません。しかしながら、Wwiseはこのようなサウンドデザイン側面を補完するツールを多数備えています。

フィジカルボイスの目標数は？

これはもちろん、正答のない質問です。あなたのゲームが対応するプラットフォームのミニマムスペックによりますし、あなたのチームがサウンドに割り当てるCPUの考え方でも当然変わります。これを前提にした上での目安は:

• PS4、Xbox One、PC、Mac: 合計80チャンネル未満
• Nintendo WiiU、Switch、そしてハイエンドのAndroidとiOS: 合計60チャンネル未満
• ローエンドの、Android、iOS、PC（XP時代）: 合計40チャンネル未満

なお、これはWwise側の制限ではないので、チャンネル数をこれより増やしても問題ないゲームもあります。私が「サウンド数」でなく「チャンネル数」としたのは、一般的にCPU負荷がチャンネル数と比例するからです（例えばステレオのCPU負荷は、モノの2倍）。とりあえずの参考値となりますので、ゲームデザインが許容すれば増やせると考えてください。また、コーデックや、ゲームでほかに行う処理も、数値に大きく影響します。多くのゲームの平均値は、ここに上げた数値よりも低いはずです。あるポイントを超えると、ポリフォニーは不協和音となってしまい、全体の音質が低下していくように人間の耳には感じられるので、チャンネル数は少ない方が望ましいです。もちろん、ボイス数のピークがこれ以上となる状況も考えられます。ピーク期間がそれほど長くなければ、サウンドエンジンが迅速にリカバーして、平常の数値に戻るはずです。ピーク値をコントロールするには、後述のPlayback Limitsを使います。

計画とプロトタイプ

プロセスの最初に正しく計画すれば、ボイス負荷を減らすことができます。具体的なゲームコンポーネント毎に、いくつのサウンドが必要になるのかを分析しておくべきです。そしてサウンド数と、そのコンポーネントのデザインを使用するゲームオブジェクト数を、掛算します。例えば、レーシングカーのサウンド数が9であれば1台分は問題ありませんが、出場車両が20台のレースでは合計180サウンドにまで増えます！  

まだ実際のゲームがなくても、デザイン中からProfilerが使えることも忘れないでください。画面上部の“Start Capture” をクリックするだけです。

サウンドをビルドする段階で、動作確認をしたり、先ほど計画したサウンド数を検証したりする時に、Profilerはとても便利です。プロトタイプをテストするには、Soundcasterでゲーム中と同じように複数のサウンドをトリガーしたり、RTPCの範囲を色々と試したり、自分が設定したほかのイベントを使ったりします。CPU使用量も表示されますが、このシナリオを稼働させるのが実際のコンソールではなくPCまたはMacなので、最終的なパフォーマンスを正しく示してくれるわけではありません。一方、ボイスやエフェクトのカウント数は、信頼できます。また、PCのCPU負荷を減らすことのできる工夫は、最終ターゲットのCPU消費も減らせると考えて良いでしょう。下のスクリーンショットのように、フィジカルボイス数を示す “Number of Voices (Physical)”が、Performance Monitorウィンドウに表示されます。

距離による減衰を設定

ゲームのようにインタラクティブな環境では、音が繰り返しトリガーされ蓄積されるうちに、CPUに対して（そしてユーザーの耳にも）、膨大な負担となりかねません。遠すぎる音は再生しないというのが、1つの分かりやすい方法です。その設定方法を、以下に紹介します:

 

• Volume Threshold (Project Settings): 「聞きとれない（inaudible）」音としてとらえる音量を指定できます。ここで設定する音量は、ゲームプレイのプラットフォームによって変わることがあり、開発するゲームの種類にもよります。例えば、とてもうるさいFPSとパズルゲームでは異なります。プレイヤーは、うるさい環境で-50 dBの音が欠けても気付かなくても、もっと静かなゲームでは気付きます。この閾値は、可能な限り高く設定しておきます。一般的に、-96 dBにしておく理由はあまりないはずです。そして、開発終盤にピンチに陥った場合は、設定を数dBだけ上げて貴重なCPUサイクルをセーブして、切り抜けることもできます。

• Virtual voice behavior (Advanced Settingsタブ): 音が「聞きとれない」レベルになった時に、どうするのかを指定できます。これはほとんどの場合、Kill if finite else virtual にしておくのが正解です。音がループしていなければ、その音が終了する設定です。

• 3D Positioningと、Attenuation (Positioningタブ): ボイス数をコントロールするのに、この2つの設定をペアで使います。ご想像のとおり、エミッターとリスナーが遠ざかれば、ボリュームが下がる設定です。そして、Volume Threshold設定やVirtual Voice設定が作動して、静かな音を終了させていきます。

以上のメカニズムで、ゲーム中の大部分の音を適宜、切り捨てできます。コンポーネント毎に減衰カーブを調整して、ほかのコンポーネントより早くカットオフすることもできます。方法は、Positioningパラメータをオーバーライドするだけです。

減衰範囲の調整が難しいと感じた場合は、Game Object Profiler (F12) を開くと、様々なオブジェクトとそれぞれの減衰の球体が観察できます。

ローエンドプラットフォーム専用のバージョン

よくあるのが、パフォーマンスのボトルネックがローエンドのプラットフォームだけで生じる状況です。幸い、Wwiseで設定できるプロパティのほとんどを“プラットフォーム毎にリンク・アンリンク”できます。プラットフォームによって設定値を変える機能です。また、音の構造をそのまま除外したり、構造の一部を除外したりできます。UIで、オレンジ色の“薬のカプセル”アイコンを探してみてください。右クリックして共通の設定値からアンリンクすれば、このプラットフォームに限り設定値を変更できます。画面左上のコンボボックスに表示されたプラットフォーム名が、表示中の設定の対象プラットフォームです。  

ローエンドプラットフォーム用のサブプラットフォームを作成するには、Platform Manager (Projectメニュー、またはShift+Alt+P) を使います。これで、リンク・アンリンク機能と合わせて使えば、デザインの中でそれほど重要でない部分を簡単に排除でき、CPUサイクルを多少セーブできます。

RTPCを使ったディテールの切り替え

どのゲームパラメータも、音のディテールを追加したり除いたりするために使えます。サウンドデザインの様々なポイントで、RTPCをスイッチコンテナやブレンドコンテナに付けられます。当然、組み込まれた距離RTPCを利用できますが、それだと効果は減衰設定とほぼ同じです。一方、Heightを使って、別の階にある音を除くことなどができます。また、PlayerとNon-Playerで切り替えるスイッチをつくれば、プレイヤーにとって肝心でも周りのNPCにはそうでないディテールを、追加したり除いたりできます。

同じ音の別バージョンを、プレイヤーとノンプレイヤ―に振り分ける

プレイヤーオブジェクト用か、ノンプレイヤーオブジェクト（NPC）用かによって、同じオーディオコンポーネントのシンプルな別バージョンを用意すれば、簡単にボイス数を減らせます。例えば、“car”のディテール（エンジン、ターボ、回転タイヤ、風、サスペンションなど）が全てそろったバージョンはプレイヤーゲームオブジェクト用に、そしてシンプルバージョン（エンジン、タイヤ）はNPC用に使えます。これをトリガーするのは、2つのイベントでも、スイッチコンテナにある1つのイベントでも良いのです。簡単な方法ですが、常に採用できるわけではありません。音の構造をコピーすると、たとえ簡素化してもゲームプロダクション中に混乱が生じたり、維持しきれなかったりすることがあります。それでもシンプルなケースでは有効な解決策です。  

もちろん前の節で説明したとおり、構造を1つだけ立ててブレンドコンテナやスイッチコンテナをつくり込めば、サブエレメントをオン・オフするだけで対応できます。余分な維持作業が必要な構造コピーを持つより、こちらの方が望ましいと思います。オーディオデータの重複の心配は無用で、Wwiseはデータ複製を正しく行い、バンクやストリーミングファイルで維持されるデータは、1つだけです。

Playback Limitsの設定

Playback Limitsは、同じような音が既に沢山あるのに、さらに似た音をトリガーするのを回避したい時に便利です。例えば、多数のNPCが歩き回っている街中の環境はフットステップ（足音）が増えすぎるかもしれません。もちろん減衰を適用していれば、自動的に遠方のフットステップが除去されます。それでも、聞こえる範囲に入ってくるフットステップが多すぎることもあり、プレイヤーが人混みを感じ取るのに足音100人分もいりません。聞き取り範囲内の音を取捨選択するために、Playback LimitとPriorityを設定する必要があります。

リミットを設定する3つの場所（レベル）が、Actor-mixer、バス、そしてグローバルです。

グローバル（全体）レベルに設定するリミットは漏れを防ぐ最終手段で、ゲームが対応できる数を全体で超えていないか、または1つのゲームプロセスが暴走してCPU全てを支配することはないか、などを確認します。Project SettingsのMax Voices Instancesで設定できます。ピーク時の予想ボイスカウント数よりも、やや高く設定してください。

特定のオブジェクトに対してリミットを設定するには、Actor-Mixer階層やInteractive Music階層のオブジェクトの、Advanced Settingsタブを開きます。なお、このリミットの対象は個別のサウンドで、親構造ではありません。例えば、3つのバリエーションのあるランダムコンテナに、グローバル（つまりゲームオブジェクト対象でない）リミットとして「2」を設定すると、ゲーム中のどの時点でも、同時に再生されるバリエーションは2つだけです。ここで、トリガーするイベント数は制限されていません。階層内に複数のリミットを設定できます。フットステップ階層の例では、一番上にあるActor-Mixerオブジェクトに上限を設ければ、一度に、地面の種類を表す様々なサブコンテナをまとめて制限できます。

バスにもPlayback Limitsがあり、バスのインプット数が制限されます。音の大きなカテゴリの許容数を割り当てるのに使うと便利です。例えば一番上のSFXバス、VOバス、Musicバスにそれぞれリミットを設定して、いつでも必ず1つ以上のVOと、充分な数のミュージックステムのスペースを確保しておくことなどができます。論理上はこの合計数がグローバルリミットになるはずですが、必ずしもそうではありません。

音を再生し始める時に、全てのリミッタ（Actor-Mixer、バス、グローバル）を確認して、全てのレベルで新しい音を再生できる余裕があった場合に限り、この音を再生します。

ただリミットだけに依存すると、近くの大きくて重要なサウンドが、他のサウンドに負けてカットされてしまう面倒な状況も考えられます。フットステップの事例は、まさしくそうです。フットステップのインスタント数のリミットを10にすると、元からある、耳に聞こえているフットステップのうち、どれをカットすべきですか？これを解決するのがPlayback Priority設定で、具体的には、Offset priority by X at max distanceの設定です。UIでは分かりにくいのですが、音が聞こえる範囲の半径のちょうど終わりに到達する時に、既定のプライオリティPを、(P – X) に、徐々に下げていきます。こうすれば、一番遠いところにある音が最初にカットされます。

 

適したコーデックの選択

ボイスのCPU負荷が高い主な原因は、複雑なコーデックの解凍処理です。採用するコーデックや設定内容でCPU負荷が大きく変わります。最適なコーデックを決めるのは、いつでもオーディオ品質、CPUコスト、ファイルサイズ、そしてストリーミング条件のバランスです。ゲームのいたるところで、使い方によって違うコーデックや設定を選択するのが理想的です。例えば、音楽に必要な帯域幅と制限事項は、ナレーションと異なります。

最初から品質を重視する人が多く、それは間違いではありません！ただし、ユーザーが感じ取れる品質としてちょうど良いレベルを最初に決めておくと、CPUサイクルを使うべきところで使えます。目安として、ほとんどの「うるさい」音（爆発音、フットステップ、衝突音など）はほかの音と比べて、圧縮して圧縮の雑音が入ってもユーザーの脳が「誤った音」として認識しないので、問題ありません。ほぼすべてのコーデックでいえることです。もちろん、大量の音にこれらの品質設定を適用する前に、代表的な音をいくつか選んで試してみてください。このような設定は、影響が大きいです。例えば、WwiseのVorbisファイルが最高品質（Q = 10）で圧縮されていると、同じファイルの低品質（Q = 0）の圧縮と比べてCPU負荷が2倍です。なお、このコーデックは2017年にさらに改良されました。

ソフトウェアコーデック（PCM、ADPCM、Vorbis）がハードウェアコーデックに勝る点が1つあり、それは、どのプラットフォームでも同じく作用するということです。ファイルサイズやオーディオ品質が、同じです。もちろん、CPUコストは異なります。Vorbisは、ハードウェアコーデックよりも遅いことが多いですが、ADPCMは速いかもしれません。もちろんPCMは本当のコーデックではないので、CPUコストもわずかです。

ハードウェアデコーダのあるプラットフォーム（PS4、Xbox One）でも、これらのコーデックの処理コストはゼロではありません！プラットフォームによっては、オーディオがデコーダとCPUの間で行き来している間に、メモリーバスやCPUがブロックされることもあります。結果として、処理能力が低下します。ただ一般的に、より複雑なソフトウェアコーデックよりも、大きく得します。ハードウェアコーデックは、長さ、ループポイントの配置、キューなどで制約事項が増えることがあり、特定の場面に採用できないかもしれません。

iOSでは、ハードウェアデコーダがあってもAACコーデックが汎用コーデックとしてお勧めできないので、注意してください。“iDevices” はミュージックプレイヤーとしてつくられたので、1つのストリームのリアルタイムデコーディングのために最適化されたデコーダが、1つあります。Wwiseはこのデコーダを利用しますが、その他のサウンドが全てソフトウェアでデコードされて、他のコーデック選択肢よりも遅くなります。つまり、あるタイプの音は、一度に1つの音しか再生されないと分かっていれば、そのタイプにAACを使うことでこのシステムを使いこなせます。その一例がナレーションで、その上にダイアログが重なることが一切ない、または稀であると分かっている場合には、使えます。

各コーデックのコストは、Profilerレイアウトでモニタリングできます。Advanced ProfilerウィンドウのPlug-insタブに、CPUの内訳としてプラグイン別の消費が表示されます。Wwiseではコーデックもプラグインなので、コーデックもリストに含まれます。

最後に

ボイス数のコントロールこそ、CPU負荷を軽減する1つの大事な方策です。上記のアイディアが適用できない具体的な場面もありますが、一般的に、実行すると大きく差がつきます。ゲームでCPU負荷の主要な要素はアクティブボイスですが、それ以外にもパフォーマンスの落とし穴は多々あります。今後のブログで、原因を探っていきます。