Wwise 2019.2.1で導入された新アセット管理ワークフローEBP（イベントベースパッケージング）は、Unreal上でWwiseアセットを管理できる洗練されたソリューションとしてWwiseとUnrealを使用する開発者コミュニティから歓迎されました。ところが一部の開発チームは従来のSoundBankワークフローから移行する際、制作活動を妨害するようなバグに遭遇しました。Audiokineticはこれまで開発者から報告されたEBP移行関連のバグの解決に取り組む一方で、SoundBankと同等の安定感を達成するための改善を計画し実践してきました。
リリース当初の機能の不整合による遅延や不都合を経験された開発チームのみなさまには、ご迷惑をおかけしたことをお詫び申し上げます。ここで私たちGame Engine Integrationチームの計画状況をお知らせし、今後の展望をお伝えしたいと思います。この機能によりお客様のアセット管理ワークフローを強化できるよう努力してまいりますので、何卒よろしくお願いいたします。
Unrealインテグレーション変更の理由
WwiseのUnrealインテグレーションに関して最も要望の多かった機能のひとつが、Unrealプロジェクト階層におけるWwise関連アセットの自動作成でした。EventやSoundBankなどのアセットをUnrealに手動でコピーするのは、とても面倒な作業です。WwiseのEventとそれに対応するUnrealアセットの名前を同期させるには、Unrealで手動で名前を変更しなければなりません。さらにWwise SoundBankはUnrealのネイティブアセットではないため、常に特別な扱いが必要でした。
Unrealインテグレーションの変更内容
このような問題を解決するために導入されたのが、WwiseプロジェクトにあるEventをベースにしたUnrealアセットの自動作成です。Fan Runpeng（范润鹏）が「 EBP（イベントベースパッケージング）の概要 」で説明したように、Wwiseプロジェクトの各Eventが自動的にUnrealアセットにパッケージされます。Unrealの既存のAudiokinetic Bankアセットタイプは、引き続きEventをグループ化するために使用できますが、デフォルトの動作では、1つのSoundBankに対し1つのEventをUnrealアセットに格納します。 EventのMediaは別扱いとなるため、EventのEvent部分とStructure部分のみがSoundBankに格納されます。 SoundBankをUnrealアセットに格納することで、Event名がWwiseとUnrealの間で自動的に更新されます。
何が間違っていたか
EBPによるアセット管理ワークフローには、主に以下の3つの要素があります:
- 単一イベントSoundBankの自動作成
- UnrealプロジェクトとWwiseプロジェクトのアセット同期
- アセットライフタイム処理の自動化（ロード、アンロード、ランタイム時のアセット準備）
いずれも単純な実装ではなく、それぞれが重要な機能と言えます。これらの変更はUnrealプロジェクトのアセット作成パイプラインに影響を与えるため、機能実装にリスクが伴います。
単一イベントSoundBankの作成自体は問題ありませんでしたが、それをUnrealアセットに格納するためディスク保存に要する時間が長くなりました。この点は私たちの初期テスト段階で見落としていましたが、リリース直後に大型プロジェクトに関わる複数のチームから連絡があり、パイプラインの動きが鈍くなっている原因がここにあると気づきました。問題というよりも使い勝手の悪さですが、理想的な状態ではないので今後改善する予定です。
一方、不具合を感じたチームから報告された多くの問題を引き起こしていたのは、ワークフローのAsset Synchronization（アセット同期）の部分でした。Asset Synchronizationコードのバグが原因で壊れたビルドや、我々が把握していなかったバージョン管理問題なども発生しました。さらにSoundBankやメディアをUnrealアセット内に格納したことでWwise SoundBankのプロファイリングも使えなくなりました。（SoundBankはエンジンのメモリにロードされるため、Wwiseのプロファイラからは見えません。）また、EBPのコアにある効率的ではあるが安全ではないSetMedia/UnsetMedia関数の使用は、多くのランタイムのクラッシュに繋がっていました。
UnrealエディタではWwise Consoleツールを使ってコマンドラインからSoundBank生成を実行します。Wwiseがこれらのファイルをディスクに生成し、それをUnrealアセットに読み込んで保存するために、従来よりも多くのディスクI/Oが発生します。この操作のパフォーマンスを向上させるために、Wwise Authoringツール接続時にWAAPI経由でサウンドデータを生成することができます。ただしその場合は2種類のサウンドデータ生成方法を維持しなければなりません。これは不可能ではありませんが、システムが複雑になり利用するのもサポートするのも容易ではありませんでした。
問題解決に向けた計画
EBPの導入後に報告されたバグや問題は随時修正してきました。最も重要な修正はSetMedia/UnsetMediaの各SDK関数の強化で、メモリ解放が安全でない場合に警告を出すようにしました。またWwise Eventパッケージ.uasset内のメディアへのソフトリファレンスをハードリファレンスへ切り替えて、インテグレーションの安定性を高めました。これ以外にも現在のアーキテクチャでは解消できない問題を起こす利用シーンが残っているため、Wwise 2022.1に向けて機能のリファクタリングを開始しました。
Wwiseの改善
サウンドデータを生成する方法が2つあることを避けるため、Wwise Authoringツールでサウンドデータを生成できるよう、WwiseのSoundBank Managerに「single-event banks」オプションを追加しています。新オプションAuto SoundBank Generationは、Project SettingsのSoundBanksタブで提供する予定です。デフォルトでは無効になっており、現在SoundBankに入っていないEventのSoundBankを自動的に生成します。
またSoundBankメタデータファイルの内容を改善し、ランタイムエンジンがデザイナーの意図通りにサウンドを再生するために必要な情報をすべて含むようにしました。これによりメタデータを「Single Source Of Truth」（SSOTと呼んでいます）として利用できるため、Unreal インテグレーションからアセット同期コードをすべて省けるようになります。
Unrealインテグレーションの簡略化
Wwiseプロジェクト内にあるものをすべてUnreal Contentフォルダに自動的に入れるのではなく、Unrealアセットを必要に応じて作成するようになります。Unrealプロジェクトで特定のイベントを使用することを選択しない限り、ディスク上にアセットが作成されることはありません。プロジェクトをパッケージ化するまでは、作成されたアセットにはそれが使用するリソースへのリファレンスのみが含まれます。パッケージ化する際にはじめて、SoundBankをUnrealのステージングフォルダ階層にコピーします。オーディオを担当しないプロジェクトメンバーがプロジェクトのオーディオを聞くために、Wwiseをインストールしなければならないという問題も解消されます。新Unrealインテグレーションでは、プロジェクトにGeneratedSoundbanksフォルダが存在するだけでWwiseオーディオを完全にサポートします。
EBPからSSOTに移行
EBP プロジェクトを新しい AutoBank/SSOT ワークフローに移行するにはある程度の時間がかかります。移行にかかる時間はUnreal プロジェクト内の Sound Data フォルダにある Unreal アセットの量に直接関係します。移行はWwiseがインストールされているシステムで行い、移行中もWwiseプロジェクトを開いておく必要があります。大型プロジェクトの場合は時間がかかると予想されますが、ありがたいことに1回行えば終わりです。
ワークフローで何が変わるのか？
私たちの一番の目標は、Wwise Unrealインテグレーションの使い勝手を改善することです。新しいワークフローに慣れるまでに時間がかかるかもしれませんが、それだけの意義がある変更内容だと考えています。最終的にはバージョン管理ツールを用いた共同作業により適した、安定性の高いWwise Unrealインテグレーションが得られるでしょう。
柔軟なGeneratedSoundBanksの保存場所
SoundBankの生成時にWwiseが新しいメタデータファイル（ProjectInfo.json）を作成し、このファイルには各プラットフォームのSoundBankが生成されるパスが含まれます。これにより各プラットフォームのワークフローに合わせて、SoundBankを生成する場所を柔軟に選択することができます。EBPを使う多くのチームが苦労しているバージョン管理の問題も、これで対応できると思われます。
Wwiseアセット名の変更
新しいワークフローでは、WwiseのEvent名がそれに対応するUnrealアセットと一対一で合致する必要がなくなります。そうするとWwise Event名をUnrealで編集できなくなると思うかもしれません。しかしそういうことはなくWAAPI Pickerで項目名を編集できるため、Unrealを使いながらWwiseプロジェクトの要素の名前を変更できます。
Unrealアセットはシリアライズしたデータというよりも、SoundBankのコンテンツへのショートカットのようなものです。インテグレーションコードがWwiseでサウンドを再生するために、メモリにロードすべきものを見つけるためのIDが含まれているだけです。
External Sourcesの最小限のサポート
EBPの導入までUnrealインテグレーションで扱えなかったもうひとつのWwiseの機能は、External Sources（外部ソース）機能です。多くのスタジオがこのWwise機能のUnrealへのインテグレーションを独自に開発してきたため、独自ソリューションからインテグレーションコードが提供するものに切り替えませんでした。反対に、独自ソリューションと干渉するためインテグレーションコードのExternal Sourcesサポートを削除しなくてはならないスタジオもありました。
UnrealインテグレーションのExternal Sources機能は、完全に任意の選択肢にしています。
まとめ
EBPワークフローを採用したWwise Unreal開発者にとって、この2年間はさまざまな道のりとなりました。多くのチームではとても喜ばれ、手作業のSoundBank管理ワークフローにはもう戻れないとのコメントをいただきました。またどうしても制約事項が今のワークフローに与える影響が大きすぎて使えないと教えてくれたチームもいくつかあります。好評も不評もフィードバックとしてすべて受け止め、この1年間インテグレーションコードのリファクタリングに取り組んできました。
Wwise AuthoringにEBP機能を取り込んでインテグレーションコードにSSOT戦略を採用することこそ、正しい方向性だと私たちは考えています。Unrealアセットを使わなくなることでオーディオチームはパイプラインを明確化できます。独自エンジンを使うチームではAutoBankやSSOTのワークフローを実装できるようになります。さらに私たちが今後のリリースでUnityインテグレーションをさらに良くするための道筋もはっきりとしてきます。
Wwise Unrealインテグレーションの新しいワークフローを試してみたい方は、2022年リリース予定のWwise 2022.1ベータ版をご期待ください。
コメント