Wwise 도움말

Wwise가 프로젝트 에셋에 ID를 부여하는 법을 설명하기 위해 아래 있는 간단한 프로젝트를 사용해봅시다. 이 프로젝트는 다음으로 구성되어 있습니다.

이미지: Play_Hello 이벤트와 대상 사운드 Hello.

Default Work Unit의 내용을 살펴보고 Wwise가 해당 Sound 오브젝트에 무엇을 할당했는지 확인해봅시다. 다음은 해당 Work Unit 파일에서 Sound 오브젝트의 항목입니다 (.wwu). 보기 쉽도록 관련 없는 Sound 오브젝트 항목은 제거되었습니다.

Wwise가 해당 Sound 오브젝트에 ID와 ShortID라는 두 ID를 부여한 것을 볼 수 있습니다. 각 ID를 좀 더 자세히 살펴봅시다.

이 ID는 Sound 오브젝트의 Wwise Authoring ID입니다. 128 비트의 전 세계적 단일 식별자 (GUID)이며 항상 단일합니다. 이 ID를 간단하게 줄여서 GUID라고 부르겠습니다. Wwise Authoring이 GUID를 사용하는 이유는 전역적 단일성 때문입니다. GUID를 사용하면 다음 작업이 훨씬 쉬워집니다.

Event 오브젝트 Play_Hello's Work Unit을 살펴보면 Sound 오브젝트 Hello를 참조하는 것이 보입니다.

하지만 Wwise Sound Engine에서 GUID를 사용할 경우, 프로젝트의 에셋 개수를 고려했을 때 크기가 너무 크기 때문에 다소 비실용적입니다.

Work Unit에서 특정 오브젝트에 주어지는 또 다른 ID는 32비트 정수인 ShortID입니다. 이 ID는 프로젝트의 SoundBank에 저장되는 유일한 식별자이며 Wwise Sound Engine에 의해 사용됩니다. 보기 쉽도록 이 ID를 ShortID라고 줄여서 부르겠습니다. 프로젝트 전체를 통틀어 단일하게 식별하는 GUID와 반대로 ShortID는 해당 ShortID 범위 내에서 단일하게 식별합니다. 따라서 오브젝트의 ShortID는 동일한 ShortID 범위를 가진 다른 오브젝트 사이에서만 단일하죠. ShortID의 범위는 세 가지가 있습니다.

1. Explicit ID - Sound Engine의 SDK 함수를 통해 접근할 수 없는 오브젝트입니다

이러한 오브젝트는 사용자 코드에 의해 참조될 수 없습니다 (예: Actor-Mixer 오브젝트). 이 범위는 오브젝트 타입으로 더 나뉘어집니다. 오브젝트의 ShortID는 해당 오브젝트 타입 안에서만 단일합니다. 다음은 오브젝트 타입의 예시입니다.

ShortID는 오브젝트 생성 시 할당되는 랜덤 숫자입니다. 이 값은 랜덤이기 때문에 각 오브젝트의 ShortID는 각 Work Unit 항목에서 명시적으로 추적됩니다.

2. Implicit ID - Sound Engine의 SDK 함수에서 접근할 수 있는 오브젝트입니다 (예: Event, State, Switch).

이 오브젝트는 이름으로 SDK 함수에 의해 참조될 수 있기 때문에, 이러한 오브젝트는 특정한 ShortID 값이 할당됩니다. ShortID는 해당 오브젝트 이름의 해시에 의해 생성됩니다. 다음과 같은 이유 때문입니다.

(위에 있는) 명시적 ShortID와 마찬가지로 이 범위에서의 오브젝트는 종류별로 묶어집니다. 다음은 오브젝트 타입의 예시입니다.

ShortID는 랜덤이 아니라 오브젝트의 이름에 의해 암시적으로 결정되기 때문에 프로젝트의 Work Unit에 의해 추적되지 않습니다. 위에서 Play_Hello 이벤트의 Work Unit의 항목을 보면 Play_Hello 이벤트에 ShortID 항목이 없는 것이 보입니다.

3. 미디어 에셋 (.wem 파일)

모든 미디어 에셋에는 저마다 명시적인 ShortID가 주어집니다. 따라서 이 아이디는 랜덤 숫자이며 Work Unit에 의해 반드시 추적되어야 합니다. 위의 예시를 보면 Sound의 미디어가 AudioFileSource 오브젝트를 통해 추적되며 미디어에 부여된 ID는 MediaID 항목을 통해 추적됩니다.

Wwise Authoring은 오브젝트가 생성됨에 따라 ShortID를 부여하여 단일하도록 해줍니다. 하지만 수많은 팀원들이 새로운 에셋을 추가하는 경우, ShortID가 겹치는 문제가 발생할 수 있습니다. 다음 상황을 고려해봅시다.

이 경우 동일한 ShortID를 가진 두 오브젝트가 생겨서 ShortID가 충돌하게 됩니다. Wwise는 두 오브젝트 중 하나에 새로운 단일한 ShortID를 부여하여 충돌을 해결합니다. Wwise는 충돌을 일으키는 오브젝트에 새로운 ShortID를 부여합니다. 즉, 첫 번째로 로드된 오브젝트의 ShortID가 유지되며 그 후에 충돌하는 오브젝트의 ShortID가 변경됩니다.

그렇다 해도, 다른 모든 에셋이 로드된 상태에서 새로운 오브젝트가 Wwise에 추가되는 한 문제는 생기지 않습니다. DLC가 있는 게임의 경우 프로젝트에 새로운 에셋을 추가할 때 반드시 이미 배급된 에셋 (예: 프로젝트 Work Unit)이 항상 로드되어 있어야 합니다. 이렇게 하면 새로운 에셋이 기존의 / 배급된 에셋과 충돌하는 것을 방지할 수 있습니다. 새로운 에셋이 다른 새로운 에셋과 충돌할 경우, Wwise는 새로운 에셋이 합쳐질 때 충돌을 해결합니다.

참고: Wwise가 충돌하는 오브젝트의 ShortID를 변경하여 ShortID 충돌을 해결할 경우 SoundBank에 있는 ShortID도 변경됩니다. 이 경우 SoundBank를 반드시 재생성해야 한다는 로그 메시지가 뜹니다.

Wwise가 오브젝트에 ShortID를 부여하여 오브젝트를 단일하게 식별하는 법을 살펴보았습니다. 미디어 에셋도 동일한 개념으로 식별된다는 것을 보았습니다. 하지만 미디어 에셋은 다른 모든 오브젝트와 다른 아주 중요한 차이점이 하나 있습니다. 바로 다시 사용될 수 있다는 점입니다. 우리가 사용한 간단한 프로젝트의 업데이트된 버전을 살펴봅시다. 이 버전에서는 Hello.wav를 사용하는 두 번째 Sound 오브젝트를 만들었습니다. 다음은 Default Work Unit에서 두 Sound 오브젝트와 관련된 내용입니다. 보기 쉽도록 미디어 에셋 ShortID를 MediaID라고 줄여 부르겠습니다.

두 Sound 오브젝트에 모두 동일한 MediaID가 주어진 것이 보입니다. 그 이유는 두 Sound 오브젝트가 모두 완전히 동일한 미디어 에셋을 사용하기 때문입니다. 게임을 출시할 때 동일한 미디어 에셋의 여러 복사본을 내보낼 필요는 없습니다. 동일한 오디오 에셋의 두 인스턴스는 .wem 파일이 동일한 경우에만 동일하다고 고려됩니다. 이 말은 다음 사항을 의미합니다.

두 Sound 오브젝트가 동일한 MediaID을 가졌던 예시에서 Hello.wav 오디오 에셋을 살펴봅시다. 프로젝트를 다시 편집해서 HelloAgain에 서로 다른 변환 설정을 지정해봅시다. 다음은 업데이트된 Work Unit입니다. 다시 말하지만 이 예시와 관련 없는 항목은 제거했습니다.

HelloAgain 이 다른 Conversion Settings를 사용하기 때문에 .wem 파일이 달라지게 되고, 이에 따라 또 다른 MediaID가 부여됩니다. 또한 Hello가 아닌 HelloAgain 에 새로운 MediaID가 부여되었다는 점을 참고해 주세요. 그 이유는 Hello 에서 미디어 에셋이 변경되지 않았기 때문입니다.

Wwise는미디어 에셋이 생성되거나 편집될 때 항상 MediaID를 재평가합니다. Wwise는 MediaID가 가능한 한 동일하게 유지되도록 합니다. 그렇지 않을 경우 생성/편집된 에셋에만 새로운 MediaID가 부여됩니다.

Wwise에서 프로젝트가 완전히 로드되고 편집되는 한, Wwise는 변경되지 않는 미디어 에셋이 자신들의 MediaID를 유지하도록 합니다. 하지만 프로젝트의 MediaID 일관성을 유지하기 위해 프로젝트 팀이 알아야 할 다른 고려 사항이 있습니다.

Wwise는 미디어 에셋의 모든 인스턴스를 살펴보고 두 개 이상의 인스턴스가 동일한 변환 미디어를 사용할 경우 MediaID를 재사용하는 방식으로 MediaID를 부여합니다. 그러기 위해서는 Wwise가 반드시 미디어 에셋의 모든 인스턴스를 파악해야 합니다. 하지만 일부 인스턴스가 Wwise에 로드되지 않았을 경우 어떻게 될까요? 한 에셋 인스턴스가 로드되지 않은 Work Unit인 경우를 예로 들 수 있습니다. Work Unit이 로드되면 Wwise는 충돌이 없는지 확실히 하기 위해 Work Unit 안에 있는 모든 MediaID를 재평가하여야 합니다. 다시 말하면, Wwise가 각 변환된 미디어에 고유한 MediaID가 단 한 개만 부여된 것이 맞는지 확실히 해야 한다는 뜻입니다. 이때 고려해야 할 두 가지 상황이 있습니다.

프로젝트 불러오기

Wwise는 모든 Work Unit이 로드되자 마자 모든 MediaID를 평가합니다. 충돌이 있을 경우, 어떤 MediaID가 유지될 것인지 예측할 수가 없습니다. 예를 들어, 여러 팀원이 프로젝트에 새로운 Work Unit을 만들 경우 이러한 문제가 생깁니다. 예시:

이 경우 MediaID 충돌이 생기며 Wwise가 해결하게 됩니다. 여기서도 고려해야 할 두 가지 상황이 있습니다.

Work Unit 로드하기

프로젝트의 일부 Work Unit이 프로젝트에 로드되지 않을 수 있습니다 (더 자세한 내용은 “프로젝트에서 Work Unit 불러오기/내리기” 참고). 위와 동일한 예시를 약간 변경해서 사용해 봅시다:

이 경우 OldWorkUnit의 MediaID를 인지하지 못한 채, 새로운 Work Unit에 각각 MediaID가 부여되는 위험이 있습니다. 그렇게 되면 OldWorkUnit 이 로드될 때 충돌이 생기며 Wwise가 NewWorkUnit1 이나 NewWorkUnit2의 MediaID를 유지하여 충돌을 해결합니다. 하지만 OldWorkUnit이 이미 출시된 에셋에 들어 있을 경우 어떻게 될까요?

어느 경우든, 팀원이 실수로 프로젝트의 MediaID 지정을 변경할 확률이 높습니다. 다음 작업 과정을 실행하면 이 문제를 방지하는 데에 도움이 됩니다.

MediaID를 올바르게 부여하려면 Wwise가 전체 프로젝트의 MediaID 할당을 알아야 합니다. 이전 섹션에서 보았듯이, 한 개 이상의 Work Unit이 언로드될 경우 Wwise가 모든 할당을 파악하지 못하게 됩니다. 이를 위해, Wwise는 단일한 파일을 사용하여 프로젝트의 MediaID 할당을 관리할 수 있는 방법을 지원합니다. 단일 파일 MediaID 관리 작업 과정을 사용할 경우

WwiseConsole.exe와 다음 전달인자를 사용하면 Wwise가 MediaID를 관리하는 법을 선택할 수 있습니다 (Work Unit vs. 단일 파일):

계속해서 예시 프로젝트인 WwiseIDs를 사용하여, 다음 명령어를 실행하여 MediaID를 단일 파일로 변경해봅시다.

WwiseConsole move-media-ids-to-single-file WwiseIDs

다음은 WwiseIDs.mediaid의 내용입니다.

다시 말하지만 예시 프로젝트에는 두 개의 음원 인스턴스를 가지는 Hello.wav라는 단 하나의 미디어 에셋만 있습니다. Hello.wav의 각 인스턴스의 경우

MediaID 파일은 프로젝트 로딩 동안 Work Unit이 로드된 후에 로드됩니다. MediaID 파일은 어느 Work Unit이 로드되었는지와 상관없이 로드됩니다. MediaID 파일을 로드할 때, 오디오 파일의 각 인스턴스의 Conversion Setting이 해시되며 파일에서의 해시와 비교됩니다. 해시가 서로 일치하지 않을 경우 인스턴스에 새로운 MediaID가 부여되며, 필요할 경우 이전 섹션에서 열거한 동일한 규칙을 사용합니다. 프로젝트가 로드되면 로드된 Work Unit에서의 모든 인스턴스에 알맞은 MediaID가 부여됩니다. 하지만 나중에 더 많은 Work Unit이 로드될 경우, MediaID가 재평가됩니다.

MediaID 파일을 사용하여 Wwise 프로젝트를 마일스톤과 동기화할 수 있습니다. 각 마일스톤에서 Wwise 프로젝트의 MediaID 파일은 WwiseConsole.exe update-media-ids-in-single-file을 통해 이전 마일스톤의 MediaID로 업데이트됩니다. 업데이트된 MediaID 파일을 통해 전체 프로젝트가 새 마일스톤으로 태그됩니다.

팀이 Wwise 프로젝트의 미디어 에셋 ID를 관리하는 방법은 팀과 프로젝트의 규모와 범위에 따라 달라집니다.

소규모 프로젝트를 작업하는 소규모 팀의 경우, 각 팀원이 전체 Wwise 프로젝트를 로드한 채로 작업하는 편이 더 관리하기 쉽습니다. 버전 관리 소프트웨어를 사용하여 프로젝트를 관리하면 MediaID가 충돌하지 않도록 할 수 있습니다. 버전 관리 소프트웨어는 확장 배포를 하는 프로젝트의 경우 꼭 필요합니다. 각 배포시에 버전 관리 소프트웨어를 사용하여 프로젝트를 잠그면, 배포된 에셋을 변경하지 않은 상태로 유지할 수 있습니다.

프로젝트의 범위가 넓으며 여러 팀원이 새로운 Work Unit을 동시다발적으로 만들고 작업할 경우, 더 나은 접근 방식이 필요합니다. 새로운 Work Unit을 별도로 개발할 수 있지만, 이 경우 팀원이 전체 Wwise 프로젝트를 로드한 채로 개발해야 하며, 새로운 Work Unit을 프로젝트에 하나씩 도입해야 합니다. 이러한 경우 단일 파일을 사용하여 프로젝트의 MediaID를 관리하는 것이 좋습니다.