The WwiseResourceCooker module provides the following functionalities:

• Converts WwiseObjectInfo structures to cooked structures for the WwiseResourceLoader Module.
• Copies requested objects’ files from the GeneratedSoundBanks to the Staging directory used by the packaging process.

See also

• Content Cooking in Unreal Engine Documentation

Preparing Cooked Data for Wwise Objects

Starting with a WwiseObjectInfo structure that identifies a specific Wwise object, the WwiseResourceCooker gathers all the information from the Project Database related to that Wwise object and returns a "cooked" data structure containing that information.

For a SoundBank or media file, this is a simple operation since these are the building blocks, and they each represent an individual file. External sources are also relatively simple, but since they are expected to be user-defined, their complexity is unknown. That said, the default resulting cooked data only has the cookie as non-debugging information.

Some cooked data only contains a Short ID. Much like external sources with their cookie, the Short ID is the only required information in the cooked data of Triggers, Game Parameters (RTPCs), and Acoustic Textures. Similarly, Switches and States only require the identifier of the group they are a part of and the value they represent.

Other objects, such as Auxiliary Busses and Effect ShareSets, can be a little more complicated. The most complex is the Event, which can have multiple required media, SoundBanks, external sources, Aux Busses, and many optional Switch Container elements.

Default Instantiation versus Platform Instantiations

The WwiseResourceCooker has a default instantiation used in the Editor and uncooked projects. This instantiation is used for Play in Editor mode and provides cooked data on demand when the Wwise assets are loaded in the Editor. This data is similar to the cooked data that is serialized in Wwise assets in the packaged game. The only difference is that Editor cooked data uses resource files (.bnk and .wem) directly in the GeneratedSoundBanks folder. In contrast, packaged cooked data uses resource files that were packaged with the game.

When packaging, an external cooking process is usually spawned and is only responsible for cooking a specific platform. For example, on a Mac computer, where the default instantiation would be for the Mac platform, it is possible to instantiate an Android WwiseResourceCooker to package an Android game.

Since loading the Project Database for a platform can be time-consuming, only required platforms are loaded for each cooking process. Generally, this means only one platform is loaded in the Project Database. However, there can be multiple loaded platforms if the same process is cooking multiple platforms or if cooking is being run directly within the editor process.

From Cooking Wwise Resources to Staging

Based on internally cached cooked data, all required files are copied from the GeneratedSoundBanks to the Staging directory. Media and SoundBanks represent individual files. External sources are user-defined since the cookie doesn't represent a file. Other objects represent more than one file. For example, the Init Bank, which is technically a SoundBank, can also require external media files, so cooking the Init Bank also copies its media files.

Cooking Options

The following cooking options are available for packaged games.

ExportDebugNameRule

When cooking for the default instance (in Editor), each cooked asset has a debug name that contains the complete Wwise Object Path, making it easy to identify assets while debugging.

When you build a packaged game, the ExportDebugNameRule determines whether the debug name field of each asset is populated or left empty. Leaving these fields empty reduces the file size and makes it easier to reverse engineer; however, it also makes it harder to debug since only the assets' Short IDs can be used to identify the corresponding Wwise objects in the cooked data.

LoadOnReference

You can enable the LoadOnReference option on AkAudioEvent assets. When enabled, based on the current set of loaded Switches and States, only the required SoundBanks and media are loaded. Loading and unloading Switches or States, in turn, dynamically loads and unloads the associated resources. With the option disabled, when an Event that contains Switch Containers is loaded, all SoundBanks and media used by those Switch Containers are loaded.

When this option is enabled, the cooking process prepares an Event’s cooked data to support this dynamic loading of resources. When disabled, the cooked data loads all the resources with the Event.

You can enable this option on a per-asset basis.

Note: Enabling this option adds a lot of complexity and requires a clear understanding of the feature, especially if the project sets Switches and States programmatically. In most cases, the optimization provided by the option is not sufficient to outweigh these disadvantages.

See also

• Optimizing Memory Usage with Reference-Loaded Switch Containers