프로젝트 개발 과정 동안 성능 문제가 일어나는 것은 꽤나 흔한 일입니다. 문제의 원인은 다양하지만 대부분의 경우 동시 재생되는 사운드의 수와 직접 관련된 경우가 많죠. 볼륨만 계산하는 가상 보이스와 달리 물리적 보이스는 모든 것을 처리합니다 (스트리밍, 디코딩, 필터 등).  각 보이스가 실제로 들리며 소리풍경에 기여할 수 있도록 확인하는 것이 좋습니다. Wwise는 사운드가 의미하는 바를 알지 못하기 때문에 이것을 혼자 결정하지 못하죠. 다행히 사운드 디자인 과정의 이 방면을 여러분이 관리할 수 있는 다양한 도구가 제공되어 있습니다.

물리적 보이스의 목표 개수를 몇 개로 해야 할까요?

물론 이 질문은 한 가지 답이 없는 굉장히 열린 질문입니다. 게임이 지원할 플랫폼의 최소 사양에 따라 달라지며 팀이 사운드에 할당하는 CPU 예산에 따라서도 당연히 달라지죠. 이 점을 감안하고, 다음은 여러분이 참고할 수 있는 대략적인 수치입니다:

• PS4, Xbox One, PC, Mac: 전체 80 채널 미만
• Nintendo WiiU와 Switch, 고성능 Android와 iOS: 전체 60 채널 미만
• 저성능 Android, iOS, PC (XP 세대): 전체 40 채널 미만

이 수치는 Wwise의 제한값이 아닙니다. 일부 게임은 이를 초과하기도 해요. 제가 여기서 '사운드'가 아닌 '채널'을 제공한 이유는 보통 CPU 사용량이 채널 개수에 따라 달라지기 때문입니다 (예: 스테레오가 모노보다 CPU를 두 배로 차지함). 하지만이 수치를 참고해서 작업하면서 게임 기획이 허용할 경우에만 초과하는 것이 좋습니다. 이 수치는 코덱의 타입뿐만 아니라 게임이 처리하는 다른 것들에 따라 굉장히 달라집니다. 대부분의 게임은 이 수치보다 평균이 더 낮습니다. 다성음의 여러 사운드가 겹치면서 불협적이게 되어 결국 전반적인 사운드의 인지적 음질이 감소하기 때문에 이 수를 작게 유지하는 것이 좋습니다. 물론 보이스 개수가 이보다 더 크게 올라가는 경우가 생길 수도 있습니다. 이 최고값이 아주 오랫동안 유지되지만 않는다면 사운드 엔진이 빠르게 회복되어 일반 수치로 돌아갑니다. 이 최고 수치의 제어는 우리가 곧 살펴볼 Playback Limit을 통해 실행되어야 합니다.

계획과 프로토타입

보이스를 올바르게 계획하면 초기 과정에서 보이스의 소비를 줄일 수 있습니다. 특정 게임 구성 요소에 몇 개의 사운드가 필요한지 평가해야 합니다. 이때 이 '구성 요소' 디자인을 사용할 게임 오브젝트의 개수로 곱하는 것을 잊지 마세요. 예를 들어 9개의 사운드를 사용하는 경주용 자동차가 한 대일 경우에는 괜찮지만 20 대가 있을 경우 사운드가 180개가 되겠죠!  

디자인 도중 실제 게임 없이 Profiler를 사용할 수 있다는 것을 잊지 마세요. 스크린 윗쪽에 있는 'Start Capture'를 누르면 됩니다.

Profiler는 사운드를 제작하면서 사운드의 작동 방식을 시험하고 초반에 예상한 보이스의 개수를 검토하는 데에 굉장히 유용합니다. 이러한 프로토타입을 시험하려면 Soundcaster를 사용해서 여러 사운드를 트리거하고, RTPC를 다양한 범위로 변경하고, 여러분이 구성한 Event를 게임이 사용할 방식으로 직접 사용해보세요. 이 검토 작업은 최종 콘솔이 아니라 PC나 Mac에서 실행되기 때문에 최종 CPU 사용량을 측정하기는 어렵습니다. 하지만 보이스와 Effect의 개수는 정확히 검토할 수 있죠. 또한 PC CPU를 낮추는 것이라면 최종 대상 플랫폼의 CPU에도 도움이 될 거예요. 물리적 보이스의 개수는 아래 스크린샷처럼 Performance Monitor 창에서 확인할 수 있습니다.

거리 기반 감쇠 사용하기

게임과 같은 상호작용적 환경에서는 사운드가 반복적으로 트리거되어 개수가 늘어나서 CPU를 과부하할 수 있습니다 (심지어 플레이어의 귀에도 좋지 않게 들릴 수 있죠). 사운드의 개수를 줄일 수 있는 한 가지 분명한 방법은 너무 멀리 있는 사운드를 재생하지 않는 것입니다. 그렇게 하기 위해서는 다음을 설정하는 것이 중요합니다.

• Volume Threshold (Project Settings): 어느 레벨에서 사운드가 '들리지 않는' 것으로 간주되는지를 결정합니다. 이 레벨은 게임을 실행하는 플랫폼뿐만 아니라 제작 중인 게임의 타입에 따라서 달라집니다. 아주 시끄러운 FPS 게임을 퍼즐 게임과 비교해보세요. 시끄러운 환경에서는 -50dB의 사운드가 없다는 것을 플레이어가 알아차리지 못합니다. 하지만 보다 조용한 게임에서는 알아차릴 수 있겠죠. 이 레벨은 여러분이 감당할 수 있는 만큼 높아야 합니다. 보통 이 값을 -96dB로 유지할 일은 거의 없습니다. 마지막에 이 값을 몇 dB 정도 올릴 경우 소중한 CPU 주기를 어느 정도 절약할 수 있죠.

• Virtual voice behavior (Advanced Settings 탭): 이 설정은 사운드가 '들리지 않을 때' 실행할 작업을 지정합니다. 이 설정은 거의 항상 Kill if finite else virtual 로 유지해야 합니다. 이렇게 하면 반복 재생되지 않는 사운드가 제거됩니다.

• 3D Positionning & Attenuation (Positionning 탭): 이 두 가지 설정은 보이스 개수 제어와 아주 밀접한 관련이 있습니다. 예상할 수 있듯이 이 설정은 에미터와 리스너가 서로 멀어지면서 볼륨을 줄입니다. 그런 다음 Volume Threshold와 Virtual Voice 설정이 실행되어 조용한 사운드를 제거하죠.

이 장치를 사용하면 게임에서 아주 많은 사운드를 추려낼 수 있습니다. 서로 다른 컴포넌트에 다른 감쇠 곡선을 설정하여 일부 컴포넌트가 다른 것들보다 더 빨리 차단되도록 할 수 있다는 것도 잊지 마세요. 그렇게 하려면 Positioning 매개 변수를 덮어 쓰면 됩니다.

감쇠 범위에 문제가 있을 경우 Game Object Profiler (F12)를 사용하여 여러 오브젝트와 감쇠 구를 확인할 수 있습니다.

저성능 플랫폼 버전

종종 성능 병목 현상은 저성능 플랫폼에서만 나타납니다. 다행히 Wwise는 대부분의 속성에서 'Platform Link/Unlink'를 제공합니다. 이 기능을 사용하면 각 플랫폼마다 서로 다른 값을 설정할 수 있어요. 또한 전체 혹은 일부 사운드 구조를 제외할 수도 있습니다. UI에서 주황색 '알약' 모양을 찾아보세요. 이 아이콘을 우클릭하면 일반 값에서 해당 값을 연결 해제하여 다른 값으로 변경할 수 있습니다. 여기서 표시된 값은 왼쪽 위의 드롭다운 메뉴에 표시된 플랫폼에서 사용됩니다.  

Platform Manager(Project 메뉴 혹은 Shift+Alt+P)를 사용하면 저성능 플랫폼의 하위 플랫폼을 생성할 수 있습니다. 이 기능을 Link/Unlink 기능과 함께 사용하면 보다 중요하지 않은 디자인을 쉽게 제외시켜 CPU 주기를 어느 정도 절약할 수 있습니다.

RTPC 기반 세부화

게임 매개 변수를 사용하면 사운드를 더욱 세부적이거나 간단하게 만들 수 있습니다. 사운드 디자인의 여러 지점에서 Switch Container나 Blend Container에 RTPC를 연결해보세요. 기본 제공되는 거리 RTPC를 사용할 수도 있지만 이 경우 Attenuation과 거의 동일한 효과를 가지게 됩니다. 하지만 Height를 사용하면 다른 층에서 일어나는 사운드를 제거할 수 있죠. 혹은  Player vs Non-Player Switch를 만들어서 주변 NPC를 제외하고 플레이어에게만 세부적인 사운드를 더하거나 제거할 수 있습니다.

플레이어와 비플레이어 사운드에 서로 다른 버전 제작하기

보이스를 보다 적게 사용할 수 있는 한 가지 쉬운 방법은 바로 플레이어 오브젝트인지의 여부에 따라 동일한 오디오 구성 요소의 간소화된 버전을 사용하는 것입니다. 예를 들어 완전히 세부적인 사운드 (엔진, 타이어 회전 소리, 바람, 서스펜션 등)가 들어간 '자동차' 버전을 플레이어 Game Object에 사용하고 간소화된 버전 (엔진과 타이어)를 주변 NPC에 사용할 수 있죠. 이 기능은 두 가지 Event를 사용하거나 한 Event에서 Switch 컨테이너를 사용하여 트리거 할 수 있습니다. 이 방법은 아주 쉽지만 모든 상황에서 알맞은 방법은 아닙니다. 구조를 복제하면 간소화된 버전이더라도 혼란이 생기고 유지 문제가 발생할 수 있어요. 하지만 간단한 상황에서는 여전히 실용적으로 사용할 수 있습니다.  

이전 섹션에서 설명한 것처럼 Blend Container를 사용하여 한 구조만 사용하고 Switch Container를 사용하여 하위 구성 요소를 켜고 끌 수도 있습니다. 이 방법은 추가 유지 작업이 필요 없어서 구조를 복사하는 것보다 더 좋습니다. 오디오 데이터의 복제에 관해서는 걱정할 필요가 없습니다. Wwise는 뱅크나 스트리밍 파일에서 한 복사본만 유지하여 데이터 복제를 알맞게 처리해줍니다.

Playback Limit 구성하기

Playback Limit은 이미 동일한 타입의 사운드가 충분히 재생되고 있을 경우 처음부터 사운드 트리거를 방지하는 데에 유용합니다. 예를 들어 수많은 NPC가 걸어 다니는 도시 환경의 경우 발자국 소리가 너무 많아질 수 있습니다. 물론 감쇠를 사용하면 멀리 있는 사운드를 자동으로 추려낼 수 있죠. 하지만 여전히 가청 범위 안에 발자국 소리가 너무 많아질 수 있습니다. 주변에 많은 사람들이 있다는 것을 알기 위해 굳이 100개의 발자국 소리를 들어야 할 필요는 없죠. 가청 범위 안의 사운드를 추려내려면 Playback Limit과 Priority 설정이 필요합니다.

이 제한값은 액터 믹서, 버스, 혹은 전역적, 이 세 가지 수준에서 설정할 수 있어요.

전역적 수준은 최종 수단으로서, 전체 게임이 지원할 수 있는 값을 초과하지 않으며 제어되지 않은 게임 처리가 CPU를 점령하지 않도록 해줍니다. 이 전역적 수준의 제한값은 Project Settings, Max Voices Instance에서 설정됩니다. 이 값은 원하는 최대 보이스 개수보다 조금 높게 설정해야 합니다.

Actor-Mixer나 Interactive Music 계층 구조 안에 있는 오브젝트의 Advanced Settings 탭에서 특정 오브젝트에 대한 제한값을 설정할 수 있습니다. 이 제한값은 상위 구조가 아닌 특정 사운드에서 적용됩니다. 예를 들어 세 가지 변형이 있는 Random Container에서 전역적 제한값 (게임 오브젝트 단위와 반대)을 2로 설정할 경우 전체 게임에서 동시에 두 가지 변형만 동시 재생될 수 있습니다. 트리거되는 Event의 개수는 제한하지 않죠. 계층 구조에서는 여러 개의 제한값을 설정할 수 있습니다. 발자국 계층 구조의 경우 최상위 Actor-Mixer 오브젝트에 제한값을 설정하면 각 표면을 구현하는 모든 하위 컨테이너에 변경 사항을 한 번에 적용할 수 있습니다.

Bus에도 Playback Limit을 적용할 수 있습니다. 이 경우 버스 입력의 수가 제한됩니다. 이 방법은 큰 유형의 사운드에 사용할 부분을 할당하는 데에 유용합니다. 예를 들어 상위 SFX 버스, VO 버스, Music 버스에 제한값을 설정하면 적어도 한 개의 VO와 충분한 음악 스템이 항상 유지되도록 할 수 있습니다. 이론적으로 전역적 제한값에 더해지겠지만 꼭 그런 것은 아닙니다.

재생을 시작하는 사운드는 모든 제한값 (액터 믹서, 버스, 전역적)에 대해 확인 절차를 거쳐 각 수준에서 자리가 있을 경우에만 재생됩니다.

하지만 제한값만 사용할 경우 여전히 중요하고 더 근접하며 소리가 큰 사운드가 다른 사운드 대신 제거되는 상황이 생길 수 있습니다. 발자국 예시가 그러하죠. 발자국 소리의 제한값을 10개의 인스턴스로 제한할 경우 가청 발자국 소리 중 어떤 것을 제거해야 할까요? 이 문제는 Playback Priority 설정 중에서 특히 Offset priority by X at max distance 설정을 통해 해결할 수 있습니다. UI만 봐서는 짐작하기가 힘들지만 이 설정은 가청 범위의 끝 부분에서 특정 우선 순위인 P를 (P – X)로 점진적으로 감소합니다. 즉 가장 멀리 있는 사운드가 먼저 제거되죠.

 

올바른 코덱 선택하기

보이스가 CPU를 많이 차지하는 이유는 보통 복잡한 코덱을 압축 해제해야 하기 때문입니다. 사용하는 코덱과 해당 코덱의 설정은 CPU에 많은 영향을 줄 수 있습니다. 음질, CPU 사용량, 파일 크기, 스트리밍 제한 사항에 대한 균형을 맞추는 것이 최고의 코덱이라고 할 수 있죠. 게임에서 사용법에 따라 서로 다른 코덱과 설정을 선택하는 것이 좋습니다. 예를 들어 음악은 보이스오버에 비해 필요한 대역폭과 제한 사항이 다르죠.

사람들은 보통 초반에 음질을 더 선호합니다. 물론 그래야 하죠! 하지만 알맞은 수준의 인지적 음질을 선택하면 CPU 주기를 올바른 곳에 사용하도록 하는 데에 많은 도움이 됩니다. 보통 가장 '시끄러운' 사운드 (예: 폭발음, 발자국, 충돌음)을 더 압축하는 것이 좋습니다. 이러한 사운드는 우리 뇌에서 압축으로 인한 결함을 '잘못된 것'으로 판단하지 않기 때문이죠. 대부분의 코덱에서 이 방법을 사용할 수 있습니다. 당연히 대량의 사운드에 적용하기 전에 몇 가지 대표적인 사운드에서만 이 음질 설정을 시험해보는 것이 좋습니다. 이 설정은 굉장히 큰 영향을 끼칠 수 있어요. 예를 들어 Wwise의 Vorbis 파일을 최고 음질 (Q = 10)로 압축할 경우 최저 음질 (Q = 0)로 압축된 동일한 파일보다 CPU를 두 배로 사용합니다. 심지어 이 코덱은 2017년에 더 최적화되었죠.

소프트웨어 코덱 (PCM, ADPCM, Vorbis)은 하드웨어 코덱과 달리 모든 플랫폼에서 작동한다는 장점이 있습니다. 동일한 파일 크기와 동일한 음질을 유지할 수 있죠. 물론 CPU 사용량은 달라지지만요. Vorbis는 종종 하드웨어 코덱보다 느리지만 ADPCM은 더 빠를 수 있습니다. 물론 PCM은 사실상 코덱이 아니기 때문에 CPU를 최소로 사용합니다.

하드웨어 디코더 (PS4와 Xbox One)가 있는 플랫폼의 경우 이러한 코덱이 처리력을 사용하지 않는다고 간주해서는 안됩니다! 플랫폼에 따라 디코더와 CPU 간에 오디오를 전송하는 도중 메모리 버스나 CPU가 차단될 수 있습니다. 이 경우 처리량이 적어지죠. 하지만 보통 복잡한 소프트웨어 코덱에 비해 상당한 장점이 있습니다. 하드웨어 코덱의 경우 길이, 반복 재생 지점의 배치, 큐에 대한 한계가 더 많아서 특정 상황에서의 사용에 제한을 줄 수 있습니다.

iOS용 AAC 코덱의 경우 하드웨어 디코더이지만 일반적으로 선택하기 좋은 코덱입니다. 'iDevices'가 음악 플레이어로 제작되어서 한 스트림을 실시간으로 디코딩하는 데에 충분히 최적화된 단일 디코더가 제공되죠. Wwise는 이 디코더를 사용하지만, 다른 모든 사운드는 소프트웨어에서 디코딩되며 다른 코덱 옵션보다 느립니다. 그렇기 때문에 이 시스템의 장점을 최대한 활용하려면 동시에 하나만 재생되는 사운드에 AAC 타입을 사용하세요. 예를 들어 서로 겹칠 일이 거의 없는 대사에서 이 타입을 유용하게 사용할 수 있습니다.

각 코덱의 사용량은 Profiler 레이아웃에서 모니터링할 수 있습니다. Advanced Profiler 창에서 Plug-ins 탭은 모든 플러그인의 CPU 사용량을 자세하게 보여줍니다. Wwise에서는 코덱이 플러그인으로 간주되기 때문에 이 목록에 코덱의 CPU 사용량도 함께 보고됩니다.

결론

보이스 개수의 제어는 CPU 부하량을 줄일 수 있는 주요 방법 중 하나입니다. 위에서 말씀드린 방법들은 특정 상황에서 사용하지 못할 수도 있습니다. 하지만 보통 이 방법을 구현하면 게임에 상당한 도움을 줄 수 있어요. 대부분의 게임에서는 활성화된 보이스가 CPU 사용량을 가장 많이 차지합니다. 하지만 성능에 영향을 주는 다른 수많은 요소가 있어요. 그 부분에 대해서는 나중에 다른 글에서 다루어보도록 하겠습니다.