多くの 新機能 では、Wwise 2017.2に移行する際にいくつかの点に注意する必要があります。
次の重要な移行ノートをよくお読みください:
一部のエフェクトやソースプラグインライブラリの名前を変更しました。
SDK lib ファイル内:
- AkSoundSeedWind.lib -> AkSoundSeedWindSource.lib
- AkSoundSeedWoosh.lib - > AkSoundSeedWooshSource.lib
- AkSynthOne.lib -> AkSynthOneSource.lib
SDK bin ファイル内:
- AudioInput.dll -> AkAudioInput.dll
- ParametricEQ.dll -> AkParametricEQ.dll
- SilenceGenerator.dll -> AkSilenceGenerator.dll
- Sine.dll -> AkSineTone.dll
- SynthOne.dll -> AkSynthOne.dll
- ToneGen.dll -> AkToneGen.dll
SDK\include\AK\Plugin 内:
Authoring\x64\Release bin 内:
- AudioInput.dll -> AkAudioInput.dll
- iZHybridReverb_Plugin.dll -> iZHybridReverb.dll
- iZTrashBoxModeler_Plugin.dll -> iZTrashBoxModeler.dll
- iZTrashDelay_Plugin.dll -> iZTrashDelay.dll
- iZTrashDistortion_Plugin.dll -> iZTrashDistortion.dll
- iZTrashDynamics_Plugin.dll -> iZTrashDynamics.dll
- iZTrashFilters_Plugin.dll -> iZTrashFilters.dll
- iZTrashMultibandDistortion_Plugin.dll -> iZTrashMultibandDistortion.dll
- ParametricEQ.dll -> AkParametricEQ.dll
- SilenceGenerator.dll -> AkSilenceGenerator.dll
- Sine.dll -> AkSineTone.dll
- SynthOne.dll -> AkSynthOne.dll
- ToneGen.dll -> AkToneGen.dll
- Wind.dll -> AkSoundSeedWind.dll
- Woosh.dll -> AkSoundSeedWoosh.dll
- AkPerforce.dll -> Perforce.dll
- AkSubversion.dll -> Subversion.dll
オーディオ出力管理、セカンダリ出力、シンクプラグインの破壊的な変更(breaking changes)
出力(メイン、BGM、ゲームコントローラのスピーカー、ヘッドフォン、DVRなど)の管理方法が、2017.2で刷新されました。全てのオーディオシンク(audio sink、オーディオハードウェアとのやりとりを担当する)でプラグインモデルが採用され、AudiokineticがWwiseで提供するオーディオシンクも同じです。つまり、全てのプロジェクトにおいて、対応プラットフォームを1つ以上使っていれば、タイプ毎のAudio Devicesシェアセットがプロジェクトに追加されます。今後はそれぞれのマスターバス(ミキシング階層のトップにあるバス)に、必ずオーディオデバイスが付随することになり、それによってミックスの出力先が定義されます。この機能は今までコードで行われ、初期化の時点(AkInitSettings
経由)で、または AK::SoundEngine::AddSecondaryOutputを使っ
て、行われました。2017.2への移行時に、既存プロジェクトのマスターオーディオバスやマスターセカンダリバスに、Systemデバイスが自動的に追加されます。
| 注意: マスターセカンダリバスの使い方を見直してください!今までに使ったことがあれば、必ず正しいオーディオデバイスを選択します。場合によっては、バス階層を分割して、ほかの出力用に別のマスターバスを確保します。これで、必要な数だけマスターバスを作成できるようになり、通常はハードウェア出力1つに対して、マスターバスを1つ準備します。 |
| 注意: 主要な出力にプラグインを使っていた場合(例えばPSVRバイノーラルプラグインなど)、それを必ずマスターオーディオバスのAudio Deviceプロパティにリンクします。もしこのプラグインに対応するプラットフォームが1つだけ(PS4など)であれば、リンク・アンリンクの機能を使って全てのプラットフォームで正しくプロパティを設定してください。 |
また、セカンダリアウトプットに関連するリスナー管理も変更されました。一般的に、今までのコードが変更なしで同じように動作するはずです。ただし、デバイスの1つのタイプに対して、許容されるデバイスが1つだけであれば、システムが必要とするリスナーは少なくなります。詳細は セカンダリ出力の統合 をお読みください。
出力管理の刷新による、APIの変更
- 関数
AK::SoundEngine::AddSecondaryOutput
が、 AK::SoundEngine::AddOutput
に変更され、パラメータが変わりました。RemoveSecondaryOutput
も同様です。これらの関数のドキュメンテーションを参照してください。あなたのWwiseプロジェクト内で、該当するオーディオデバイス名を見つけて(または追加して)、同じ関数を AddOutput
で入手します。
AK::SoundEngine::Init
(AkInitSettings
) や AK::SoundEngine::AddSecondaryOutput
で使われていたenumである AkAudioOutputType
が、削除されました。その機能を代わりに行うのが、オーディオデバイス用のプラグインのメカニズムです。
AK::SoundEngine::GetSpeakerConfiguration、
AK::SoundEngine::GetPanningRule、AK::SoundEngine::SetPanningRule、
AK::SoundEngine::GetSpeakerAngles、
AK::SoundEngine::GetSpeakerAngles、
AK::SoundEngine::SetSpeakerAngles
は全て、AkAudioOutputType
ではなく、
AkOutputDeviceID
を使います。 AkOutputDeviceID
が、 AK::SoundEngine::AddOutputによっ
て、または新関数の AK::SoundEngine::GetOutputIDによっ
て、返されます。
モーション対応における破壊的な変更(breaking changes)
モーションシステム(rumble、振動)全体がリファクタリングされ、旧来の別々のコードバスではなく、オーディオデバイスの汎用プラグインメカニズムと、新しい出力システムが使われます。モーションデバイスを、今後は特別なステータスのデバイスではなくオーディオデバイスとして扱います。これでMotionオブジェクトのコードやデータモデルの無駄が省かれ、オーディオパイプラインと同じ機能セットを全て利用できるようになりました。つまり、同じMotionエフェクトを確保するには、既存のコードに多数の修正が必要となります。Wwiseプロジェクト側の変更内容は、大部分が自動的にトランスペアレントに実行されます。あなたのプロジェクトに対して実施される変更内容については、以下の 基本的なプロジェクト移行の変更点: のセクションを参照してください。
モーションのリファクタリングによる、APIの変更
AK::MotionEngineのネームスペー
ス が、全て削除されました。つまり、 AK::MotionEngine::AddPlayerMotionDeviceを置き換えるに
は、AK::SoundEngine::AddOutputをコールして、その際に正しいAudio Device ShareSet名(通常はWwise_Motion)を使う必要があります。このオーディオデバイスは、自動的にプロジェクトに追加されるはずです。
さらに、Motionに関連するリスナー管理も変更されました。 AK::MotionEngine::SetListenerPipelineをコールするのでは
な く、プレイヤーにリンクしているリスナーを、 AK::SoundEngine::AddOutputに対するパラメータとして提供する必要があり
ま す。なおこのリスナーは、ゲームのプレイヤーが1人だけであれば、必須ではありません。マルチプレイヤーゲームの場合は、今までのように正しくリスナーを管理する必要があります。
ゲームにモーションを実装する詳細は、このSDKヘルプ: Wwise Motionの統合 を参照にするか、またセカンダリアウトプットの一般的な情報: セカンダリ出力の統合 を参照してください。
基本的なプロジェクト移行の変更点:
既存プロジェクトは、自動的に新システムに移行されます。あなたのプロジェクトで、以下の変更が実行されたか確認してください:
- Master-Mixer Hierarchyで、Motion Busを、Audio Busに変更。 Motion FX が、Sound FX となり、Motion Bus レファレンスはOutput Bus レファレンスに変わり、Output Busの親のオーバーライドが有効になり(親がある場合)、Output Busレファレンスを使うので、ルーティングが行われることを確認します。
- Motion Sourceは、SFX Language指定を追加したSource Pluginとなります。DeviceCompanyIDとDevicePluginIDが削除されます。 移行後もモーションができるだけシームレスに動作するようにしたいので、プロジェクトのプラットフォームを1つ以上、Wwise Motionがサポートしている場合は、自動的に新しいWwise Motion ShareSetをAudio Devicesデフォルトワークユニットに追加します。例外について、下記Noteを参照してください。
- Audio Device ShareSetレファレンスは、Master Audio Bus、Master Secondary Bus、Master Control Busにおいて、デフォルトのSystemに設定されます。
- プロジェクトが対応していれば、Wwise Motion ShareSetが、Master Motion BusまたはMotion Master Busにアサインされます。例外について、下記Noteを参照してください。
- WwiseオーサリングアプリケーションのProperty EditorにあったMotionタブが、削除されました。
| 注釈: モーションバスへのレファレンスがない場合は、プロジェクト内の全てのモーションバスが削除されます。また、Wwise Motionシェアセットは、それに対応しているプロジェクトでも、追加されません。 |
Audio-To-Motionの移行:
- Motion Busレファレンスは今後は、元の(モーション)バス(移行後は通常のオーディオバス)の子のAuxiliary Busに対するUser Aux Sendとなります。ここで、"モーション" Aux sendが確実に実行されるように、移行後のオブジェクトのUser aux sendオーバーライドを許可することが、暗黙の了解です。これによる影響は、以下の Audio-to-motionにおいて、モーションバスレファレンスを、User Auxilisary Sendに切り替えた時の影響 で詳しく説明します。
- Motion Low Passプロパティは、Auxilieary send LPFとなります。
- Motion Volume Offsetプロパティは、Auxiliary sendボリュームとなります。
Audio-to-motionにおいて、モーションバスレファレンスを、User Auxilisary Sendに切り替えた時の影響
モーションバス用の別のパスを使わず、基本的なUser aux bus sendを使うことになるので、いくつかのシナリオが考えられます。
- もしサウンドSFXやミュージックトラックに、既に4つのUser aux sendがある場合は、audio-to-motionが移行されません。
- モーションバスレファレンスをUser aux sendレファレンスに変換する過程で、対象のオブジェクトのUser aux sendが整理されます。
- もしUser aux sendの設定で、親のオーバーライド設定が有効でなければ、削除してしまいます。こうすることで、既存のUser aux sendsの個数が多すぎてaudio-to-motionの移行が失敗するような確率を、減らせます。
| 注釈: 以下のサブセクションについて: User aux sendをコピーする過程で、バスレファレンス、ボリューム、LPFもコピーします。全てのRTPC、Modulator LFO、Modulator Envelope、そしてボリュームやLPFに対するCurveやModifierも、コピーします。全てのID(ユニークID、ShortID)を再生成することで、移行後のプロジェクトをロードする時のIDクラッシュを最小限に抑えることができます。残るクラッシュ(おそらくShortIDが関与)がある場合は、Wwiseのプロジェクトロードの手順で解消します(Project Load Logの警告付き)。 |
| 警告: ノードから子孫にUser aux sendをコピーすると、子孫がノードのAux sendを継承するように設定するのと等しい作用ですが(最初は)、ノードのAux sendに変更を加えると、それは子孫に反映されません。 |
Audio-to-MotionオブジェクトのUser aux sendsで、'Override parent'が有効になっていない場合に、移行
- オーバーライドが有効になります。
- 移行するオブジェクトの祖先のUser aux sendが、オブジェクトにコピーされます。もし祖先のAux sendが移行したaudio-to-motionからくるものがあれば、それはコピーされません。
- オブジェクト1つに対してAux sendが4つに制限されているので、祖先のAux sendが全てコピーされない可能性があります。この場合、audio-to-motionは移行されず、既存のオーディオ動作を維持することが優先されます。
Audio-to-MotionオブジェクトのUser aux sendsで、'Override parent'が有効になっている場合に、移行
- オーバーライドは有効のままです。
- 既に親をオーバーライドしていたため、上位のUser aux sendをコピーする必要はありません。
Audio-to-Motionを、子孫のあるオブジェクトに移行
- 子孫が既に(移行後の)親のUser aux sendをオーバーライドしていて、それ自身の(オーバーライドする)audio-to-motionがなければ、移行後のノードの新しい"モーション" Aux sendを子孫へコピーします。もし既に子孫に4つのAux sendが設定されていれば、コピーされません。子孫を下っていくトラバースが止まるのはaudio-to-motionがあるノードに到達した時で、それがその子孫のソースだからです。
- もし子孫がその親のUser aux sendをオーバーライドしない場合は、その子孫に対してコピーする必要はなく、それは上位からの"モーション"を継承します。
モーションの移行に関する、その他の制限や変更内容
- ネスト化したワークユニットは正しく扱われず、あるオブジェクトが最上位オブジェクトかどうかを判断する際に、ネスト化したワークユニットを経由してノード階層を上へトラバースすることはありません。影響:
- トップレベルでないノードがトップレベルとして扱われてしまい、audio-to-motionがないのにも関わらず、あると判断されてしまいます。これは、モーションバスのレファレンスがあり、Override Motion Outputが無効になっている場合に発生することがあります。
- プリセットで、モーション関連の情報を削除します。つまり、移行を試みません。ここで対象となるのは:
- Motion FXオブジェクト、Motion Sourceオブジェクト
- Motion Volume、Motion Lowpass、Override Motion Outputの各プロパティ
- Motion Busレファレンス
- Wwiseオーサリングアプリケーションにあったこれらへのレファレンスが、削除されています。
- クエリで、モーション関連の情報を削除します。ここで対象となるのは:
- Motion Volume、Motion Lowpass、Override Motion Outputの各プロパティ
- MotionBus、Motion FX、Motion Sourceの各オブジェクトタイプ
- モーションアウトプットバスのルーティング
- モーションデバイスのソース
- Wwiseオーサリングアプリケーションにあったこれらへのレファレンスが、削除されています。
WAAPI機能の名称変更
以下の機能の名称を変更して、使用目的をより明確にしました:
ak.wwise.core.plugin.getList
の新名称は、ak.wwise.core.object.getTypes
ak.wwise.core.plugin.getProperties
の新名称は、ak.wwise.core.object.getPropertyNames
ak.wwise.core.plugin.getProperty
の新名称は、ak.wwise.core.object.getPropertyInfo
以前の名前は非推奨となり、新コードに使用できません。
WAAPI C++ SampleClientの変更
- コンストラクタでタイムアウトを提供した場合は、
Client
クラスの使用がコンパイルしません。タイムアウトは、クライアントへの全てのメソッドコールで同じではなくなったので、コール毎に提供する必要があります。
- SampleClientで使われたAutobahnライブラリのAkAutobahnというバージョンが、静的ライブラリとしてSampleClientとは独立してビルドされるようになりました。Wwise SDKの一部として提供されることになりました。使用例を見るには、SampleClientソースコードを確認してください。
Wwise Authoring 32-bitの終了
32-bit Wwise Authoring を削除しました。Wwise Authoringは、Windows用もmacOS用も、64-bitサポートに限定してコンパイルされます。
なお、Wwise SDKライブラリ用に、32-bitサポートを引き続き提供します。
User-defined positioningのオブストラクション、オクルージョン
- 組み込みLPF/HPFパイプラインを革新すると同時に、オブストラクションやオクルージョンをGame-defined positioningに限定していた任意の条件を削除しました。User-defined 3D positioningを設定した音がオブストラクションやオクルージョンの対象にならなかった点を利用していた場合は、それらの音には別のゲームオブジェクトを使う必要があります。
Auxバスがドライシグナルを処理するようになりました。
Wwise 2017.2で、ドライシグナルをAuxバスが処理することになり、無視されません。Auxバスに配置されたエフェクトのドライシグナルをミュートするように、移行を実行しました。この変更に影響されるエフェクトは、以下のとおりです:
- Wwise RoomVerb
- Wwise Convolution Reverb
- Wwise Matrix Reverb
- Wwise Reflect
- Wwise Delay
- Wwise Harmonizer
- Wwise Pitch Shifter
- Wwise Stereo Delay
- iZotope Hybrid Reverb
| 注意: あるエフェクトをAuxバスと別のタイプの媒体に適用すると、それもミュートされ、プロジェクト動作が変更される可能性があります。 |
組み込みオーディオ
ジオメトリ主導のスプレッド
ユーザーは、Aux bus(ポータル)で使われる減衰シェアセットのスプレッドカーブを削除しなければ、スペーシャルオーディオのジオメトリ主導型スプレッドの計算を活用できません。
Room aux sends
Roomのauxセンドに送信する時は、AkRoomParams
で指定してスペーシャルオーディオが完全に管理するものなので、今後は AK::SpatialAudio::SetEmitterAuxSendValue
をコールしないようにします。 AK::SpatialAudio::SetEmitterAuxSendValueのセンド
は、Roomsのセンドに追加されるので、同じ部屋の中で、より複雑なリバーブゾーンをカスタム化したり実装したりするときに利用できます。