パート1と2では、デザイナーたちがインパルスレスポンス（IR）の初期の部分で起きる音響現象に、どのように着目し、そこから産出されるオーディオを、どのように自分の好みに合わせてWwise Spatial Audioでオーサリングするのかを見てきました。今回は同じように、IRの後期の部分について考えてみたいと思います。
図 1 - インパルスレスポンス（IR） [20]
ルームやポータルを使い、環境情報を送る
WwiseのSpatial Audioにおける後期残響（Late Reverberation）のデザインアプローチは、Aux sendを使って環境をオーサリングした従来の方式、つまりゲームのビジュアル性や価値観に合うように自分が選んだリバーブエフェクトを微調整していく方式と、酷似しています。実は、Spatial Audioの考え方はまったく同じで、唯一の違いは、あなたの代わりにエンジンがスペーシャリゼーションを施してくれるということで、ルーム（Room）やポータル（Portal）を通して、活き活きとさせてくれます。
従来のAux send方式では、環境または環境タイプにリバーブエフェクトのAuxバスを割り当てて、その環境（またはリスナー）があるバスに、ボイスを送り込みますが、「ルーム」は、この流れを軽量化したものです。ルームとポータルを使う場合は、ルームとルームの間にポータルが入って連結してくれます。音のあるルームで励起が起きると、音はルームとポータルを経由してリスナーに向かって伝搬します。シグナルフローは、それぞれのルームのAuxバスに送られ、複数のAuxセンドを順番に通り、リスナーに到達します。回折や、隣のルームの残響音場のスペーシャリゼーションとスプレッドは、ポータルが行います。私たちのチームメンバーのネイサンが、このシステムをブログでうまく解説しています [21]。
スペーシャルオーディオの2つのパラダイム
パート1・2で解説したレイキャストエンジンと、このルームとポータルのシステムは、別々のパラダイムにのっとったもので、それぞれ異なるデザインワークフローがあり、パフォーマンス上の配慮も違います。ここでは、前者のパラダイムをジオメトリによる音響シミュレーション（Geometrical Acoustic Simulation）と呼び、後者のパラダイムを音響パラメータによるリバーブエフェクト制御（Reverb Effect Control from Acoustic Parameters）と呼ぶことにします。
ジオメトリによる音響シミュレーション
ジオメトリによる音響シミュレーションでは、三角形やマテリアルを使いますが、デザイナーがコントロールできるのは、原則的にマテリアルの吸収率と、距離カーブや回折カーブ（Wwiseの場合）です。
IRの後期部分をレイベース方式でレンダリングすると、計算が急激に複雑になります。実際、このメソッドを安易に拡張すると、エコーの密度が弱すぎるため、荒々しい、またはザラザラとした音になってしまい、後期残響さえ再現できなくなってしまいます。日常生活では、サーフェススキャタリングやエッジ回折の要素は、反射の次数が一定数を超えると、実は鏡面反射に勝る傾向があります [22]。つまり最終的には、単純なレイベース方式のモデルで予測できる波面の数、そして、この方式で使う単純化されたジオメトリで許容される波面の数よりも、かなり多くの波面がリスナーに到達するのです。
しかし、この難題を乗り越えるために、ディテールを極小レベルまでこだわるのは実用的ではありません。逆に、納得のいく結果を得るためにレイベース方式のモデルにstochastic（確率論的な）要素が追加されることが多く、グラフィックで言えば、メッシュだけに頼るのではなく、全体の見た目をよくするためにシェーダーや拡散のライティングのテクニックを使うのと似ています。
オーディオ No.1 - 次数16の鏡面反射だけの反射によるIR。Wwise Reflectを細工したバージョンを使い、やや台形型の直方体で、回折を無効にしたものに、デジタルインパルスを送り込みました。
図 2 - CPU負荷（y軸）と、シミュレーション長さ（x軸）の関係。シミュレーションの長さは、残響時間にゆるく結びついていますが、同時に、レイが徐々に多くのジオメトリに反応していることを意味しています。実線のグラフはブルートフォース的なアプローチを表し、正確な後期残響の計算コストが極めて高いことが分かります。点線は、推定値を活かしながらパフォーマンスを現実的なレベルに維持した場合です。
Oculusの音の伝播の技術は、こちらのパラダイムに従っています。レイトレーシングを使って、高次の現象を計算し、アーリーリフレクション（Early Reflection）と後期残響の両方をレンダリングします [23]。後期残響の極めて複雑な性質を避けるために、複数のテクニックを用いていると予想されます。デザイナーは主に、マテリアルのプロパティで工夫しながら、音を微調整します。
音響パラメータによるリバーブエフェクト制御
2つ目のパラダイムは、音響パラメータを消費し、リバーブエフェクトを使ってIRをレンダリングするものです。デザイナーはリバーブエフェクトの設定やセンドレベルなどを調整し、ランタイムには、音響パラメータが力を発揮してその設定をモジュレーションします。このアプローチだと、CPU使用のほどんどが、音の伝搬の演算ではなくリバーブエフェクトの処理となり、負荷が比較的軽くなります。
音響パラメータはその本質からして、ゲーム中のリスナーやエミッターの場所に左右されるものです。ただし、その性質や、それを取得する過程が、ソリューションによってかなり異なります。必要となるスペーシャルサンプリングも様々ですが、IRの初期部分のリバーブエフェクトに必要な情報量の方が、後期部分よりも多いというのが、一般的な目安です。
実際、IRの初期部分を構成するオーディオイベントの方が方向性が分かりやすく、方向性は環境内にあるエミッターやリスナーの場所で大きく変わります。例えば、直接パス（回折パス）の方向性は、エミッターとリスナーの位置関係や、妨げとなる障害物の有無に、完全に依存します。アーリーリフレクションの方向性も似たようなものですが、近くの壁との距離も影響します。一方、IRの後期部分は方向性が薄く、リスナーに当たる波面は、一見ランダムな方向から到達するように思えます。よって、空間のサンプリングはおおざっぱで充分です。
図 3 - IRの各部分を正確にレンダリングしようとしたとき、ジオメトリ情報で変化する音響パラメータが、リバーブエフェクトを制御する上で必要とする、音響パラメータのスペーシャルサンプリングの程度。後期では、エミッターとリスナーが同じルームまたは環境の中にいて、互いにある程度近ければ、その位置関係はさほど影響しませんが、前期部分の方はより細かいサンプリングが必要です。スペーシャルサンプリングの密度が高いからといって必ずしもCPU負荷が大きくなるわけではありませんが、少なくともメモリ量は増え、パラメータを導き出す手間も増えます。
MicrosoftのProject Acousticsで開発されたソリューションは、ジオメトリ情報を活用する音響パラメータを使ってリバーブエフェクトを制御する方法です。パラメータ化のプロセスは自動で、オフラインで行う波動ベースのシミュレーションを使用します。抽出されたパラメータでリバーブエフェクトやセンドレベルを動かします [24]。このソリューションは直接パスを含むIR全体をカバーするので、比較的細かいグリッド（メートルの数分の一単位）で、エミッター・リスナーの各ペアに対して、すべての可能なポジションにおける、パラメータセットを計算します。
反対に、Wwise Spatial Audioにおけるルームの音響パラメータは、そのルームにどのAuxバスをアサインするかを知ることで成り立っています。現在はジオメトリから自動的に推定されるのではなく、デザイナーがそのジオメトリの音として適切だと感じるパラメータを、デザイナー自身が手作業でアサインしています。また、1つのルームに対して1つの音響パラメータの組み合わせしかないので、すでに触れたとおり、スペーシャルサンプリングはとてもおおざっぱです。
両パラダイムを使うWwise Spatial Audio
これまでの内容を、表にまとめます。
| ジオメトリ主導の音響シミュレーション | 音響パラメータによるリバーブエフェクト制御 | |
| デザイナーが制御 | 距離カーブ、回折カーブ、マテリアル吸収率 | リバーブ設定、センドレベル |
| エンジンのインプット | ジオメトリ、タグ付きマテリアル | 何らかの方法でジオメトリより抽出する、音響パラメータ |
| コスト | CPUコストは比較的高く、シミュレーションの長さと共に飛躍的に増加 | ランタイムは低コスト。初期IRをとらえるためには、パラメータ化に高精度のサンプリングが必要。 |
表 1 - ジオメトリによる音響シミュレーションと、音響パラメータによるリバーブエフェクト制御の、2つのパラダイム。
Wwise Spatial Audioでは、この2つのパラダイムの長所を、どちらも取り入れるようにしています。Spatial Audioのルームという概念に基づき、後期残響には「リバーブ制御」のアプローチに重きを置き、音響パラメータ数を最小限に抑えています。一方、直接パス [25] やアーリーリフレクションは、CPUコストがジオメトリ主導のシミュレーションの方が小さいので、このアプローチを採用しています。
2つのパラダイムの組み合わせ方を、下図に示します。
図 4 - ダブルアプローチ。Wwise Spatial Audioは、IR初期部分ではジオメトリ主導（Geometry-Driven）のシミュレーションのCPUコストが低いのでこれを採用し、後期部分はスペーシャルサンプリングが荒くても済むリバーブエフェクト制御（Reverb Effect Control）を使います。
リバーブの回転
前述のとおり、1つのルームに対して音響パラメータは1セットしかないので、ルームは、室内のエミッターやリスナーのポジションに配慮しない情報を、リバーブに送ります。ところがルームには オリエンテーション も定義されているので、リスナーに対するルームの相対的なオリエンテーション（向き）は、考慮することが可能です。そして実際に、3Dバスの「魔法」のおかげで、難なく考慮できます。
説明します。リバーブは、Auxバスに対してマルチチャンネルシグナルを出力します。このAuxバスがRoomゲームオブジェクトに結び付いていて、Roomゲームオブジェクトのオリエンテーションを、ゲームが定義します。そして、このルーム内にリスナーがいると、Auxバスのシグナルは、スプレッド値が100%に近いソースとして機能します。3D Spatialization Positionを設定してOrientationモードを選択すると、リスナーのルームに対するオリエンテーションに従って音場を回転します [26]。すると、リバーブから発せられるサラウンドサウンドは、まるでリスナーではなくワールドに結び付いているように感じられます。
図 5 - Wwise ProfilerのVoice Graphの、3Dバスなどを示したスクリーンショット。マルチチャンネルのリバーブ出力シグナルを、ルームとリスナーゲームオブジェクトの相対的なオリエンテーションに基づいて、ここで回転させます。なお、ルームリバーブに送られるエミッターはすべて、このリバーブによってモノにダウンミックスされるので、個々の方向性は失われます [27]。
さて、ここでリバーブから出力された音場を回転させる理由は？ほとんどの人工的なリバーブレーターは、等方性のシグナルを出す（つまり、どの方向からも均等にエネルギーがくる）ように設計されているので、回転させても違いは聞こえないはずです。Wwise RoomVerbのLRモジュールなどは、その一例です。ところが、同じリバーブエフェクトでもERモジュールは、ゲームのジオメトリに起因しない、はっきりとした方向性のパターンが示されます。また、現実の残響音も、例えば廊下やトンネルの中は異方性があるかもしれないとする研究があります [28]。つまり、本物のトンネル内でレコーディングしたマルチチャンネルIRを、Convolution Reverbで使って、Spatial Audio Roomバスにのせたとすると、ゲームの中のトンネルのオリエンテーションは、オリジナルのオリエンテーションを追うはずです。目立たないかもしれませんが、音のオリエンテーションが画像と必ず一致して、それがダイナミックに変化すれば、没入感の向上がはっきりと分かるはずです。あなたには、聞こえますか？
オーディオ No.2 - OpenAirのサイトにあるInnocent Railway Tunnelで録音された1次アンビソニックスIRの、2種類のバイノーラルレンダリング [29]。どちらも、Wwise Convolution Reverb、そしてGoogle Resonanceバイノーラルプラグインでレンダリングされていますが、1つだけ、回転を適用しました。差が分かりますか？トンネルのオリエンテーションは、分かりますか？
今後の展望
アーリーリフレクションと後期残響の境界をあいまいに
私たちの経験では、どのオーディオチームも自分なりのアプローチでゲームにスペーシャルオーディオを取り込み、様々なオプション機能を採用したり、異なるワークフローや価値観やシステムを使ったりして、そのゲーム固有の方法で全体を発展させて、唯一無二の作品にしようと努力します。私たちは、Wwise Spatial Audioで、それを実現しやすくすることが目標です。今後は、先ほど紹介した2つのバラダイムについて、次のように、どちらも作業を進めていきたいと考えています:
A. シミュレーション: 完全なIRを、ジオメトリやマテリアル特性からシミュレーションできるように。
B. リバーブの制御: リバーブエフェクトで、さらにゲームジオメトリ情報が役立つように。
この2つのパラダイムの合流の度合いを、皆さんが自由に設定して、開発中のゲームのシステムや価値観、そしてチームのワークフローや好みにしっくりくる形にできることを、私たちは願っています。
A. シミュレーション
完璧なIRのシミュレーションにつながる最初の一歩は、私たちのレイキャストエンジンの性能を向上し続けることです。その点、私たちはWwiseの次のリリースで皆さんに披露することを楽しみにしている進捗中の機能がありますが、これは、バジェットに合わせてジオメトリエンジンのパフォーマンスを加減できるものです。
B. リバーブの制御
ほかのアプローチと比べて、私たちのやり方の欠点は、ルームやポータルがジオメトリとは別個のものなので、手作業で構築する必要があることです。
1. ジオメトリの事前処理: 私たちはUnreal Engineインテグレーションで、この問題を軽減しようと懸命に努力しています。ルームやポータルのコンポーネントを追加し、ブループリントのサポートも追加しています。最近の弊社ライブストリームイベントで、ジオメトリを簡素化してルームやポータルにできる開発中の便利なツールを、少しご覧になったかもしれません [30]。
2. 同時に、リバーブとルームのマッピング「第一案」の自動提示を、改善しようと進めています。ルーム形状から、大まかなリバーブ特性を抽出することが目的で、あなたがすぐに作業開始できるように整えておき、必要に応じてこのルームを調整できるようにします。
また、RTPC経由でジオメトリの情報をリバーブに送るためのツールを、さらに多く提供する予定です。お楽しみに！
簡素化と、汎用化
ブログの第１弾で、私はサイモン・アシュビーの言葉を引用して、「ミキシングのルールをコントロールするのは自分だけど、最終的に決めるのは、このシステムだ」と言いました。つまり、物理的な数値（距離や回折角度など）を、様々なツールやカーブの設定で「再解釈」してからオーディオシグナル処理に送り込む自由度があります。この自由がどれだけ大切かについても、ブログで探ってきました。それでも結局、どんな状況でも対応できるのか、と不安になることがあります。うまくいくのか？絶対に成功するように、私たちができるお手伝いは？考えられるいくつかの手段:
- 問題のあった場合にデザイナーが「オーバーライド」できるツールを提供することで、制御機能をさらに強化。
- 基盤となっている音響モデルを改善して、より自然に汎用化できるようにする。
- 柔軟性を少し犠牲にしてでも、規則を曲げやすいように設定をシンプルにする。
どれも、反対方向を向いているような方針です。あなたが求めている方向に、私たちの開発が進むように、あなたのご意見とご参加を私たちが望んでいることは、言うまでもありません。
コメント