このブログは私が2022年に書いた『Wwise Unrealインテグレーションの改善』に続くものです。前回のブログではWwise Unrealインテグレーションの以前のバージョンでみられた問題についてお詫びし、今後の計画をお伝えしました。今回はそれからの1年を振り返りながらWwise Unrealインテグレーションの現在の状況についてお話します。

1年の振り返り

Wwise 2022.1 Unrealインテグレーションのリリースにおいて、SSOT（Single Source Of Truth）と呼ばれる新しい考え方が導入されました。簡単に説明すると、Wwise UnrealインテグレーションではGenerated SoundBankフォルダを信頼できる唯一の情報源、つまりSSOTとしてとらえ、Wwiseプロジェクトを「理解」するためにこれに依存します。新しいモデルではWwiseプロジェクトにあるすべてのイベントとバスにそれぞれに対応するUnrealアセットを自動的に作成することをやめ、Unrealプロジェクトで使用されるWwiseオブジェクトだけに対してUnrealアセットを作成するようにしました。Wwise UnrealプラグインのAkAudioEventアセットはクッキング、ビルド、パッケージングの要です。これらはブループリントやC++コードでサウンドの再生をコントロールする時にも使用するアセットです。

ベータ版に対するフィードバック

Wwise 2022.1.0ベータ版を提供しはじめ、すぐにコミュニティからのフィードバックが入ってきました。私はAudiokineticサポートチームの一員として、送られてきたサポートチケットにある建設的な批判内容について大半を知っております。

SSOTに切り替えたことを誰もが賛成してくれたようでしたが、Unrealアセットを管理するためのツールが一部足りないことがすぐに明らかになりました。Wwise Unrealインテグレーションの現行ユーザからは、以前のインテグレーションにあったアセットの自動同期機能をなつかしむ声があがりました。WwiseでEvent名を変更した場合においても、Unrealアセットの名前を自動的に変更しないという私たちの決断に納得しないユーザも多くいました。WwiseでEvent名が変更された場合にも新しいUnrealアセットは再生すべきサウンドを問題なく把握できますが、Unrealアセット名がEvent名にそっていないことで混乱するかもしれません。

リリースの延期

ベータ期間中に寄せられたフィードバックの量は相当なものであり、何らかの変更を必要とするフィードバックが大半でした。フィードバックを取り込みながら正式バージョンを予定通りにリリースできないことが早々に判明し、リリース時に完全で安定したソリューションを提供するためにWwise 2022.1.0のリリース日を遅らせることにしました。

Wwise BrowserとReconciliation

ベータローンチ後に入ってきたフィードバックに基づき、Wwise Browserへの統合計画が明確な優先事項となりました。ご存知のない方のために説明しますと、2022.1.5のリリースでWwise BrowserにWwise PickerとWAAPI Pickerが統合されました。SoundBankメタデータに何があるのかをWwise Pickerに示し、接続中のWwiseプロジェクトに何があるのかをWAAPI Pickerに示すという従来の方法に代わりに、Wwise Browserで両方を表示してWwiseオブジェクトや対応するUnrealアセットのステータスの情報を提示します。

見た目は小さな更新ですが、2022.1.6バージョンではReconcileボタンが追加され、WwiseオブジェクトやUnrealアセットの同期に大きな影響を与えました。マウス数クリックだけでWwiseオブジェクトの一部またはすべてを同期できるようになったのです。またSoundBank生成後などにWwiseReconcileCommandletを起動し、Reconciliation（調停）を自動化することも可能です。

複数のサウンドエンジンバージョンをサポート

本インテグレーションで導入されたもう1つの変更点が、Wwiseがプロジェクトに存在しないことを状況によって許容するということです。当初の動機はゲームのオーディオが不要なサーバ版を構築するチームのために、ソリューションを提供することでした。私たちがNull Sound Engineと呼ぶもので、一部のプロジェクト構成をWwiseなしで構築することができます。この変更前は使用予定のないSoundEngineを無駄にロードすることが頻繁にありました。

特定バージョンのインテグレーションコードで複数のSoundEngineに対応できるようになったところで、Wwiseのメジャーバージョンのためのモジュールを追加しはじめました。現在のインテグレーションコードがWwise 2022.1.xや2023.1ベータ版でうまく動作するのはこのためです。インテグレーションコードがWwiseバイナリのバージョンを検出し、Wwiseとのやり取りのための適切なSoundEngineモジュールを使用します。特定のプラットフォームのWwiseバイナリが欠落している場合、インテグレーションはNull SoundEngineを使用します。

SSOTの場合のアセット管理

過去のUnrealインテグレーションで行われてきたEBP（Event-Based Packaging）から離れ、WwiseでSoundBankを自動的に生成することができるようになりました。これらをAuto-defined SoundBankと呼び、Wwiseで手動でつくるSoundBankをUser-defined SoundBankと呼ぶようになりました。これらをUnreal SSOTプロジェクトで引き続き使用することができますが、UnrealインテグレーションにおけるWwiseアセットの管理方法が理解されている必要があります。

レガシーIOフックとUnreal IOフック

IO（Input and Output）フックはディスクのファイルを読み書きする関数です。WwiseのIOフックはWwiseでデフォルトで使用されるためデフォルトStreaming Managerと呼ばれていますが、Wwiseユーザが別のツールでIOを管理することも予想されます。例えば独自ゲームエンジンを使用しているチームなどはWwise SoundBankやストリーミングファイルをロードするために、独自ゲームエンジンのIOフックを使うかもしれません。

2019.2.1でEBPワークフローが導入されたことに伴い、プロジェクトでEBPが使用される場合はUnreal IOフックを使用することになりました。従来のワークフローを使い続けているチームのために、レガシーIOフックを残しておきました。

2022.1.0にSSOTワークフローが導入され、すべてのIOにUnreal IOが使われるようになったため、レガシーIOフックの使用を廃止しました。UnrealユーザがエンジンのIOフックをオーバーライドすることはないと思われ、WwiseのデフォルトStreaming Managerは任意であったため、これをUnrealのフックに置き換えました。

WwiseメモリとUnrealメモリ

Wwiseの初期化シーケンスの一環として、実行時にSound Engineに必要なメモリを管理するためにMemory Managerモジュールを初期化します。Wwise Unrealインテグレーションにおいて常にこのようにしてきましたが、この時にメモリにロードされる内容は使用するモデル（レガシー、EBP、またはSSOT）によって異なります。2019.2より前のインテグレーション（つまりレガシー）においてはSoundBankやストリーミングメディアのファイルをロードし、ゲームで再生しました。対応するEventやSoundBankのUnrealアセットはUnreal Engineが割り当てるメモリにロードされました。

2019.2.1バージョンでEBPワークフローを導入して以来、アセットにカプセル化されたメディアをUnrealが割り当てたメモリに保存するようになりました。私たちが学んだ手痛い教訓のひとつはUnrealアセットがプロジェクトのクッキングやパッケージングに優れている一方、メディアを入れる容器としては信頼できないということでした。EBPのSoundBankにメディアが入っておらず、Wwiseでオーサリングした状態のEventやStructureが入っているだけでした。これらはWwiseが管理するメモリにロードされていました。

Wwise 2022.1.0のSSOT導入以来、WwiseメディアをUnrealアセット内に保存しなくなりました。EventアセットにはWwise Eventに関する情報だけ、つまりディスク上の場所や、Wwiseがそれらを見つけるためのIDだけが入るようになりました。EBPではSSOT用のSoundBankにメディアが含まれておらず、Wwiseが管理するメモリにロードされます。Eventのロードが必要となった時にメディアの入っていないSoundBankがWwiseメモリにロードされ、メディアファイルがUnrealメモリにロードされます。ロードされたメモリ上の場所はSDK関数のLoadBankMemoryViewまたはLoadBankMemoryCopyを使用してWwiseに渡されます。メモリ効率が最もよい選択肢はAuto-defined SoundBanksであり、LoadBankMemoryViewによってロードされるためメモリの重複を回避できます。

このメモリアロケーションは効率性が最も高い一方、Wwise ProfilerでモニタリングできるメモリはWwiseが割り当てたものだけという欠点があります。つまりメディアの入っていないSoundBankが使用するメモリはWwise Profilerに表示されますが、メディア保存に使用するUnrealメモリは表示されません。このため私たちはUnrealのWwise/WwiseMemory statカテゴリにWwiseのメディアメモリカウンタを集約し、Unreal statコマンドを使用してメディアアロケーションを追跡できるようにしました。

将来の展望

現在取り組んでいる改善の1つがUnrealプロジェクトにおけるWwiseデータのパッケージングオプションの更新です。いまはUAsset以外のアセットをUnrealでパッケージングすることが難しいため、改善すべき領域であると認識しています。特にサポートを改善したいのがZen Loader、Zen Store、DLC、ローカライゼーション、新Virtual Asset、機能アップデートなどです。

近日予定されているのが私たちのUnreal GymsのGitHubへのリリースです。私たちはSSOTワークフローの開発中にGymsフレームワークを作成し、可能な限りテストを自動化させました。またサポートに報告された問題を再現するために、このフレームワークを使いはじめました。調査の過程で開発された新しいジェムは私たちのコレクションに加えられ、将来のテストが強化されます。