|
Wwise SDK 2019.2.15
|
Spatial Audio モジュールは、空間オーディオに関連するいくつかのサービスを公開しています。特に：
- 与えられたジオメトリのReflectの画像ソースを計算する;
- RoomやPortalからの音の伝播を、3Dバスをコントロールしてモデル化します;
- ジオメトリのエッジにおける、オブストラクションを受けた音源の回折をモデル化します;
- Wwise Reflect のraw API に簡単にアクセスできます。
中で、それは：
- ゲームオブジェクトと、そのプロパティ（ポジション、Aux センド、オブストラクション、オクルージョン）を管理して、3Dバスをコントロールします;
- スペーシャルオーディオのゲームオブジェクトのポジション（複数のポジション）やAuxセンドを、コントロールします;
- ジオメトリに従った音の反射や、回折アルゴリズムを実行します;
- Wwise Reflect のデータをパッケージ化します。
次のフローチャートに示すように、Wwiseサウンドエンジンの一部をラップするゲーム側のSDKコンポーネントです。
Spatial Audioの概念
Spatial Audioに関連する音響の基礎概念を、以下に簡単に説明します。
Diffraction（回折）
回折は、音波が小さい障害物に当たったり、大きな障害物の端や開口部に当たったりして、それを回り込んでいく場合に発生します。開口部（ポータル）を経由して横方向に向かって伝播する音を表すので、開口部のすぐ前にないリスナーにも聞こえます。回析を聞いたプレイヤーが、音のエミッタと自分の間に存在する通り道を感じ取るヒントとなるので、一般的にゲームで非常に大事です。下図は、平面波の音場の図で、右上からきて、図の中央に始まる有限の面（黒い線）に当たる様子です。この端によって発生した摂動を、回析と呼びます。左側はビューリージョンで、飛行機の波は影響を受けずに通過します。右上のリージョンがリフレクションリージョン（Reflection Region）で、表面の反射が起きて、入射波とミックスされて、このようなギザギザしたパターンになります。右下のリージョンはシャドーリージョン（Shadow Region）で、回折の影響が大きい場所です。これは大まかな図で、実際には音場がリージョンの境界線でも連続していて、端の回折はビューリージョンでも発生していますが、入射波そのものと比較すると、一般的に無視できる程度です。
端を点音源として解釈して、距離と共に振幅が減少します。また、高周波の振幅の方が低周波よりも速く減少するので、ローパスフィルタで適切にモデル化できます。Wwise Spatial Audioでは、回折のモデル化に2つのAPIを使います。Rooms and Portalsでポータルの回折をモデル化する方法については、Rooms and Portalsの 回折（diffraction） を、エミッターとその初期反射の回折をモデル化する際にジオメトリを考慮する方法については、 Geometry APIを使った回折（diffraction）と透過（transmission）のシミュレーション を参照してください。
透過
音の透過（transmission）も、重要な音の現象として、Wwise Spatial Audio内でモデル化されています。透過とは障害物を透過する音のエネルギーのことで、透過損失（transmission loss）は、障害物によって失われたエネルギーの割合を示します。透過は、反射した音波で損なわれたエネルギーの割合を表す吸音（absorption）とは、異なります。2つの媒体の境界では複雑な反応が起きますが、反射エネルギーと吸音エネルギーの比率は、物体の表面の特性によって定義されると言える一方、透過したエネルギーと透過率の関係は、障害物の大きさや形状や密度によって変わってきます。
障害物の材質が密度の大きいコンクリートなどであれば、透過によって耳に届くエネルギーの割合は、回折と比較するとかなり小さくなり、特に近くに開口部があるときなどはそうです。ところが近くにそのような開口部のない場合や、密度がより小さい材質、例えば木材やガラスなどの障害物であれば、透過の貢献度が大きくなるので、それをシミュレーションすることが大事になります。
ルームカップリング
一定の時間が経過すると、サウンドエミッターのある環境の音響特性に依存した拡散音場がつくられます。一般的にゲームで実装するには、関連する環境を表現できるように、リバーブエフェクトのパラメータを調整して使います。拡散音場は、開口部を通過したり壁を貫通したりしてリスナーに到達することもあり、そこでリスナーの環境が励起されます。ルームカップリングとは、音響エネルギーが、1つの環境または部屋から、ほかの環境または部屋へと伝達される様子を指し、リバーブとも呼ばれます。ゲームでは、ある部屋のリバーブのアウトプットを、次の部屋のリバーブに送信してこれを再現することが多いです。
オブストラクションとオクルージョン
オブストラクションは幅広い音響現象を示すもので、音波が障害物に当たった時に発生する全ての現象を指します。オクルージョンは似ていますが、暗に音が障害物の周りを回れないものとしています。Wwiseサウンドエンジンは、ゲームがゲームオブジェクトにオブストラクション値やオクルージョン値を設定することを許容しますが、それがゲーム全体を対象（グローバル）とするボリューム、ローパスフィルタ、ハイパスフィルタなどのグラフにマッピングされます。2つの違いは、オブストラクションがアクターミキサーやバスと、その出力バスの間の、ドライ・直接シグナルだけに影響する一方、オクルージョンはAUXセンドにも影響します。つまり、オブストラクションはエミッタとリスナーが同じルームにいる時の障害物によるオブストラクションをよくエミュレートできるのに対して、オクルージョンは閉ざされた壁を通るトランスミッションのモデル化に適しています。
APIの概要
Spatial Audio の関数と定義は in SDK/include/AK/SpatialAudio/Common/にあります。 その主な関数はネームスペース AK::SpatialAudioに公開されています。APIカテゴリが、4種類あります:
- Basic Functions（基本機能）
- Rooms and Portals API（ルームとポータルのAPI）
- Geometry API（ジオメトリのAPI）
- Wwise Reflectを直接アクセスするためのヘルパー機能（いわゆる生のイメージソース）
Rooms and Portals APIは、シンプルでハイレベルのジオメトリ抽象化で、ほかの部屋にあるサウンドエミッタの伝播のモデル化に使用します。Geometry APIは、Wwise Reflectでダイナミックアーリーリフレクションをシミュレーションしたり、ジオメトリによるディフラクションを計算したりするときに、三角形をそのまま使います。Spatial Audioは、Wwise Reflectの生APIを直接アクセスするためのヘルパー機能も公開しています。
Basic Functions（基本機能）
AK::SpatialAudio::Init() を使用してSpatial Audioを初期化します。
Spatial audioを利用するには、まず1つのゲームオブジェクトを明示的にSpatial Audio Listenerにアサインする必要があります。それには、希望するリスナーのIDを、 AK::SpatialAudio::RegisterListener() をコールして渡します。このゲームオブジェクトはサウンドエンジンにおいても、リスナーとして登録してアサインする必要があります。Sound Engine内のリスナーについての詳細は、 リスナーの統合 を参照してください。
ゲームオブジェクトが Spatial Audio Emitter となるのは、オーサリングツール内でSpatial audioの設定を1つ以上有効にしてある音を、再生したときです。
- Room reverbを有効にするには、General settingsタブで、その音のGame-defined auxiliary sendsを有効にします。
- Reflection処理を有効にするには、General settingsタブで、その音にEarly reflectionバスをアサインします。
- Diffraction処理を有効にするには、Positioningタブで、その音のEnable diffractionボックスをチェックします。
ゲームオブジェクトのポジションは、エミッタの場合もリスナーの場合も、 AK::SoundEngine::SetPosition を使ってサウンドエンジンに送られます。Spatial AudioがそのPosition情報をSound Engineから直接取得し、ReflectionやDiffraction処理を行うソースのポジションを判断します。
 |
警告: 現在、Spatial Audioはトップレベルのリスナー1つだけに対応しています。 |
|
警告: ほとんどの場合で、マルチポジションとSpatial Audioを一緒に使うのは避けるべきで、これは、PortalのInterpolation（補間）、Diffraction（回折）、Reflection（反射）の処理に、ソースポジションが1つだけ必要だからです。ゲームオブジェクトに複数のポジションを設定すると、Spatial Audioの計算に使われるのは、最初のポジションだけとなります。 |
Geometry APIの使用
Geometry APIによって、三角形メッシュをゲームからWwise Spatial Audioに送ることができますが、それには以下の2つの目的があります:
- エミッタからリスナーに伝播する音の、エッジ回折のシミュレーション（ Geometry APIを使った回折（diffraction）と透過（transmission）のシミュレーション 参照）。
- Wwise Reflectを使ったアーリーリフレクションのシミュレーション（ アーリーリフレクションのシミュレーションにおける、Geometry APIの使用 参照）。
ジオメトリの表現方法
ゲームのジオメトリはAK::SpatialAudio::SetGeometry()経由でWwise Spatial Audioに送られ、AkGeometryParams構造を使い表現されます。その中身の概要を、以下で説明します:
- Vertex（AkVertex）はアレイ
AkGeometryParams::Verticesで定義され、これは三角形とは別であり、三角形のアレイAkGeometryParams::Trianglesの中の各三角形は、Vertexアレイのインデックスを参照します。 - 各三角形に
AkAcousticSurface構造へのインデックスも含まれ、これによりAcoustic Textureやディスクリプション文字列が定義されます。 - Acoustic Surfaceと三角形との関係は、ユーザーが決めます。例えば、三角形ごとに異なるSurfaceを適用したり、全三角形に同じ1つのSurfaceを適用したり、その間をとったり、自由に選択できます。
- Acoustic surfaceの設定は、任意です。Surfaceの音響特性をカスタマイズすることが望ましくない場合は、三角形をAK_INVALID_SURFACEのままで残し、NULLを
AkGeometryParams::Surfacesに送り、AkGeometryParams::NumSurfacesを0に設定することができます。
スペーシャルオーディオ用の三角形メッシュを作成するには
一般的に、どのような三角形メッシュもWwise Spatial Audioで使えますが、注意すべき点がいくつかあります。
- できるだけシンプルなメッシュにします。音響計算で大量のレイトレーシング（ray tracing）操作が行われるので、負荷が重くなる可能性があります。必要最小限の数の三角形でシーンを表現することが望ましいです。
- 三角形は、必ず両面があります。音響反射は三角形の両面で発生するため、容積のないメッシュを作成した方が有利な場合があります。例えば壁は、箱ではなく面とします。
- 重複する頂点は「溶接する」ようにしてメッシュを継続させます。つまり、つながった2つの三角形は、どちらもVertexアレイの、同じ2つの頂点を参照するようにします。これはディフラクション計算に重要で、従わない場合はメッシュを通して音が漏れてしまう可能性があります。
- 頂点の座標は、必ずワールド空間内にあるものとします。
- 複数のメッシュを、複数のコールでスペーシャルオーディオに送り、ジオメトリを設定する場合は、同じ頂点を参照することはできないので、接続または連続したメッシュとして捉えられません。この場合、複数のメッシュに渡るエッジに関しては、回折エッジが生成されません。
- メッシュに縮退三角形を含めることはできません。必ず三角形の面積を0より大きくします。
- これ以外にも、あなたのジオメトリに基づく回折を使うには、ルールがいくつかあります。詳細は、 Geometry APIを使った回折（diffraction）と透過（transmission）のシミュレーション をご覧ください。
アーリーリフレクションのシミュレーションにおける、Geometry APIの使用
Geometry APIはエミッタやリスナーのポジションと、ゲームの（簡素化されることが多い）ジオメトリの三角を使って、ダイナミックアーリーリフレクションをシミュレーションするためのイメージソースを計算しますが、これはWwise Reflectプラグインと連結して行います。サウンドデザイナーは、距離やマテリアルに基づいてWwise Reflectのプロパティを調整することで、イメージソースポジションのトランスレーションを直接コントロールします。
ジオメトリによって変化するアーリーリフレクション（ER）の概要について、掲載中のブログ Image Source Approach to Dynamic Early Reflectionsや、Creating compelling reverberations for virtual realityなども参考にしてください。
 |
注釈: 反射の「次数」は、波面がリスナーに到達する前に、いくつの面に反射したのかを表します。例えば直方体の形をした部屋には6つの壁面がありますが、この部屋の一次反射をシミュレーションすると、1つのエミッタに対し、6×1のアーリーリフレクション、別名イメージソースが、発生します。その結果、反射の数は合計6です。さらに、2次反射のシミュレーションをすると、1次反射が6つあり、それぞれに残りの壁面の数、つまり5をかけるので、6×5の2次反射が追加されます。その結果、1つのエミッタに対し反射の数は合計36となります。このように、反射の数は次数とともに指数関数的に増加します。 現在、Wwise Spatial Audioは4次反射までシミュレーションできます。反射の次数はグローバル設定で、 AkSpatialAudioInitSettings::uMaxReflectionOrder initで設定します。また、ダイナミックに変化させるには、 AK::SpatialAudio::SetReflectionsOrder を使ってください。 |
Wwiseプロジェクトセットアップ
サウンドがダイナミックなアーリーリフレクションに対応できるようにするには、 Wwise Reflect プラグインのホストであるAuxiliary Busを示すために、Wwise AuthoringツールのGeneral settingsタブで、Early reflectionsバスをアサインする必要があります。Spatial Audioが、このバスと特別なAux send接続を確立させます。また、Sendボリュームを設定できます。
環境リバーブの場合は、リスナーゲームオブジェクト上にAuxiliary Busを作成し、同じバスやエフェクトインスタンスを、複数のエミッタが共有できるようにするのが一般的です。これは、Spatial Audioのレイトリバーブに使うRoomでも同じですが、アーリーリフレクションでは異なり、その場合は各エミッタに、そのエミッタ独自のポジションで決まるリフレクションが一式あります。代わりにERバスインスタンスがエミッタのゲームオブジェクト上で作成され、各エミッタはそれぞれ、Auxiliary Busの違うインスタンスに対して送信します。これは、以下の「Wwiseプロジェクト設定」のVoices Graph スクリーンショットに示されています。
Wwiseプロジェクトの動的環境効果を効果的に処理するためには、バス構造設計の次の点を理解する必要があります。
Attenuationの設計
Spatial Audioを使うサウンドでAttenuation（減衰）カーブを設計する際に、効率的な計算を行うために注意すべき重要な点が1つあります。アーリーリフレクションのAuxiliary Busをアサインしたサウンドや、AuthoringツールでEnable diffractionを有効にしたサウンドは、Attenuationをアサインするときに半径（Radius）を有限にして、パス（path）計算を制限する必要があります。
Spatial Audioではリフレクションとディフラクションの両方のパス計算において、伝播可能な最大距離を、音の減衰に基づいて判断するので、Maximum attenuation distanceが、理にかなった値であることが重要です。また、減衰がプラットフォームの指定ボリューム閾値よりも低くならない場合は、その音のRadiusが実質的に無限となります。その場合、リスナーがワールド内のどこに配置されていても、Spatial Audioはリフレクションやディフラクションを計算しようとします。Output Bus volumeカーブと、Auxiliary send volumeカーブは、どちらもカーブ右端の最終ポイントが、ボリューム閾値よりも低い位置になるようにし、Spatial Audio計算がエミッタGame Objectの周りの有限半径の中に納まるようにしてください。なお、Volume threshold（ボリューム閾値）はAuthoringツールのProjectメニューにある、Project settingsダイアログで定義します。
|
注釈: あるGame Objectで複数のアクティブサウンドを再生中で、それぞれに異なるAttenuationがアサインされている場合は、最大のAttenuation半径を採用してパス処理を制限します。パス処理は1つのGame Objectに対し1度だけ行われ、そのパスを、複数のサウンドで必要に応じて再利用します。 |
Auxiliary Busデザイン
通常、様々なAuxiliary Busが異なる環境を表すために使用され、これらのバスは、これらの環境のリバーブ特性をエミュレートする異なるリバーブShareSetsをホストすることができます。SpatialAudioでWwise Reflect よって処理されるような動的ERを使用する場合、後期リバーブは補助バスのリバーブを使用して設計することができます。ただし、これらのリバーブ（該当する場合）のERセクションを無効にしたい場合があります。これはWwise Reflectで処理する必要があるためです。
一方、Wwise Reflectは後半の残響に使用されるAUXバスと並行して実行する必要があります。下の図は、EarlyReflectionsバスの下にある3つの補助バスに、それぞれWwise ReflectのShareSet が異なる一般的なバス構造を示しています。この設計では、初期反射を生成するために、わずかなShareSetsしか使用しないことに注意してください。これは、このEffect の「空間的要素」がランタイムにゲームジオメトリによって駆動されるという事実によって動機づけられます。ここでは、他のオブジェクトが発する音よりも、プレーヤー（リスナー）が発する音に対して異なる減衰カーブが必要なので、異なるShareSetを使用します。
バス インスタンス
ERバス（ Wwise Reflect をホストするバス）は、ERバスをアサインしたサウンドを再生中のゲームオブジェクトの数と、同じだけの数のインスタンスとして、存在します。これは重要で、なぜなら、イメージソースの位置がエミッタのポジションに基づいているからです。ERバスのルーティングを正しく設定するには、下図のとおり、Listener Relative Routingというチェックボックスを有効にしておく必要があります。これを行うことにより、ERバスの様々なインスタンスによって生成された信号は、下流の次のミキシングバスの単一インスタンスに適切にミックスされます。この単一のインスタンスは、プレーヤー（またはカメラ）に対応する、通常は最終的なリスナーであるこのエミッターを聴いているゲームオブジェクト（AK::SoundEngine::SetListeners 経由で設定）に対応します。
同じゲームオブジェクトで再生中の複数のサウンドに、それぞれ異なるアーリーリフレクションのAuxiliary busがアサインされている場合は、そのバスの複数のインスタンスが、同じエミッタゲームオブジェクト上で作成されます。Spatial Audioで実行するリフレクション計算は、依然としてゲームオブジェクト1つに対して1回だけですが、結果は Wwise Reflect プラグインの、2つの別々のインスタンスに送られます。こうすることで、ユーザーはサウンドごとに、このプラグインの異なるシェアセットを使い、リフレクションカーブをカスタマイズできます。
|
警告: ERバスのListener Relative Routingを有効にし、すべてのエミッターインスタンスをリスナー側のバスに確実に合流させる必要がありますが、Wwiseで3Dスペーシャリゼーションを二重に行ってしまうのを避けるために、3D SpatializationモードはNoneに設定します。同様にAttenuationは、Wwise Reflectのイメージソースカーブの上にさらに減衰を追加したい場合を除き、適用しないようにします。 |
後期反響に送信する初期反射
また、遅れた残響を処理するために使用された補助バスにゲームオブジェクト（エミッター）が送信されるため、ERバスと後期リバーブバスとの間にも接続が確立されます。これは、生成されたERが後期リバーブを色づけして「緻密化」するために利用されるため、通常望ましいことです。 これを有効にするには、ERバスでゲーム定義の補助送信を使用するチェックボックスを有効にする必要があります。下のVolumeスライダを使って、後期リバーブに送る初期反射の量とダイレクトサウンドのバランスを合わせることができます。
次の図は、前の説明の実行時イラストです。以下が図中で確認できます:
- Weapon Fire SWは、Early Reflectionセンドのため、FirstPerson （アーリーリフレクション）バスへ送られます。
- このFirstPersonバスは、FirstPersonCharacterゲームオブジェクトのスコープ内にあります。よって、ほかのゲームオブジェクトは、予定どおり、このFirstPersonバスの別のインスタンスへと送られます。
- FirstPersonバスから、Mezzanine2 Auxバスへ、センド接続があり、その理由は、 Use game-defined auxiliary sends が有効になっているからです。
- FirstPersonのアウトプットバスであるBinauralは、リスナーのスコープ内にある、つまりPlayerCameraManagerであり、その理由は、FirstPersonバスで Listener Relative Routing オプションを有効にしてあるからです。すべてのアーリーリフレクションバスのインスタンスで、このオプションを有効にしておくべきで、そうすれば、どれもが、リスナーの1つのBinauralバスインスタンスに返します。この設定を怠ると、エミッタゲームオブジェクトで、Binauralバスの別のインスタンスが誤ってインスタンス化されてしまいます。
- FirstPersonバスと、Binauralの各バスの間で、距離による減衰はなく、その理由は、ERの減衰が、すでに Wwise Reflect 内で設定されて適用されているからです。
Acoustic Textureを使用する
各反射三角形について、ゲームはマテリアルのIDを渡します。これらのマテリアルは、Virtual Acoustics ShareSetsのAcoustic Texture の形式でWwiseプロジェクトで編集されています。ここで、各マテリアルの吸収特性を定義することができます。
ルームとポータルを使用する
Wwise Spatial Audioでは、後期残響を設定するのにリバーブEffectやAux sendを使います。このワークフローを実現するためにWwise Spatial Audioは、Rooms and Portalsというシンプルかつハイレベルで抽象的なジオメトリを公開し、ほかの部屋に配置されたエミッタの音の伝播を効率的にモデル化します。部屋によって変化する音の伝播の主な性能は、リバーブの回析（diffraction）、カップリング（coupling）、スペーシャリゼーション（spatialization）です。サウンドデザイナーがWwiseで使っているツールを応用しているので、オーディオへ変換された結果をサウンドデザイナーが完全にコントロールできます。さらに、ゲームエンジンに左右されるようなレイキャストに基づくオブストラクションは、ゲームエンジンによってかなり異なり、パフォーマンス上の負荷が一般的に大きいので、リスナーと同じ部屋から近いエミッタだけに制限することができます。なお、Geometry APIを使ってオブストラクションを完全にWwise Spatial Audioに任せてしまうことも可能です（ Geometry APIを使った回折（diffraction）と透過（transmission）のシミュレーション 参照）。
ルームには次元がなくポータル経由でつながっていて、それらが集合してルームと開口部のネットワークができあがり、これを通して別室で発生した音がリスナーに伝わります。Spatial Audioはこのネットワークを利用して、ドライシグナルの経由距離、予想される発生位置、回析角などを修正します。回折角（diffraction angle）はオブストラクションにマッピングしたり、デザイナーがプロパティ（ボリューム、ローパスフィルタなど）にRTPCで関連付けたDiffractionという組み込みゲームパラメータにマッピングしたりします。また、Spatial Audioでは、隣接するルームの リバーブをそのルームのポータルに配置して、リスナーのいるルームのリバーブにカップリングできるように3Dバスを使うこともできます。最後に、ルームにオリエンテーション（方向）も設定されているので、ルーム内でそのルームのリバーブから出た拡散音場は回転してからリスナーに届けられることで、リスナーの頭の中ではなく、ゲームのジオメトリに合わせています。
APIの概要
エミッタゲームオブジェクトのRoom reverbを使えるようにするには、Wwise Authoringツールで Use game-defined auxiliary sends チェックボックスを有効にします。ゲームからリクエストされたGame-defined sendsがあれば、それに追加するかたちで、このRoomに対するセンド（send）がSpatial Audioによって適用されます
Roomバスのポジショニング設定を正しく選択する必要があるので、 Listener Relative Routing を有効にし、3D Spatializationは "Position And Orientation" に設定し、 Use game-defined auxiliary sends を有効にしてください。あるいは、バスを作成するときにPresetの Room Auxiliary Bus を使います。
あなたのマップやレベルのジオメトリをもとに、ルームやポータルを AK::SpatialAudio::SetRoom や AK::SpatialAudio::SetPortal を使用して作成する必要があります。ルームやポータルの設定をランタイムに変更することが可能で、ランタイムに同じIDでファンクションをもう一度コールします。続いてゲームが各エミッタやリスナー用に AK::SpatialAudio::SetGameObjectInRoom をコールして、それらがどのルームにいるのかをSpatial Audioに伝えます。Spatial Audioはルームに決まった位置や形や大きさがあるとは、とらえていません。このため形状に制限はありませんが、オブジェクトがどのルームにあるのかを判断するコンテインメントテストの実行は、ゲーム側の責任です。
|
警告: ルームIDに注意してください。ゲームオブジェクトとスコープが同じなので、絶対にゲームオブジェクトで使われているIDを使用しないでください。 |
|
警告: 裏の仕組みとして、Spatial AudioはそれぞれのルームをゲームオブジェクトとしてWwiseに登録しています。ユーザーは、アンビエンスやルームのトーンサウンドのために、このゲームオブジェクトに対しイベントをポストすることができますが、 AK::SoundEngine へのコールの中で、オブジェクトのポジションやGame-defined sendsを修正しようとしないでください。 |
最も重要なルーム設定が AkRoomParams::ReverbAuxBus で、エミッタがそのルームにいるときにどのAuxバスにセンドするべきかを、Spatial Audioに知らせます。ほかの設定について、以下のセクションで説明します（spatial_audio_roomsportals_using3dreverbs、 透過 を参照）。
ポータルは、2つのルームの間の開口部を表します。ルームと違いポータルには位置や大きさがあるので、Spatial Audioが独自にコンテインメントテストを実行できます。ポータルの大きさは、ポータルの設定である AkPortalParams::Extentで決まります。WidthとHeight（XとY）はSpatial Audioで回折とスプレッドを計算するのに使われ、Depth（Z）はSpatial Audioで2つの隣接するRoomにおいて、Auxiliary sendレベル、Room Objectの配置、Spread（3D Spatializationで使用）を細かく調整してスムーズにトランジションを行う範囲を、定義します。詳細は、以下のセクション 3Dリバーブを使う 、 ゲームオブジェクトについて を参照してください。また、ポータルを有効にしたり（開いたり）、無効にしたり（閉じたり）するのに、 AkPortalParams::bEnabled ポータルの設定を使用します。
Spatial Audioのエミッタと AK::SoundEngine::SetMultiplePositions を一緒に使うことに関しては、Spatial Audioがリフレクション、ディフラクション、ポータルトランジションなど様々な計算に最初のポジションしか使わないので、 注意してください。ルームセンドを使うゲームオブジェクトに対し、 AK::SoundEngine::SetMultiplePositions を使うことは可能ですが、もしゲームオブジェクトがポータルを通過している場合は、最初のポジションが、2つのルームの間のクロスフェードに使われることに留意してください。また、ゲーム側が AK::SoundEngine::SetGameObjectAuxSendValues をSpatial Audioルームと組み合わせて使うことも可能です。ゲームのセンドが、ルームオブジェクトやAuxiliary busのセンドに追加されます。詳細は、 複雑なルームリバーブの実装 を参照してください。
また、Spatial Audioがオブストラクションやオクルージョンを、それぞれディフラクションやトランスミッションのモデル化にも利用しますが、それでも AK::SoundEngine::SetObjectObstructionAndOcclusion や AK::SoundEngine::SetMultipleObstructionAndOcclusion を、Spatial Audioエミッタと一緒に使うことができます。APIで決まるオクルージョン値やオブストラクション値が、Spatial Audioで決まる値と競合することがあれば、サウンドエンジンは、両者の最大値を使います。オブストラクションやオクルージョンの詳細と、それらをSpatial Audioのルームやポータルでどのように使用するかについては、 ほかのルームの音伝播のモデル化 や、 同じルームの音の伝播を、ゲーム側でモデル化 のセクションを参照してください。
このAPIの使い方を説明するデモページが、Integration Demoサンプル（場所はSDK/samples/IntegrationDemo）にあります。Demo Positioning > Spatial Audio: Portals にあります。
ObstructionやOcclusionと、PortalのTransmissionやDiffractionの違い
Wwise Spatial Audioに関しては、ほかのルームからの音の伝播は、Rooms and Portalsの抽象化だけで管理されています。リスナーまで、開いたポータルを通る伝播パスが1つ以上あるようなルームは、ObstructionまたはDiffraction組込みゲームパラメータを使い、ディフラクション（回折）をシミュレーションします。さらに、壁を通る音の伝達をモデル化するために、ルームでWwise Occlusionを使います。
あなたが、自分のオブストラクション方式（ゲーム側のレイキャストによって操作されるものなど）を実装させ、Spatial Audioのオブストラクションと合わせて使いたい場合は、サウンドエンジンの APIである AK::SoundEngine::SetObjectObstructionAndOcclusion をゲームで使えます。ポータル開口部のオクルージョンには、Spatial AudioのAPIである AK::SpatialAudio::SetPortalObstructionAndOcclusion をゲームで使えます。ゲームが、ゲームオブジェクトのパラメータとしてRoomのIDを設定して AK::SoundEngine::SetObjectObstructionAndOcclusion をコールすると、どのような結果となるのか不明なため、これは絶対に行わないでください。Spatial Audioで同じルームのオブストラクションを使う場合の詳細は、section 同じルームの音の伝播を、ゲーム側でモデル化 を参照してください。
これらの音響の概念については、 Spatial Audioの概念 を参照してください。
音の伝播機能の概要
下表はSpatial AudioのRooms and Portals機能の内容で、音響現象の種類別に、Spatial Audioでできることと、サウンドデザイナーがプロジェクトに取り入れる方法を、まとめています。
| 音響現象 | Spatial Audio | Wwiseサウンドデザイン |
|---|---|---|
| ダイレクトパスの回折 |
|
|
| 拡散音場（リバーブ） |
|
|
| ルームカップリング: 隣接するルームの拡散音場 のリバーブのスペーシャリゼーション、回折 |
|
|
| トランスミッション |
|
|
3Dリバーブを使う
Spatial Audioのルームやポータルで使うAuxバスのデザインは、今までのモデル化と、基本的なところで同じです。ルームごとにAuxバスをアサインすることが必要で、そこにデザイナーが選んだリバーブエフェクトを搭載して、リスナーがルーム内でも外でも、同じバスを使います。唯一の違いは、下図のとおり、3DにするためにListener Relative Routing（Positioningタブ）を有効にし、3D Spatializationの設定をPosition + Orientation、またはPositionとする点です。このように、隣のルームにあるゲームオブジェクトのポジションとスプレッドに基づいて、ポータルの位置で、隣のルームのリバーブのスペーシャリゼーションを実行することができます。
ルームのレファレンスオリエンテーションは、ルームの設定（AkRoomParams::Up と、 AkRoomParams::Front）で決まり、変化しません。それに対応するゲームオブジェクトのオリエンテーションが、ルームのオリエンテーションと等しくされます。リスナーがルームにいるときは、Spatial Audioがバスのスプレッドを100（360度）に設定します。3Dポジショニングのおかげで、リバーブの出力は、リスナーとルームの相対的オリエンテーションに基づいて、回転されて親バスにパンニングされます。これは、Auxバスがルームのゲームオブジェクトに紐づいているのに対して、親バスがリスナーに紐づいているためです。下のスクリーンショットは、エミッター、ラジオ、Auxiliary Bus Mezzanine2への送信を示しています。このルームAk_RV_Mezzanine用に別のゲームオブジェクトが作成されていて、ラジオでもリスナーでもないということが分かります（PlayerCameraManager_0）。
例えばスペーシャリゼーションを適用したアーリーリフレクションのパターンをリバーブに焼き付けてある場合は（このようなパターンはWwise RoomVerbのERセクションで明示的に存在するほか、Wwise Convolution ReverbのマルチチャンネルIRレコーディングにも暗黙に存在します）、リスナーが回るときにそれを追うのではなく、ルームに紐づけておきます。正しい没入感のためには、望ましいことです。一方、「うまく回転する」ようなコンフィギュレーションを優先することが推奨されます。アンビソニックのコンフィギュレーションは回転に左右されないので、望ましいです。標準のコンフィギュレーション（4.0、5.1、など）はそれほどでもありません。標準コンフィギュレーションを使用する場合は、センターチャンネルがないものを選択して、Auxバスと親に同じコンフィギュレーションを使い、Focusを100に設定するようにします。このような条件では、Roomで北向きにオリエンテーションが設定された4.0リバーブで、北向きのリスナーに聞こえてくるのは、まさにスピーカーに直接アサインされているかのようなリバーブです。リスナーの向きが真東、真西、または真南であれあば、元のリバーブが、違うチャンネルから聞こえます。最後に、リスナーがこれらの間の方向を向いている場合は、元のリバーブの各チャンネルがミックスされて、2つの出力チャンネルから聞こえます。
リスナーがルームのポータルから離れていると、Spatial Audioがポータルの範囲に従ってスプレッドを減少させるので、遠くなればなるほど、シームレスにリバーブの出力を点音源に集約していきます。Spreadは、リスナーがポータルに半ば入ったときに50（180度）に設定されています。スプレッドはルームに入り込むにつれ、さらに増加して、開口部は、一番近いポータルの方向性に確実に維持されるようにします。
音をポータルに対しミキシングするときは、Spatial Audioが音源とリスナーの間のパス全体の長さを計算します。この距離を各サウンドの減衰カーブに適用してから、そのサウンドをルームのバスにミキシングするので、各サウンドに減衰を適用したあとのボリュームの相対関係が、維持されます。ルームバスに対し、減衰をさらに適用する必要はありません。Room Auxiliary Busに減衰を適用する場合は、各サウンドの減衰処理の上から重ねて、ミックス後に適用されるので、リバーブのボリュームをさらに下げたり、ポータルを通る信号に追加のフィルターを適用したりする効果があります。
RoomゲームオブジェクトのポジションはSpatial Audioによって管理され、リスナーがルーム内にいるときは、ゲームオブジェクトがリスナーと同じ場所に配置されます。この場合、減衰カーブがアサインされていれば、すべてDistanceを0として評価されます。
|
警告: なお、もしRoom Auxiliary Busに減衰がアサインされていれば、Spatial AudioがPortalのジオメトリに従いSpreadを変更できるようにするため、Auxiliary BusのAttenuationにSpreadカーブを設定してはいけません。そこでSpreadカーブを使うと、Spatial Audioが計算した値がオーバーライドされてしまいます。 |
Roomのバス同士をチェインでつなげ、Roomをカップリングする
ルームカップリング（ ルームカップリング 参照）では、ルームのバス同士を「チェイン」で連結します。これを行うには、まず各RoomのAuxiliary Busの、 Enable Game-Defined Sends チェックボックスを有効にしてください。こうすることで、RoomからリスナーのRoom（またはパス上の次のルーム）のリバーブにも送ることができます。あるサウンドに設定されたGame-Defined Auxiliary Sendボリュームや、減衰カーブによって、ルームのリバーブチェインにある最初のバスに対し、そのサウンドをどれだけミキシングするのかが決まり、各RoomのGame-Defined Auxiliary Sendボリュームによって、チェイン上で次にくるルームに、どれだけ送るかが決まります。これは、音響エネルギーがPortal経由で隣接するRoomにどれだけ送られるのかを左右します。
ゲームオブジェクトについて
Spatial Audioのルームやポータルは、Wwiseサウンドエンジンが把握しているゲームオブジェクト（ゲームに登録されたエミッタと、Spatial Audioに登録されたルームゲームオブジェクト）のポジションや、その固有のプロパティであるゲーム定義のセンド、オブストラクション、オクルージョンなどを操作することで、機能します。
エミッタ
Spatial Audioの初期設定 DiffractionFlags_CalcEmitterVirtualPosition を設定すると、リスナーの隣のルームに位置するエミッタのポジションが、必要に応じて回折角の方から出るように、修正されます。以下の3D Game Object Profilerのスクリーンショットでは、リスナー（Listener L）がPortalの右にあり、「真の」エミッターが左下にあります（オリエンテーションベクトルのないEmitter E）。そこでSpatial Audioは、エミッタの位置を左上に変えて、ポジションがコーナーの方向であるかのようにしながらも、通った距離も考慮します。リスナーはPortalエッジのシャドーゾーンに約45度入ったところにあり、その結果、2本の線分の交点に表示されているとおり、回折係数が27となっています。
2つのルームが複数のポータルでつながっている場合、1つのエミッタに複数のポジション（1つのポータルにつき1つのポジション）をアサインするかもしれません。MultiPosition_MultiDirection モードを使うので、あるポータルを有効・無効にしても、ほかのポータルから聞こえるボリュームに影響しません。
|
警告: Spatial Audioのエミッタと AK::SoundEngine::SetMultiplePositions を一緒に使うことに関しては、Spatial Audioがリフレクション、ディフラクション、ポータルトランジションなど様々な計算に最初のポジションしか使わないので、 注意してください。 |
ルームとポータル
Spatial Audioは舞台裏で、ルーム1つにつきWwiseにゲームオブジェクト1つを登録します。
|
警告: このゲームオブジェクトのポジションや、Auxセンド値を、直接変更してはいけません。 |
リスナーがルームにいると、ルームのゲームオブジェクトは、リスナーを追うように移動します。このため、ルームとリスナーオブジェクトの間の距離は、約0です。ただし、オリエンテーションはルームの設定（AkRoomParams）の指定どおりに維持されます。3Dバスのオリエンテーションの検討については、 3Dリバーブを使う を参照してください。
リスナーがルームの外にいると、ルームのゲームオブジェクトにポータルのポジションが適用されます。厳密には、ポータルのうしろに配置され、リスナーからポータルのタンジェントへの投影の場所で、ポータルの範囲に固定されています。確認するにはルームのゲームオブジェクトを見ますが、前出の エミッタ の3D Game Object Profilerのスクリーンショットにも表示されています。
複数のポータルの場合、エミッタの場合と同じ理由で、ルームのゲームオブジェクトが MultiPosition_MultiDirection モード複数のポジションにアサインされます。
ポータル内でトランジションするときに、「ルーム内」動作と「ポータル」動作はスムーズに補間されます。
ほかのルームの音伝播のモデル化
Spatial Audioのルームやポータルを使うと、リスナーのいるルーム以外のルームの音の伝播は、Rooms and Portalsの抽象化で管理します。別のルームにあるエミッタは、ポータルや、それに関連する回折や、ルームの壁の透過などを通して、リスナーまで伝わります。伝搬させる音のそれぞれのEnable Diffractionチェックボックスを、Positioningタブで必ずチェックしてください。
回折（diffraction）
Spatial Audioは、隣のルームの各エミッタに対して、接続するポータルの最も近い端のShadow Boundaryから、回折角を計算します。前述の Diffraction（回折） を参照してください。回折角は最大180度まで広がり、0～100の係数にマッピングされてからWwiseユーザーに提供され、Wwiseユーザーは、これに対応するオーディオ変化を2つの方法のどちらかを使い実行します。エミッタのゲームオブジェクトにオブストラクション値を設定するか、組み込みゲームパラメータの値を設定します。Spatial Audioがどちらを行うかは、初期化するために使う AkDiffractionFlags の選択で決まります。
組み込みパラメータDiffractionを使うには、ゲームパラメータを作成して、ドロップダウンメニューのBind to Built-in Parameterに、Diffractionを選択します。このゲームパラメータにプッシュする値はゲームオブジェクトごとのスコープなので、エミッタごとに固有です。これにRTPCを適用すれば、アクターミキサーのどのプロパティでもコントロールできます。最も理にかなっているのが、Output Bus VolumeとOutput Bus LPFで、回折が周波数に依存する性質をエミュレートできます。Output Bus VolumeとLPFは、基本のVolumeやLPFよりも優先され、それはルームのリバーブへのAuxセンドではなく、直接シグナルパスだけに適用するからです。
ルームの拡散エネルギーも、ルームのAuxバスの出力として、Spatial Audioの音伝播モデルに含まれます。これの拡散計算も、Spatial Audioが行います（いわゆるウェット回折）。Spatial Audioは、拡散エネルギーがポータルに対して垂直に、ルームから漏れ出るものととらえています。つまり、回折角をポータルの通常のベクトルに対する角度として、計算します。この回折角は、エミッタのドライパスと全く同じようにWwiseで使えます。組み込みゲームパラメータを使う場合は、RTPCをルームのAuxバスに対して設定するべきで、一般的にバスのOutput Bus VolumeやOutput Bus LPFに対してです。バスのOutput Bus Volumeプロパティは、アクターミキサーの場合と同じ理由でBus Volumeプロパティよりも優先するべきで、このリバーブをリスナーのルームのリバーブにカップリングするために使うAuxセンドパスが、影響されないようにします。
あるいは、組み込まれたプロジェクト全体のオブストラクションを使って、Spatial Audioの回折のオーディオを修正できます。その際Spatial Audioは、Diffractionの計算結果を使いオブストラクションを適用します。組み込みゲームパラメータDiffractionに対して、プロジェクト全体のオブストラクションは、Wwiseプロジェクトにグローバル設定されたカーブにマッピングされます。Project Settingsでオーサリングできません。Obstruction Volume、LPF、HPFは、前述のとおり、Output Bus Volume、LPF、HPFに適用される結果となります。オブストラクションカーブはグローバル設定なので、プロジェクト全体に設定したのオブストラクションは、組み込みゲームパラメータのDiffractionほど応用が利きません。一方、操作や修正の必要性（RTPC使用）も少ないです。また、ゲームオブジェクトはポジションによってオブストラクション値も変わりますが、組み込みゲームパラメータは、あるゲームオブジェクトの全てのポジションに1つの値だけを適用させることがあります。（複数の値が設定されていると、最小を使用します。）ルームに複数のポータルがある場合に、複数のゲームオブジェクトのポジションが使われるのを、思い出してください。
透過
エミッタが別のルームにある場合に、Spatial Audioは壁を通る音をモデル化するのに透過（transmission）も使いますが、それにはエミッタゲームオブジェクトのオクルージョンを利用します。オクルージョン値はルームの設定 AkRoomParams::WallOcclusion を利用して、最大オクルージョン値は、リスナーのルームとエミッタのルームの間からとります。オクルージョンは、Project SettingsのObstruction/Occlusionタブで設定した、グローバルでプロジェクト全体のカーブを経由して、ボリューム、LPF、HPFにマッピングされます。オブストラクションと違い、オクルージョンはAuxバスに送られたシグナルにも影響するので、オクルージョンを受けたエミッタのルームリバーブへの影響や、カップリングされたリバーブは、オクルージョンカーブに従い拡大・縮小したりフィルターをかけたりします。このようにして、オクルージョンで吸収（透過）を適切にモデル化できます。
カップリング
リスナーのルームのポータルを通して隣室などから浸透してくる拡散エネルギーは、このポータルに位置する音源ととらえることが可能で、そのため、リスナーのルームの励起に貢献するはずです。言い換えると、リスナーのルームのAuxバスにセンドするべきです。前述のとおり、これは隣のルームのAuxバスのEnable Game-Defined Sendsチェックボックスをチェックすればできます。ほかのルームのリバーブに送る量を微調整するには、Game-Defined Send Offsetを使います。
同じルームの音の伝播を、ゲーム側でモデル化
リスナーと同じルームから出された音のオブストラクションは、ジオメトリーによる回折（ Geometry APIを使った回折（diffraction）と透過（transmission）のシミュレーション 、 ジオメトリのAPIとルームやポータルを、合わせて使う を参照）で対処できますが、Spatial Audioのルームやポータルだけでは処理できません。オブストラクションの計算目的でSpatial Audioにジオメトリを送信したくない場合は、同じルームで起きるオブストラクションを、ゲーム側で処理する必要があります。同室内のオブストラクションを計算するために使うジオメトリの表現、方式、そして理想の詳細レベルは、ゲームエンジンによってかなり違います。典型的なゲームでは、このタスクの実行にレイキャストを採用していますが、精度はゲームによって様々です。このセクションでは、ルームやポータルに関して、ゲーム側でオブストラクションを実装するためのコツを提供します。
しかしSpatial Audioのルームやポータルを活用すれば、全てのエミッタで処理する必要はなく、リスナーと同じルームにいるエミッタだけになります。通常のレイキャストが伝播パスを計算するのは、Spatial Audioに使われるアルゴリズムと比較してかなり負荷が大きいので、有利です。エミッタとリスナーの間の室内オブストラクションは同じルームで起きるので、その言葉の意味からして、障害物がリスナーやエミッタを完全に覆うことはなく、音は室内の反射を通してリスナーに届くものと考えます。これは、Auxセンドを変えずにドライ・直接シグナルだけを変えれば正しくモデル化できるので、該当するメカニズムはオブストラクションです。この目的のためには、ゲームは AK::SoundEngine::SetObjectObstructionAndOcclusion をコールすべきです。
さらに隣室へのポータルは、リスナーのルーム内にあるサウンドエミッタのようにとらえるべきです。これに伴い、リスナーと、リスナーがいるルームのポータルの間でも、ゲームのオブストラクションアルゴリズムを実行するべきです。それにはゲームが各ポータルに関して AK::SpatialAudio::SetPortalObstructionAndOcclusion をコールして、ルーム内のオブストラクションをリスナーに確実に宣言するべきです。
複数のルームを経由する
音の伝播は、複数のルームも経由できます。伝播のパスを探す時に、SpatialAudio内でRoomツリーのサーチを行います。円形のサーチを防止するために、すでにサーチしたルームに再び来た時は停止します。サーチの深度は、Spatial Audioの初期化設定 AkSpatialAudioInitSettings::uMaxSoundPropagationDepth で制限できます（デフォルトは 8）。
複雑なルームリバーブの実装
サウンドエンジンのAPIである AK::SoundEngine::SetGameObjectAuxSendValues を使って、Spatial Audioで設定されたAuxiliary Sendsに追加することができます。室内に複雑なリバーブをデザインする時などに便利で、例えば同じ部屋に環境エフェクトが違う物体や地形がある場合などに利用できます。Roomの AkRoomParams::ReverbAuxBus は "none" （ AK_INVALID_AUX_ID ）のままにすると、センドバスを、 AK::SoundEngine::SetGameObjectAuxSendValues 経由でゲームだけが管理できるようになります。
Geometry APIを使った回折（diffraction）と透過（transmission）のシミュレーション
Wwise Spatial Audioに送信したジオメトリを、音の回折や透過のシミュレーションに使うことがあります。つまり、あなたのゲームエンジンでオブストラクションを計算するレイキャスト方式を、完全に置き換えることも可能です。
エミッターが障害物に隠れてリスナーから見えないとき、Spatial Audioが障害物の端にそってパスを計算し、見つかれば、その端を回り込む音によって発生する回折係数を計算します。これに合わせてエミッターの見かけの入射角が調整され、回折値がWwiseに送信されるので、最終的に音にどう影響するかをあなたがWwiseでコントロールできます。回折の結果としてローパスフィルターが適用されるのが一般的です。
さらに、Spatial Audioはジオメトリを通るサウンドパスを計算します。障害物を透過する音には、API経由でジオメトリにアサインされた表面プロパティで決まる透過損失（transmission loss）の係数が適用されます。透過損失は、ローパスフィルタとボリューム減衰でモデル化されるのが一般的です。
下図Wwiseの3D Game Object Viewerのスクリーンショットに表示されているのが、音が薄い壁の端の周りを回折している様子です。
|
警告: 障害の計算方法として、あなたのゲームエンジンのレイキャスト方式から、ジオメトリを使った回折と透過に、完全に切り替えることは可能ですが、ジオメトリが複雑になるとパフォーマンスコストが急速に増大します。Spatial Audioに送信するジオメトリは、できるだけシンプルにしてください。また、効率的なRooms and Portalsによる抽象化（ ルームとポータルを使用する 参照）を、ジオメトリによる回折と合わせて利用した方が、後者の複雑な計算を減らせます。 |
Wwise Reflectと組み合わせて使えば、ジオメトリによる回折をエミッターとリスナーの間の直接的な音の伝播のパスだけでなく、その初期反射のパスに対しても適用できます。
回折用（diffraction）に、ジオメトリを設定する
Spatial Audioに送信されるジオメトリセットはすべて、回折のパスを計算するときに考慮するべきかどうかを明確に示す必要があります。明示するには、AkGeometryParams::EnableDiffraction フラグを使います。このフラグが回折の計算に必要なエッジデータ生成を可能にし、ダイレクトパスに対するジオメトリによるディフラクションと、リフレクションのディフラクションの、両方で使われます。
また、メッシュの境界エッジでも音が回折するのかどうかを検討します。メッシュの境界エッジとは、1つの三角形だけにつながるエッジのことで、多様体の境界に存在することになります。エッジ数が増えると回折の計算がより複雑になるので、あなたのメッシュの境界エッジで音が回折しないのであれば、このオプションを無効にしておきます。
最後に、エッジ材質はエネルギーを吸収せず、Acoustic Surfaceに設定されているAcoustic Textureは回折に一切影響しません。エッジは、音を単に曲げるだけです。
透過（transmission）用に、ジオメトリを設定する
最初に、透過をシミュレーションできるように、フラグ AkSpatialAudioInitSettings::bEnableTransmission がTrueに設定されていることを確認します。
ジオメトリについて、様々なジオメトリタイプに合わせて透過損失（transmission loss）の係数を調整するのが望ましいことがあります。例えばコンクリート構造は、ほぼすべての音響透過を妨げる可能性が高いのに対し、ベニヤ板で構成されたジオメトリは、わずかに音を妨げるだけかもしれません。
AkGeometryParams::Triangles アレイの中の各 AkTriangle に、 AkTriangle::surface が入っていますが、これは AkGeometryParams::Surfaces アレイに対するインデックスです。 AkAcousticSurface::occlusion フィールドは、それを参照する三角形を透過する音に対し、どれだけの透過損失を適用すべきかを表します。値は0から1の間で設定されます。透過損失は損失率に変換され、オクルージョンカーブを評価するために使われます。ある透過損失の音に適用される最終的なボリューム減衰とフィルター値は、Wwise Project Settingsで定義したオクルージョンカーブによって決まります。
ダイレクトパスの、ジオメトリによる回折
Geometric Diffractionのデモが、Integration Demoサンプルにあるので（SDK/samples/IntegrationDemoの中）、ダイレクトパスのジオメトリによる回折に、ジオメトリを利用する例を、ご覧ください。このデモの場所は、Demo Positioning > Spatial Audio: Geometryです。
回折（diffraction）と透過（transmission）のために音を準備する
Wwise AuthoringツールのPositioningタブで、Enable Diffractionがチェックされていることを確認します。このボックスは、回折や透過に関するSpatial Audio機能を有効にするもので、例えば以下が可能となります。
- 音の回折パスがジオメトリやポータルを経由する場合は、その計算。パスの計算は、Spatial Audioが、回折と透過を有効にしたサウンドを再生している各ゲームオブジェクトに対し、行います。同じゲームオブジェクト上で、回折を有効にした複数のサウンドが再生中であれば、パス計算は1回だけ行われます。
- ジオメトリやルーム間を経由する音の透過パスの計算。必ず、透過パス上で遭遇した透過損失値のうち、それがルームの
AkRoomParams::WallOcclusionからくるものであれ、三角形に関連したAkAcousticSurface::occlusionオクルージョンであれ、最大のものを最終的な透過損失の係数として用います。 - Spatial Audioの初期設定で
AkSpatialAudioInitSettings::bCalcEmitterVirtualPositionが設定されていれば、音をレンダリングするために回折パスのバーチャルポジションを生成してSound Engineに送ります。 - Spatial Audioの初期設定で
AkSpatialAudioInitSettings::bUseObstructionが設定されていれば、回折係数に基づいてオブストラクションカーブを適用します。もしゲーム側もAK::SoundEngine::SetObjectObstructionAndOcclusion経由でオブストラクション値を設定していれば、両者の値の大きいほうを使います。 - Spatial Audioの初期設定で
AkSpatialAudioInitSettings::bUseOcclusionが設定されていれば、透過損失の係数に基づいてオクルージョンカーブを適用します。もしゲーム側もAK::SoundEngine::SetObjectObstructionAndOcclusion経由でオクルージョン値を設定していれば、両者の値の大きいほうを使います。
Wwiseにおける、ダイレクトパスの回折
回折の様子を3D Game Object Viewerで観察するには、Profiler Settings設定やViewer Settingsのオプション設定を調節します（下図参照）。エミッターからリスナーまでのパスで計算された回折係数が、回折エッジごとに表示されます。この回折係数は、Spatial Audioの初期化で渡されたAkSpatialAudioInitSettings::uDiffractionFlagsに従い、組み込みゲームパラメータのDiffractionを介して、またはエミッターのObstruction値を介して、または両方を介して、Wwiseに伝達されます。組み込みゲームパラメータ値はそれが使われているRTPCカーブで直接プロファイリングでき、オブストラクションはProfilerのObs/Occタブで観察できます。
Portalsと同じく、Diffraction値はエミッターがリスナーの視界に入っているときに0で、エミッターがシャドーゾーンを貫通し始めると増加します（Diffraction（回折） 参照）。また、シャドーゾーンの回折の詳細や、組み込みのDiffractionゲームパラメータとオブストラクションの使い方の違いについては、Rooms and Portalsの 回折（diffraction） を参照してください。
ダイレクトパスの回折と、Spatial AudioのRooms and Portalsの関係
Spatial AudioのRooms and Portals（ ルームとポータルを使用する ）でも、隣接するルームのダイレクトサウンドの回折をPortalsによってモデル化します。これら2つのシステムは補完し合う関係で、リスナーと同じ部屋にないエミッターに対して、ジオメトリに基づく回折パスを見つけようとすることはありません。ジオメトリよりもRooms and Portalsの計算の方がかなり効率的なことを考慮すると、複雑な計算を制限するために、2つのシステムを併用することにメリットがあります。
アーリーリフレクションの、ジオメトリによる回折
上記の通りアーリーリフレクションはエッジで回折することがあり、エミッターをWwise Reflectにルーティングすると、Spatial Audioがこの現象のモデル化をサポートします。
その方法を説明する前に、ビューゾーン内の回折を定義する必要があります。
下図をご覧ください。エミッターはリスナーの視界に入っていますが、鏡面反射がリスナーに当たっていません。つまり、ビューゾーンに入っているのです。すでに Diffraction（回折） で説明した通り、回折はビューゾーン内でも発生します。ただしWwise Spatial Audioでは、ダイレクトパスのモデル化を行うRooms and Portalsでもジオメトリによる回折でも、ビューゾーン内の回折が実際のダイレクトパスと比較して無視できる程度なので、考慮されません。しかし反射に関しては、ビューゾーンの回折が劇的な影響をもっています。回折がないとアーリーリフレクションが聞こえるのはリフレクションゾーン内だけで、そこでは純粋な鏡面反射となっています。リスナーがビューゾーンに入った途端、反射が聞こえなくなります。回折を有効にしておけば、エッジが作用して反射波が回折されます。そうすると、リスナーがリフレクションゾーン内を歩き回ったり、そこを遠ざかったりしたときに、追加のフィルタリングや減衰が適用されたあとの反射を聞くことができるのです。
リフレクションゾーン内では、鏡面反射でほかが圧倒されるものと予想し、回折パスも、それに伴う回折値も、計算されません。あるエッジにおけるビューゾーンの回折を計算すると、リフレクションゾーンとビューゾーンの境界線において0となり、ビューゾーンとシャドーゾーンの境界線において100となります。
高次のアーリーリフレクションでは、ビューゾーンとシャドーゾーンの両方の回折が作用します。
サウンドにReflectionを適用するには
リフレクションを要するすべてのサウンド用に、Wwise Authoringツールで、Wwise Reflectの入ったAuxバスにアーリーリフレクションのセンドを設定します。詳細は Wwiseプロジェクトセットアップ を参照してください。反射の回折を目的とする回折の特別な設定はなく、ジオメトリに対して回折を有効にするだけで充分です。
Wwise Reflectの設定
回折エフェクトを適用した反射は、Wwise Reflectでイメージソースとして表示されます。反射の回折のエフェクトをデザインするのに、回折で変化する3つのカーブ、つまりDiffraction Attenuation、Diffraction LPF、Diffraction HPFを使うことができます。詳細は Wwise Reflect's documentation を参照してください。
ジオメトリのAPIとルームやポータルを、合わせて使う
Wwise Spatial Audioのルームやポータルは、ジオメトリ関連のAPIと協力し、反射や回折を表現します。ルームやポータルのネットワークを、周辺のジオメトリのハイレベルの抽象化（またはLOD（Level of Detail）の低レベルバージョン）としてとらえることができます。ルームやポータルを、レベルのジオメトリと注意深く合わせて使えば、詳細で効率的な音響シミュレーションを達成できます。
ポータルを通過するジオメトリによる回折
エミッタ（ジオメトリ回折用に正しく設定されたサウンドを再生中のエミッタ、 回折（diffraction）と透過（transmission）のために音を準備する 参照）が、リスナーと同じルームにない場合、ジオメトリによるパスを以下のように計算します:
- エミッタからリスナーまでの音の伝播パスを、ルームとポータルのネットワークを使い計算します。
- 各パスの、エミッタに最も近いポータルとエミッタの間の部分は、ジオメトリの回折アルゴリズムを使い、まるでポータルがリスナーであるかのように計算します。リスナーから見て、エミッタが1つのポータルの真後ろにいない限り、計算されるジオメトリパスは1つ（最短のもの）だけです。それ以外にエミッタとポータルのパスをいくつ計算しても、別のバーチャルポジションが出るわけではないので、不要です。
- 2つのポータルの間も、ポータル同士で直視できなければ、ジオメトリによる回折を使い、間のパスを計算します。これらの計算は、シーンにジオメトリやポータルが追加されたり削除されたりする度に行い、必要に応じて再利用します。多くの場合、2つのポータルの間の最短パスだけを使います。唯一、リスナーがポータルの真後ろにいるときが例外で、その場合は複数のパスを用い、リスナーがポータルを通過した際の中断を回避します。
- 各パスの、リスナーに最も近いポータルとリスナーの間の部分は、ジオメトリに従った回折アルゴリズムを使い、まるでポータルがエミッターであるかのように計算します。
- 以上のパスを組み合わせた結果がパスとなり、必要に応じて複数のパスをつなげたり合体させたりします。
ポータルを通過する反射
リフレクションはポータルを通過することができ、ポータルの開口部で最大2つの平面が交差していても通過できます。ポータル自体が音響的な開口部なので、音を通過させるために三角形ジオメトリに「穴をあける」必要はなく、三角形の数が大幅に増えるのを回避できます。例えば、箱のようなジオメトリのルームがあり、6つの面を、それぞれ2つの三角形で表すとします。音が箱の外にも伝播するようにしたければ、1つの壁と交差するポータルを追加し、ポータルのZ軸が壁に交差するように配置します。いつも通り、どのゲームオブジェクトがルーム内にあり、どれが外にあるのかは、ゲームが判断し、判断するのに使うのは AK::SpatialAudio::SetGameObjectInRoom です（ APIの概要 参照）。 エミッタ（リフレクション用に正しく設定されたサウンドを再生中のエミッタ、 Wwiseプロジェクトセットアップ 参照）が、リスナーと同じルームにない場合、音の伝播ネットワークでそのサウンドが伝わる状態であれば、リフレクションをシミュレーションします。反射を、以下のように計算します:
- エミッタのあるルームに接続する各ポータルと、エミッタの間の反射を、まるでポータルがリスナーであるかのように計算します。
- ポータルとリスナーの間の回折パスを、 ポータルを通過するジオメトリによる回折 の説明のとおりに計算し、ポータルとエミッタの間の反射パスに付け加えます。
- もし回折パスが回折100を超える場合は反射を計算せず、途中で超えた場合は、その時点で計算を停止します。
特定のルームのジオメトリのタグ付け。
レイとトライアングルの交差テストや、反射が生じるかもしれない面を、サーチする領域を制限する最適化の1つとして、特定のルームにジオメトリを自分でアサインすることが可能です。まず、そのルームのIDに、 AkGeometryParams::RoomID を設定します。そうすることで、ルームのジオメトリがほかのルームから見えるのはポータルを通したときだけで、直接には見えないということを、Spatial Audioに示します。1つのルームIDに関連付けられるジオメトリセットは1つだけなので、 AkGeometryParams::RoomID を無効にしない限り、複数の部屋で見えるようなジオメトリをルームに設定できません。また、ルームのIDに関連付けられたジオメトリセットがあれば、このルームにあえて関連付けたジオメトリ以外をルームが「見る」ことはできません。ルームにジオメトリセットをアサインしたあとは、そのルームの反射や回折をシミュレーションするときに、Spatial AudioはルームIDに具体的に関連付けられたジオメトリ以外を見ません。
Stochastic Ray Castingのジオメトリの使い方
はじめに
Stochastic Ray Castingは、n次のリフレクションやディフラクションを効率的に評価するテクニックです。リスナーからランダムにキャストされたレイ（ray）を追って、リフレクションやディフラクションを続けて受けたときのパスを、確認するというのが基本的な考えかあです。この技術の発想は、グラフィックレンダリング技術からきています。現在の実装はリフレクションやディフラクションを、リスナー側とエミッタ側で、4次までサポートしています。
概念
- Primary rays: リスナーから直接キャストされたレイ
- Reflection: サウンドの、面からの跳ね返り
- Diffraction: サウンドの、物体周りの回折
- Paths: リスナーからエミッタまでの、一連のリフレクションまたはディフラクション
- Emitter receptor: エミッタを中心に配置された、ボックスまたは球体の囲い
設定
- Number of Primary Rays (uNumberOfPrimaryRays): リスナーからキャストされるレイの数。Primary rayの数を増やすと結果は良くなりますが、CPU時間のコストが増えます。デフォルト値が、ほとんどの適用例に適しています。
- Maximum Reflection Order (uMaxReflectionOrder): レイが連続して面から跳ね返る、最大回数。リフレクションの次数を増やすと音響シミュレーションがより繊細になりますが、CPUパフォーマンスへの負荷が大幅に増える可能性があります。
- Direct Diffraction Path (bEnableDirectPathDiffraction): リスナーとエミッタの間の、直接の回折のパス、つまり回折のセグメントだけで構成されたパス。Direct diffraction path計算を有効にすると、CPUの使用量が大幅に増えます。
- Diffraction on Reflections (bEnableDiffractionOnReflection): リフレクションのパスの最初と最後に、回折を適用します（リフレクションのセグメントだけで構成されたパス）。Diffraction on reflectionsを有効にすると、エミッタまたはリスナーが障害物の後ろに移動したときに、不意にリフレクションが消えてしまうようなシミュレーションを防げます。Direct diffraction pathと同じく、CPUの使用量が大幅に増えます。
- Maximum Path Length (fMaxPathLength): パスのセグメント長さの最大値。値が高いほど長いパスを計算できますが、CPUの使用量が増えます。
制約事項
Stochastic ray castingエンジンのジオメトリを定義する際に、考慮すべき制約がいくつかあります。パフォーマンスと、最終的な品質の両方に関する制約です。
ジオメトリの見える角度
三角形がサンプリングの密度よりも小さいと、レイキャストをするエンジンが見つける確率は、減ります。
ジオメトリの見える角度α（アルファ）とは、リスナー視点からジオメトリが見える角度のことです。Primary rayの数によって、2つのレイの間の平均的な角度 γ（ガンマ）は異なります。αとγの相対関係によって、オブジェクトとの交点（リフレクションまたはディフラクション）が見つかる確率が変わります。γがαより小さければ、交点が見つかる確率が上がります。γがαより大きければ、交点が見つかる確率が下がります。
三角形の個数
ジオメトリ内の三角形の数が、エンジンのCPU消費量と直接関係し、三角形が増えれば、それだけCPUの消費量が増えます。これは、オブジェクトに必要となる交点テストが増えるからです。一般的に音の伝播に高度なジオメトリは必要ありません。そこで三角形の数を減らせば、品質を犠牲にすることなくパフォーマンスを向上できます。
ジオメトリの形状
ジオメトリ形状は、処理しやすいものと、しにくいものがあります。一般的に、平面やボックスなどは簡単に処理でき、音の伝播の観点では一番良い結果を出します。球体や円柱は、エラーが発生しやすくなります。球体や円柱には曲面が伴うからです。場合によって、見落とされる回折エッジが出てしまい、そうすると一部の回折パスが抜けてしまいます。アルゴリズムにヒューリスティックをいくつか導入しているので、多くのケースでこの問題に対処できます。Primary rayの数を増やしたり、ジオメトリを簡略化したりすることでも、この問題を解消できます。
"Raw" Image Sourcesを使用する
Wwise Reflect は AK::SoundEngine::SendPluginCustomGameData を使用してゲームで直接使用および制御することができますが、 AK::SpatialAudio は、便利なエミッタごとの集計や画像ソースのパッケージングを提供することで、使いやすくします。 また、「生の」画像ソースをサーフェスリフレクター（同じターゲットバス/プラグイン上にある可能性があります）とミックスして一致させることができます。
ゲーム側のセットアップ
各ゲームソースの AddImageSource を呼び出します。バスIDとオプションのゲームオブジェクトIDをターゲットにします（ゲームオブジェクトIDはリスナーまたはメインリスナーでもよいことに注意してください）。イメージソースの記述方法の詳細については、 AkReflectImageSource を参照してください。
例えば、画像ソースはレイキャスティングまたは独自の画像ソースアルゴリズムを介して、この機能を既に実装しているゲームエンジンによって反映されるように提供されてもよいです。
Wwiseプロジェクトセットアップ
アーリーリフレクションのシミュレーションにおける、Geometry APIの使用 については、同じである上記の Wwiseプロジェクトセットアップ を参照してください。 Reflect on FPSサウンドのサンプルデザインについては、Wwise Helpの Wwise Reflectドキュメントを参照することもできます。
|
注釈: オーサリングツールの、Early reflectionのセンドレベルやバスは、 AK::SpatialAudio::SetImageSource() を使って設定したイメージソースに適用されません。このファンクションを使うとき、Reflectのバスやセンドレベルは、プログラミングで設定するしかありません。 |
- 参照
- Wwise Help でBusにPositioningを適用。
- Wwise Help でEmitter-Listenerの関連性。
- Wwise Help でWwise Reflect。