소개

이 글에서는 게임 스카스 어보브(Scars Above)를 프로파일링하고 오디오를 최적화하는 데 적용한 다양한 원칙을 설명해드리려고 합니다. 사운드 디자이너분들에게 저희가 겪은 과정에 대한 통찰력을 제공하고 오디오 최적화에 대한 접근 및 계획 방법에 대한 조언을 제공함으로써 도움이 되기를 바랍니다.

전적으로 시니어급 분들을 대상으로 한 글은 아니지만 이 글을 좀 더 쉽게 이해하려면 Wwise와 Unreal Engine 및 해당 작업 과정에 대한 몇 가지 기본 지식이 필요합니다. 독자 여러분들이 Wwise Authoring Tool과 Unreal Editor로 사운드를 가져오고, 구성하고, 통합한 경험이 잇다는 가정하에 진행하겠습니다.

스카스 어보브는 Unreal Engine 버전 4.27.2와 Wwise Unreal Engine 통합 버전 2021.1.9.7847.2311을 기반으로 한 커스텀 엔진을 사용하여 컴파일되었습니다.

목차

• 최적화 원칙
• 게임의 제한 사항
  • 예산 요약
  • 메모리 혹은 CPU의 오디오 문제
    • 메모리 부족 현상 (OOM)
    • CPU 스파이크
    • 보이스 고갈 상태
    • 음원 고갈 상태
• 프로파일링
  • Wwise Profiler
    • Wwise 프로파일러 매개 변수
  • Unreal Editor에서의 프로파일링
  • QA 부서에 도움 요청하기
• 최적화
  • 애셋 자체 작업하기
    • 디스크에서 스트리밍하도록 설정하기
    • 음원 단축하기
    • Conversion settings 설정하기
    • 모노로 변환하기
    • Blend Container 서로 붙이기
    • 효과 처리 최적화하기
  • 애셋 재생 방식 최적화하기
    • 보이스
    • AkComponent
    • 애니메이션 노티파이
  • 최적화를 위한 애셋 구성
    • SoundBank
    • Level Streaming (레벨 스트리밍)
    • 사용하지 않는 애셋 제거하기
  • SpatialAudio
  • 기타 조정 사항 (모든 솔루션을 사용한 후)
    • Stop 이벤트를 Execute Action on Event/ID로 교체하기
    • 가능한 경우 액터 믹서를 폴더로 교체하기
    • Random Container 안의 변형음의 수 줄이기
• 마치는 말
• 유용한 링크

최적화 원칙

최적화는 게임 작업에서 중요한 과정이며 보통 제작 후반에 진행됩니다. 하지만 오디오 예산과 게임의 제약을 이해하는 것이 좋기 때문에 제작 초기 단계에서 최적화에 대한 계획을 세울 것을 권장합니다. 미리 정해놓은 제한 안에서 유지하면 게임이 모든 플랫폼과 구성에서 잘 작동하도록 보장할 수 있습니다. 오디오가 잘 작동하면 사운드 문제가 없죠. 예산을 초과할 경우 갑자기 사운드가 멈추거나, 오디오 결함이 들리거나, 게임 플레이에 부정적인 영향을 줄 수 있는 프레임 속도 저하 등 다양한 문제가 발생할 수 있습니다. 그렇기 때문에 오디오 계획 및 최적화를 통해 게임이 항상 최고의 성능을 내도록 노력하는 것이 중요합니다.

오디오에 관해 게임을 더 매끄럽게 만들 수 있는 몇 가지 방법이 있습니다. 어떤 사람은 오디오 애셋의 메모리 소비량 감소를 고려하는 방면 어떤 사람은 오디오 스레드의 부하량 낮추기에 집중합니다. 대부분의 방법은 메모리 및 CPU 사용량에 모두 도움이 됩니다.

스카스 어보브는 Wwise와 Unreal Engine을 사용하기 때문에 두 방면에서 실행할 수 있는 단계들이 있습니다. 다음 페이지에서 저희 게임의 오디오를 최적화하기 위해 실행한 모든 단계를 설명해드리겠습니다.

게임의 제한 사항

제작 후반부 쯤에 저희는 오디오가 게임 성능에 주는 영향을 주의 깊게 살펴보기 시작했습니다. 프로그래밍 팀과 논의한 후 모두가 동의하는 각 플랫폼에서의 오디오 예산을 정할 수 있었죠.

전반적으로 게임에서의 주요 관심사는 Gen 8 플랫폼에서의 메모리 부족 현상(OOM, out of memory)이었습니다. Gen 8의 메모리 리소스는 특히 기본 PlayStation 4 및 Xbox One에서 어느 정도 제약되어 있습니다 (Gen 8 플랫폼의 사용 가능한 RAM은 Gen 9 플랫폼에서 사용 가능한 RAM의 절반에 불과합니다). Gen 8과 보다 낮은 성능의 PC에서는 오디오 메모리 예산이 총 250MB를 넘지 않아야 한다는 것에 모두 동의했습니다.

또한 오디오는 CPU에 부담을 줄 수도 있죠. 각 프레임마다 수많은 계산이 이뤄지며 전체 게임에서 복잡한 Spatial Audio 구성을 사용하기로 결정했기 때문에, 이러한 계산은 특히 Gen 8 플랫폼에서 비용이 아주 커질 수 있습니다. Wwise Profiler를 통해 오디오 스레드 소비를 쉽게 프로파일링할 수 있었기 때문에 CPU 예산은 저희가 책정할 수 있었습니다. 오디오 스레드의 총 CPU 최대 피크 값이 100%, 평균 CPU는 Gen 8에서 50%, Gen 9와 PC에서는 30% 이하로 유지하는 것으로 결정했습니다 .

예산 요약

	총 미디어 메모리	총 CPU 피크	평균 CPU
Gen 8	250MB	100%	50%
Gen 9	250MB	80%	30%
PC	250MB	80%	30%

표 1: 모든 플랫폼에서의 오디오 메모리 및 CPU 예산 제한

메모리 혹은 CPU의 오디오 문제

게임플레이 도중 몇 가지 경로를 통해 오디오 문제가 일어날 수 있습니다. 여기에서는 가장 일반적인 네 가지 경우인 메모리 부족(OOM), CPU 스파이크, 보이스 고갈, 음원 고갈을 다루겠습니다.

메모리 부족 현상 (OOM)

메모리 부족 현상(OOM)은 시스템이 새로운 처리에 대해 더 이상 메모리를 할당할 수 없을 경우에 발생합니다. 이 현상은 플랫폼의 사용 가능한 최대 실제 메모리를 초과하거나 사운드 엔진의 최대 메모리 할당량을 초과할 경우에 발생합니다 (AkMemSettings::uMemAllocationSizeLimit 초기화 매개 변수에서 정의됨). OOM 문제는 실제 메모리가 초과될 경우 시스템 크래시를 일으킬 수 있으며, 사운드 엔진 메모리를 초과할 경우 사운드 엔진 초기화 실패, 뱅크 로딩 실패, 전환 효과 실행 실패, 사운드 재생 실패 문제를 일으킬 수 있습니다.

OOM 오류는 여러 가지 원인으로 인해 일어날 수 있습니다. 올바르게 관리할 경우 오디오는 보통 전체 메모리 사용량에서 작은 부분을 차지합니다. 그럼에도 불구하고 항상 게임 예산을 정의할 때 동의한 사운드 엔진 메모리 제한을 초과하지 않도록 해야 합니다.

CPU 스파이크

오디오 스레드는 게임 스레드와 분리되어 있으며 Wwise 오디오 엔진이 지속적으로 차지하는 오디오 처리의 대부분을 다룹니다. Wwise Profiler에서 모든 CPU 측정은 오디오 스레드의 소비와 관련되어 있습니다.

오디오 스레드가 모든 사운드를 한 프레임에서 렌더링할 수 없는 경우 Wwise Profiler에서 소비량이 100%를 초과하게 됩니다. 이러한 현상은 다양한 원인으로 인해 발생할 수 있으며, 주로 해당 프레임에서 오디오 스레드에 대한 오디오 계산 요구가 너무 지나칠 경우 일어납니다. 스카스 어보브에서 CPU 스파이크의 주요 원인은 Spatial Audio 경로 전달 계산과 대량의 오디오 이미터를 동시에 등록 및 등록 해제하는 것이었습니다.

너무 높지 않거나 너무 자주 일어나지 않는 단일한 CPU 스파이크는 문제가 들리지 않을 수 있습니다. 따라서 총 CPU Peak 제한을 100%로 안전하게 설정할 수 있습니다 (표 1). 하지만 CPU 스파이크가 너무 높거나 (수백 혹은 수천으로 측정될 경우) 연달아 많이 일어날 경우 오디오 엔진이 오디오 결함이나 사운드가 갑자기 멈추는 현상을 겪을 수 있습니다.

보이스 고갈 상태

보이스 고갈 상태는 오디오 스레드가 여러 연속 프레임에 대해 한 프레임 안에서 모든 사운드를 렌더링할 수 없을 경우 발생하며 100% Total CPU 소비가 발생합니다. 이 오류는 사운드가 갑자기 멈추며 결함이 들리는 것으로 나타납니다. 스카스 어보브 개발 도중에는 Gen 8 콘솔, 특히 PS4에서 복잡한 Spatial Audio 지오메트리가 많고 각 프레임에서 계산이 필요한 이미터가 많은 게임 영역에서 Voice Starvation 오류가 발생했습니다. Spatial Audio의 복잡성을 감소하고 동시에 로딩되는 이미터의 개수를 제한하니 Voice Starvation 오류를 해결하는 데 큰 도움이 되었습니다.

음원 고갈 상태

Source Starvation(음원 고갈 상태) 오류는 CPU보다 메모리와 관련이 있으며 디스크에서 직접 스트리밍되도록 설정된 사운드가 적절한 시간 내에 Streaming Manager에 데이터를 제공하지 못할 경우 발생합니다. 이는 다양한 원인으로 일어날 수 있으며, 종종 스트리밍 파일이 너무 많거나 디스크(I/O 장치)가 느린 속도로 인해 모든 데이터를 동시에 처리할 수 없는 경우에 발생할 수 있습니다. 이 또한 사운드가 갑자기 중단되는 현상으로 나타납니다 (특히 스트리밍되는 사운드에서). 특정 I/O 설정을 조절하는 것이 Source Starvation 오류 발생을 감소할 수 있지만 가장 효율적인 해결책은 동시에 디스크에서 스트리밍되는 사운드의 수를 제한하는 것입니다 (스트리밍 사운드에 대한 더 자세한 설명은 글의 후반부에서 다루겠습니다).

프로파일링

프로파일링은 최적화 과정에서 필수 단계입니다. 게임 최적화를 시작할 때 메모리와 CPU 소비량의 현재 상태를 평가하고 이러한 매개 변수에 영향을 줄 수 있는 잠재적인 병목 현상을 식별하는 것이 중요합니다.

모든 시험은 Unreal Editor나 개발 빌드가 아닌 테스트 혹은 출시 빌드에서 수행되어야 합니다. Unreal Editor에서 시험하는 것이 게임의 작동 방식에 대한 일반적인 이해를 제공할 수는 있지만 올바른 빌드에서 시험을 진행하면 오디오 최적화를 위해 신뢰할 수 있는 정확한 성능 데이터를 얻을 수 있습니다.

Wwise Profiler

Wwise Profiler는 오디오 성능을 평가하기 위한 주요 도구 역할을 합니다. 처음에는 아주 직관적이지 않은 것처럼 보일 수 있지만 Wwise Profiler는 현재 오디오 상태에 대한 귀중한 통찰력을 제공하며 게임플레이 도중 나타날 수 있는 성능 문제를 식별하는 데 도움이 되는 풍부한 데이터를 제공합니다.

프로파일링 도중 몇몇 CPU 및 Memory 매개 변수를 집중적으로 살펴보겠습니다. 이는 Wwise Authoring 도구의 Profiler 레이아웃에 있는 Performance Monitor 섹션에 표시됩니다.

그림 1: Wwise Profiler 레이아웃

Performance Monitor에서는 게임에서 다양한 사운드 성능 매개 변수의 실시간 상태를 시각적 및 숫자로 볼 수 있습니다.

이러한 중요한 매개 변수를 모니터링하면 언제든 게임의 사운드 성능을 명확하게 볼 수 있습니다. Profiler는 게임의 각 프레임 도중 일어나는 모든 동작에 대한 자세한 로그를 나타냅니다. 특정 프레임을 분석하기 위해 모니터를 따라 노란색 커서를 이동하면 특정 시점을 확인할 수 있습니다.

그림 2: Performance Monitor 타임라인

예를 들어 CPU 소비량이 갑자기 치솟거나 그래프에서 보이스의 개수가 갑자기 증가할 경우 커서를 특정 시점으로 옮겨서 해당 프레임에서 일어난 모든 동작과 CPU Total 소비량을 확인할 수 있습니다.

그림 3: CPU 스파이크 예시

Wwise 프로파일러 매개 변수

다음 매개 변수는 게임에서 사운드 성능의 핵심 지표 역할을 하며 일반적으로 모니터링됩니다.

• CPU - Total: 오디오 처리에 관한 전반적인 CPU 사용량을 추적합니다.
• CPU - Plug-in Total: 게임에 사용되는 오디오 플러그인에 기인하는 CPU 소비량을 측정합니다.
• Number of Voices (Physical): 동시에 재생되는 활성화된 오디오 보이스의 총 개수를 표시합니다.
• Number of Streams (Active): 활성화된 오디오 스트림의 개수를 나타냅니다.
• Spatial Audio - CPU: Spatial Audio 처리와 특정히 관련된 CPU 사용량을 추적합니다.
• Spatial Audio - Emitters Processed: Spatial Audio 계산을 위해 처리되는 오디오 이미터의 개수를 보여줍니다.
• Total Reserved Memory: 오디오 애셋을 위해 예약된 메모리의 양을 반영합니다.
• Total Media (Memory): 미디어 애셋의 총 메모리 소비량을 측정합니다.

위에서 언급한 매개 변수는 CPU 소비량을 모니터링하지만, 메모리 소비량을 추적하는 Total Media(Memory)와 Total Reserved Memory는 제외됩니다.

Unreal Editor에서의 프로파일링

안타깝게도 Wwise 오디오 데이터는 Unreal Editor에서 명확하게 표시되지 않습니다. Wwise는 메모리나 CPU 소비량에 대한 데이터를 Unreal Engine에 다시 전달하지 않기 때문에 프로파일링 기능이 제한됩니다. Unreal Insights나 Low-Level Memory Tracker와 같은 도구는 Unreal Editor 측에서 CPU나 메모리를 프로파일링하는 데 유용하지만 특별히 Wwise 애셋 및 처리와 관련된 정보는 제공하지 않습니다.

바로 사용할 수 있는 것은 Output Log를 활용하여 잘못된 사운드 구현으로 인한 오류를 식별하는 것입니다. Wwise Profiler와 관련된 로그 메시지는 Unreal Editor의 Output Log에서 교차 참조할 수 있습니다. Output Log에 표시되는 Wwise Error는 보통 'LogAkAudio' 접두사가 붙어있어 필터링을 통해 문제를 쉽게 검색할 수 있습니다. QA 팀에서 문제 보고를 받으면 추가 조사를 통해 이러한 오류가 포함된 로그 파일을 쉽게 첨부할 수 있습니다.

QA 부서에 도움 요청하기

물론 오류를 보고하는 가장 효과적인 방법은 QA 팀이 Wwise Profiler를 사용하여 게임을 테스트하고 해당하는 .prof 파일을 버그 리포트에 첨부하는 것입니다. 이 방법을 사용하려면 QA 팀이 Wwise Profiler를 실행하는 법을 알아야 가능합니다. 사운드 성능 시험을 집중적으로 하는 전담 QA 인력를 두는 것은 정말 중요하기 때문에, QA 테스트 책임의 긴 목록 중 일부로 사운드 프로파일링을 포함시키는 것이 어떤지 경영진과 상의하는 것이 좋습니다.

최적화

이번 장에서는 애셋 성능을 개선하는 다양한 최적화 기술을 살펴보겠습니다. 여기에는 서로 다른 사운드 설정을 조정하고, 게임에서 애셋이 재생되는 방식을 변경하고, 필요할 때마다 로드/언로드하여 리소스를 절약하도록 애셋을 효율적으로 구성하는 작업이 포함됩니다.

애셋 자체 작업하기

애셋의 음원, 즉 제작한 사운드를 고려할 때 최적화를 위한 다양한 기술을 적용할 수 있습니다. 상황에 따라 이러한 사운드의 여러 다른 속성을 변경하여 충실도는 유지하면서 리소스 소비량을 줄일 수 있습니다. 여기서 목표는 애셋의 품질을 손상시키지 않으면서 애셋이 보다 적은 리소스를 소비하도록 균형을 맞추는 것입니다.

디스크에서 스트리밍하도록 설정하기

파일을 디스크에서 스트리밍하도록 설정하는 것은 오디오 메모리 로드를 줄이는 효율적이고 간단한 방법입니다. 이 방법은 시간이 중요하지 않는 (즉, 이미지와 완벽히 동기화될 필요가 없는) 반복 재생 환경음, 음악, 대사와 같은 긴 파일에 적합합니다. 총성, 임팩트, 발걸음과 같은 이미지와 밀접히 연결된 짧은 단발성 사운드는 디스크에서 스트리밍하도록 설정해서는 안됩니다. 스트리밍은 메모리 대신 디스크에서 로드할 때 시간이 걸리기 때문에 사운드에 레이턴시를 일으킬 수 있습니다.

스트리밍하도록 설정하면 스트리밍되는 파일의 미디어가 SoundBank에 전혀 포함되지 않습니다. 디스크에서 직접 파일을 열고 읽는 것은 Wwise Stream Manager가 담당합니다. 플랫폼의 스트리밍 대역폭에 따라 수많은 스트리밍 사운드의 동시 재생을 활성화할 수 있기 때문에 메모리 로드를 확연히 줄일 수 있습니다.

사운드에 스트리밍을 활성화하는 방법은 아주 간단합니다. 해당 사운드 혹은 상위 계층의 General Settings 탭에 있는 'Stream' 상자를 클릭하여 스트리밍 옵션을 활성화하세요.

그림 4: SFX 오브젝트에서 Stream 옵션 활성화하기

스트리밍 사운드가 이미지와 좀 더 동기화되어야 한다면 'Zero latency' 상자를 선택할 수 있습니다. 이렇게 하면 해당 파일의 시작에 해당되는 작은 부분이 처음부터 메모리에 로드되어 나머지 부분이 스트리밍되는 동안 레이턴시 없이 재생할 준비가 되도록 할 수 있습니다. 미리 로드되는 부분의 길이는 Prefetch 길이 시간에 의해 결정됩니다.

• Source Starvation 오류

Source starvation(음원 고갈 현상) 오류는 스트리밍 대역폭이 한계에 도달하고 관리자가 디스크에서 더 이상 데이터를 읽을 수 없을 경우 발생합니다. 이로 인해 사운드가 갑자기 중단되거나 다른 문제가 발생할 수 있기 때문에 사운드를 Stream으로 설정할 경우 주의해야 합니다.

음원 단축하기

긴 오디오 파일에 대해 더 말하자면, 공간을 많이 차지하지만 사운드의 전체 길이 동안 대부분 콘텐츠가 비슷한 오디오 파일을 다시 확인할 수 있습니다. 보통 룸 톤이나 지속적인 바람 소리 반복 재생음 등, '베드'라고 알려진 기본 환경음이 이에 해당합니다. 이러한 반복 재생음을 디스크에서 스트리밍하도록 설정하지 못할 경우 사운드의 길이를 줄이면 해당 메모리 사용량을 훨씬 줄일 수 있습니다 (특히 파일 크기보다 품질을 우선시하는 변환 설정을 사용할 경우).

그림 5: 단축된 기본 환경음

환경음을 단축시키는 흥미로운 방법 중 하나는 짧은 사운드 세그먼트 여러 개를 만들어 Random Container에 넣는 것입니다. 이를 Continuous Infinite Loop 재생 모드로 트리거하면 보다 적은 메모리 소비량을으로 콘텐츠에 다양성을 줄 수 있습니다. 하지만 이 방법은 CPU 로드를 약간 증가시킬 수 있습니다. 세그먼트 간에 크로스페이딩을 하면 한 오디오 파일을 재생하는 것보다 보이스가 두 배로 생성되기 때문입니다.

그림 6: 크로스페이드 전환 효과가 설정된 반복 재생되는 Random Container

Conversion settings 설정하기

오디오 파일에 변환 설정을 적용할 때 각 플랫폼에 대해 최종 파일 형식과 변환 품질을 결정하게 됩니다. 파일 형식은 원본 .wav 파일, 채널 개수, 샘플 레이트 및 코덱의 품질 설정은 사용하는 코덱에 의해 결정됩니다.

올바른 변환 설정을 선택하면 게임의 메모리 및 CPU 로드를 더욱 최적화할 수 있습니다. 손실 없는 파일 포맷은 보통 출시 빌드에서 필요하지 않습니다. Vorbis와 같은 압축된 형식은 품질을 크게 손상시키지 않으면서 뛰어난 압축 비율을 제공할 수 있습니다. 코딩된 파일은 재생 이전에 디코딩되어야 하기 때문에 디코딩을 하는 일부 플러그인은 다른 것보다 CPU 사용량이 더 클 수 있습니다.

대부분의 사운드가 동일한 변환 설정을 사용할 것이기 때문에 ShareSet를 사용하여 Conversion Settings를 프리셋으로 구성할 수 있습니다.

스카스 어보브의 경우 모든 플랫폼에 대해 'Default Conversion Settings' ShareSet 프리셋에서 품질 설정이 4로 되어 있는 Vorbis를 사용하여 균형을 잘 맞출 수 있었습니다. WEM Opus나 ATRAC9와 같은 코덱도 Gen 8 플랫폼에서 하드웨어 디코딩을 허용하는 고려할만한 옵션이었지만 Vorbis의 성능에 만족했으며 Gen 8 하드웨어에 그런 코덱을 통합하는 데 시간을 투자하고 싶지 않았습니다 (Wwise의 Vorbis 구현은 Audiokinetic에 의해 모든 플랫폼에서 굉장히 최적화돼있습니다). 뿐만 아니라 Vorbis는 Gen 9 플랫폼에서 하드웨어 디코딩을 지원하기 때문에 훨씬 더 편리한 선택이었습니다.

'Default Conversion Settings' ShareSet 프리셋은 Project Settings의 Source Setting 탭에서 설정되어 있습니다.

그림 7: Project Settings 창의 Source Settings 탭

다음은 어떤 코덱을 사용할 것인지 보다 유익한 결정을 내릴 수 있도록 Wwise가 지원하는 사용 가능한 코덱의 다양한 측면을 비교하는 표입니다.

파일 형식	압축 비율	CPU	메모리	보통 사용되는 방식의 예시	제한 사항
PCM	1:1	아주 낮음	높음	높은 품질이 필요한 사운드	없음
ADPCM	4:1	낮음	보통	환경음 및 SFX.	64 샘플 경계에서만 반복 재생
Vorbis	3-40:1	보통 ~ 높음	보통 ~ 매우 낮음	대사, 음악, 환경음, SFX.	다른 형식보다 메타데이터 오버 헤드가 약간 더 크기 때문에 아주 작은 사운드에서는 사용하지 말아야 합니다 (수십 밀리 초 미만). 빠른 이동을 위해 빠른 이동 테이블이 필요합니다.
AAC	3-23:1	높음 (iOS에서 하드웨어 보조 디코더를 사용할 경우 낮음)	보통 ~ 낮음	배경 음악 (상호작용이 아닌)	메타데이터 오버헤드가 매우 큼. 구성 시간이 김. 샘플 단위로 정밀해야 하는 재생에 적합하지 않음.
WEM Opus	10-60:1	높음 (하드웨어 가속이 아닐 경우), 매우 낮음 (하드웨어 가속일 경우)	보통 ~ 매우 낮음	대사, 단순한 음악, 환경음, SFX.	플랫폼 기능에 따라 제한 사항이 다름.

표 2: 사용 가능한 모든 코덱 비교 (출처: Audiokinetic 문서)

• Sample Rate Automatic Detection (샘플 레이트 자동 감지)

Sample Rate Automatic Detection은 Wwise 인코더가 사운드 파일의 콘텐츠를 분석하고 특정 콘텐츠에 가장 적합한 샘플 레이트를 선택하도록 하는 옵션입니다. 예를 들어 사운드가 대부분 저주파 콘텐츠로 구성되어 있을 경우 오디오 충실도를 많이 손상시키지 않으면서 파일의 크기를 줄이기 위해 보다 낮은 샘플 레이트를 선택할 수 있습니다. 하지만 스카스 어보브의 경우 샘플 레이트 자동 감지 기능을 사용하지 않기로 했습니다. 게임에 주로 저주파로 된 사운드가 많지 않았고 모든 사운드의 샘플 레이트가 플랫폼의 기본 레이트인 48kHz과 동일하게 만들고 싶었기 때문입니다. 이 방법은 48kHz로 업샘플링할 때 에일리어싱 결함을 방지하는 데 도움이 되었습니다. 염두에 두고 있었던 또 다른 사항은 Vorbis 인코더의 경우 16kHz 이하의 사운드를 변환할 시 코덱이 보다 높은 샘플 레이트에 대해 특별히 조정되었기 때문에 음질이 좋지 않을 수 있다는 점입니다.

모노로 변환하기

게임의 메모리 로드, 디스크 크기 및 CPU 로드를 감소할 수 있는 좋은 방법은 채널 구성이 Mono로 설정된 Conversion Setting ShareSet 프리셋을 사용하여 사운드를 모노로 변경하는 것입니다 (적용 가능한 경우).

그림 8: Conversion Settings ShareSet 프리셋 편집기

멀티 채널 파일은 단일 채널 파일에 비해 메모리 사용 공간이 훨씬 더 큽니다. 예를 들어 채널이 두 개인 스테레오 파일은 이에 대응하는 모노 파일보다 공간을 두 배로 차지합니다.

더 중요한 것은 멀티 채널 파일이 게임에서 음원으로서 어떤 식으로 작동하는지 고려해야 한다는 것입니다. 오디오의 각 채널은 게임에서 한 Voice에 해당합니다. 이 규칙은 Audio Object에도 적용되기 때문에 각 채널이 한 Audio Object에 해당합니다. 플러그인에 멀티 채널 사운드를 삽입할 경우 각 채널이 하나의 플러그인 인스턴스를 만들게 됩니다. 이 효과는 오버라이드하지 않는 한 계층 구조에 있는 모든 하위 계층에 전파됩니다.

채널이 많은 오디오 파일이 비용에 얼마나 부담을 주는지 쉽게 알 수 있죠. Voices/Audio Object가 더 많을수록 플러그인, 변환, 사운드 믹싱에 대해 추가적인 CPU 리소스를 할당해야 합니다.

다음 기준 중 하나 이상에 속하는 사운드를 모노로 변환하는 것을 고려해보세요.

• 모든 채널에 있는 콘텐츠가 같거나 아주 비슷한 경우.
• 감쇠 반경이 아주 작은 감쇠 프리셋을 사용하는 사운드.
• Spread 값이 아주 낮은 감쇠 프리셋을 사용하는 사운드.

보통 보이스오버, 레벨의 작은 이미터에서 재생되는 사운드(예: 작은 적들과 동물들), 특정 UI 사운드, 폴리 사운드(크기와 거리에 따라), 레벨에서의 작은 상호작용 등이 모노로 변환하기에 적합합니다.

파일을 모노로 변환하려면 해당 사운드나 상위 계층의 Conversion 탭으로 가서 Default Conversion Settings 프리셋을 오버라이드하거나 'Override parent' 옵션을 선택한 후 알맞은 ShareSet 프리셋을 선택하세요.

그림 9: Conversion Settings 프리셋 오버라이드하기

모노로 변환하도록 구성된 모든 오브젝트에 대한 개요를 보려면 Conversion Settings ShareSet 프리셋의 참조 목록을 확인하면 됩니다.

그림 10: Conversion Settings ShareSet 프리셋 에디터의 Reference 버튼

이 버튼을 클릭하면 해당 ShareSet 프리셋으로의 모든 참조가 열거된 Reference View 창이 열립니다.

그림 11: Reference View가 'Vorbis mono' 프리셋에 대한 모든 참조를 보여줍니다.

Blend Container 서로 붙이기

스카스 어보브의 Wwise 프로젝트에서 도입한 최적화 실행법 중 하나는 모든 Blend Container를 통합(혹은 접착)하는 것이었습니다. 여기서 접착(glue)이란 음원(여기서는 Blend Container)에서부터 출력을 새로운 오디오 파일로 녹음하여 해당 음원을 새로운 파일로 교체하는 과정을 말합니다. 이 과정을 거치면 모든 Blend Container가 단일한 SFX 오브젝트로 교체됩니다.

게임의 제작 단계 동안 저희는 많은 사운드를 가져왔고 Blend Container는 여러 레이어의 사운드를 한 컨테이너로 구성할 수 있는 편리한 방법을 제공했습니다. 이로 인해 Event에 있는 한 Play 동작을 트리거하는 것만으로 컨테이너를 쉽게 시험할 수 있었죠. Wwise에서 레이어를 가지는 것은 이러한 레이어의 믹스를 더욱 개선할 수 있게 해주었고, 이 모든 레이어를 한 상위 계층 아래 둠으로서 여러 다른 방식으로 이를 트리거하고 처리할 수 있었습니다.

하지만 레이어를 구성하는 데만 Blend Container를 사용하는 것은 다소 과하게 보일 수 있습니다. Blend Container의 주요 목적은 Blend 트랙을 만드는 것입니다. 이 트랙은 해당 컨테이너 안에 있는 하위 오브젝트 간에 정확한 전환 효과를 정의하고 여러 다른 게임 매개 변수로 이 전환 효과를 제어할 수 있게 해줍니다.

트리거되면 각 Blend Container가 동시에 여러 하위 계층을 재생하기 때문에 Blend Container와 관련된 CPU 로드를 주시해야 합니다. 예를 들어 'Impact', 'Tail', 'Foley' 'Mechanics' 레이어를 위한 별도의 하위 컨테이너들이 담긴 Gunshot Blend Container가 있을 경우 이 Blend Container를 트리거하면 네 개의 사운드가 모두 동시에 재생됩니다.

그림 12: 하위 계층이 네 개인 Blend Container의 예시

Gunshot 이벤트 안에 담긴 각 레이어가 두 채널을 가진 스테레오 재생으로 구성되었다고 가정하면 이 Gunshot 이벤트를 트리거할 때 여덟 개의 물리적 보이스를 차지하게 되죠. 여러 Gunshot 이벤트가 빠르게 트리거될 경우 보이스 개수가 아주 빠르게 증가할 수 있습니다. 뿐만 아니라 이 Blend Container에 플러그인이 삽입되어 있을 경우 각 Gunshot 이벤트가 각각 삽입된 플러그인의 여덟 개의 인스턴스를 생성하게 됩니다.

이 Blend Container를 접착하면 보이스 개수가 여덟 개에서 두 개가 되어 메모리와 CPU 로드가 훨씬 줄어들게 됩니다.

Blend Container 안에 있는 하위 컨테이너가 각 Gunshot 이벤트의 서로 다른 레이어 믹스를 생성하도록 설계된 Random Container일 경우 Blend Container를 필요한 만큼 접착하여 충분한 변형음을 만들고 충실도를 유지하면서 최적화된 Gunshot 사운드를 성취하도록 할 수 있습니다.

Blend Container를 접착하는 최적의 방식은 Wwise Authoring Tool 자체에서 출력을 녹음하는 것입니다. Master Audio Bus에 Wwise Recorder 플러그인을 삽입하고 올바르게 구성하면 Blend Container를 트리거할 때마다 디스크상의 특정 .wav 파일로 녹음할 수 있습니다.

그림 13: Master Audio Bus에 삽입된 Wwise Recorder 플러그인

그림 14: Wwise Recorder Effect Editor 창

Blend Container 재생이 끝나면 해당 .wav 파일이 생성됩니다. 새로운 녹음을 시작하기 전에 반드시 녹음 파일을 다른 위치로 옮기거나 알맞은 이름으로 변경해야 합니다. 이렇게 하면 각 재생이 이전 녹음을 덮어 쓰는 일이 없게 됩니다.

변형음을 충분히 생성한 후 녹음한 모든 파일을 새로 만든 Random Container 안으로 가져올 수 있습니다. 이 Random Container를 이벤트 안에 있던 Blend Container 대신 사용할 수 있습니다. 녹음을 끝내고 나면 Master Audio Bus에서 Wwise Recorder 플러그인을 우회하는 것을 잊지 마세요.

그림 15: Wwise Recorder로 생성한 변형음으로 구성된 Random Container

이제 사용하지 않는 Blend Container도 후에 믹스를 변경하거나 해당 과정을 반복하기 위해 프로젝트에 유지하는 것이 유용합니다. '_Glued' 폴더 안에 넣은 후 제외시킬 것을 권장합니다. 이렇게 하면 새로운 변형음을 생성하고자 할 때 다시 쉽게 포함시킨 후 Wwise Recorder 플러그인을 재삽입하고 필요한 내용을 변경한 후 새로운 녹음 파일을 만들 수 있습니다.

그림 16: 제외된 Blend Container

효과 처리 최적화하기

Wwise에서 제공된 플러그인 효과로 사운드를 처리하는 작업은 CPU뿐만 아니라 심지어 메모리 리소스도 많이 소비할 수 있습니다. 하지만 Wwise 환경 안에서 처리를 최적화하고 성능을 개선할 수 있는 몇 가지 방법이 있습니다. 다음 섹션에서는 이러한 최적화 방법을 더욱 자세히 살펴보겠습니다.

• 효과 렌더링하기

앞서 언급했듯이 Wwise에서 오디오 오브젝트에 추가된 각 플러그인 효과는 오브젝트의 각 채널과 해당 하위 계층마다 인스턴스를 생성하게 됩니다. 이러한 플러그인에 의해 실행되는 처리는 게임 플레이 도중 실시간으로 계산됩니다. 하지만 게임 매개 변수를 사용하여 동적으로 변경되지 않아도 되는 효과 처리가 있을 경우 이를 대신 렌더링하는 방법을 선택할 수 있습니다.

'Render' 옵션을 활성화하면 SoundBank에 사운드를 패키징하기 전에 사운드 안에 효과를 효율적으로 만들어 넣게 됩니다. 이 방법은 런타임 때 처리 능력을 절약해줍니다. 하지만 앞서 언급했듯이 효과를 렌더링하고 나면 게임 매개 변수(RTPC) 를 사용하여 효과를 변경하거나 우회할 수 없습니다.

그림 17: Container Property Editor의 Effects 탭에서 Render 옵션이 선택됨

렌더링할 수 있는 삽입 효과의 전체 목록을 쉽게 얻을 수 있는 방법이 있습니다. Integrity Report(무결성 보고서, 기본 단축키인 [Shift + G]를 눌러 창을 열 수 있음)를 생성하면 다음 메시지와 함께 각 플랫폼에 대해 렌더링을 사용하여 최적화될 수 있는 효과의 모든 인스턴스가 열거됩니다.

'The effect could be rendered to save CPU, since no parameter will change in game.' (게임에서 매개 변수가 변경되지 않기 때문에 이 효과를 렌더링하여 CPU를 절약할 수 있습니다)

그림 18: Integrity Report 창

여기에서 해당 효과가 담긴 오브젝트의 Property Editor를 열어 'Render' 옵션을 활성화할 수 있습니다. 이를 실행하고 나면 해당 효과가 Integrity Report에 더 이상 열거되지 않습니다 (렌더링에 관한 이 특정 문제에 관해서).

• 버스에 효과 삽입하기

보통 렌더링할 수 없는 효과를 사용할 경우 Actor-Mixer나 Interactive Music 계층 구조 내의 오브젝트가 아닌 버스에 효과를 삽입하는 것이 좋습니다. 그 이유는 버스의 채널 개수가 고정되어 있기 때문에 버스에 효과를 삽입하면 버스의 채널 수만큼 여러 번 효과를 인스턴스화하기 때문입니다. 반면 효과를 Actor-Mixer 오브젝트에 삽입할 경우 해당 오브젝트의 각 하위 계층의 각 채널마다 효과가 인스턴스화됩니다. 두 접근 방식 모두 궁극적으로 동일하게 들리지만 첫 번째 방법에서 인스턴스화되는 효과의 개수가 더 적습니다.

하지만 이 규칙은 오브젝트가 전송되는 채널보다 버스에 채널 개수가 더 많을 경우에는 예외가 됩니다. 이 경우 버스가 SFX 오브젝트보다 더 많은 효과 인스턴스를 생성하기 때문에 SFX 오브젝트에 효과를 삽입하는 것이 더 나을 수 있습니다. 여기에도 예외가 있습니다. 리버브는 채널당 성능 비용이 그다지 크지 않으며 보통 Auxiliary Bus에서 사용하는 것이 좋습니다.

• General Settings에서 효과로 처리 옮기기

리소스를 더 절약하기 위해 버스나 오브젝트에 있는 매개 변수를 런타임 도중 처리 능력을 소비하는 효과로 간주할 수 있습니다. Bus나 Voice Volume, Pitch, Low-pass filter, High-pass filter와 같이 General Settings 탭에 있는 매개 변수는 게임 플레이 도중 CPU 리소스를 사용하기 때문에 게임 매개 변수에 의해 변경되지 않을 경우 전용 효과 플러그인으로 교체한 후 렌더링할 수 있습니다.

그림 19: General Settings 탭에서 매개 변수 처리하기

Low-pass filter와 High-pass filter는 Wwise Parametric EQ의 한 인스턴스로 교체할 수 있고, Pitch는 Wwise Pitch Shifter나 Wwise Time Stretch 플러그인의 한 인스턴스로 교체할 수 있습니다. Volume이나 Make-Up gain은 Wwise Gain 플러그인 효과로 교체할 수 있습니다.

GIF 1: General Settings 매개 변수 대신 Wwise 플러그인이 삽입됨

다음은 Audiokinetic 문서에서 LPF와 HPF 값을 Cutoff Frequency에 참조하는 표입니다.

Wwise LPF및 HPF 값 Cutoff Frequency

애셋 재생 방식 최적화하기

이 섹션에서는 사운드 애셋이 재생 및 중단되는 방식, 보이스 및 AkComponent의 개념, 사운드 재생 및 트리거를 최적화할 수 있는 몇 가지 단계에 대해 설명해드리겠습니다.

보이스

게임에서 재생되는 개별적인 각 사운드는 한 보이스를 차지합니다. 이벤트가 트리거되면 해당 이벤트에 관련된 음원이 런타임 때 '보이스'가 됩니다. 이러한 보이스가 활성화되고 다양한 작동 방식을 적용하기 위해 계산이 필요합니다. 이 계산은 주로 해당 보이스에 대한 처리량에 따라 다릅니다. 계산을 최소화하고 필요할 때만 실행하도록 하면 CPU 리소스를 상당히 절약할 수 있습니다.

현재 게임에서 재생 중인 모든 보이스의 목록을 확인하려면 Wwise Profiler에서 게임에 연결하고 'Voices' 탭으로 가세요.

그림 20: Advanced Profiler의 Voices 탭

• Virtual Voice (가상 보이스)

보이스가 활성화되어 있고 사운드를 생성할 경우 이를 'Physical Voice(물리적 보이스)'라고 합니다. 각 Physical Voice는 각 프레임에서 다음 계산을 실행합니다.

1. 오디오 파일 디코딩
2. 사운드 리샘플링 (필요시 Pitch Shift 적용)
3. 효과 및 필터 처리
4. 볼륨 계산

관련된 액터가 너무 멀리 있는 등, Physical Voice가 들리지 않을 경우 이 보이스는 'Virtual Voice(가상 보이스)'로 설정됩니다. Virtual Voice는 볼륨 계산을 제외한 모든 계산을 건너뛰게 됩니다. 볼륨 계산은 다시 들리게 될 때 사운드를 다시 재생할 볼륨을 결정하기 위해 필요합니다. Physical Voice를 Virtual로 설정하면 CPU 리소스가 상당히 절약되기 때문에 더 이상 들리지 않는 사운드가 활성화되어 있지 않도록 하는 것은 게임을 최적화하기 위한 중요한 단계입니다.

Virtual Voice 작동 방식은 각 사운드 애셋에 대해 Property Editor의 'Advanced Settings' 탭에서 정의할 수 있습니다.

그림 21: Property Editor의 Advanced Settings 탭

가상 보이스 작동 방식 옵션은 보이스의 볼륨이 Volume Threshold(볼륨 스레숄드) 아래로 떨어질 경우 어떻게 할 것인지를 결정합니다.

여기에는 몇 가지 옵션이 제공됩니다.

1. Continue to play: 보이스가 여전히 활성화되며 계속해서 정상적으로 재생됩니다.
2. Kill voice: 보이스가 완전히 중단되며 더 이상 재생되지 않습니다.
3. Send to virtual voice: 보이스가 Virtual Voice가 되어 볼륨 계산을 제외한 대부분의 계산을 건너뜁니다.
4. Kill if finite else virtual: 사운드가 유한적일 경우 (반복 재생이 아닐 경우) 가상 보이스로 전송되면 완전히 중단됩니다. 사운드가 반복 재생될 경우 Virtual Voice가 됩니다.

저희는 대부분의 애셋에서 보통 기본값을 'Kill if finite else virtual'로 설정합니다. 이렇게 하면 사운드 볼륨이 특정 스레숄드 아래로 떨어질 때 사운드를 처리해야 하는 거의 모든 경우를 다룰 수 있습니다. 유한적인 사운드는 멀리 움직일 경우 나머지를 듣지 않게 되기 때문에 제거되지만, 반복 재생음의 경우 사운드가 가상으로 전환되죠.

그리고 Physical Voice 상태로 돌아오면 모든 가상 보이스를 'Play from elapsed time'으로 설정했습니다. 이렇게 하면 볼륨 계산과 더불어 Wwise가 보이스가 가상 상태에 있는 시간을 추적합니다. 보이스가 다시 활성화되면 경과 시간부터 계속 재생되어 게임 시간의 흐름을 매끄럽게 인식할 수 있게 해줍니다.

• Volume Threshold 및 Max Voice Instances

Wwise가 Physical Voice를 Virtual 상태로 전송할 시기를 결정하도록 하기 위해서는 Volume Threshold를 지정해야 합니다. Volume Threshold는 사운드 볼륨이 충분히 낮다고 판단되어 안전하게 Virtual Voice로 변환되는 최소 볼륨 레벨을 나타냅니다.

이는 각 플랫폼에 따라 'Project Settings' General 탭에서 정의됩니다.

그림 22: Project Settings 창의 General 탭

스카스 어보브의 경우 Volume Threshold를 -40으로 설정하는 것이 Virtual Voice 작동 방식에 적합했습니다.

Max Voice Instances(최대 보이스 인스턴스)는 플랫폼마다 허용되는 Voice의 최대 개수를 정의합니다. Physical Voice의 개수가 이 제한을 넘어가면 우선 순위에 따라 추가 보이스가 즉시 가상으로 전송됩니다. 저희는 게임에 있는 보이스 개수를 좀 더 잘 제어하고 싶었기 때문에 이 매개 변수에는 상대적으로 관대한 값을 설정했습니다.

보이스를 프로파일링할 때 'Number of Voices (Physical)'과 'Number of Voices (Total)'이라는 두 매개 변수를 모니터링하는 것이 중요합니다. 'Number of Voices (Physical)'은 게임에서 현재 동시에 재생되는 모든 Physical Voice의 개수를 보여주며, 'Number of Voices (Total)'은 등록된 Physical과 Virtual Voice의 합친 개수를 보여줍니다.

그림 23: Wwise Profiler의 'Number of Voices' 매개 변수

스카스 어보브에서는 각 플랫폼에서 허용되는 Physical 및 Total Voice의 개수에 대해 다음 표와 같이 일반적인 규칙을 설정했습니다.

	Physical Voices (최대)	Total Voices (최대)
Gen 8	30	500
Gen 9	40	600
PC	40	600

표 3: 플랫폼별 보이스의 최대 개수

Virtual Voice는 Physical Voice에 비해 계산 요구 사항이 훨씬 적지만 게임에서 Virtual Voice를 너무 많이 사용하지 않도록 하는 것이 좋습니다. 리소스는 적게 사용하지만 Virtual Voice는 여전히 Volume과 Elapsed time(경과 시간) 계산을 필요로 하기 때문이죠. 더 중요한 것은 Virtual Voice가 여전히 Emitter로 간주되기 때문에 Spatial Audio로 전송될 경우 Diffraction 경로 계산에 기여하게 됩니다.

• Playback Limiting (재생 제한)

사운드가 예측할 수 없는 횟수로 트리거될 수 있거나 동시에 재생되는 사운드의 인스턴스가 너무 많아질 경우 Wwise에서 해당 사운드에 대한 Playback Limit을 적용할 수 있습니다.

Playback Limit 옵션은 Property Editor의 Advanced Settings 탭에서 찾을 수 있으며, 여기에서 'Limit sound instances to'를 특정 숫자로 설정할 수 있습니다. 여기에서 한계의 범위를 설정할 수 있는 유연성이 있습니다. Game Object와 Global 중에서 결정할 수 있는 옵션은 사운드를 액터마다 혹은 전체 게임에서 전역적으로 제한할 수 있게 합니다.

그림 24: Random Container의 사운드 인스턴스 제한하기

저희는 사운드 인스턴스 제한을 주로 적들의 사운드에 사용했습니다. 특히 강렬한 전투 상황에서 동일한 유형의 적 여러 마리가 스폰할 경우 동시에 수많은 비슷한 사운드가 트리거될 수 있는 상황에서 사용했죠. 재생 제한을 설정함으로써 게임의 성능을 최적화했을 뿐만 아니라 과도하게 겹치는 사운드를 줄여서 전체 믹스를 향상시켰습니다.

AkComponent

AkComponent는 Unreal Engine에서 활성화된 Wwise Event 역할을 하며 USceneComponent에서 파생됩니다.

사운드 디자이너의 시점에서 볼 때 AkComponent는 게임에 있는 음원 혹은 스피커라고 볼 수 있습니다. 이 컴포넌트가 게임에 있으면 이 스피커가 사운드를 방사하고, 액터에 연결되고, 심지어 함께 이동할 수 있습니다.

게임에서 AkComponent를 효율적으로 관리하는 것은 오디오 성능을 최적화하는 데 중요한 단계입니다. 활성화된 각 AkComponent는 모든 프레임에서 여러 계산이 실행되어야 하며, 이로 인해 등록된 AkComponent 개수가 너무 많을 경우 CPU에 무리가 갈 수 있습니다.

사운드 발송을 최적화하려면 각 이벤트마다 새로운 컴포넌트를 스폰하는 대신 기존의 AkComponent를 활용해야 합니다. 게임의 모든 AkComponent를 추적하고 기존 컴포넌트에 필요할 때마다 사운드를 발송하면 전반적인 CPU 부하량을 줄일 수 있습니다.

AkComponent로 사용하기에 적당한 후보는 플레이어 캐릭터, NPC, 적군, 발사체와 같이 게임에 지속적으로 존재하고 움직이는 액터들입니다. AkAmbientSound와 같은 일부 액터에는 AkComponent가 기본적으로 이미 연결되었을 수 있습니다.

• AkComponent에 대신 Post Event at Location 사용하기

Wwise의 'Post Event at Location' 함수는 AkComponent를 필요로 하지 않고 이벤트를 전송할 수 있게 해줍니다. 이 함수는 이벤트를 데이터로 변환하여 입력하고, ID 번호가 지정된 임시 Wwise Game Object를 등록하며, 해당 이벤트를 트랜스폼의 위치 및 방향에 전송합니다.

AkComponent를 생성하고 이를 통해 이벤트를 전송하는 것과 비교하여 'Post Event at Location' 함수를 사용하면 훨씬 비용이 저렴합니다. Wwise Game Object는 보통 거의 정보를 갖고 있지 않지만 여전히 AkComponent에 게시된 사운드와 비슷하게 작동합니다. 주요 차이점은 Wwise Game Object에 전송된 이벤트는 전송 후 트랜스폼을 변경할 수 없으며 또 다른 액터에 첨부될 수 없고 Wwise Switch, State 혹은 Callback을 활용할 수 없으며 Game Object 범위에서 게임 매개 변수로 변경될 수 없다는 것입니다.

이러한 한계에도 불구하고 위치에서 이벤트를 전송하는 것은 여러 다른 유형의 사운드에서 여전히 아주 유용합니다. 이는 보통 한번 위치가 지정되어 있으며 재생되면 끝인 단발성 사운드나 반복 재생음에 사용됩니다. 액터나 위치에 묶이지 않은, 위치가 지정되지 않은 2D 사운드도 이 함수를 사용하여 게시될 수 있습니다. 이 사운드는 트랜스폼 데이터를 무시하게 됩니다.

스카스 어보브에서는 UI 사운드, 음악 트랙, 게임 내 상호작용 사운드, 임팩트 이벤트(적에 대한 특정 타격음 포함)에 'Post Event at Location'을 광범위하게 사용했습니다. 전역적 상태를 설정하고, 전역적 믹스를 변경하거나, 버스를 일시 정지/일시 정지 해제하는 버스와 같이 전역적 범위의 다용도적 이벤트도 'Post Event at Location' 함수를 사용하기에 적합합니다.

'Post Event at Location'을 사용할 때 고려해야 할 사항이 몇 가지 있습니다.

1. 사운드의 원하는 위치를 가져오기 위해 해당 위치를 제공하는 컴포넌트나 액터를 검색할 수 있습니다. 'Get World Location'이나 'Get Actor Location' 함수를 사용하여 위치 데이터를 검색하세요. 

그림 25: 액터 위치를 사용하여 위치가 지정된 사운드 전송하기

2. BeginPlay에서 사운드를 게시할 경우 Spatial Audio 액터가 이벤트를 전송하기 전에 로드되어야 합니다. 이렇게 하면 Spatial Audio 네트워크 안에서 해당 사운드의 위치가 올바르게 지정되도록 해줍니다. AkComponent와 달리 Game Object에 전송된 이벤트는 Spatial Audio 액터가 로드되었을 때 Spatial Audio와 관련하여 위치를 업데이트하지 않습니다.

3. 반복 재생되는 사운드를 AkComponent가 아닌 Game Object에 전송할 경우 이 반복 재생되는 사운드의 중단도 처리해줘야 합니다. AkComponent를 파괴하면(예: 상위 액터가 언로드될 경우) 이에 라우팅된 모든 사운드가 중단됩니다. 하지만 'Post Event at Location' 함수를 위해 일시적으로 생성된 Game Object는 아무 게임 논리와 관련이 없습니다. 사운드를 중단하려면 올바른 Game Object를 등록 해제하거나 이벤트를 직접 중단해야 합니다. Game Object 이벤트를 중단할 수 있는 제일 간단한 방법은 Game Object ID를 입력으로 하여 'Execute Action on Playing ID' 함수를 호출하는 것입니다.

그림 26: 위치 지정되지 않은 UI 사운드 게시 및 중단하기

애니메이션 노티파이

애니메이션에서 이벤트를 직접 게시하는 것은 게임에서 사운드를 트리거하는 일반적인 방법입니다. 대부분의 사운드가 동일한 AkComponent에 전송되었지만 대량의 동시다발적 노티파이가 사운드를 동시에 재생하도록 트리거하여 Physical Voice의 수가 많아질 수 있습니다.

사운드를 작은 부분이나 여러 레이어로 나누면 충실도를 더 높이면서 동작과 더 잘 동기화할 수 있습니다. 하지만 사운드를 빠르게 연속적으로 전송할 경우 트리거되는 이벤트의 양이 너무 많아져서 Wwise로 수많은 호출을 발생시킬 수 있습니다 (특히 비슷한 애니메이션 여러 개가 동시에 재생될 경우).

블렌드 공간은 이 문제를 더 악화시킬 수 있습니다. 노티파이 개수가 많은 두 애니메이션을 블렌드할 경우 심지어 더 많은 이벤트가 트리거될 수 있기 때문이죠.

그림 27: 여러 개의 사운드 노티파이가 있는 애니메이션 몽타주

이런 경우 애니메이션당 수많은 노티파이가 정말 필요한지, 그리고 보다 적은 오디오 이벤트 개수로 비슷하거나 같은 수준의 품질을 도출할 수 있는지 생각해봐야 합니다. 애니메이션에서 동시다발적 사운드가 보다 적으면 활성화된 보이스 개수가 줄어들어 CPU 부하량을 줄일 수 있습니다.

최적화를 위한 애셋 구성

애셋을 구성하는 것은 성능뿐만 아니라 프로젝트의 일반 작업 과정을 개선하는 데 아주 중요합니다. 애셋을 올바른 SoundBank와 하위 레벨에 배치하면 이러한 애셋을 언제 로드/언로드할 것인지 제어할 수 있습니다. 이렇게 하면 리소스 사용량을 더욱 효율적으로 관리하여 주어진 시점에서 필요한 애셋만 메모리에 로드할 수 있습니다.

또한 프로젝트를 깔끔하게 유지하며 중복된 애셋이 없도록 하는 것도 중요합니다. 필요 없는 애셋을 제거하면 혼란을 감소시킬 뿐만 아니라 메모리 및 CPU 사용량을 최소화하는 데 도움이 됩니다.

SoundBank

사운드를 SoundBank로 묶는 것은 게임에서 오디오 메모리를 관리하는 훌륭한 방법입니다. 대부분의 경우 모든 사운드가 항상 로드되어야 할 필요가 없기 때문에 사운드를 묶어서 필요할 때만 로드하는 것은 메모리 부하량을 줄이는 가장 좋은 방법 중 하나이며, 언제 어떻게 사운드가 로드되고 재생되는지를 명확하게 확인할 수 있습니다.

여러 다른 유형의 사운드를 올바르게 로드할 수 있도록 하기 위해 스카스 어보브에서는 사운드를 다음 카테고리로 묶었습니다.

1. Main: 전체 게임에서 사용될 이벤트가 담겨 있습니다.
2. Player: 모든 플레이어 이벤트가 담겨 있습니다.
3. Enemies: 적 종류마다 한 뱅크가 있으며, 해당 적에 대한 모든 이벤트가 담겨 있습니다.
4. CharactersCommon: 공유되는 모든 캐릭터 이벤트가 담겨 있습니다.
5. Levels: 레벨/하위 레벨마다 한 뱅크가 있으며, 해당 레벨/하위 레벨에 대한 모든 이벤트가 담겨 있습니다.
6. LevelsCommon: 공유되는 모든 레벨 이벤트가 담겨 있습니다.
7. Music: 모든 음악 이벤트가 담겨 있습니다.
8. Voice: 모든 대사 이벤트가 담겨 있습니다.
9. EmotionalResponses: 모든 Player Emotional Responses 이벤트가 담겨 있습니다.
10. Cinematic: 모든 시네마틱 이벤트가 담겨 있습니다.
11. HapticFeedback: 모든 햅틱 피드백 이벤트가 담겨 있습니다.

 

• 자동으로 로드되는 SoundBank

자동으로 로드되도록 설정된 뱅크는 해당 뱅크에 속하는 이벤트가 게임에서 참조될 때 자동으로 로드됩니다. Main, Player, Music과 같은 SoundBank는 항상 참조되며 게임 기간 동안 메모리에 유지됩니다. Enemies SoundBank의 경우 각 적 유형이 참조되는 시기와 장소를 추적하며 각 적 종류에 해당하는 SoundBank가 동적으로 로드/언로드되도록 하는 자동 로드 시스템에 의존했습니다.

스카스 어보브 프로젝트에서 Levels SoundBank를 제외한 SoundBank는 자동으로 로드되도록 설정되어 있습니다. Levels의 경우 액터와 이벤트가 로드되는 시기와 장소를 엄격히 제어하고 싶었습니다. Levels SoundBank 로드는 World Composition 레벨 스트리밍 시스템에 연결하여 필요에 따라 특정 레벨을 로드/언로드하도록 했습니다 (레벨 스트리밍에 대해서는 이 섹션의 후반부에서 설명해드리겠습니다).

• Common SoundBank

여러 다른 캐릭터나 레벨이 공유하는 이벤트를 저장하기 위해 Common SoundBank를 만들었고 자동으로 로드되도록 했습니다. Common SoundBank를 두면 공유되는 미디어가 여러 SoundBank에서 중복되지 않고 한 번에 로드되어 메모리 부하량을 절약할 수 있습니다. 반면 Common SoundBank는 특정 캐릭터나 레벨에 묶이지 않기 때문에 자동 로딩 혹은 스트리밍에 비해 더 오래 로드되어 있습니다.

공유된 이벤트를 사용할 때 Common SoundBank 대신 중복된 미디어를 서로 다른 SoundBank에 복사해넣을 수 있습니다. 이렇게 하면 동일한 이벤트가 여러 뱅크에 로드되는 기간이 생길 수 있지만 이러한 뱅크를 올바르게 처리하면 Common SoundBank를 사용하는 것보다 시간이 훨씬 짧을 수 있습니다.

Common SoundBanks를 사용하는 것은 동시에 여러 다른 캐릭터나 레벨에 의해 참조될 이벤트를 저장하고 싶은 경우에 최적입니다. 예를 들어 같은 영역에서 일부 사운드를 공유하는 여러 다른 그룹의 적들을 만날 경우 그러하죠. 다른 접근 방식은 재사용되는 이벤트가 동시에 여러 뱅크에 로드되지 않을 경우 더 적합하며, 보통 Level SoundBank가 이런 경우에 해당됩니다. 프로젝트의 요구와 특정 상황에 따라 일반 및 특정 SoundBank를 로드하는 시기와 방식을 결정하는 것은 사운드 디자이너의 권한입니다.

• Event-Based Packaging (이벤트 기반 패키징) / Auto-Defined SoundBanks (자동 정의 사운드뱅크)

스카스 어보브는 이제 레거시가 된 SoundBank 시스템을 사용하여 개발되었지만 추후 모든 프로젝트에서는 Auto-Defined SoundBank로 전환할 계획입니다. Wwise 버전 2022.1에서 소개되었던 Auto-Defined SoundBank는 Event-Based Packaging 개념을 기반으로 하며 레거시 시스템을 교체하는 것이 목표입니다. Auto-Defined SoundBank의 주요 원칙은 각 이벤트 자체를 작은 SoundBank라고 여겨서 이벤트가 참조될 때만 로드하고 재생이 끝나고 나면 언로드하는 것입니다.

스카스 어보브 제작 동안 Event-Based Packaging으로 전환하려는 시도가 있었지만 기능을 구현하는 데 많은 문제가 있었습니다. 이론적으로는 아주 매력적인 기능이지만 실제로 Event-Based Packaging 기능은 충분히 다듬어지지 않았기 때문에 레거시 SoundBanks 시스템을 사용하기로 했습니다.

Level Streaming (레벨 스트리밍)

Level Streaming을 사용하면 실제로 필요한 해당 레벨에 있는 액터만 메모리에 로드되도록 할 수 있습니다. 이렇게 하면 동시에 로드되는 액터의 개수가 감소되어 소중한 오디오 스레드 시간을 사용하는 Emitter와 Game Object 개수가 줄어듭니다.

레벨에서 Spatial Audio로 전송되는 각 이미터에 대해 리스너가 이동할 때마다 회절 경로에 대한 계산이 필요합니다. 이는 매프레임에서 일어나며 수백 개의 이미터가 로드될 경우 Spatial Audio CPU가 갑자기 치솟을 수 있죠 (그림 3 참조).

현재 활성화된 이미터의 개수는 Wwise Profiler에서 언제든지 확인할 수 있습니다. 제 분석을 기반으로 이미터의 개수(Profiler에 있는 'Spatial Audio - Emitters Processed')를 Gen 8 플랫폼에서는 150, Gen 9와 PC 플랫폼에서는 200 아래로 유지하는 것을 권장했습니다.

이미터를 줄이는 최적의 방법은 맵을 더 작은 하위 레벨로 나눠서 필요할 때만 로드하도록 하는 것입니다. 액터를 특정 Sound 하위 레벨로 묶으면 해당 레벨에 속한 액터가 로드되는 영역을 제어할 수 있습니다. 플레이어가 지정된 지역 안에 들어가면 해당 하위 레벨에 속한 액터가 로드되며, 플레이어가 해당 영역에서 나가면 액터가 언로드됩니다. 스카스 어보브에서 레벨 범위를 기준으로 레벨 로드/언로드를 위해 사용한 시스템은 World Composition이라고 부릅니다.

• World Composition (월드 구성)

World Composition은 큰 맵을 관리하기 위한 시스템입니다. 이 맵은 Stream Layer로 구성된 더 작은 하위 레벨로 나뉩니다. 각 하위 레벨에는 자체적인 Level Bounds 상자가 있으며, Stream Layer에 따라 스트리밍 거리값이 Unreal 단위로 할당됩니다. 이 거리는 하위 레벨이 로드될 Level Bounds 상자 주변의 범위를 정합니다. 예를 들어 Level Bounds 상자의 스트리밍 거리가 1500 단위일 경우 해당 레벨은 플레이어가 경계의 (혹은 상자 안) 1500 단위 안에 있을 때 로드됩니다.

이 시스템은 맵을 관리 가능한 부분들로 효율적으로 나눠서 주어진 영역에 필요한 액터만 로드할 수 있게 해줍니다. 사운드를 Virtual Voice 시스템으로 전송하는 것도 CPU 처리를 어느 정도 해제할 수 있지만 액터 자체는 여전히 로드되어 있고 해당 게임 오브젝트도 Volume 및 Spatial Audio 계산을 위해 등록되어 있습니다. 이러한 오브젝트가 메모리에 너무 많을 경우 CPU 스파이크가 일어날 수 있습니다.

• 스카스 어보브에서 레벨을 나누는 방법

레벨을 더 작은 하위 레벨로 나눌 때 가장 직관적인 방법은 액터를 속한 특정 영역이나 구역별로 묶는 것입니다. 구역은 음향적 및 시각적으로 충분히 구별되어 애셋 구성 및 이름 지정에 있어 다른 영역으로 취급될 수 있는 레벨 부분을 말합니다.

각 구역마다 전용 Sound 하위 레벨이 있습니다. 구역의 복잡성과 크기에 따라 더 작은 레벨로 나누는 것이 유리할 수 있습니다.

그림 28: 스카스 어보브에서의 늪 지역 및 이에 대한 Sound 하위 레벨 경계

• Level Bound (레벨 경계)

World Composition을 활성화한 후에 레벨 스트리밍에 사용할 각 하위 레벨의 Level Bound를 정의할 수 있습니다. 해당 레벨에 대한 Level Bounds 액터의 인스턴스는 World Outliner에서 찾을 수 있습니다. 이러한 액터는 투명한 상자로 표시되며 (기본 모양인 상자만 사용할 수 있으며 변경할 수 없습니다) 각 하위 레벨이 다룰 구역을 결정합니다. 경계를 설정할 때 Level Bounds 상자가 해당 하위 레벨에 속한 모든 사운드와 액터를 포함할 것인지의 여부를 고려하는 것이 중요합니다.

경계를 결정하는 최적의 방법은 해당 레벨에 있는 모든 액터를 선택하고 이 액터가 다루는 영역을 관찰하는 것입니다. 보통 AkAmbientSound 액터의 Attenuation 반경이 레벨의 가장 큰 영역을 차지하기 때문에 이를 보게 됩니다.

그림 29: 하위 레벨에서 선택된 모든 오디오 액터

그런 다음 Level Bound는 감쇠 반경 구를 고려하며 선택한 액터를 포함하도록 조정되어야 합니다.

그림 30: 하위 레벨의 모든 오디오 액터를 포함하는 Level Bounds 상자

• Stream Layer (스트림 레이어)

하위 레벨이 올바르게 스트리밍도도록 하기 위해서는 이를 Stream Layer에 할당해야 합니다. 이 작업은 Levels 창에서 하위 레벨을 선택한 다음 올바른 Stream Layer를 선택하여 수행됩니다.

그림 31: Sound 하위 레벨을 올바른 Stream Layer로 할당하기

World Composition 창에서 Stream Layer를 선택하면 해당 레이어에 할당된 모든 레벨의 경계를 위에서 내려다보는 시점으로 확인할 수 습니다.

그림 32: World Composition 창이 'Sound 10m' Stream Layer에 할당된 하위 레벨을 보여줍니다

• AntiLevelStreaming

지금이면 아마 간단한 상자 모양으로 로드할 액터 영역을 덮는 것이 하위 레벨 로드/언로드를 최적화하는 데 최상의 방법이 아니라는 것을 아마 알아차리셨을 겁니다. 상자처럼 아주 간단한 모양으로 제한될 경우 하위 레벨의 경계를 정확하게 정의할 수 없죠. 이럴 경우 맵에서 여러 레벨이 서로 겹쳐치고 동시에 로드되는 영역이 생기게 됩니다. 단지 Level Bounds 액터의 상자 모양때문에 해당 영역에서 레벨을 제외할 수 없었기 때문에 말이죠.

많은 액터가 있는 밀도 높은 영역에서는 심지어 Level Bounds 배치가 올바르더라도 맵에서 동시에 너무 많은 액터가 로드되는 곳이 생길 수 있습니다.

이러한 문제를 해결하기 위해 프로그래밍 팀은 World Composition을 보완하는 AntiLevelStreaming이라는 맞춤 해결책을 구현했습니다.

AntiLevelStreaming 액터 인스턴스를 맵에 추가하면 Level Bound와 굉장히 비슷한 경계 상자를 만들고 이러한 상자 안으로 들어갈 때 레벨 스트리밍에서(예: 언로드) 제외시키고자 하는 특정 하위 레벨을 지정할 수 있습니다. 이 시스템을 World Composition와 함께 사용하여 하위 레벨이 과도하게 메모리에 로드되었던 영역에서 레벨 스트리밍 문제를 성공적으로 해결할 수 있었습니다.

그림 33: Sound 하위 레벨이 추가된 AntiLevelStreamingActor

• Spatial Audio 스트리밍

안타깝게도 Spatial Audio 액터를 스트리밍하는 방법은 사용하지 못했습니다. Spatial Audio 볼륨을 로드/언로드하는 것을 시험해보니 특히 AkAcousticPortal에서 재계산을 많이 실행해야 했고 CPU에 무리가 갔습니다.

시험 동안 Spatial Audio 볼륨과 AkAcousticPortal을 런타임 때 동적으로 로드/언로드하는 것이 CPU 성능에 상당한 영향을 준다는 것을 발견했습니다. 로드/언로드된 각 Spatial Audio 액터에 대해 모든 활성화된 액터에서 회절 경로가 다시 계산되어야 했죠. 그렇기 때문에 다른 오디오 애셋과 함께 Spatial Audio 액터를 스트리밍하는 것은 실용적이지 못했습니다.

이 문제를 해결하기 위해 모든 Spatial Audio 액터가 담긴 퍼시스턴트(persistent) Spatial Audio 하위 레벨을 만들기로 했습니다. 이 하위 레벨은 레벨 스트리밍과 독립적으로 항상 로드되어 있습니다.

이로 인해 과도한 Spatial Audio 지오메트리가 생겨서 제작 후반부에 문제가 생겼습니다 (한 퍼시스턴트 하위 레벨에 수천 개의 Spatial Audio 액터가 있던 시기도 있었죠). 저희는 이 하위 레벨을 보다 작은 두 개의 하위 레벨로 나누고 게임에서 멀리 떨어진 구역 간의 전환 도중에 로드되도록 했습니다. 전환이 로딩 스크린에 의해 처리되기 때문에 플레이어의 경험에 영향을 끼치지 않으면서 필요한 Spatial Audio 하위 레벨을 로드/언로드할 수 있었습니다.

사용하지 않는 애셋 제거하기

장기 프로젝트에서는 팀이 적합한 해결책에 정착하기 전에 여러 반복 작업을 거치면서 더 이상 쓸모 없거나 완전히 달라지는 기능이 생기기 마련입니다. 이러한 기능을 위해 맞춰진 사운드는 더 이상 유용하지 않고 새로운 사운드가 생성되어야 할 수 있죠.

많은 사람들이 같은 프로젝트를 작업할 때 사운드의 모든 변경 내용 및 버전을 추적하는 것이 항상 가능한 것은 아니며, 일부 사운드는 사운드 디자이너가 알아차리지 못한 채로 중복될 수 있습니다. 메모리 리소스를 최적화하기 위해서는 사용되지 않는 이벤트를 구별하고 제거하는 것이 중요합니다.

AkEvent .uasset이 사용되는지 확인하는 가장 쉬운 방법은 레퍼런스를 확인하는 것입니다. 이벤트에 레퍼런스가 하나일 경우(해당 SoundBank에 대한 레퍼런스) 잘못 구현되었거나 더 이상 사용되지 않을 가능성이 높습니다. 이러한 경우 사용되지 않는 이벤트를 SoundBank에서 제거하고 Unreal Editor와 Wwise에서 모두 'Unused' 폴더로 옮기는 것이 좋습니다. 이렇게 하면 사용되지 않는 이벤트가 게임에서 메모리를 소비하지 않지만 나중에 필요하게 될 경우 여전히 접근할 수 있습니다.

그림 34: 해당 SoundBank만 참조하는 AkEvent

SpatialAudio

Spatial Audio는 굉장히 범위가 큰 주제이므로 이 문서에서 더 깊게 살펴보지 않겠습니다. 하지만 Spatial Audio에 대한 자세한 내용은 Spatial Audio 최적화 모범 사례를 포함하여 이전 글에서 설명해드렸습니다.

해당 글의 최적화 섹션으로의 링크

Spatial Audio 최적화

이 섹션에서는 완전히 최적화된 Spatial Audio를 성취하기 위해 필요한 모든 상세 정보를 찾을 수 있습니다.

간단히 말해 Spatial Audio 최적화에 대한 주요 단계에는 다음과 같은 내용이 포함됩니다.

• 삼각형의 총 개수를 주시하여 최대한 간단한 지오메트리를 가질 것
• 볼륨의 개수 최소화 (특히 AkAcousticPortal)
• 모든 볼록한 볼륨에서 Surface Reflector 비활성화
• 각 프레임에서 처리되는 이미터의 총 개수 주시
• 플랫폼별로 Spatial Audio 초기화 설정 조정

Spatial Audio에 대해 더 알아보고 싶다면 문서를 살펴보고 Audiokinetic 공식 문서에서 이 주제를 찾아보세요.

기타 조정 사항 (모든 솔루션을 사용한 후)

이전 솔루션들로 문제를 해결하지 못했을 경우 게임의 원하는 상태를 성취하기 위해 고려해 볼 몇 가지 추가 단계가 있습니다.

Stop 이벤트를 Execute Action on Event/ID로 교체하기

특정 유형의 사운드에 대해 전용 Stop 이벤트를 생성 및 구현해야 할 필요가 있습니다.

하지만 'Execute Action on Event'/'Execute Action on Playing ID'이라는 기존의 Blueprint 함수를 사용할 수 있는 옵션이 있습니다. 이러한 함수는 Stop이나 Pause와 같은 동작을 제공하며, 사운드를 중단 및 일시 정지하기 위한 일부 이벤트를 교체할 수 있습니다. 전용 이벤트 대신 이 UE 함수를 사용하면 이벤트를 SoundBank에서 완전히 제거할 수 있습니다. 이렇게 하면 영향이 상대적으로 작을지라도 프로젝트의 메모리 부하량을 줄이는 데 도움을 줍니다. 영향이 작더라도 게임을 더욱 최적화하는 데 기여하게 되죠.

가능한 경우 액터 믹서를 폴더로 교체하기

Wwise 프로젝트에서 액터 믹서가 단지 사운드를 구성하기 위한 용도로만 사용되며 이 자체에서 실제 변경 사항이 없을 경우 간단한 폴더로 교체하여 같은 결과를 얻을 수 있습니다. 이렇게 하면 거쳐야 할 계층 구조 레벨 하나가 줄어들기 때문에 사운드에 필요한 계산의 개수가 줄어듭니다.

Stop 이벤트를 교체하는 것과 비슷하게 이 방법은 다른 최적화 기술에 비해 개선 효과가 크지 않지만 최적화에 도움을 주기 위해 어떤 방법이든 사용해야 할 때가 있죠.

Random Container 안의 변형음의 수 줄이기

특정 플랫폼에서 한계에 도달할 경우 특정 애셋을 제외하여 메모리 부하량을 감소할 수 있습니다. 이는 Random Container에서 쉽게 적용할 수 있습니다. 해당 플랫폼에서 한 사운드에 좀 더 적은 변형음을 선택하고 부담이 적은 다른 플랫폼에서는 원래 만큼의 변형음을 유지하도록 할 수 있죠.

Random Container에서 변형음을 제외하려면 특정 변형음에 대해 'Inclusion' 옵션을 연결 해제하고 최적화하고자 하는 플랫폼에서 해당 사운드를 제외할 수 있습니다. 이렇게 하면 특정 플랫폼에서는 메모리 사용량을 줄이면서 다른 플랫폼에서는 기존의 다양한 사운드를 유지할 수 있습니다.

마치는 말

글을 읽어주셔서 감사합니다. 게임 오디오를 최적화하는 것은 우수한 성능과 효율적인 메모리 사용을 달성하는 데 중요한 단계입니다. 여기서 다룬 다양한 최적화 기술을 구현함으로써 플레이어의 전반적인 만족도를 향상시키고 매끄러운 시청각적 경험을 즐기면서 완전히 몰입되도록 하는 목표를 이루기 바랍니다.

지원과 피드백을 주신 Mad Head Games(매드 헤드 게임즈)의 동료 사운드 디자이너인 디미트리제(Dimitrije), 셀레나(Selena), 테오도라(Teodora), 마르코(Marko)와 EA Dice(EA 다이스)의 니콜라(Nikola)에게 큰 감사를 표합니다. 그리고 저희 오디오 프래그래머인 아르템(Artem)과 Mad Head Games QA 팀인 올자(Olja), 라자르(Lazar), 스테반(Stefan), 보리슬라브(Borislav)에게도 큰 감사를 드립니다. 피드백을 주시고 이 블로그로 제 연구 결과를 글로 펴낼 기회를 주신 Audiokinetic의 줄리(Julie), 마샤(Masha), 막시밀리앙(Maximilien), 데미안(Damian)에게도 정말 감사합니다.

유용한 링크

Wwise-251 자격증 과정

https://www.audiokinetic.com/ko/courses/wwise251/

프로파일링 공식 문서:

https://www.audiokinetic.com/ko/library/edge/?source=Help&id=profiling

Wwise Profiler 매개 변수에 대한 짧은 설명

https://www.audiokinetic.com/en/library/edge/?source=Help&id=performance_monitor_settings#profiler_counters

보이스 고갈 상태에 대한 문서:

https://www.audiokinetic.com/fr/library/edge/?source=Help&id=ErrorCode_VoiceStarving

음원 고갈 문제 해결하기에 대한 짧은 문서

https://www.audiokinetic.com/ko/library/edge/?source=SDK&id=streamingmanager_tips.html#streamingmanager_tips_troubleshooting_sourcestarvation

Wwise CPU 최적화 일반 안내서

https://blog.audiokinetic.com/ko/wwise-cpu-optimizations-general-guidelines/

CPU 사용량 최적화하기

https://www.audiokinetic.com/ko/library/edge/?source=SDK&id=goingfurther_eventmgrthread.html

변환 팁과 모범 사례

https://www.audiokinetic.com/ko/library/edge/?source=Help&id=versions_tips_and_best_practices

블로그 글의 Spatial Audio 최적화 섹션

https://blog.audiokinetic.com/ko/wwise-spatial-audio-implementation-workflow-in-scars-above/#optimization