menu
バージョン
2018.1.11.6987
2024.1.4.8780
2023.1.12.8706
2022.1.19.8584
2021.1.14.8108
2019.2.15.7667
2019.1.11.7296
2018.1.11.6987
2017.2.10.6745
2017.1.9.6501
2016.2.6.6153
2015.1.9.5624
2024.1.4.8780
2023.1.12.8706
2022.1.19.8584
2021.1.14.8108
2019.2.15.7667
2019.1.11.7296
2018.1.11.6987
2017.2.10.6745
2017.1.9.6501
2016.2.6.6153
2015.1.9.5624
Wwise SDK 2018.1.11
|
Spatial Audio モジュールは、空間オーディオに関連するいくつかのサービスを公開しています。特に:
中で、それは:
次のフローチャートに示すように、Wwiseサウンドエンジンの一部をラップするゲーム側のSDKコンポーネントです。
Spatial Audioに関連する音響の基礎概念を、以下に簡単に説明します。
回折は、音波が小さい障害物に当たったり、大きな障害物の端や開口部に当たったりして、それを回り込んでいく場合に発生します。開口部(ポータル)を経由して横方向に向かって伝播する音を表すので、開口部のすぐ前にないリスナーにも聞こえます。回析を聞いたプレイヤーが、音のエミッタと自分の間に存在する通り道を感じ取るヒントとなるので、一般的にゲームで非常に大事です。下図は、平面波の音場の図で、右上からきて、図の中央に始まる有限の面(黒い線)に当たる様子です。この端によって発生した摂動を、回析と呼びます。左側はビューリージョンで、飛行機の波は影響を受けずに通過します。右上のリージョンがリフレクションリージョン(Reflection Region)で、表面の反射が起きて、入射波とミックスされて、このようなギザギザしたパターンになります。右下のリージョンはシャドーリージョン(Shadow Region)で、回折の影響が大きい場所です。これは大まかな図で、実際には音場がリージョンの境界線でも連続していて、端の回折はビューリージョンでも発生していますが、入射波そのものと比較すると、一般的に無視できる程度です。
端を点音源として解釈して、距離と共に振幅が減少します。また、高周波の振幅の方が低周波よりも速く減少するので、ローパスフィルタで適切にモデル化できます。Wwise Spatial Audioでは、回折のモデル化に2つのAPIを使います。Rooms and Portalsでポータルの回折をモデル化する方法については、Rooms and Portalsの 回折(diffraction) を、エミッターとその初期反射の回折をモデル化する際にジオメトリを考慮する方法については、 Geometry APIを使用した回折シミュレーション(実験的) を参照してください。
考慮すべき別の音響現象として、障害物による音の吸収と、その逆の透過がありますが、透過とは障害物を貫通するエネルギーの比率です。一般的に、近くに開口部が存在すれば、回折でリスナーに到達するエネルギーと比較して、透過で到達するエネルギーの割合は無視しても問題ありません。
一定の時間が経過すると、サウンドエミッターのある環境の音響特性に依存した拡散音場がつくられます。一般的にゲームで実装するには、関連する環境を表現できるように、リバーブエフェクトのパラメータを調整して使います。拡散音場はまた、開口部を通して(そして壁を通過して)、リスナーまで到達します。
オブストラクションは幅広い音響現象を示すもので、音波が障害物に当たった時に発生する全ての現象を指します。オクルージョンは似ていますが、暗に音が障害物の周りを回れないものとしています。Wwiseサウンドエンジンは、ゲームがゲームオブジェクトにオブストラクション値やオクルージョン値を設定することを許容しますが、それがゲーム全体を対象(グローバル)とするボリューム、ローパスフィルタ、ハイパスフィルタなどのグラフにマッピングされます。2つの違いは、オブストラクションがアクターミキサーやバスと、その出力バスの間の、ドライ・直接シグナルだけに影響する一方、オクルージョンはAUXセンドにも影響します。つまり、オブストラクションはエミッタとリスナーが同じルームにいる時の障害物によるオブストラクションをよくエミュレートできるのに対して、オクルージョンは閉ざされた壁を通るトランスミッションのモデル化に適しています。
Spatial Audio の関数と定義は in SDK/include/AK/SpatialAudio/Common/にあります。 その主な関数はネームスペース AK::SpatialAudio
に公開されています。APIカテゴリが、4種類あります:
Basic Functionsは、 AK::SpatialAudio::Init()
以外に、Spatial Audioがゲームオブジェクトをエミッタやリスナーとして把握してポジションを把握するために使いますが、これはSpatial Audioのほかのサービスを利用するためです。Rooms and Portals APIは、シンプルでハイレベルのジオメトリ抽象化で、ほかの部屋にあるサウンドエミッタの伝播のモデル化に使用します。Geometry APIは、Wwise Reflectでダイナミックアーリーリフレクションをシミュレーションしたり、ジオメトリによるディフラクションを計算したりするときに、三角形をそのまま使います。Spatial Audioは、Wwise Reflectの生APIを直接アクセスするためのヘルパー機能も公開しています。
AK::SpatialAudio::Init()
を使用してSpatial Audioを初期化します。
全てのゲームオブジェクトを、Wwiseサウンドエンジンに AK::SoundEngine::RegisterGameObj
を使用して登録する必要がありますが、Spatial Audioでも使うには、さらにエミッタとして AK::SpatialAudio::RegisterEmitter
を使用して AK::SpatialAudio
に登録する必要があります。
また唯一のリスナーも、 AK::SpatialAudio
に AK::SpatialAudio::RegisterListener
で登録する必要があります。
dangerous | Warning: 現在、Spatial Audioはトップレベルのリスナー1つだけに対応しています。 |
Spatial Audioにエミッタやリスナーの位置が分かるようにコールするのは AK::SpatialAudio::SetPosition
であり、 AK::SoundEngine
の該当コール (AK::SoundEngine::SetPosition
)ではありません。また、ゲーム定義Auxセンドを透過的に設定する可能性があるので、Spatial Audioの動作を邪魔せずに自分のカスタムゲーム定義Auxセンドを設定したい場合は、コールするのは AK::SpatialAudio::SetEmitterAuxSendValues
であり、 AK::SoundEngine::SetGameObjectAuxSendValues
ではありません。
info |
Note: すべての呼び出しを AK::SoundEngine::SetPosition と AK::SoundEngine::SetGameObjectAuxSendValues を AK::SpatialAudio のものに置き換えることができます。オブジェクトがRegisterEmitter経由で AK::SpatialAudio::RegisterEmitter に登録されていない呼び出しは、 AK::SoundEngine に直接転送されます。 |
dangerous | Warning: Spatial Audioは、RoomやPortalの複数のポジション計算を行っています。ただし、複数のポジションをSpatial Audioのエミッタやリスナーに指定することはできません。1つのゲームオブジェクトに複数のポジションが設定されている場合は、エミッタやリスナーとしてSpatial Audioに登録しないでください。 |
Geometry APIで、ゲームがWwise Spatial Audioに三角形メッシュを送信できますが、その目的は2つあります:
ゲームのジオメトリはAK::SpatialAudio::SetGeometry()
経由でWwise Spatial Audioに送られ、AkGeometryParams構造を使い表現されます。その中身の概要を、以下で説明します:
AkGeometryParams::Vertices
で定義され、これは三角形とは別であり、三角形のアレイAkGeometryParams::Triangles
の中の各三角形は、Vertexアレイのインデックスを参照します。AkAcousticSurface
構造へのインデックスも含まれ、これによりAcoustic Texture、ディスクリプション文字列、リフレクターチャンネルマスクが定義されます。AkGeometryParams::Surfaces
に送り、 AkGeometryParams::NumSurfaces
を0に設定することができます。一般的に、どのような三角形メッシュもWwise Spatial Audioで使えますが、注意すべき点がいくつかあります。
Geometry APIはエミッタやリスナーのポジションと、ゲームの(簡素化されることが多い)ジオメトリの三角を使って、ダイナミックアーリーリフレクションをシミュレーションするためのイメージソースを計算しますが、これはWwise Reflectプラグインと連結して行います。サウンドデザイナーは、距離やマテリアルに基づいてWwise Reflectのプロパティを調整することで、イメージソースポジションのトランスレーションを直接コントロールします。
ジオメトリによって変化するアーリーリフレクション(ER)の概要について、掲載中のブログ Image Source Approach to Dynamic Early Reflectionsや、Creating compelling reverberations for virtual realityなども参考にしてください。
ダイナミックERをサポートすべきエミッターごとに、対応するゲームオブジェクトをサウンドエンジンに登録した後で AK::SpatialAudio::RegisterEmitter()
を呼び出します。反射計算のパラメータを決定するには、 AkEmitterSettings
を使用します。
AkEmitterSettings::reflectAuxBusID
: 目的のプラグインWwise Reflectをホストする Auxiliary BusのID。SpatialAudioは、このバスへのAux送信接続を確立します。ただし接続先は、エミッタと同じゲームオブジェクトに関連するバスのインスタンスです。これは、異なるエミッタが補助バスの異なるインスタンスに、したがってプラグインの異なるインスタンスに送信することを意味します。これは、早期反射のセットは各エミッターに固有のものであるため、重要です。これは、以下の「Wwiseプロジェクト設定」のVoices Graph スクリーンショットに示されています。AkEmitterSettings::reflectionsAuxBusGain:
補助バスに向かってレベルを送信します。AkEmitterSettings::reflectionsOrder:
計算された反射の順序を決定します。1つの面に当たって生じる反射を1次反射と呼びます。2次反射は、リスナーに到達する前に2つのサーフェスに当たる音などによって生成されます。注意してください!生成された反射の数は、指数関数的に増加します。AkEmitterSettings::reflectionMaxPathLength:
反射の計算を止めるヒューリスティック。このエミッターで再生される音のMax Distance 以下に設定する必要があります。 これらのエミッターのサウンドエンジン関数の代わりに、 AK::SpatialAudio::SetPosition
と AK::SpatialAudio::SetEmitterAuxSendValues
を使用してください。 AK::SpatialAudio::SetGeometry
と AK::SpatialAudio::RemoveGeometry
を使用して、関連ジオメトリをSpatialAudioにプッシュしてください。Geometry APIの詳細は、 Geometry APIの使用 を参照してください。 ジオメトリにAcoustic surfaceがアサインされますが、これをWwiseプロジェクトで設定するAcoustic Texture ShareSetに紐づけることができます。AkAcousticSurface::textureID
参照してください。これらのAcoustic Textureは、マテリアルの反射特性とみなされ、計算された初期反射に適用されるフィルタリングに影響を与えます。Wwiseプロジェクトの動的環境効果を効果的に処理するためには、バス構造設計の次の点を理解する必要があります。
通常、様々なAuxiliary Busが異なる環境を表すために使用され、これらのバスは、これらの環境のリバーブ特性をエミュレートする異なるリバーブShareSetsをホストすることができます。SpatialAudioでWwise Reflect よって処理されるような動的ERを使用する場合、後期リバーブは補助バスのリバーブを使用して設計することができます。ただし、これらのリバーブ(該当する場合)のERセクションを無効にしたい場合があります。これはWwise Reflectで処理する必要があるためです。
一方、Wwise Reflectは後半の残響に使用されるAUXバスと並行して実行する必要があります。下の図は、EarlyReflectionsバスの下にある3つの補助バスに、それぞれWwise ReflectのShareSet が異なる一般的なバス構造を示しています。この設計では、初期反射を生成するために、わずかなShareSetsしか使用しないことに注意してください。これは、このEffect の「空間的要素」がランタイムにゲームジオメトリによって駆動されるという事実によって動機づけられます。ここでは、他のオブジェクトが発する音よりも、プレーヤー(リスナー)が発する音に対して異なる減衰カーブが必要なので、異なるShareSetを使用します。
ERバス(Wwise Reflect をホストする)は、初期の反射を生成したいエミッターと同じ数のインスタンスに存在します。これは、前のセクションで説明したように、これらのエミッタをSpatial Audio APIに登録し、このバスに送信することによって実行されます。これを正しく動作させるには、下の図に示すように、このバスのPositioningチェックボックスを有効にする必要があります。. これを行うことにより、ERバスの様々なインスタンスによって生成された信号は、下流の次のミキシングバスの単一インスタンスに適切にミックスされます。この単一のインスタンスは、プレーヤー(またはカメラ)に対応する、通常は最終的なリスナーであるこのエミッターを聴いているゲームオブジェクト(AK::SoundEngine::SetListeners
経由で設定)に対応します。
dangerous | Warning: ERバスのListener Relative Routingを有効にし、すべてのエミッターインスタンスをリスナー側のバスに確実に合流させる必要がありますが、Wwiseで3Dスペーシャリゼーションを二重に行ってしまうのを避けるために、3D SpatializationモードはNoneに設定します。同様にAttenuationは、Wwise Reflectのイメージソースカーブの上にさらに減衰を追加したい場合を除き、適用しないようにします。 |
また、遅れた残響を処理するために使用された補助バスにゲームオブジェクト(エミッター)が送信されるため、ERバスと後期リバーブバスとの間にも接続が確立されます。これは、生成されたERが後期リバーブを色づけして「緻密化」するために利用されるため、通常望ましいことです。 これを有効にするには、ERバスでゲーム定義の補助送信を使用するチェックボックスを有効にする必要があります。下のVolumeスライダを使って、後期リバーブに送る初期反射の量とダイレクトサウンドのバランスを合わせることができます。
次の図は、前の説明の実行時イラストです。
各反射三角形について、ゲームはマテリアルのIDを渡します。これらのマテリアルは、Virtual Acoustics ShareSetsのAcoustic Texture の形式でWwiseプロジェクトで編集されています。ここで、各マテリアルの吸収特性を定義することができます。
Wwise Reflect は AK::SoundEngine::SendPluginCustomGameData
を使用してゲームで直接使用および制御することができますが、 AK::SpatialAudio は、便利なエミッタごとの集計や画像ソースのパッケージングを提供することで、使いやすくします。 また、「生の」画像ソースをサーフェスリフレクター(同じターゲットバス/プラグイン上にある可能性があります)とミックスして一致させることができます。
各ゲームソースの AddImageSource を呼び出します。バスIDとオプションのゲームオブジェクトIDをターゲットにします(ゲームオブジェクトIDはリスナーまたはメインリスナーでもよいことに注意してください)。イメージソースの記述方法の詳細については、 AkReflectImageSource
を参照してください。
例えば、画像ソースはレイキャスティングまたは独自の画像ソースアルゴリズムを介して、この機能を既に実装しているゲームエンジンによって反映されるように提供されてもよいです。
アーリーリフレクションのシミュレーションにおける、Geometry APIの使用 については、同じである上記の Wwiseプロジェクトセットアップ を参照してください。 Reflect on FPSサウンドのサンプルデザインについては、Wwise Helpの Wwise Reflectドキュメントを参照することもできます。
Spatial AudioモジュールはRoomやPortalというジオメトリを抽象化したシンプルでハイレベルなものを公開して、他のルームに配置されたエミッタの音の伝播を効率的にモデル化します。部屋によって変化する音の伝播の主な性能は、リバーブの回析(diffraction)、カップリング(coupling)、スペーシャリゼーション(spatialization)です。サウンドデザイナーがWwiseで使っているツールを応用しているので、オーディオへ変換された結果をサウンドデザイナーが完全にコントロールできます。さらに、ゲームエンジン主導のレイキャストに基づくオブストラクションは、特にゲームエンジン固有となり、一般的にパフォーマンスへの負担が大きいので、リスナーと同じ部屋にいるエミッタに限定する機能もあります。
ルームには次元がなくポータル経由でつながっていて、それらが集合してルームと開口部のネットワークができあがり、これを通して別室で発生した音がリスナーに伝わります。Spatial Audioはこのネットワークを利用して、ドライシグナルの経由距離、予想される発生位置、回析角などを修正します。回折角(diffraction angle)はオブストラクションにマッピングしたり、デザイナーがプロパティ(ボリューム、ローパスフィルタなど)にRTPCで関連付けたDiffractionという組み込みゲームパラメータにマッピングしたりします。また、Spatial Audioでは、隣接するルームの リバーブをそのルームのポータルに配置して、リスナーのいるルームのリバーブにカップリングできるように3Dバスを使うこともできます。最後に、ルームにオリエンテーション(方向)も設定されているので、ルーム内でそのルームのリバーブから出た拡散音場は回転してからリスナーに届けられることで、リスナーの頭の中ではなく、ゲームのジオメトリに合わせています。
ほかのSpatial Audioのサービスと同様に、エミッタやリスナーも AK::SpatialAudio::RegisterEmitter
や AK:SpatialAudio:
:RegisterListener に登録する必要があり、その前に、該当するゲームオブジェクトをサウンドエンジンに登録しておきます( AK::SoundEngine::RegisterGameObj
参照)。ルームやポータルに関連するエミッタ設定は AkEmitterSettings::roomReverbAuxBusGain
だけで、Auxバスへのセンドレベルをエミッタごとにコントロールできるようにします。
あなたのマップやレベルのジオメトリをもとに、ルームやポータルを AK::SpatialAudio::SetRoom
や AK::SpatialAudio::SetPortal
を使用して作成する必要があります。ルームやポータルの設定をランタイムに変更することが可能で、ランタイムに同じIDでファンクションをもう一度コールします。続いてゲームが各エミッタやリスナー用に AK::SpatialAudio::SetGameObjectInRoom
をコールして、それらがどのルームにいるのかをSpatial Audioに伝えます。Spatial Audioはルームに決まった位置や形や大きさがあるとは、とらえていません。このため形状に制限はありませんが、オブジェクトがどのルームにあるのかを判断するコンテインメントテストの実行は、ゲーム側の責任です。
dangerous | Warning: ルームIDに注意してください。ゲームオブジェクトとスコープが同じなので、絶対にゲームオブジェクトで使われているIDを使用しないでください。 |
dangerous |
Warning: 裏の仕組みとして、Spatial AudioはそれぞれのルームをゲームオブジェクトとしてWwiseに登録しています。このゲームオブジェクトは、AK::SoundEngine へのコールに具体的に使用するべきではありません。 |
最も重要なルーム設定が 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::SpatialAudio::SetPosition
を使用して、 AK::SoundEngine::SetPosition
を使用しないでください。また、 AK::SoundEngine::SetMultiplePositions
をSpatial Audioのエミッタと使用することはできず、これはSpatial Audioが、生のマルチポジショニングを内部で使用しているからです。ただし、Spatial Audioで使わないゲームオブジェクトに AK::SoundEngine::SetMultiplePositions
を使用することに問題はありません。AK::SoundEngine::SetMultiplePositions
はローレベルのポジショニング機能として捉えて、もし使用するのであれば、その環境は自分で管理してください。 同様に、 AK::SoundEngine::SetGameObjectAuxSendValues
をSpatial Audioのエミッタに絶対に使用しないでください。ただし、 AK::SpatialAudio::SetEmitterAuxSendValues
をルームの中にあるSpatial Audioエミッタと使用することはできます。詳細は、 複雑なルームリバーブの実装 を参照してください。
また、 AK::SoundEngine::SetObjectObstructionAndOcclusion
や、 AK::SoundEngine::SetMultipleObstructionAndOcclusion
を、Spatial Audioエミッタに使用しないでください。Spatial Audioは、エミッタがほかのルームにあるときは、オブストラクションやオクルージョンを、より精度の高い回折やトランスミッション経由で管理します。ルーム内のオブストラクションを設定するには、 AK::SpatialAudio::SetEmitterObstructionAndOcclusion
や AK::SpatialAudio::SetPortalObstructionAndOcclusion
経由で行います。オブストラクションやオクルージョンの詳細と、それらをSpatial Audioのルームやポータルでどのように使用するかについては、 ほかのルームの音伝播のモデル化 や、 同じルームからの音の伝播のモデル化 のセクションを参照してください。
このAPIの使い方を説明するデモページが、Integration Demoサンプル(場所はSDK/samples/IntegrationDemo)にあります。Demo Positioning > Spatial Audio: Portals にあります。
Wwise Spatial Audioに関しては、ほかのルームからの音の拡散は、Rooms and Portalsの抽象化だけで管理されています。開いたポータルのないルームでは、透過のモデル化にWwise Occlusionを活用しますが、リスナーへの伝播パスで開いたポータルを経由するものが1つでもあるルームでは、オブストラクションか、組み込みゲームパラメータの回折(diffraction)を使います。同じルームのオブストラクションには、ゲームで既に提供されているジオメトリやレイキャストのサービスに基づいた独自のアルゴリズムを実装して、希望の詳細レベルも採用することを推奨しています。ただし、ここで必ず AK::SpatialAudio::SetEmitterObstructionAndOcclusion
と AK::SpatialAudio::SetPortalObstructionAndOcclusion
を使い、Spatial Audioの回折と競合しないようにします。Spatial Audioで同じルームのオブストラクションを使う場合の詳細は、section 同じルームからの音の伝播のモデル化 を参照してください。
これらの音響の概念については、 Spatial Audioの概念 を参照してください。
下表はSpatial AudioのRooms and Portals機能の内容で、音響現象の種類別に、Spatial Audioでできることと、サウンドデザイナーがプロジェクトに取り入れる方法を、まとめています。
Acoustic Phenomenon | Spatial Audio | Wwiseのサウンドデザイン |
---|---|---|
Diffraction of direct path |
|
|
拡散音場(リバーブ) |
|
リバーブ、バスボリューム、ゲーム定義のセンドオフセットを適用した<span>Actor-Mixer |
ルームのカップリング: リバーブのスペーシャリゼーションと、回折を適用した<span>隣のルームの拡散音場 |
|
|
トランスミッション(アクティブなポータルがない場合のみ) | オクルージョン | ボリュームやフィルター付けを<span> Actor-Mixer |
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度)に設定されています。スプレッドはルームに入り込むにつれ、さらに増加して、開口部は、一番近いポータルの方向性に確実に維持されるようにします。
隣のルームのリバーブは、ポータルの位置にある音源としてとらえるべきで、リスナーとの距離関係に基づく作用の変化については、AuxバスのPositioningタブにあるAttenuation ShareSetが使えます。このバスのEnable Game-Defined Sendsチェックボックスを選択すると、リスナーのルームのリバーブに、より遠くまで送信されるようになります(下図参照)。リスナーのリバーブに送信される量の調整は、Game-Defined Send Offsetや、Game-Defined Attenuationで距離を使ってできます。以下の例で使用されているShareSet は、「Portal」と呼ばれます。RoomのPortalの動作に従って設計されているためです:リスナーがPortal から離れていくと、ポイントソースになります。距離ゼロでは、リスナーはポータルを完全に横切ってRoomの中にいます。
dangerous | Warning: なお、Spatial Audioがポータルのジオメトリに従ってスプレッドを変更できるようにするには、Auxバスの減衰設定でスプレッドカーブを設定してはいけません。そこでスプレッドカーブを使うと、Spatial Audioが計算した値がオーバーライドされてしまいます。 |
ルーム内で、ルームゲームオブジェクトのポジションはリスナーと同じ位置に維持されるので、全ての減衰カーブの距離が0と判断されます。
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
モードを使うので、あるポータルを有効・無効にしても、ほかのポータルから聞こえるボリュームに影響しません。
dangerous | Warning: なお、Spatial Audioエミッタにマルチポジションを適用できません。できるのはSpatial Audioだけで、「舞台裏」で行っています。 |
Spatial Audioは舞台裏で、ルーム1つにつきWwiseにゲームオブジェクト1つを登録します。
dangerous | Warning: このゲームオブジェクトは、直接使うべきではありません。 |
リスナーがルームにいると、ルームのゲームオブジェクトは、リスナーを追うように移動します。このため、ルームとリスナーオブジェクトの間の距離は、約0です。ただし、オリエンテーションはルームの設定(AkRoomParams)の指定どおりに維持されます。3Dバスのオリエンテーションの検討については、
3Dリバーブを使う を参照してください。
リスナーがルームの外にいると、ルームのゲームオブジェクトにポータルのポジションが適用されます。厳密には、ポータルのうしろに配置され、リスナーからポータルのタンジェントへの投影の場所で、ポータルの範囲に固定されています。確認するにはルームのゲームオブジェクトを見ますが、前出の エミッタ の3D Game Object Profilerのスクリーンショットにも表示されています。
複数のポータルの場合、エミッタの場合と同じ理由で、ルームのゲームオブジェクトが MultiPosition_MultiDirection
モード複数のポジションにアサインされます。
ポータル内でトランジションするときに、「ルーム内」動作と「ポータル」動作はスムーズに補間されます。
Spatial Audioのルームやポータルを使うと、リスナーのいるルーム以外のルームの音の伝播は、Rooms and Portalsの抽象化で管理します。ほかのルームのエミッタは、ポータルとポータルに関連した回折を経由してリスナーまで伝わり、そのようなパスが存在しない場合は、ルームの壁を透過して伝わります。
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は透過(壁の透過)のモデル化に頼り、これにはエミッタゲームオブジェクトのオクルージョンを使用します。オクルージョン値はルームの設定 AkRoomParams::WallOcclusion
を利用して、最大オクルージョン値は、リスナーのルームとエミッタのルームの間からとります。オクルージョンは、Project SettingsのObstruction/Occlusionタブで設定した、グローバルでプロジェクト全体のカーブを経由して、ボリューム、LPF、HPFにマッピングされます。オブストラクションと違い、オクルージョンはAuxバスに送られたシグナルにも影響するので、オクルージョンを受けたエミッタのルームリバーブへの影響や、カップリングされたリバーブは、オクルージョンカーブに従い拡大・縮小したりフィルターをかけたりします。このようにして、オクルージョンで吸収(透過)を適切にモデル化できます。
info | Note: Spatial Audioは、Wwiseサウンドエンジンの制約のため、回折と透過を同時に並行してモデル化することはできません。しかし壁を透過してくるエネルギーは、開いたドアを回折するエネルギーと比較すると、一般的に無視できるほど小さいものです。 |
リスナーのルームのポータルを通して隣室などから浸透してくる拡散エネルギーは、このポータルに位置する音源ととらえることが可能で、そのため、リスナーのルームの励起に貢献するはずです。言い換えると、リスナーのルームのAuxバスにセンドするべきです。前述のとおり、これは隣のルームのAuxバスのEnable Game-Defined Sendsチェックボックスをチェックすればできます。ほかのルームのリバーブに送る量を微調整することも可能で、Game-Defined Send Offsetや、Game-Defined Attenuationと距離などで、調整します。
リスナーと同じルームから出された音のオブストラクションは、Spatial Audioのルームやポータルで対応できないので、ゲーム側に委ねられています。同室内のオブストラクションを計算するために使うジオメトリの表現、方式、そして理想の詳細レベルは、ゲームエンジンによってかなり違います。典型的なゲームでは、このタスクの実行にレイキャストを採用していますが、精度はゲームによって様々です。
しかしSpatial Audioのルームやポータルを活用すれば、全てのエミッタで処理する必要はなく、リスナーと同じルームにいるエミッタだけになります。通常のレイキャストが伝播パスを計算するのは、Spatial Audioに使われるアルゴリズムと比較してかなり負荷が大きいので、有利です。エミッタとリスナーの間の室内オブストラクションは同じルームで起きるので、その言葉の意味からして、障害物がリスナーやエミッタを完全に覆うことはなく、音は室内の反射を通してリスナーに届くものと考えます。これは、Auxセンドを変えずにドライ・直接シグナルだけを変えれば正しくモデル化できるので、該当するメカニズムはオブストラクションです。この目的のためには、ゲームは AK::SpatialAudio::SetEmitterObstructionAndOcclusion
をコールすべきで、 AK::SoundEngine::SetObjectObstructionAndOcclusion
をコールすべきではありません。同じルーム内にオブストラクションがエミッタとリスナーの間にあることをSpatial Audioに知らせるには、この方法しかなく、Spatial Audioは、これを計算に取り込むと同時に、ほかの目的で使うオブストラクションやオクルージョンの活用(回折や透過)に干渉させません。
さらに隣室へのポータルは、リスナーのルーム内にあるサウンドエミッタのようにとらえるべきです。これに伴い、リスナーと、リスナーがいるルームのポータルの間でも、ゲームのオブストラクションアルゴリズムを実行するべきです。それにはゲームが各ポータルに関して AK::SpatialAudio::SetPortalObstructionAndOcclusion
をコールして、ルーム内のオブストラクションをリスナーに確実に宣言するべきです。
dangerous |
Warning: Spatial Audioエミッタとして登録されているゲームオブジェクトに関して、 AK::SoundEngine::SetObjectObstructionAndOcclusion or AK::SoundEngine::SetMultipleObstructionAndOcclusion を絶対にコールしてはいけません。 |
音の伝播は、複数のルームも経由できます。伝播のパスを探す時に、SpatialAudio内でRoomツリーのサーチを行います。円形のサーチを防止するために、すでにサーチしたルームに再び来た時は停止します。サーチの深度は、Spatial Audioの初期化設定 AkSpatialAudioInitSettings::uMaxSoundPropagationDepth
で制限できます(デフォルトは 8)。
AK::SoundEngine::SetGameObjectAuxSendValues
はゲームオブジェクトのセンド値をオーバーライドするのでSpatial Audioのエミッタとの使用を絶対に避けるべきですが、 AK::SpatialAudio::SetEmitterAuxSendValues
はSpatial Audioが既に設定したAuxセンドに追加されます。室内に複雑なリバーブをデザインする時などに便利で、例えば同じ部屋に環境エフェクトが違う物体や地形がある場合などに利用できます。ルームの AkRoomParams::ReverbAuxBus
を"none" (AK_INVALID_AUX_ID
)にすると、センドバスを、 AK::SpatialAudio::SetEmitterAuxSendValues
経由でゲームだけが管理できるようになります。
Wwise Spatial Audioへ送信されたジオメトリ情報を使って、音の回折をエミュレートできます。つまり、あなたのゲームエンジンでオブストラクションを計算するレイキャスト方式を、完全に置き換えることも可能です。エミッターが障害物に隠れてリスナーから見えないとき、Spatial Audioが障害物の端にそってパスを計算し、見つかれば、その端を回り込む音によって発生する回折係数を計算します。これに合わせてエミッターの見かけの入射角が調整され、回折値がWwiseに送信されるので、最終的に音にどう影響するかをあなたがWwiseでコントロールできます。回折の結果としてローパスフィルターが適用されるのが一般的です。
下図Wwiseの3D Game Object Viewerのスクリーンショットに表示されているのが、音が薄い壁の端の周りを回折している様子です。
dangerous | Warning: オブストラクションの計算方法として、あなたのゲームエンジンのレイキャスト方式から、ジオメトリを使った回折に完全に切り替えることは可能ですが、ジオメトリが複雑になるとパフォーマンスコストが急速に拡大します。現時点では、回折の計算をシンプルなジオメトリに制限し、回数も調整すべきです。実験的な機能としてフラグが立っているのは、このためです。また、効率的なRooms and Portalsによる抽象化( ルームとポータルを使用する 参照)を、ジオメトリによる回折と合わせて利用した方が、後者の複雑な計算を減らせます。 |
Wwise Reflectと組み合わせて使えば、ジオメトリによる回折をエミッターとリスナーの間の直接的な音の伝播のパスだけでなく、その初期反射のパスに対しても適用できます。
Spatial Audioに送信されるジオメトリセットはすべて、回折のパスを計算するときに考慮するべきかどうかを明確に示す必要があります。明示するには、AkGeometryParams::EnableDiffraction
フラグを使います。このフラグが回折の計算に必要なエッジデータ生成を可能にし、ダイレクトパスに対するジオメトリによるディフラクションと、リフレクションのディフラクションの、両方で使われます。
また、メッシュの境界エッジでも音が回折するのかどうかを検討します。メッシュの境界エッジとは、1つの三角形だけにつながるエッジのことで、多様体の境界に存在することになります。エッジ数が増えると回折の計算がより複雑になるので、あなたのメッシュの境界エッジで音が回折しないのであれば、このオプションを無効にしておきます。
最後に、エッジ材質はエネルギーを吸収せず、Acoustic Surfaceに設定されているAcoustic Textureは回折に一切影響しません。エッジは、音を単に曲げるだけです。
Geometric Diffractionのデモが、Integration Demoサンプルにあるので(SDK/samples/IntegrationDemoの中)、ダイレクトパスのジオメトリによる回折に、ジオメトリを利用する例を、ご覧ください。このデモの場所は、Demo Positioning > Spatial Audio: Geometryです。
音のエミッターのダイレクトパスの回折にジオメトリを適用する場合は、そのエミッターのAkEmitterSettingsを適切に設定する必要があります。特に、AkEmitterSettings::diffractionMaxEdges
、AkEmitterSettings::diffractionMaxPaths
、AkEmitterSettings::diffractionMaxPathLength
は、必ず0より大きい値とします。詳細は、それぞれのドキュメンテーションを参照してください。
回折の様子を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( ルームとポータルを使用する )でも、隣接するルームのダイレクトサウンドの回折をPortalsによってモデル化します。これら2つのシステムは補完し合う関係で、リスナーと同じ部屋にないエミッターに対して、ジオメトリに基づく回折パスを見つけようとすることはありません。ジオメトリよりもRooms and Portalsの計算の方がかなり効率的なことを考慮すると、複雑な計算を制限するために、2つのシステムを併用することにメリットがあります。
上記の通りアーリーリフレクションはエッジで回折することがあり、エミッターをWwise Reflectにルーティングすると、Spatial Audioがこの現象のモデル化をサポートします。
その方法を説明する前に、ビューゾーン内の回折を定義する必要があります。
下図をご覧ください。エミッターはリスナーの視界に入っていますが、鏡面反射がリスナーに当たっていません。つまり、ビューゾーンに入っているのです。すでに Diffraction(回折) で説明した通り、回折はビューゾーン内でも発生します。ただしWwise Spatial Audioでは、ダイレクトパスのモデル化を行うRooms and Portalsでもジオメトリによる回折でも、ビューゾーン内の回折が実際のダイレクトパスと比較して無視できる程度なので、考慮されません。しかし反射に関しては、ビューゾーンの回折が劇的な影響をもっています。回折がないとアーリーリフレクションが聞こえるのはリフレクションゾーン内だけで、そこでは純粋な鏡面反射となっています。リスナーがビューゾーンに入った途端、反射が聞こえなくなります。回折を有効にしておけば、エッジが作用して反射波が回折されます。そうすると、リスナーがリフレクションゾーン内を歩き回ったり、そこを遠ざかったりしたときに、追加のフィルタリングや減衰が適用されたあとの反射を聞くことができるのです。
リフレクションゾーン内では、鏡面反射でほかが圧倒されるものと予想し、回折パスも、それに伴う回折値も、計算されません。あるエッジにおけるビューゾーンの回折を計算すると、リフレクションゾーンとビューゾーンの境界線において0となり、ビューゾーンとシャドーゾーンの境界線において100となります。
高次のアーリーリフレクションでは、ビューゾーンとシャドーゾーンの両方の回折が作用します。
コード側では、通常どおりに対象のエミッターが、希望する次数でWwise Reflectに送信するように設定するだけです。詳細は、 ゲーム側のセットアップ をご覧ください。反射の回折を目的とする回折の特別な設定はなく、ジオメトリに対して回折を有効にするだけで充分です。
回折エフェクトを適用した反射は、Wwise Reflectでイメージソースとして表示されます。反射の回折のエフェクトをデザインするのに、回折で変化する3つのカーブ、つまりDiffraction Attenuation、Diffraction LPF、Diffraction HPFを使うことができます。詳細は Wwise Reflect's documentation を参照してください。
現時点で、Spatial AudioのRooms and Portalsと、アーリーリフレクション計算は、互いに作用しません。このため、反射と、さらに重要なことに、回折された反射は、エミッターとリスナーが違うルームにあっても計算されます。