作为在 Unreal 中管理 Wwise 素材的便捷解决方案，Wwise 2019.2.1 中引入的 Event-Based Packaging (EBP) 素材管理工作流程受到了 Wwise Unreal 开发者社区的广泛欢迎。不过，有些团队在从传统 SoundBank 工作流程做出转变时遇到了一些制作上的阻碍。为此，我们一直在设法解决开发人员转到 EBP 工作流程时报告的错误。同时，也在规划和实施相应改进以确保 SoundBank 操作的稳定性。 


对于发布时功能不一致造成的延误和不便，我们要向受影响的团队真诚地说一声抱歉。在此，我们想跟各位聊聊 Game Engine Integration 团队目前的计划，同时也让大家大概了解一下对未来有何期待。我们会通过所述功能增强素材管理工作流程，还请诸位耐心等待。

为何对 Unreal Integration 实施改进？

对于 Unreal Integration，用户最想实现的一项功能是在 Unreal 工程层级结构中自动创建 Wwise 相关素材。因为，必须在 Unreal 中手动复制 Event 和 SoundBank 素材实在是很麻烦。要让 Wwise 中的 Event 名称与关联 Unreal 素材的名称保持同步，只能在 Unreal 中手动进行重命名。另外，对 Wwise SoundBank 总要特别小心，因为它们并不是原生的 Unreal 素材。

对 Unreal Integration 做了哪些改进？

为了解决上述问题，我们引入了基于 Wwise 工程中的 Event 自动创建 Unreal 素材这一功能。正如范润鹏在其《EBP 管线概述》博文中所说的那样，这样 Wwise 工程中的每个 Event 都会自动打包到 Unreal 素材中。Unreal 中的现有 Audiokinetic Bank 素材仍可用于分组存放 Event，不过默认会在 Unreal 素材中为每个 SoundBank 存储一个 Event。因为 Event 的媒体是单独处理的，所以只有 Event 及其 Structure 会存储在 SoundBank 中。通过在 Unreal 素材中存储 SoundBank，我们可以在 Wwise 和 Unreal 之间自动更新 Event 名称。 

到底哪里出了差错？

Event-Based Packaging 素材管理工作流程可分为三个主要部分：

• 自动创建包含单个 Event 的 SoundBank
• 在 Unreal 和 Wwise 工程之间同步素材
• 在素材生命周期内自动加以处理（在运行时加载、卸载、准备素材）

它们每一项都很重要，都可被视为重大功能。考虑到相关改动会影响 Unreal 工程中的素材制作管线，这些功能实现起来还是有一定风险的。

虽然自动创建包含单个 Event 的 SoundBank 并没有造成问题，但存储在 Unreal 素材中会增加将其保存到磁盘中所需的时间。在最初的测试中，我们并未发现这一点。发布不久后听处理大型工程的团队说了，我们才意识到这会拖慢他们的制作管线。这种情况并不理想，我们准备加以改进。不过，与其说它是个问题，不如说是一种不便。

受影响团队报告的大多数问题出在工作流程的 Asset Synchronization 部分。同时，Asset Synchronization 代码中的错误也导致了我们没有察觉的构建中断和版本控制问题。而且，将 SoundBank 和媒体存储在 Unreal 素材中也使得对 Wwise SoundBank 的性能分析变得形同虚设（因为 SoundBank 是在引擎的内存中加载的，所以在 Wwise 性能分析器中是看不到的）。另外，在 EBP 的核心使用高效但不安全的 SetMedia/UnsetMedia 函数时常会导致运行时崩溃。

Unreal Editor 使用 Wwise Console 工具从命令行执行 SoundBank 生成操作。让 Wwise 将这些文件生成到磁盘，然后在 Unreal 素材中读取和存储，会使用比以前更多的磁盘 I/O。要提高此操作的性能，可在连接 Wwise 设计工具时通过 WAAPI 生成 Sound Data。不过，这也意味着现在有了两种 Sound Data 生成方式要维护。虽然这样并非不可能，但是系统会比较复杂，难以管理并提供支持。

准备如何解决问题？

自引入 EBP 工作流程以来，我们一直在对错误和问题进行修复。其中最关键的修复涉及到增强 SetMedia/UnsetMedia SDK 函数以在释放内存会造成风险的情况下发出警告。为了使集成更加稳定可靠，我们还把对 Wwise Event 打包的 .uassets 中的媒体的软引用改为了硬引用。不过，当前架构中仍然存在我们无法找到解决方案的问题使用场景。为此，我们已经着手对 Wwise 2022.1 的功能进行重构。 

对 Wwise 实施改进

为了避免使用两种方式生成 Sound Data，我们将在 Wwise 的 SoundBank Manager 中添加用于“创建包含单个 Event 的 SoundBank”的选项，来专门让 Wwise 设计工具生成 Sound Data。名为 Auto SoundBank Generation 的新增选项设在 Project Settings 的 SoundBanks 选项卡下。在默认情况下，它会被禁用，并会为当前不在 SoundBank 中的 Event 自动生成 SoundBank。

为了包含运行时引擎所需的各种信息以便设计师根据需要播放声音，我们还对 SoundBank 元数据文件的内容实施了改进。这样便可抛开 Unreal Integration 中的所有素材同步代码，转而依靠元数据作为 Single Source Of Truth（我们称之为 SSOT）。 

简化 Unreal Integration

现在不必每次都将 Wwise 工程中的所有条目自动添加到 Unreal Content 文件夹，只需在必要时创建 Unreal 素材即可。除非选择使用 Unreal 工程中的特定 Event，否则不会在磁盘上创建素材。在对工程进行打包之前，这些素材只包含对其所用资源的引用。只有到打包工程的时候才会将 SoundBank 复制到 Unreal 暂存文件夹层级结构。藉此，还可解决音频以外的项目成员遇到的问题。之前，他们有时必须安装 Wwise 才能将音频整合到工程中。新的集成包只需要有 GeneratedSoundbanks 文件夹便可在工程中获得全方位的 Wwise 音频支持。

从 EBP 迁移到 SSOT

将 EBP 工程迁移到新的 AutoBank/SSOT 工作流程会花一些时间，迁移的时长与 Unreal 工程中 Sound Data 文件夹下的 Unreal 素材数量直接相关。所述迁移必须在装有 Wwise 的系统上执行，并且在迁移过程中要打开 Wwise 工程。对于大型工程来说，这估计会是一项耗时的任务，好在只需要做一次就可以了。

工作流程会有何改变？

我们给自己设定的主要目标是提升 Wwise Unreal Integration 的使用体验。适应新的工作流程可能需要一个过渡期，但我们认为做出这些改变是值得的。最终，Wwise Unreal Integration 会更加可靠，更能满足使用版本控制工具进行协作的团队。

灵活设定 GeneratedSoundBanks 位置

在生成 SoundBank 时，Wwise 会创建新的元数据文件 (ProjectInfo.json)。此文件将包含针对各个平台生成的 SoundBank 所在的路径。这样，团队便可更加灵活地选择对于各个平台要将 SoundBank 生成到哪个位置，以此来满足自身工作流程的需要。而且，应该还可解决对很多采用 EBP 工作流程的团队造成影响的版本控制问题。

修改 Wwise 素材名称

新的工作流程不需要 Wwise 中的 Event 名称与相应 Unreal 素材一一对应。那么，这是否意味着将无法在 Unreal 中编辑 Wwise Event 名称呢？当然不是。将来可以在 WAAPI Picker 中编辑媒体项的名称，以便在聚焦于 Unreal 时对 Wwise 工程的元素进行重命名。

Unreal 素材就像是 SoundBank 内容的快捷方式而非序列化数据。它们只包含 ID。这些 ID 允许集成代码查明要在内存中加载什么以便 Wwise 播放声音。

对 External Source 的最低支持

在引入 EBP 工作流程之前，Unreal Integration 没有妥善处理的另一 Wwise 功能是 External Source。由于很多开发商已经在 Unreal 中构建了自己对此 Wwise 功能的集成，所以他们并没有由自己的解决方案改为使用集成代码提供的解决方案。有些甚至不得不从集成代码中移除对 External Source 的支持，因为它会对其自身的解决方案产生干扰。

对此，我们会将 Unreal Integration 的 External Source 功能设为完全可选的功能。

以此为基础持续改进

对采用 EBP 工作流程的 Wwise Unreal 开发者来说，过去两年可以说相当精彩，也很有挑战性。很多团队跟我们说自己非常喜欢这一工作流程，再也不想回到手动管理 SoundBank 的工作流程。也有团队表示想采用该工作流程，但其局限性对自身工作流程影响太大了。在过去一年里，我们考虑了所有的反馈，无论好的还是坏的，为的就是重构集成代码。

在我们看来，将 EBP 功能引入到 Wwise 设计工具中并在集成代码中采用 SSOT 策略在方向上是正确的。在 Unreal 素材的使用上做出转变之后，音频团队的制作管线变得更加清晰了。其他使用自研引擎的团队将能够运用 AutoBank 和 SSOT 工作流程。另外，这也为在未来版本中改进 Unity Integration 开辟了一条崭新的道路。

如有兴趣尝试新的 Wwise Unreal Integration 工作流程，请留意今年春季即将发布的 Wwise 2022.1 Beta 版本。