Version Control of Wwise Project Files

Wwise에 대한 팁과 도구

Most game developers use a version control system to store their project files and facilitate the collaborative nature of their work. This article aims to answer the following question: What files in a Wwise project folder should be stored in version control?

The Good

In order to answer that question, we will start by explaining which files are essential for the creation of the final audio assets of a Wwise project. Maximilien Simard Poirier, a sound designer working at Audiokinetic,  made a video tutorial that covers this topic; it can be found here.

The Wwise Project and Work Unit Files

All the essential files can be identified by taking a look at the File Manager (Shift+F1). Here is what we see when we open this dialog with the Cube Wwise project loaded:

Picture1 

This tells us that the Cube.wproj and all the folders seen here are critical to the project. If we expand the Actor-Mixer Hierarchy folder, we see the following:

Picture2 

This indicates that the Actor-Mixer Hierarchy folder must exist and contain at least the “Default Work Unit.wwu” file. If the Actor-Mixer Hierarchy folder is deleted from the project’s folder, Wwise will recreate it along with the (empty) Default Work Unit.wwu and warn the user when the project is loaded. Although they are not critical for Wwise to be able to open the project, the other Work Unit files are also required for the project to work as designed. Consequently, all the files shown in the Work Unit tab of the File Manager should be added to the version control system.

Content of a Wwise Project Folder

If we take a look at the content of the project folder, we see it contains the previously mentioned items and a few others:

Picture3 

The .validationcache and .wsettings files are user-specific and should not be added to version control. The IncrementalSoundBankData.xml file is used to know what SoundBank content has changed and needs to be updated when we generate the SoundBanks of the project. It does not belong in version control as it reflects the state of the SoundBanks based on the local content of the Wwise project and local SoundBank generation history. The .cache folder is rarely added to version control; we will discuss the .cache folder and its content later in this article.

Wwise Sources (a.k.a. Originals)

If we click on the “Source Files” tab of the File Manager, we have the following:

Picture4 

This shows the folder structure found under the Originals folder and all WAV and MID files used by the Cube project. All these files are required to recreate the final audio assets of a Wwise project, which are SoundBanks, and streaming and loose files. All of these source media files should be added to the version control system.

Content of the Originals Folder

If we navigate to the Originals folder with the Windows File Explorer, we see the following content:

Picture5

Every WAV file has a corresponding AKD file that contains metadata about the audio content of the WAV files. The AKD files contain data for Loudness Normalization and/or HDR envelope tracking if these features are selected in the Wwise project. They also contain peak analysis data that Wwise performs when audio files are imported into a project. The AKD files do not need to be added to version control as they will be created by Wwise as needed.

The Bad

Now that we know which files are essential for the creation of the final audio assets of a Wwise project, we ask ourselves if we should also add SoundBanks and streaming and loose files to version control; the answer is maybe. If you have members of your team who do not use Wwise but need to be able to hear the sounds while playing the game in development, then they will need these files, and version control could be the most convenient way to provide them with access. If that option is selected by your team, the “bad” thing that could happen is SoundBanks becoming de-synchronized. For example, if updated SoundBanks are added to the version control system but the new Init.bnk is not, the sound engine will report errors when it tries to load the new SoundBanks. Another example where this could happen is a mismatch between streamed files and their prefetch which is included in the SoundBank; if both are not from the same generation, it could lead to audio glitches or crashes. A good solution for these potential issues is to designate a system and/or a team member to build all the audio assets and commit them to version control, periodically. Using this “SoundBank Build Machine” practice can save you from problems caused by mismatching audio assets.

Files in the SoundBank Path Folder

SoundBank files are always generated because they contain the converted media, they also contain the structures and Events relating to the sounds. Streaming files are only present when one or more of the sounds in the Wwise project have the “Stream” option selected in their General Settings. Loose files (or loose media) are present when you choose to use the Prepare Event method to manage your media.

The Cube project contains a single streamed file and does not use Prepare Event. Consider the options selected under the SoundBanks tab of the Project Settings (Shift+K):

 

Picture6

The resulting content of the generated SoundBanks folder will be:

Picture7 

The English(US) folder is empty because this Wwise project does not contain any localized Sound Voice objects. Wwise needs to access the four BNK files and the 797700993.wem streaming file at runtime to play the sounds included in the project. The PluginInfo.xml file lists all the plug-ins that are required by the content of the SoundBanks being generated. The SoundbanksInfo.xml file is used when the SoundBanks are generated; namely, they indicate what streamed files should be copied from the cache by the CopyStreamedFiles.exe tool. These two XML files normally should not be added to version control as they are only used by Wwise when generating SoundBanks, and Wwise will re-generate them if they are not present when needed.

The NameOfSoundBank.txt files are present because the “Generate Bank Content TXT Files” option is checked. These are not required to play the sounds but could be used to integrate Wwise in your toolchain. Check with your audio programmer if they use their content to support features in your game engine. If they do, then they will want the “Generate Bank Content TXT Files” to be added to version control.

In short, if you decide to add your runtime audio assets to your version control system, you should add all BNK and WEM files found under the SoundBank path. You may want to add TXT, XML, and/or JSON files depending on how Wwise is integrated with your game engine.

The Ugly

Now that essential and optional files have been covered, let’s take a look at the files that should not go to the version control system.

Contents of the .cache Folder

We have talked about most of the content of a Wwise project so far. One missing piece is the .cache folder. As stated in the documentation: “The project's cache folder contains intermediate data generated by Wwise during audio file conversion and SoundBank generation.” As a general rule, this folder should not be added to the version control system. The contents of the Cube project’s .cache folder are mostly WEM files:

Picture8 

These files have the same name as their source WAV files with an added hexadecimal number before the WEM file extension. When the content of the Originals folder is encoded, the WAV files are converted using the audio codec specified in the Conversion Settings for every item in the project. If an Effect has the Render option selected, the Effect is rendered in the WEM. If the audio source has been trimmed in Wwise’s Source Editor, only the active part of the source is included in the encoded file to save memory. Modifications applied to any of these will be reflected in a change of the hexadecimal number before the WEM file extension.

There are also SBStat folders in the .cache that contain {GUID}.stat files, as shown below. These temporary file are used by the Wwise SoundBank Manager view to show the Data Size and the Decoded Size of SoundBanks. The Data Size is the in-game memory size for the selected platform and the Decoded Size is the in-game memory of the decoded Vorbis media.

 

Picture9

Although it is not meant to be shared, as its content can always be recreated when the Wwise project and originals are available, some teams choose to add the contents of the .cache to version control. The main motivation for this is that when the Wwise project contains a great number of audio assets, the conversion process to recreate the .cache can be time-consuming. The problem with this approach is that any change to a property, Conversion Setting, or Audio Source leads to a change to the filename saved to the .cache folder, and this can lead to many unneeded files being added to the version control repository.

The .backup Folder

Another folder that can be found under the root of your Wwise project is the .backup folder. This folder is automatically created by Wwise when you open your project with a newer major version of Wwise, and the project is upgraded. In case you want to revert a Wwise upgrade of your project, you can use the content of the .backup folder. There is no reason to add the content of this folder to version control since you can simply retrieve a version of your Wwise project prior to the upgrade to get the same files.

Conclusion

It is good practice to add the project, Work Unit, and original WAV files to version control. Adding your SoundBanks and streamed and loose files requires that you pay attention to keeping them synchronized; failing to do that is bad. Adding the content of the .cache folder should be avoided as it could get ugly. I hope this article helped you understand which files of your Wwise project folder should be added to your version control system!

Guillaume Renaud

Lead, Field Application

Audiokinetic

Guillaume Renaud

Lead, Field Application

Audiokinetic

Guillaume has been part of the customer support team at Audiokinetic since early 2014. He is well versed in Wwise and loves to share this knowledge with the community, convinced that technology can only reach its potential when it is understood by its user. When he is not exploring fictional worlds in games or books, he likes to explore the real world wearing running shoes or riding his snowboard.

댓글

댓글 달기

이메일 주소는 공개되지 않습니다.

다른 글

Wwise에서 Audio Object를 저작하고 프로파일링하는 간단한 9 단계

Wwise에서 새롭게 제공되는 오브젝트 기반 오디오 파이프라인을 둘러보고 싶지만 어디서부터 시작해야 할지 모르시는 분들 계시나요? 그렇다면 Windows용 Wwise에서 Audio...

21.7.2021 - 작성자: 데미안 캐스트바우어 (Damian Kastbauer)

새로워진 Wwise Audio Lab(WAL)을 소개합니다

Wwise Audio Lab(와이즈 오디오 랩, WAL)은 Unreal Engine 4를 통해 오픈 소스로 개발된 게임 형식의 3D 환경이며 Wwise 런처를 통해 제공됩니다....

19.1.2022 - 작성자: 데미안 캐스트바우어 (Damian Kastbauer)

ReaWwise 개발 | 제 1부 - 사전 제작

이제 ReaWwise가 출시되었으니 이 REAPER 확장을 제작한 과정에 대해 공유할 좋은 기회가 왔다고 생각했습니다. 두 부분으로 구성된 이 블로그 시리즈의 첫 번째 부분에서는...

6.10.2022 - 작성자: 베르나르 로드리그 (Bernard Rodrigue)

Wwise Unreal 통합 현황

이 글은 작년에 게시한 'Wwise Unreal 통합 개선하기(Improving the Wwise Unreal Integration)'에 대한 후속 글입니다. 저번 블로그에서는...

13.10.2023 - 작성자: 기욤 르노 (Guillaume Renaud)

Wwise Spatial Audio 2023.1의 새로운 기능 | 위상 완화 (Phasing Mitigation)

오늘 이 글에서는 '위상(phasing)'이라는 흥미로운 음향적인 현상에 대해 알아보겠습니다. 이 현상은 특정 환경에서 음향을 모델링할 때 나타날 수 있죠. Wwise 23.1의...

25.1.2024 - 작성자: Allen Lee

ReaWwise를 사용한 ReaScript(Lua)에서의 WAAPI

ReaWwise에서 잘 알려지지 않은 기능 중 하나는 원시적 WAAPI 함수를 REAPER에 노출하여 사용자 정의 ReaScript에서 사용할 수 있다는 것입니다. 이 블로그...

20.11.2024 - 작성자: 앤드류 코스타 (Andrew Costa)

다른 글

Wwise에서 Audio Object를 저작하고 프로파일링하는 간단한 9 단계

Wwise에서 새롭게 제공되는 오브젝트 기반 오디오 파이프라인을 둘러보고 싶지만 어디서부터 시작해야 할지 모르시는 분들 계시나요? 그렇다면 Windows용 Wwise에서 Audio...

새로워진 Wwise Audio Lab(WAL)을 소개합니다

Wwise Audio Lab(와이즈 오디오 랩, WAL)은 Unreal Engine 4를 통해 오픈 소스로 개발된 게임 형식의 3D 환경이며 Wwise 런처를 통해 제공됩니다....

ReaWwise 개발 | 제 1부 - 사전 제작

이제 ReaWwise가 출시되었으니 이 REAPER 확장을 제작한 과정에 대해 공유할 좋은 기회가 왔다고 생각했습니다. 두 부분으로 구성된 이 블로그 시리즈의 첫 번째 부분에서는...