이 글은 작년에 게시한 'Wwise Unreal 통합 개선하기(Improving the Wwise Unreal Integration)'에 대한 후속 글입니다. 저번 블로그에서는 이전 버전의 Wwise Unreal 통합에 있던 실수에 대해 사과하고 추후 계획을 소개했습니다. 이번 글에서는 지난 해를 되돌아보고 현재 Wwise Unreal 통합의 상태에 대해 이야기해보려고 합니다.

지난 해를 되돌아보며

Wwise 2022.1 Unreal 통합 출시에서는 단일 진실 공급원(Single Source Of Truth, SSoT)이라는 새로운 모델을 소개했습니다. 간단히 설명하자면 이 통합은 Wwise 프로젝트를 '알기' 위해 오직 Generated SoundBank 폴더 안에 있는 내용만 단일 진실 공급원으로서 의존합니다. 또한 이 새로운 모델은 Wwise 프로젝트에 있는 각 Event와 버스에 대한 Unreal 에셋 자동 생성을 제거해서 이제 Unreal 프로젝트에서 사용되는 Wwise 오브젝트만 Unreal 에셋을 가지게 되었죠. Wwise Unreal 플러그인의 AkAudioEvent 에셋은 쿠킹, 빌딩, 패키징의 초석입니다. 또한 Blueprint와 C++ 코드에서 새운드 재생을 제어하는 데 사용되는 에셋이기도 하죠.

베타 피드백

Wwise 2022.1.0 베타가 출시되자마자 커뮤니티로부터 피드백을 받기 시작했습니다. Audiokinetic 기술지원팀의 일원으로서 저는 지원 티켓을 통해 들어오는 대부분의 건설적인 비판에 대해 잘 알고 있죠. 

모두가 SSoT로의 변경이 좋은 방향이라는 점에는 동의하지만 Unreal 에셋을 관리하는 일부 도구가 없다는 사실을 빠르게 알게 되었습니다. 현재 Wwise Unreal 통합 사용자들은 이전 통합의 일부였던 에셋 자동 동기화가 없어진 것을 아쉬워했습니다. Wwise에서 Event의 이름을 변경하더라도 Unreal이 에셋의 이름을 자동으로 변경하지 않기로 한 결정에 의문을 제기했죠. 새로운 Unreal 에셋은 Wwise에서 Event의 이름이 바뀌더라도 어떤 사운드를 재생할지 계속 추적하지만 에셋의 이름이 Event의 이름을 따르지 않는다는 사실이 혼동을 줄 수 있습니다.

늦춰진 출시

베타 기간 동안 수많은 피드백을 받았고, 대부분의 피드백은 어느 정도 변경을 필요로 했습니다. 그렇기 때문에 피드백을 받아들이면서 공식 버전을 출시할 수 없다는 것을 알았고 처음부터 더욱 완전하고 안정적인 솔루션을 제공하기 위해 Wwise 2022.1.0의 출시를 미루게 되었죠.

Wwise 브라우저 및 재조정(Reconciliation)

출시 후에 받은 피드백을 통해 Audiokinetic은 통합된 Wwise Browser를 소개하는 것을 우선시하기로 계획했습니다. 혹시 2022.1.5 출시를 놓친 분들을 위해 설명드리자면, 저희는 이 버전을 통해 Wwise와 WAAPI Picker를 Wwise Browser에 병합하도록 변경했습니다. Wwise Picker가 SoundBank 메타데이터 안에 있는 것을 표시하고 WAAPI Picker가 연결된 Wwise 프로젝트에 있는 내용을 표시하는 대신 Wwise Browser가 두 가지를 모두 표시하며 Wwise 오브젝트의 상태 및 해당 Unreal 에셋의 상태 표시도 제공하게 됩니다.

2022.1.6 버전에서는 Reconcile 버튼이 추가되었습니다. 작은 UI 업데이트지만 Wwise 오브젝트와 Unreal 에셋을 동기화하는 데 엄청난 영향을 미치죠. 일부 혹은 모든 Wwise 오브젝트를 단 몇 번의 마우스 클릭만으로 동기화할 수 있게 해주는 기능입니다. 또한 예를 들어 SoundBank를 생성한 후 WwiseReconcileCommandlet를 호출하여 재조정을 오토메이션할 수도 있습니다.

여러 사운드 엔진 버전 지원

통합에 소개된 또 다른 변경 사항은 바로 프로젝트가 일부 상황에서 Wwise를 표시하지 않도록 허용하는 것이었습니다. 그렇게 하기로 한 초기 동기는 오디오가 불필요한 게임 서버 버전을 빌드하는 팀을 위한 솔루션을 제공하기 위함이었습니다. 이것을 저희는 'Null Sound Engine'이라고 부르며, 일부 프로젝트 구성을 Wwise 없이 빌드할 수 있게 해주죠. 이 변경 사항 전에는 SoundEngine이 불필요하게 자주 로딩되었고 사용되지 않았죠.

특정 버전의 통합 코드에 두 개 이상의 SoundEngine을 지원하는 기능을 통해 저희는 Wwise의 메이저 버전용 모듈을 추가하기 시작했습니다. 이것이 바로 Wwise 2022.1.x와 2023.1 베타가 현재 통합 코드와 잘 작동하는 이유죠. 통합 코드는 Wwise 바이너리의 버전을 감지하고 알맞은 SoundEngine 모듈을 사용해서 Wwise와 상호작용합니다. 특정 플랫폼용 Wwise 바이너리가 없을 경우 통합은 Null SoundEngine을 사용하게 됩니다.

SSoT에서의 에셋 관리

과거 Unreal 통합에 의해 진행되었던 Event-Based Packaging(이벤트 기반 패키징)에서 벗어나 Wwise가 SoundBank를 자동으로 생성할 수 있는 기능을 부여했습니다. 이를 Auto-defined SoundBank라고 하며, Wwise에서 수동으로 생성한 SoundBank는 이제 User-defined SoundBank라고 하죠. 이 사운드 뱅크는 Unreal SSOT 프로젝트에서 여전히 사용할 수 있지만 Unreal 통합에서의 Wwise 에셋 관리를 이해해야 합니다.

Legacy 및 Unreal IO Hook

Input과 Output (IO) Hook는 파일을 읽고 디스크에 작성합니다. Wwise의 IO Hook는 'default Streaming Manager(기본 스트리밍 메니저)'라고 하는데, 이는 Wwise가 이 후크를 기본적으로 사용하며 Wwise 사용자가 다른 도구를 사용해서 IO를 관리할 수 있기 때문이죠. 이에 대한 좋은 예시로 자체적인 게임 엔진을 사용하고 게임 엔진의 IO 후크를 사용해서 Wwise SoundBank와 스트리밍 파일을 로드하는 팀을 들 수 있습니다. 

2019.2.1에서 EBP 작업 과정을 소개하면서 저희는 프로젝트가 EBP를 사용하도록 선택할 경우 Unreal IO 후크를 사용하기 시작했습니다. Legacy IO Hook는 레거시 작업 과정을 계속 사용하기로 한 팀을 위해 계속 제공했습니다.

2022.1.0에서 SSoT 작업 과정이 도입되면서 이제 모든 IO가 Unreal의 IO를 사용하여 수행되어서 Legacy IO Hook의 사용이 쓸모 없게 되었습니다. Unreal 사용자가 엔진의 IO 후크를 오버라이드하지 않을 것으로 예상하며 Wwise 'default Streaming Manager'가 선택 사항이기 때문에 Unreal의 후크로 대체했습니다.

Wwise 메모리와 Unreal 메모리

Wwise 초기화 시퀀스의 일부로 Memory Manager 모듈이 초기화되어 Sound Engine이 필요한 메모리를 런타임 때 관리합니다. Wwise Unreal 통합의 경우 항상 그랬지만 메모리에 로드된 내용은 사용하는 모델(Legacy, EBP 혹은 SSoT)에 따라 다릅니다. 2019.2 통합 이전(Legacy라고 통칭)에는 바로 여기에서 SoundBank와 스트리밍용 미디어 파일이 로드되고 게임에 의해 재생되었습니다. 해당하는 Event와 SoundBank Unreal 에셋은 Unreal Engine에섯 할당한 메모리에 로드되었죠. 

2019.2.1 버전에서 EBP 작업 과정을 도입한 후 저희는 Unreal이 할당하는 메모리를 사용하여 에셋 안에 캡슐화된 미디어를 저장하기 시작했습니다. 여기서 배운 뼈아픈 교훈 중 하나는 Unreal 에셋이 프로젝트 쿠킹과 패키징 면에서는 훌륭하지만 미디어용 컨테이너에 대해서는 그렇지 않다는 점이었습니다. EBP 안에 있는 SoundBank는 미디어를 담지 않았고 Wwise에서 저작한 Event와 Structure만 담았죠. 이들은 Wwise가 관리하는 메모리에 로드되었습니다.

Wwise 2022.1.0에 SSㅐT를 도입하면서 Wwise 미디어는 더 이상 Unreal 에셋 안에 저장되지 않습니다. Event 에셋은 이제 Wwise Event에 대한 정보(디스크상 위치와 Wwise가 이벤트를 찾을 수 있도록 해주는 다른 ID)만 담습니다. EBP의 경우 SSOT용 SoundBank가 미디어를 담지 않으며 Wwise가 관리하는 메모리에 로드됩니다. Event가 로드되어야 할 때 미디어가 없는 SoundBank는 Wwise 메모리에 로드되며 미디어 파일은 Unreal 메모리에 로드됩니다. 그런 다음 로드되는 메모리의 위치는 LoadBankMemoryView나 LoadBankMemoryCopy SDK 함수를 통해 Wwise로 전달되죠. Auto-defined SoundBank가 LoadBankMemoryView에 의해 로드됨이 따라 이를 사용하여 메모리 중복을 방지하는 것이 가장 메모리에 효율적입니다. 

이 메모리 할당 체계는 가장 효율적이지만 단점이 있습니다. 바로 Wwise Profiler는 Wwise가 할당한 메모리만 모니터링할 수 있다는 점이죠. 다시 말해 Wwise Profiler가 미디어가 없는 SoundBank가 사용하는 메모리는 보고하지만 미디어를 저장하기 위해 사용되는 Unreal 메모리는 보고하지 않게 됩니다. 바로 이 때문에 Unreal에서 Wwise/WwiseMemory 통계 카테고리 안에 Wwise 미디어 카운터를 모아서 Unreal 통계 커멘드를 사용하여 미디어 할당을 추적할 수 있게 합니다.

다가오는 업데이트

현재 작업 중인 개선 사항 중 하나는 Unreal 프로젝트 안에서의 Wwise 데이터 패키징 옵션을 업데이트하는 것입니다. 현재 Unreal에서 UAsset이 아닌 에셋을 패키징하는 것이 어렵기 때문에 이 부분을 개선해야 한다는 것을 알고 있습니다. 특히 Zen Loader와 Store, DLC, 현지화, 새로운 Virtual Asset, 기능 업데이트를 더욱 잘 지원하기 위해서요.

곧 출시될 또 다른 사항은 저희 Unreal Gym을 GitHub에 출시하는 것입니다. 저희는 SSoT 작업 과정을 개발하는 도중 Gym 프레임워크를 제작해서 테스팅을 최대한 오토메이션했습니다. 또한 지원팀에 보고되는 문제를 재현하는 데에 이 프레임워크를 사용하기 시작했죠. 조사 과정에서 새로운 짐(gym)을 개발하게 되면 컬렉션에 추가되어 향후 테스팅이 더욱 강화됩니다.