Hitman 2 - 最新のCPU向けに、リバーブを強化

ゲームオーディオ / スペーシャルオーディオ / Wwiseの使い方やツール

6コアや8コアのCPUが広く使われるようになり、余裕のある処理能力がゲームに提供されるようにました。     そのパワーの一部を、プレイヤーのオーディオ体験     向上のために使うことができます。増えたコアを活用するには、開発者がコード実行を積極的に並列化し、CPUが異なってもゲームの機能が的確にスケーリングされることを、確保する必要があります。この記事はIO Interactive* Intelの共同作業に基づき、マルチコアCPUと並列化を採用してHitman 2*のサウンドの没入感を深めた方法を紹介します。具体的には、リバーブという、ゲームオーディオにとって重要かつ演算負荷の高い分野について、改善できる点をみていきます。

Hitman 2とは

201811月にリリースされたステルスゲームHitman 2は、コペンハーゲンのIO Interactiveが開発し、世界中に何百万人ものファンがいるフランチャイズの続編です。プレイヤーは、有名なアサシンAgent 47をコントロールしながら、広大で躍動感あるレベルを探索し、厳重に守られている大物ターゲットを難なく排除するクリエイティブな方法を見出します。

別のゲームキャラクターに変装してターゲットに静かに近づくにしろ、事故を装うにしろ、銃弾を浴びさせてミッションを達成するにしろ、手段はプレイヤーが自由に決めます。どのアプローチでも機会は豊富にあり、ほかの人と組んだり対抗したりできるCoopモードやVersus multiplayerモードなどもあります。Hitman 2生きたゲーム世界     なので、新しい場所やミッションやコンテンツを追加してくれる、定期的なアップデートがあります。

1 

このゲームは、独自ゲームエンジンGlacierとオーディオミドルウェアのWwiseを使い開発されました。ここに記載する実装内容は、Wwise特有のものも多いですが、ほかのサウンドエンジンにも簡単に応用できます。


単純なリバーブシステムの仕組みと欠点

リバーブは、音波が周りの面に反射したときに発生する現象です。反射によって音が増幅され色付けされ、元の直接の音波が消え去っても、続きます。ビデオゲームでは、リバーブによってプレイヤーは進行中のアクションの周辺環境を、音響的なヒントで感じ取ることできるので、大事な没入感のツールです。リバーブする音に影響してくる複数の反射面を考慮すると、この現象を正確にシミュレーションするのは非常に演算負荷が高く、ゲームデベロッパーは様々な近似値を代わりに採用します。

よく行われるのは、ゲームワールド全体の空間を複数のエリアに小分けして、それぞれのエリアにリバーブのプリセットを割り当てる方法です。この記事で、分割したエリアをルーム(部屋)と呼びますが、これはGlacierWwiseの用語に準拠した考え方で、実際に閉ざされた空間の部屋であるとは限りません。この場合、ルームは1つのゲームレベルの中で類似した音響特性を有する部分を指します。したがってルームはゲームレベルの物理的な構造に大まかに沿った形状となり、屋内外のどちらの環境も表し、広大な地形を部分的に示すこともあります。Hitman 2ではバウンディングボックス、コーン、 凸多角形などの3次元形状を使ってルームを定義していますが、それを示したのが図1です。

2

1サウンドジオメトリの、非常に簡略化された例。小屋全体のサウンドが、赤いルームで表されている。

リバーブのプリセットは、特定のルームの音響をシミュレーションするために事前に調整されたリバーブエフェクトです。ここで使うエフェクトは、シンセティックリバーブ(Wwise RoomVerbなど)やコンボリューションリバーブなどです。 Hitman 2  では、主に後者を使います。

シンセティックエフェクトは、ディレイラインや、コームやオールパスなどのフィルタを使い、リバーブをアルゴリズムでシミュレーションします。これらのエフェクトはCPU負荷が軽くなりますが、コンボリューションリバーブほどは自然に聞こえず、音響的な美しさも弱まり、特に複雑な音響や長めのリバーブタイムを有するルームでは質が低下します。また、満足できる効果を得るには、設定が難しい傾向があります。

一方、コンボリューションリバーブは、実際にあるロケーションのインパルスレスポンスを事前に録音し、これを使います。インパルスレスポンスは、スパーク音やスターターピストル音などの短い音を再生し、その部屋のレスポンス音を録音することで作成します。ここで得たオーディオサンプルを、コンボリューション計算     を使ってゲーム音に適用すれば、音がこの部屋で再生されたかのように聞こえます。コンボリューションリバーブはCPU負荷が高く、メモリ負荷も高く、さらに、インパルスレスポンスを購入するか、見つけるか、レコーディングする必要があり、これに時間とお金もかかります。ただ、良いインパルスレスポンスをいったん入手すれば、優れた音を聞くことができ、たとえ音響的に複雑な環境設定であっても説得力のある再現音を提供してくれ、調整や修正もあまり必要ありません。

ゲームは常にオーディオリスナーの現在位置を確認し、今いるルームに事前にアサインされたプリセットを、再生中のすべての3D音に適用します。一般的に、リスナー位置はプレイヤーがコントロールするキャラクターの頭か、ゲームカメラ上です。簡単に実装でき、かなり効果的なソリューションなので、Hitmanシリーズをはじめ多くのゲームで採用されてきました。しかし同時に原始的なやり方なので、欠点もいくつかあります。

1つは、シンプルな事例で説明できる欠点です。自分のゲームキャラクターが狭いコンクリートバンカーに隠れながら、丘の連なる草原に潜む敵の攻撃を避けようとしているとします。シンプルなソリューションでは、バンカーのリバーブが自分のウェポンの音だけでなく、敵の銃撃音にも適用されます。敵のショット音に、屋外の開けた丘陵地によくあるエコー的なリバーブではなく、重く金属的な響きが加わり、まるであなたのコンクリートバンカーの中から発射されたように聞こえます。これではプレイヤーであるあなたに、音の正しい環境が示されないので、不自然に聞こえてしまいます。現実世界では、草原からくる音にまず、丘の斜面のリフレクションやエコーが加えられ、色付けされるはずで、それはプレイヤー側のバンカーの壁面によるリフレクションよりも、影響が大きいはずです。

この問題を解決するには、音別に、リスナーに伝搬する過程で発生するであろうリフレクションを、リバーブでシミュレーションすればいいのです。これもまた、CPU負荷が非常に大きくなります。ただし、リスナーに到達するまでに音が通過するルームを把握すれば、大体のリバーブを予想することができ、それらのルームのリバーブプリセットを、音に連結することができます。個々の音にそのサウンドエミッターが位置するルームのリバーブを適用するだけでも、リスナー側のルームに設定されたリバーブを全サウンドにそのまま適用するよりも、空間的な感覚をより正確に伝えられます。

図 2の動画は、異なるリバーブを Hitman 2 でいくつかの音に、方法を変えて適用してみたデモです。

2オーディオ機能の説明: ここで紹介したリバーブのポイントを示す動画。

音が伝搬する元の場所や、通過する場所のリバーブを適用する際は、以下のような課題が発生します:

  • リバーブエフェクトのレンダリングにかかる、CPUへの負荷
  • ルームの検知
  • リバーブの連結
  • リバーブの方向性
  • 異なるCPUにおけるスケーリング

それでは、1つずつ詳しくみていきます。

リバーブエフェクトのレンダリングと、CPUへの負荷

リバーブエフェクトはCPU負荷が高くなることが多く、ゲームで同時にアクティブとなるエフェクトインスタンス数を最低限に抑える必要があります。そこで基本的に、リバーブエフェクトは個々のサウンドに適用しません。その代わりに、特定のリバーブエフェクトが必要なサウンドは、いわゆるAUXバスに送られ、そこでサブミックスが行われ、求められるエフェクトが1度だけ、適用されます。個々のサウンドのリバーブの強弱は、それがバスにサブミックスされるときに、いわゆるセンド値を適用して音の大きさを一定量だけ変化させることで、コントロールします。ほとんどのゲームの標準的な運用方法です。Wwiseでは、SetGameObjectAuxSendValues というAPIを使ってサウンドエミッターをルーティングします。

Hitman 2 では、図 3で示すように、典型的な環境を表現する数十個のリバーブバスを設定しました。サウンドデザイナーが、ゲームのすべてのルームにバスを1つずつアサインしました。

3  3 私たちのWwiseプロジェクトの、リバーブバス階層。

あるバスがアクティブになったとき、つまり再生中のサウンドがそのバスにルーティングされてきたときに限り、そのバスのエフェクトはレンダリングされます。もしバスに再生中のサウンドが入ってこなければ、そのバスは休止状態であり、基本的にバスのエフェクトはCPUを消費しません。例外は、バスにルーティングされてきたサウンドがすべて終了したあとも、そのエフェクトで発生したテイル、例えばリバーブなどを、再生し終わるまでバスのアクティブ状態が続いた場合です。

前述のソリューションの、CPUフットプリント

ここで記載したソリューションはCPU消費の観点でいうと、安価です。すべてのサウンドをリスナーのあるルームのバスにルーティングするので、1つのリバーブエフェクトだけをレンダリングすればいいのです。リスナーがルームとルームを接続するポータル(例えばドアなどの開口部分)の近くに来ると、同時に複数のバスがアクティブになります。そのような場合は、リスナーのルームのバスだけでなく、付近のポータルの向こう側にあるルームの、それぞれのバスにも、サウンドを送る必要があります。こうすれば、リスナーが1つの部屋から別に移る場合に、滑らかなリバーブのトランジションが行われます。それでもアクティブ状態のバスは多くて2つか3つなので、これらのエフェクトに起因するCPU負荷も、それほど気になりません。

新ソリューションのCPUフットプリント

様々なサウンドを、それぞれが位置するルームのバスにルーティングし始めると、状況がまったく変わってきました。 Hitman 2 で同時再生される最大サウンド数(ボイス上限)が64なので、もしすべてのサウンドが違うルームに入っていて、各ルームに専用のバスがあれば、理論上は最大64個のアクティブなリバーブバスが存在するかもしれないのです。この極端なシナリオが実際に発生する可能性は非常に少ないものの、アクティブなリバーブバス数は旧ソリューションよりも必然的に高くなり、平均で同時に8から10となります。例えば図 4にあるのは典型的なレベルを表示したWwise Advanced Profilerのスクリーンショットで、アクティブなリバーブバスの一覧と、それぞれのバスにミキシングされるサウンド数(Mix Count列)が分かります。

4 4 アクティブなリバーブバスの一覧。Mix Count0でもアクティブ状態のバスがあることに注目。これらのバスは、すでに終わったサウンドの、リバーブテイルを再生中。

リバーブインスタンス数が810個になっても、旧ソリューションの23個という数字と、それほど変わらないと思うかもしれません。しかしコンボリューションリバーブを使うと、CPU負荷が高く、リバーブインスタンス数と比例してさらに増大します。つまり新システムに切り替えると、オーディオフレームレンダリング時間が、リバーブ設定にもよりますが、合計50%以上も長くかかります。となると、ハードウェア側で再生するサウンドデータが足りなくなる前にレンダリングをしなければスタッター(stutter)が発生する可能性があり、少なくともフレームレート(fps)に悪影響があります。

オーディオレンダリングの並列化

幸い、リバーブバス同士の依存性はないので、エフェクトは、そのバス専用のサブミックスバッファに書き込まれます。つまり、並列実行の最有力     候補なのです。ここで注目したいのが最近のマルチコアCPUの役割で、複数のリバーブエフェクトを異なるハードウェアスレッドで同時に処理できれば、リバーブインスタンス数が増加したことによるデメリットが低減され、場合によって完全に相殺されるからです。

私たちはWwiseを使うので、この強みを無料で手にできます。Intelのエンジニアたちが実装したタスクベースのオーディオレンダリング機能が、Wwiseの標準SDKに、2018.1バージョンから含まれています。オーディオレンダリングパイプラインが細分化され、並列で処理できる複数のグラニュラータスクセットに整え、それらの実行をゲームに依頼します。これらのタスクを、私たちのタスクスケジューラに送り込むと、図 5のように、タスクをスケジューラが空いているワーカースレッドで実行させます。Wwiseを使っていてもタスクスケジューラのないゲームでは、SDKで提供されているサンプルインプリメンテーションが役に立つかもしれません (TaskSchedulerサンプル参照)。使い始めの作業も少なく、オーディオフレームのレンダリング時間の改善はよく分かります。

5  5  Hitman 2 の典型的なオーディオフレームを並列でレンダリングするときの、Glacierプロファイラのスクリーンショット。横軸の “JqWorker” というラインが、それぞれワーカースレッドであり、赤や黄のアイテムは、スレッドで実行されるタスク(Glacierではjobという)を示す。このビューは、オーディオタスクだけを表示するフィルターを適用している。

パフォーマンスの比較

それでは、並列化したオーディオレンダリングを使った場合と使わない場合のパフォーマンスを、比較します。図 6 に示す場所でアイドリングしていたときのオーディオフレーム平均レンダリング時間を測定し、比較しました。

6 6 パフォーマンス測定に使った、 Hitman 2 Miamiレベルの実際の位置。

最初のテストケースでは、旧リバーブシステムを有効にしてあります。テスト場所はポータルの付近で、アクティブリバーブが2つあります。2つ目のテストケースでは新ソリューションに切り替えるので、アクティブリバーブが8個になります。そして最後に、新しいシステムに、サウンドが最高で速度が最も遅い最上級のリバーブプリセットを組み合わせ、その様子をデモンストレーションします。

どのテストケースでも、使ったエフェクトはWwise Convolution Reverbです。このプラグインを知っている人向けの情報として、最初の2つのテストケースで使ったプリセットは、モノのインパルスレスポンス(IR)でスレッショルド(閾値)-50 dBであり、最後のテストで使ったプリセットは、ステレオのIRでスレッショルドは -144 dBでした。通常のプリセットでも高品質プリセットでもIRの長さは同じで、プリセットによって1秒から3秒ほど違います。

7

7 は、6コアのCPUのパソコンで行ったテスト結果。

見て分かる通り、並列化オーディオレンダリングを使うと、非並列バージョンと比較して、テスト1では1.45倍の改善、テスト2では2倍の改善、テスト3では1.9倍の改善がありました。さらに重要なのは、リバーブのインスタンス数や、各インスタンスのCPU負荷が増えるにつれ、スケーリングが改善される点です。

テストに使ったパソコンでは、各タスクにかかる平均時間が60マイクロ秒と、タスクのグラニュラリティとして比較的良い値です。コンボリューションリバーブのタスクだけは例外で、最高品質のプリセットでエフェクトをレンダリングするのに、最大1ミリ秒(ms)もかかりました。それでも、一番負荷の高いテストケースで8個の高品質リバーブを処理した場合に、すべてのコアでオーディオタスクを実行するのにかかったゲームフレーム毎の平均合計時間は、シングルコアのフレームタイムの17%だけでした。つまり、オーディオ関連のタスクに各コアが費やす時間は比較的少なく、ほとんどのCPUリソースをほかのゲームタスクに使うことができます。

同じテストをXbox One* PlayStation 4* で実行した場合の大まかな結果を知るには、図 7 の時間を4倍にしてください。

図 8 で、コア数の異なるCPUにおいて、並列化で達成されたパフォーマンスの効率化を比較しています。同時実行することで、古い4コアや6コアのCPUでも明らかな改善があり、最近の8コアCPUでは最大の改善幅がみられます。

8 8 Intel® Core™ プロセッサでコア数の異なる場合の同時並行によるパフォーマンス改善。テストケースごと、そしてCPUごとに、同期オーディオフレームのレンダリング時間を、並列化レンダリング時間で割り、ゲイン係数を算出。

ルームの検知

あるサウンドを、どのリバーブバスに送ればいいのかを判断するには、そのサウンドが位置するルームを確認する必要があります。これを目的に、ルームを枝分かれした空間データ構成に保存してあるので、1つのポイント(サウンドエミッターのポジション)から素早くルックアップできます。アルゴリズムは、2015年のGame Developers Conference Europe (GDCE) で、 "Sound Propagation In Hitman" という講演で詳しく説明しました。

実装方法は分かりやすく、唯一の注意点は、複数の環境がネスト化したり重複したりするなか、正しいものを選ぶことです。ルームの優先順位を設定しておくと、作業しやすくなります。外側のルームはプライオリティを最も低くし、最も内側にあるルームのプライオリティは一番高くします。プライオリティは自動計算し、あとで微調整する必要があるときに、エディタでオーバーライドできるようにします。

もう1つ考慮すべきなのは、サウンドエミッターが1つのルームから別のルームに移った際に、リバーブが唐突に変化するのを避けるための手段です。これには、近くのポータルを把握し、サウンドエミッターをポータルの向こう側にあるルームのバスにルーティングするようにします。この場合のセンド値は、サウンドエミッターと、別の部屋につながる一番近い開口部の間の距離に、係数をかけたものです。

これを実装するには、あるポイントから一定範囲以内のポータルの一覧を効率的に入手する方法が必要です。そこで、ルーム用に使う空間の細分化構造と同類のものを、ポータルのジオメトリの保存用に用意します。

ルームと付近のポータルのクエリをかけ、すべてのサウンドを適切なバスにルーティングする処理は、毎フレームで行う必要があります。ポジションが変わらないサウンドでは、ジオメトリが変化していなければ、この処理は不要です。それでも実際に多数の処理を実行する必要が出てくることもあり、11つは比較的軽い作業でも合計するとメインスレッドに対し好ましくないオーバーヘッドとなる可能性があります。そこで、ワーカースレッドに回してしまうと良いでしょう。

まず、すべてのクエリをいくつかのサブセットに細分化し、各サブセットをそれぞれのタスク内で処理するというのが、1つの方法です。タスク数はワーカースレッド数と同じになるので、それを念頭にサブセットの大きさを決めてください。タスクをゲームロジックのアップデート直後のスケジュールにすれば、クエリ実行中に新しいエミッターがスポーンされません。タスクはオーディオコマンドキューを処理し始める前に、つまりWwiseを使う場合はRenderAudioをコールする処理の前に、完了させます。

あるいは、サウンドエミッターの更新ルーチン全体を1つのタスクにしてしまい、これらのタスクをワーカースレッドで並列実行すれば、さらに効率がよくなります。ここでいう更新ルーチンとは、再生中のサウンドエミッター用に、フレーム毎にメインスレッドで行うすべての計算をまとめて指す名前です。オクルージョン、回折、容積、ドップラー、リバーブなどの計算は、これに含まれます。

リバーブの連結

1つのサウンドがリスナーに到達するまでに通過する、各ルームのリバーブを適用するには、それらのルームのそれぞれのバスを連結する必要があります。例えば、ルームAに複数のサウンドがあり、リスナーはルームCにいるとします。ルームACは、ルームBを挟んで接続しています。まず、これらのサウンドをルームAのバスにルーティングします。このバスをルームBのバスにルーティングし、さらに、後者のバスを、ルームCのバスにルーティングします。そうすることで、サウンドが3つの部屋を経由する際に、それぞれのリバーブが適用されます。

パフォーマンスに関する注意事項: 3つのルームにある全サウンドの合計数にかかわらず、アクティブなバスの数は3つです。ただし、もし再生中のサウンドが別々の部屋に入っていたり、多数の違うルームを経由して伝搬したりするようであれば、すぐにアクティブバス数が増加してしまいます。その場合は総数を削減するロジックの実行が必要で、例えばミックス全体に大きく影響しないようなサウンドは、バスにルーティングしないことを選択します。

GDCEで伝搬システムに関する講演をしたことに触れましたが、このシステムを拡張すれば、複数の伝搬パスや、それぞれの伝搬パスにある複数のルームが、把握できます。この情報さえあれば、バスへのルーティングの設定は比較的単純です。

Wwiseでバスのルーティングを設定

Audiokineticが出したブログ記事、 Working With the New 3D-Bus Architecture in Wwise 2017.1: Simulating an Audio Surveillance System に、設定の詳細が説明されています。内容はオーディオを監視するシステムの実装ですが、同じ考え方で、リバーブの連結設定ができます。まずリバーブバスのListener Relative Routing機能(Wwise 2018.1より前はEnable Positioningという設定)を有効にし、各ルームのサウンドエミッターを登録し、SetListenersというAPIを使い、サウンドを1つのルームのエミッターから別のものにルーティングします。最後に、通常のサウンドエミッターで SetGameObjectAuxSendValues というAPIを使ってリバーブバスのルーティングを設定する際に、通常のエミッターが位置するルームのエミッターIDに、AkAuxSendValue::listenerID を設定します。

伝搬システムの並列化

当初 Hitman (2016) 用に書かれた伝搬システムはオクルージョンやディフラクションの計算だけに使うものだったので、あるルームからリスナーのルームまでの、最適な伝搬パスを見出す役割のみを担っていました。その結果、伝搬システムの更新負荷は軽く、1フレームにつき0.1ミリ秒ほどだったので、メインスレッドで行っていました。しかしサウンドがリスナーに到達するまでの複数のパスをトラッキングするとなると負荷は大きくなるので、ワーカースレッドに分散するほうが理にかなっています。

その際の一般的な注意点として、ほかのスレッドで更新が完了するのを待つことは、常に避けるべきです。対策として、2つのシンプルな工夫をしました:

  • 更新するタイミング: 伝搬システム更新スケジュールをフレームの早期にして、カメラやゲームキャラクターポジションの更新後に入れています。この時点で、リスナーポジションが分かるからです。オーディオシステム更新に伝搬データが必要となるのはフレームの最後なので、伝搬タスクが処理を終えるのに十分な時間を確保できます。
  • 伝搬データのダブルバッファリング: ゲームループでスポーンされた新しいサウンドが、伝搬システムの更新中に伝搬システムにクエリをかける可能性があるので、直前のフレームの伝搬データをキャッシュし、現在のフレーム中にそれを提供します。フレームの最後で、オーディオシステムを更新する前に伝搬データを入れ替えます。

リバーブの方向性

シングルリバーブの旧ソリューションでもみられ、新ソリューションでさらに重要となる問題は、ゲームで使われるリバーブエフェクトの多くで、サウンドがシングルチャンネルのため方向性が保たれないことです。パフォーマンスの面で、このようになっています。ところが結果として、サウンドがどの方向にあるのかにかかわらず、全スピーカーからリバーブが聞こえてしまいます。例えばノンプレイヤーキャラクター(NPC)が、あなたのゲームキャラクターの左側で発砲したとします。直接音は明らかに左から聞こえてくるのに、そのリバーブ音は、全方向から広がるように感じられます。サウンドとリスナーが同じ閉ざされた空間にあれば問題ありませんが、実際にはこれ以外の場合は、リバーブの方向性やスプレッドを制御できるようにしたいわけです。特に多数のリバーブが同時にアクティブな場合などは、そうです。方向性が欠如してもリバーブが12個であれば許容できますが、多数の無指向性のインスタンスが存在すれば、ミックスが混乱して音も悪くなる可能性があります。

リバーブバスのパンニング

方向性の問題を簡単に解決するには、各ルームのリバーブアウトプット自体を独立した3Dサウンドとして扱い、パンニングやスプレッドを設定し、方向性やボリュームをもたせる方法があります。

これをWwiseで設定するのは、「Wwiseでバスのルーティングを設定」の説で説明した手順とほぼ同じです。リバーブバスのListener Relative Routing機能を有効にし、ルームの中にある通常のエミッターのリバーブルーティングを設定するときに、そのルームのエミッターID AkAuxSendValue::listenerID にアサインすることで、バスをルームエミッターと関連付けることができます。これで、ルームエミッターをルームの中央、またはリスナーのルームにつながるポータル(このほうが現実味は増すが実装は難しくなる)に配置すれば、リバーブのパンニングができます。さらに RegisterBusVolumeCallback というAPIを使えばミキシングのカスタム設定もでき、これはWwiseでエミッターとリスナーの距離を変更する以外に、スプレッドをコントロールする唯一の手段なので、便利です。

この手法の明らかな欠点として、リスナーのルームのリバーブはパンニングできません。もしそのルームが大きい空間であれば、問題になります。対策として、大きい空間をプログラミング上は複数に分割し、それぞれのサウンドエミッターを作成して該当部分にサウンドをルーティングします。同じことをリスナーのいない大きいルームでも行う必要が出てくるかもしれません。ジオメトリの分割を、ジオメトリ生成プロセスの一環としてオフラインで行うこともできます。

もう1つの欠点は、パフォーマンスに関するものです。リバーブバスのポジショニングを可能にして、ルームごとにサウンドエミッターを使うと、各ルームにアクティブバスのインスタンスを作成する結果となります。以前は同じリバーブバスを2つのルームが一緒に使っていれば1つのアクティブなバスインスタンスとなり、スポーンされるリバーブエフェクトも1つだけでしたが、今はそれぞれのバスインスタンスができます。前述の方法でジオメトリを分割した場合も同様で、各部分のバスインスタンスがスポーンされます。これが問題かどうかは、あなたのジオメトリによって違います。

マルチチャンネルのリバーブエフェクトの利用

リバーブの方向性を保つもう1つの方法が、マルチチャンネルリバーブです。縦方向にも対応する場合を除き、チャンネル数は4つで充分です。各サウンドはリスナーとの相対的な位置関係に基づいて、リバーブバスの該当するチャンネルにミキシングされます。すべてのサウンドをサブミックスしてから、そのフレームで耳に聞こえるコンテンツのないチャンネルを除き、チャンネルごとにリバーブエフェクトを別々にレンダリングします。次にリバーブバスの各チャンネルを最終的な出力用オーディオバスにアップミックスしますが、この最終バスのチャンネルコンフィギュレーションは、プレイヤーの実際のスピーカーセットアップ(ステレオ、5.17.1など)に対応しています。

この方式では、リバーブによる負荷が、チャンネル数を掛けた分だけ増えます。つまり、アクティブなリバーブバスすべてにこのエフェクトを使うと、膨大な負担になります。リスナーのルーム以外ではモノのリバーブエフェクトとリバーブバスのパンニングを用いて、リスナーのルームではマルチチャンネルのリバーブエフェクトを使うのが、最適のアプローチです。リスナーが隣のルームにつながるポータルに近づくと、そのルームのモノのリバーブと、マルチチャンネルのリバーブがクロスフェードし、スムーズなトランジションとして聞こえるはずです。

Wwiseは、マルチチャンネルのリバーブエフェクトに対応していません。Wwise Convolution ReverbFilterモードを使うと、上記のロジックに近いかたちで機能します。ただし様々なチャンネルコンフィギュレーションに対応できるような柔軟性はないので、本番環境では使えません。また、このモードはリバーブのシミュレーション用ではありません。つまりマルチチャンネルのリバーブは、自分でコンボリューションリバーブのプラグインを開発する気のある人だけが選択できるオプションとなります。そしてプラグインを実装するときに、並列化を活用し、各チャンネルのエフェクトのレンダリングを、ワーカースレッドで個別のタスクとして実行することを検討してみてください。これらのタスクは実行中、相互の依存性はありません。

異なるCPUのスケーリング

 Hitman 2 では、旧システムのサポートを維持し、出荷するコンソールで旧システムを入れてあります。しかしPC向けでは、3つの品質レベルから選択できるようになっていて、オーディオシミュレーションの品質のオプションとしてまとめてあります:

  • Base: オーディオの強化なし。フィジカルコアが4コア以下のCPUでは、これがデフォルト。
  • Better: 新リバーブシステム。フィジカルコアが5コア以上のCPUでは、これがデフォルト。
  • Best: Betterと同じだが、最高品質のリバーブ設定を提供。フィジカルコアが6コア以上のCPUでは、これがデフォルト。

図 9のとおり、プレイヤーはAudio Optionsでオーディオシミュレーションの品質をコントロールできます。

9 9 オーディオシミュレーション品質の設定。

Wwiseの実装

Wwiseでリバーブエフェクトの品質レベルを数種類に分けて対応するには、図 10に示すようにリバーブバスの階層をコピーし、ハイクオリティ(HQ)バスで高品質のエフェクトを使うようにします。シミュレーション品質値に基づき、プログラムコードによって、正しいバス(スタンダードまたはHQ)が自動的に選択されます。

10 10 ハイクオリティのバスは、通常のリバーブバス階層のミラーである。

もう少し簡単に維持するには、階層を1つにし、各リバーブバスにエフェクトを2つとも追加しておき、ランタイムにグローバルRTPCReal-time Parameter Controls)を使い、コードでどちらかのエフェクトをバイパスさせるという方法もあります。

どちらの方法を使うにしろ、エフェクトのメディアをそれぞれ違うサウンドバンクに保存し、シミュレーション品質の設定値に基づいて正しいサウンドバンクをロードすれば、不要なメモリ使用のオーバーヘッドを回避できます。私たちは図 11のとおり、各レベルで違うコンボリューションリバーブのサウンドバンクを用意しました。

11  11 Hitman 2 のサウンドバンク構造

まとめ

この記事は、最近のCPUのマルチコアを活用することで、今まで演算負荷が高いために手の届かなかったゲームオーディオ品質向上の手法を、実現できる可能性を示しています。ここで取り上げたリバーブシステムの変更を、 Hitman 2 のプレイヤーたちは気づき、気に入ってくれました。オーディオシステムの並列化を改善したことで、CPUリソースが空き、オーディオチームやほかの担当部署によって有効利用されています。

一方で、この使用例も低スペックのマルチコアCPUの限界に、影響を受けています。今後、8コア以上のシステムの採用が広がり、ゲーム開発者が演算の並列化を重視し、オーディオミドルウェアの提供者がベクトル化を活用(例 Intel® Advanced Vector Extensions 2 (Intel® AVX2) Intel® Advanced Vector Extensions 512 (Intel® AVX-512)など)していけば、ゲームのサウンドにさらなるディテールや没入感が加わることが予想されます。

 
参考文献
 

このブログは、もともと Intel のために執筆されたものです。

 

ステパン・ボエフ(Stepan Boev)

リードオーディオプログラマー

IO Interactive

ステパン・ボエフ(Stepan Boev)

リードオーディオプログラマー

IO Interactive

IO Interactiveのリードオーディオプログラマー。ビデオゲーム業界歴14年の間に、Hitman、Far Cry、World in Conflictシリーズなどのゲームに携わる。ゲームオーディオの表現力、没入感、そしてディテールに強いこだわりを持ち、複雑なプログラミング問題の解決やパフォーマンス最適化などにも熱心に取り組む。

コメント

Replyを残す

メールアドレスが公開されることはありません。

ほかの記事

WwiseのCPU最適化ガイドライン

13.6.2017 - 作者 アドリエン・ラヴォア(ADRIEN LAVOIE)

ハイブリッドインタラクティブミュージックの時代が到来?PART II - テクニカルデモ

このブログのPART Iで、Hybrid Interactive...

8.5.2018 - 作者 オリヴィエ・ドリヴィエール(OLIVIER DERIVIÈRE)

Wwise 2019.1 がリリースされました!

最新版Wwise 2019.1がついにWwise Launcherからダウンロードできます。 このバージョンには、GDC19来場者皆さまから大好評の Voice...

2.4.2019 - 作者 Audiokineticについて

UIデザインを切り口に、UIオーディオを考える – パート 1

12.3.2020 - 作者 ジョセフ・マルチューク(JOSEPH MARCHUK)

Aporia: Beyond the Valley - 幽霊のサウンドをつくる

7.7.2020 - 作者 トローオルス・ニガルド(TROELS NYGAARD)

Mastering Suiteの裏にあるストーリー: オーディオマスタリングをゲーム内で

ゲーム業界のクリエイティブ系の人やエンジニアたちがコラボレーションを続けた結果が、このMastering...

23.7.2020 - 作者 ダニエリ・シェンブリ(DANJELI SCHEMBRI)

ほかの記事

WwiseのCPU最適化ガイドライン

ハイブリッドインタラクティブミュージックの時代が到来?PART II - テクニカルデモ

このブログのPART Iで、Hybrid Interactive...

Wwise 2019.1 がリリースされました!

最新版Wwise 2019.1がついにWwise Launcherからダウンロードできます。 このバージョンには、GDC19来場者皆さまから大好評の Voice...