[UE][번역] World Partition 2024

 

에픽 게임즈 재팬의 스즈키 타카시님이 발표한 「World Partition 2024」의 번역입니다. 

5.4 이전의 전반적인 World Partition 내용을 다루고 있으니 World Building Guide (https://dev.epicgames.com/community/learning/knowledge-base/r6wl/unreal-engine-world-building-guide) 이전에 보면 좋습니다.

---

안녕하세요, 에픽게임즈 재팬의 스즈키입니다. 오늘은 "World Partition 2024"라는 주제로, 언리얼 엔진의 중요한 기능 중 하나인 World Partition의 지금까지와 앞으로에 대해 소개하고자 합니다. 잘 부탁드립니다.

자, 시작하자마자 오늘 모이신 여러분께 간단한 설문조사를 해보겠습니다. 주제는 "World Partition을 사용해 본 적이 있습니까?"입니다.

선택지는 다음과 같습니다. World Partition은 처음 들어본다. 처음 들어봤지만, 대략적으로 알고는 있다. (이름만 들어봤다.) 이름은 들어봤고 어떤 것인지도 알지만, 아직 서두를 필요는 없다. (아직 사용하지 않아도 괜찮다.)
World Partition을 실제로 사용하고 있고, 대략적으로 어떤 것인지도 알고 있으며, 질문을 받으면 무엇이든 대답할 수 있다.

자, 먼저 1번 "World Partition은 처음 들어본다"라는 분 계십니까? 아, 10명 정도 계시는군요. 감사합니다.
다음으로, 2번 "World Partition은 이름은 알고 있지만, 잘 모르겠다"라는 분? 네, 감사합니다.
3번 "World Partition은 알고 있고 어떤 것인지도 알지만, 아직 서두를 필요는 없다"라는 분 계십니까? 아, 엄청 많으시네요! 알겠습니다.
마지막으로 4번 "World Partition을 사용해 본 적이 있고, 어떤 것인지도 알고 있다"라는 분? 아, 강하시네요. 감사합니다.

아마 오늘은 아직 "지켜봐야 할 녀석"이라고 생각하시는 분들이 많이 계실 것 같습니다. 그런 분들을 위해 설명해 드리고 싶습니다. 그럼 잘 부탁드립니다.

World Partition 정리

오늘의 흐름은 다음과 같습니다.
우선은, World Partition이란 무엇인가라는 부분입니다. 이 부분을 따라가면서 자세한 내용을 전달하고자 합니다. World Partition을 처음 접하는 분들도 꽤 계시므로, 이걸로 대략적인 개념을 파악해 주시면 좋겠습니다.

World Partition은 언리얼 엔진 용어로 말하면, World를 어떻게 만들어갈 것인가 하는 이야기입니다. World Partition이 탄생한 경위를 따라가려면, 가장 단순한 레벨 구성인 단일 Persistent Level에는 몇 가지 문제가 있습니다. 그중 하나가 이 레벨을 편집할 수 있는 사람은 한 명뿐이라는 문제입니다. 동시에 이 파일을 편집하면 변경 사항이 충돌하여 누군가는 눈물을 흘리는 상황이 벌어집니다. 

그래서 Persistent Level의 정보를 몇 가지 범위로 분할한 것을 Sublevel로 분리하고, 각각의 작업 담당자가 Sublevel만 잠궈서 동시에 작업을 수행할 수 있도록 합니다. 이것이 언리얼 엔진의 Sublevel Workflow입니다. 언리얼 엔진 4 시절에는 이걸 사용해서 게임 개발을 하셨을 겁니다.

Sublevel은 동적으로 정보를 디스크에서 메모리로 불러와 표시하거나 삭제할 수 있습니다. 이를 통해 영역을 분할하고 World의 일부분만 메모리에 올려서 심리스한 경험을 만들 수 있습니다. 이 레벨 분할은 프로젝트의 사용에 따라 면밀한 계획하에 수동으로 분할되어 왔습니다.

그리고 2010년 전후였을까요? 광대한 세계를 심리스하게 탐험할 수 있는 오픈 월드에 대한 니즈가 점차 높아졌습니다. 비-오픈 월드 게임에서는 이동할 수 있는 범위에 제한을 두고, 적절하게 구역감을 이동시키는 방법을 사용하는 경우가 많지만, 오픈 월드 게임에서는 이동의 자유도가 현저히 높아지기 쉽습니다.

이것을 기존의 Sublevels Workflow로 만들려고 하면 영역 분할 수가 엄청나게 많아져 수동으로 분할하는 것은 상당한 고통이 됩니다. 언리얼 엔진도 World Composition 등의 메커니즘을 도입하여 대응해 왔지만, 약간 부족한 점도 있었다는 것을 부정할 수 없습니다.

 

그리고 2022년 4월, 언리얼 엔진 5가 릴리스되었습니다. 언리얼 엔진 5에는 World Partition이라는 오픈 월드 제작 지원 기능이 포함되어 있습니다.
World Partition의 큰 특징으로는 월드의 자동 분할 기능, 레벨 동시 편집 기능, 자동 스트리밍을 통한 심리스한 경험을 들 수 있습니다. Sublevels Workflow에 비하면 수동으로 관리해야 하는 부분이 상당히 간소화되어 넓은 World를 구현할 수 있도록 설계되어 있습니다. 

 

World Partition이라고 한마디로 말해도 하나의 큰 메커니즘이 덩그러니 있는 것이 아니라, 내부에는 몇 가지 도구나 기능이 조합된 것입니다.

 

여기서 중요한 항목을 몇 가지 뽑아내서 각각에 대해 개요를 살펴보고자 합니다. 우선은 World Partition입니다. 이것은 지정한 크기로 World를 분할하여 제어할 수 있도록 하는 메커니즘입니다.

에디터 상에서는 분할을 의식하지 않고 단일의 광대한 World로 편집할 수 있지만, 에디터에서의 Play In Editor 시작 시나 패키지 빌드를 작성할 때 Cook 프로세스에서 무수히 많은 스트리밍 가능한 레벨로 자동 분할됩니다. 따라서 런타임에서는 분할된 레벨 패키지가 많이 있는 상태가 됩니다. 이 분할 단위를 "Cell"이라고 부르기도 합니다.

 

다음은 Data Layer입니다. Data Layer는 어떤 의미에서는 페인트 소프트웨어의 레이어 기능과 같은 것으로, World에 존재하는 Actor를 레이어에 할당하여 관리하는 메커니즘입니다. 이 기능을 이용하여 에디터 상에서 일괄적으로 표시/숨김을 전환하거나, 런타임에서 임의의 타이밍에 로드 등의 제어에 사용됩니다.

 

다음으로 HLOD입니다. HLOD는 Hierarchical Level of Detail, 즉 계층 LOD의 약자입니다. 오픈 월드 게임은 매우 멀리까지 레벨을 렌더링하고 멀리 보이는 산이나 벼랑 아래에 펼쳐지는 정글 등으로 심리스하게 이동할 수 있어야 합니다. 이럴 때 하나의 World에 10만을 넘는 수의 Actor가 배치될 가능성이 있습니다. 그것을 그대로 World에 넣어서 표시하려고 하면 매우 성능적으로 힘들어집니다. 따라서 직접 접촉하는 가까운 곳 이외에는 간략화된 메시로 바꿔서 표시함으로써 이 문제를 해결합니다. 이것이 HLOD입니다.

 

다음으로 Level Instance입니다. Level Instance라는 명칭은 기존의 Sublevels Workflow에서도 동적인 레벨의 생성 기능으로서 사용되던 것입니다. 명칭은 기존의 Sublevels Workflow에서의 동적인 레벨의 동적 처리, 동적 로드에 사용되던 것으로, 완전히 이름이 겹쳐서 매우 혼란스럽지만, 실제로는 둘 다 레벨을 다루는 기능이므로 가까운 친척 같은 것입니다. 가능하면 기능에 차이가 있으므로 이름을 구별하고 싶다는 생각이 듭니다. 이번에는 World Partition의 Level Instance에 대한 이야기라는 것을 알아주세요. World Partition의 Level Instance는 주로 World 편집 기능의 효율성을 높이거나 재사용성을 높이기 위한 기능입니다.

World Partition의 중요한 기능 중 하나는 One File Per Actor입니다. World 내의 Actor 각각을 하나의 파일에 대응시켜서 저장하는 메커니즘입니다. 즉, 1 Actor 단위로 파일을 잠그고 편집할 수 있으므로, 여러 개발자가 같은 레벨에 액세스해서 편집할 수 있게 된다는 메커니즘입니다. 설정 항목에 따라서는 External Actors라고 불리기도 하니 알아두시기 바랍니다.

 

최근 엔진에서 특히 힘을 쏟고 있고 강력한 도구가 되어가는 것을 느낄 수 있는 것이 PCG입니다. Blueprint와 같은 비주얼 스크립팅으로 표현된 프로그램에 따라 Actor를 자동으로 배치하는 메커니즘입니다. 요즘 유행하는 프로시저럴 (Procedural)이란 거죠. 넓은 World에 자연스럽게 에셋을 배치하는 것은 힘들지만, PCG와 같은 프로시저럴 기술을 사용함으로써 작업 효율을 크게 높일 수 있습니다. 저희 타이틀에서도 적극적으로 활용하고 있습니다. 작년 말에 릴리스된 레고 포트나이트 (포트나이트 내의 한 게임)에서는 PCG를 대대적으로 사용하여 만들었습니다. 이것이 없었다면 완성하지 못했을 것이라고 생각될 정도입니다. 에픽게임즈 재팬에서도 프로시저럴 콘텐츠 생성에 관한 슬라이드를 공개하고 있으니, 이 기회에 학습하시고 고효율 워크플로우를 구현하시기 바랍니다.

 

자, World Partition의 개요를 대략적으로 설명했으니, 각각의 구체적인 요소를 살펴보겠습니다. 

우선은 World Partition의 분할 기능입니다. World Partition의 기능을 이용하려면 World Partition 대응 레벨을 만드는 것이 첫 번째 단계입니다. 만드는 방법은 주로 두 가지가 있습니다. 템플릿에서 작성하는 방법과 기존의 비-World Partition 레벨을 Commandlet으로 변환하는 방법입니다. 체크 박스의 On/Off처럼 간단하게 전환할 수는 없습니다. 게다가, World Partition으로 변환한 레벨을 되돌릴 수도 없으니 주의가 필요합니다. 

 

World Partition 대응 레벨인지 간단하게 확인하려면 미니맵이 표시되는 World Partition Editor Window를 확인하는 것이 간단합니다. 내부적으로는 World, 즉 UWorld가 World Partition Object를 가지고 있는지 판정합니다. 이렇게 만들어진 레벨은 기본적으로 2D 그리드로 분할됩니다.

 

미리보기 표시를 하면 교토 거리처럼 깔끔하게 분할선이 표시되어 마치 메시가 슬라이스되는 듯한 분위기를 받지만, 분할은 Actor 단위로 이루어집니다. 분할된 Cell은 화면 중의 흰색 원처럼 거리 기반으로 스트리밍됩니다.

 

원형 렌더링을 잘라서 읽어들이는 거리를 짧게 해서, 시티 샘플 (매트릭스 어웨이크 데모에 사용된 거리)을 날아다녀보면 이동에 따라 Cell이 자동으로 스트리밍되고 있다는 것을 알 수 있습니다.

 

스트리밍 분할 설정은 World Settings에 있습니다. Cell Size나 로딩 범위, 읽어들이는 우선순위 등을 설정할 수 있습니다. 그리드가 배열형으로 되어 있다는 것을 눈치채신 분들도 많을 텐데, 여러 그리드를 정의할 수도 있습니다. 이것에 대해서는 나중에 설명하겠습니다.

 

기본적으로 플레이어를 중심으로 한 자동 로드가 이루어지지만, 예를 들어 Fast Travel (오픈 월드 게임이라면 거의 반드시 들어 있을 거라고 생각하지만) 등으로 원격지로 직접 이동하거나 하는 경우에는 이동할 곳을 미리 읽어들여야 로딩 화면을 거치는 것 같은 상황을 피할 수 있습니다.

 

불필요한 로딩 시간 없이 부드러운 동작을 가능하게 하려면 멀리 떨어진 Cell을 읽어들이고 싶을 때 World Partition Streaming Source를 사용합니다. 이 기능을 가진 Actor를 World에 추가하면 그 주변의 Cell이 읽어들여집니다. 화면의 디버그 표시에 두 개의 원이 표시되어 있는 것이 보이시나요? 가운데 그리드에 주황색으로 보이는 것이 있을 텐데, 하나는 플레이어이고, 하나는 World Partition Streaming Source입니다.

 

Streaming Source는 Component이므로 Actor에 넣어 사용합니다. Component에는 읽어들일 대상을 필터링하는 파라미터나 읽어들이는 범위를 지정하는 Shape 등의 설정이 있습니다. 읽어들일 대상 Cell이 늘어난다는 것은 그만큼 메모리 소비량이 늘어난다는 의미이므로, Fast Travel 연출에는 최소한의 이동할 곳 근처만 읽어들이는 컨트롤을 하는 것이 좋습니다. 이렇게 함으로써 두 개의 영역을 읽어들이는 메모리 소비량을 줄일 수 있다고 생각합니다. 이처럼 다양한 궁리를 할 수 있게 되어 있으니 꼭 활용해 보시기 바랍니다.

 

기본적으로 Player Controller를 중심으로 로드된다고 말씀드렸습니다만, 이는 Player Controller 자체도 Streaming Source로 취급되기 때문입니다. Player Controller에도 읽어들이는 범위의 Shape 등의 프로퍼티가 있어 조정할 수 있게 되어 있습니다. 예를 들어 동적으로 로딩 범위를 전환하거나, 플레이어가 보고 있는 방향은 멀리까지 읽어들이고 싶지만 뒤쪽은 가까운 곳만 읽어들이고 싶다는 설정을 Shape 조합으로 만들 수 있습니다.

 

최근 스토리지는 매우 빨라졌지만, 그렇다고 순식간에 로딩이 완료되는 것은 아닙니다. 읽어들여야 할 Cell이 모두 읽어들여졌는지 여부는, 이러한 Blueprint의 함수 (IsStreamingCompleted 등)를 사용하여 확인하는 것이 좋습니다.

 

그리드와 프로모션

다음으로 그리드와 Promotion에 대해 설명하고 싶습니다. 이것들은 표면에 직접적으로 드러나지는 않지만, 의도하지 않은 동작을 일으킬 수 있으므로 주의가 필요한 부분입니다. 엔진의 버전업에 따라 문제가 경감되고 있습니다만, 프로젝트에 따라서는 버전업을 하지 않고 5.2에 머무르는 경우도 있다고 생각하므로 설명드리겠습니다.

화면의 흰색 선이 설정된 Cell Size로 분할된 그리드라고 생각해 주세요. 예시로 이 원을 레벨에 배치한다고 칩시다. 이처럼 Actor가 분할선에 걸치지 않으면 지정한 Cell 안에 순순히 배치됩니다.

 

이것을 조금 변경해서 분할선 위에 놓으면 어떻게 될까요? 설정이나 Actor의 크기에 따라서도 영향을 받지만, 어느 Cell도 적절하지 않다고 판단된 경우에는 Promotion이라는 동작이 수행됩니다.

 

Promotion은 그림과 같이 기본 Cell Size보다 한 단계 큰 (대략적인) 그리드로 격상된다는 것입니다. 이러한 그리드 단계를 그리드 레벨이라고 합니다. 그리드 레벨이 다르면 스트리밍 Cell도 다른 것이 됩니다. Actor가 예상 외의 그리드 레벨에 할당되면 같은 메시를 똑같이 배치했더라도 일부 메시만 스트림 아웃되지 않거나, 결국에는 모든 Actor가 항상 읽어들여진 상태 (Persistent 상태)가 되어버립니다.

 

Actor가 어느 Cell에 할당되었는지는 HLOD를 표시해 보거나, Play In Editor를 시작하거나, Cook을 할 때마다 자동으로 출력되는 로그를 확인해 주세요. 오른쪽 위의 아웃라이너에 HLOD 이름이 나와 있는데, 이쪽에 있네요. 그리드에 할당되었는지는 L0, L1 같은 숫자가 그리드 레벨을 나타냅니다. 이런 것을 확인해 주세요.

 

이러한 분할 거동을 제어하려면 언리얼 엔진 5.2까지는 콘솔 변수를 INI 파일에 지정해서 설정하는 형태였습니다. 화면 오른쪽에 있는 설정이 저희가 추천하는 설정입니다. 이 설정을 해두면 Promotion을 상당히 줄일 수 있지만, 기본 설정에서는 앞에서 설명한 것처럼 어느 Cell에도 들어가지 않는 문제가 발생하기 쉽습니다. Always Loaded 문제라고도 합니다. 이런 일이 발생하면 World Partition을 믿을 수 없게 되어 버리는 불행한 부작용이 생겨버립니다. 슬픈 일이므로 5.2 이전 버전을 사용하시는 경우에는 꼭 한 번 설정을 확인해 주세요.

언리얼 엔진 5.3 이후라면 2D 분할 설정을 World Settings 안에서 설정 가능하게 되어 더욱 쉽게 조정할 수 있게 되었습니다. 거동이 이상하다고 생각되면 여기를 확인해 주세요.

 

언리얼 엔진 5.4, 앞으로 봄에 릴리스될 언리얼 엔진 5에서는 지금까지 설명한 2D 그리드 분할뿐만 아니라 3D 그리드, 높이 방향으로도 분할되어 Cell을 만드는 3D 분할 기능이 제공됩니다. 게다가 프로젝트에 맞는 보다 커스터마이즈된 분할 기능을 구현하는 것도 가능하게 됩니다. 언리얼 엔진 5.3까지는 분할 처리에 손을 대려면 엔진에 직접 코드를 수정해야 했지만, 바람직하지 않은 커스터마이징은 이제 안녕입니다.

 

World Partition으로 작업할 때 중요한 기능 중 하나가 미니맵이 있는 World Partition Editor Window입니다. 여기에서 선택 범위를 로드/언로드하거나 맵을 더블 클릭하여 카메라를 이동할 수 있습니다. 

 

미니맵에서 선택한 범위는 Convert Selection to Actors라는 명령을 통해 Actor화할 수 있습니다. 특정 로드 대상 영역을 저장해 두거나, 미니맵 상에서 가시화되는 북마크로 사용할 수 있습니다. Actor로서 프로젝트 내에 저장되므로 다른 개발자와 공유할 수 있다는 장점도 있습니다. "여기는 시가지입니다.", "여기는 유적입니다." 와 같은 것을 Actor로서 저장해 둘 수 있습니다.

 

World Partition 고유의 기능은 아니지만, 미니맵의 컨텍스트 메뉴에서 Bug It 명령을 출력할 수도 있습니다. 클릭하면 클립보드에 메모로 입력할 수 있는 문자열이 들어오므로, 텍스트 파일이나 Wiki (각 회사에서 사용하고 있다고 생각합니다만) 등에 이 Bug It 명령을 나열해 두면 "지금 작업 중인 곳은 여기입니다.", "여기에서 버그가 발생했습니다." 와 같은 것을 Wiki 등에 정리할 수 있습니다. 버그 데이터베이스에 넣는 것도 좋을 것 같습니다. 그 장소로 이동하고 싶다면 콘솔 명령 상자에 복사해 넣으면 그곳으로 직접 이동할 수 있습니다. World Partition을 이용하는 사람에게는 특히 주변도 자동으로 로드되므로 비교적 편리하게 사용할 수 있습니다. 참고로, Play In Editor 실행 시 Bug It 명령을 사용하면 해당 Bug It 명령과 주변 보고서, 스크린샷 등도 포함해서 Save 폴더 아래에 자동으로 저장됩니다. Play In Editor를 실행하다가 갑자기 버그가 발생했다면 콘솔 명령을 열어서 Bug It 명령을 입력해 주시면 스크린샷을 포함해서 저장되니 꼭 활용해 주시기 바랍니다.

 

미니맵에 관한 팁으로서 World Partition으로 관리해야 할 Actor의 존재 범위가 극단적으로 커지면 미니맵의 활용성이 극단적으로 나빠지는 경우가 있습니다. 관리 화면 Window 안에 그 범위가 표시되어 있습니다. 언리얼 엔진 5.4에서는 이 아래쪽에 표시되지만, 5.3에서는 왼쪽 위에 표시되었던 것 같습니다. 여기에 지금 32km라고 쓰여 있나요? 32 x 32 x 32로 되어 있네요. 엄청나게 넓은 범위로 되어 있다면, 실제로 Actor가 놓여 있는 것은 중심의 1% 정도밖에 안 된다는 일이 벌어지기 쉽습니다. 이 상태로 World 미니맵 전체를 표시시키면 앞서 설명한 Region을 선택하는 것이 매우 어려워지므로 사용자 편의성이 상당히 떨어집니다.

 

게다가 이처럼 극단적으로 넓은 상태로 만들면 미니맵 빌드를 수행하여 갱신하는데, 그게 전혀 끝나지 않게 됩니다. Actor가 없는 상태인데도 몇십 분이나 걸리기도 합니다. 그 원인으로는 천구나 볼륨 등 World Scale의 크기를 가진 Actor가 World Partition의 분할 대상이 되어 있다는 경우가 많습니다. 이러한 Actor는 상세 패널 안의 Is Spatially Loaded 체크를 해제하고, World Partition 관리에서 제외해 줌으로써 미니맵의 범위가 정상화됩니다. 다른 사례로는 예를 들어 던전이나 이벤트, 전투 구역 같은 것을 맵 안의 떨어진 위치에 만들어놓고 이동해서 처리하는 것이 게임 개발에서 흔히 있는 일이라고 생각합니다. 이러한 것을 떨어진 위치에 만들어놓으면 실제로 World의 대규모화가 일어나서 미니맵의 사용자 편의성이 떨어지는 경우가 있으니 주의해서 사용해 주시기 바랍니다.

 

다중 그리드

다음 화제는 Sub World Partition입니다. World의 분할 설정에서 그리드가 배열로 되어 있었습니다만, 이것을 사용하여 보다 세심한 처리를 할 수 있습니다.

 

공식 문서에 보면 그리드를 2개 이상 사용하면 성능에 심각한 나쁜 영향을 줄 수 있다고 엄청나게 협박해 오는데, 그리드를 늘린 순간에 갑자기 성능이 극단적으로 떨어진다거나 하는 일은 없습니다. 실제로 내부적으로는 Cell의 수가 늘어나므로 그만큼의 오버헤드는 있지만, 그 편리성과 실현하고 싶은 것의 균형을 따져보고 사용할 가치가 있다고 생각되면 사용해 주시기 바랍니다.

 

 

여러 그리드로 실현할 수 있는 것 중 하나는 특정 Actor 그룹만 빠르게 스트림 아웃시키거나, 시가지처럼 대부분의 영역이 밀도가 낮은 사바나 같은 상태인데 일부 지역에 시가지가 있는 맵을 상상해 주시면 좋겠습니다. 시가지 같은 고밀도 지역에는 보다 세밀한 그리드를 할당하고, 광대한 일반 필드 지역에는 넓은 셀을 할당하는 것 같은 사용법을 생각할 수 있습니다. 어느 그리드에 속하는지는 각 Actor의 Runtime Grid 프로퍼티에 이름을 설정함으로써 수행할 수 있습니다. 나중에 설명할 Level Instance를 사용하면 그 안의 Actor에 대해 일괄적으로 설정을 적용할 수 있으므로 추천합니다.

 

Level Streaming Persistence Plugin

다음에 소개하는 것은 Level Streaming Persistence Plugin입니다. 이 플러그인은 스트림 아웃된 Actor의 프로퍼티를 이 플러그인이 저장해 두었다가 다시 스트림 인했을 때 그 값을 복원하는 기능을 가지고 있습니다. 이것을 사용하지 않으면 스트림 아웃하면 Actor가 삭제되어 버리므로, 런타임에 뭔가 프로퍼티를 쓴 부분이 전부 삭제되고 다음에 스트림 인했을 때는 완전히 처음 상태의 Actor가 생성되는 것이 기본 동작입니다.

 

동작을 보면 10, 11, 12로 스트림 아웃했다가 다시 가까워지면 13부터 시작해 주는 기능입니다. 이것은 Persistent Property를 설정해두는 것인데, 그 외에도 임의의 프로퍼티를 수동으로 프로그램에서 덮어쓰거나 저장 데이터를 Persistent Property 파일에 출력하는 것도 가능합니다. 구현은 LevelStreamingPersistenceManager에 있으므로, 한 번 이 플러그인의 구조를 읽어보시고 필요하면 이것을 기반으로 커스터마이징한 것을 만드는 것을 개인적으로 추천합니다.

 

INI 파일 설정은 다음과 같습니다. 슬라이드를 공개한 후에 봐주시면 좋겠습니다.

 

One File Per Actor (OFPA)

World Partition의 마지막 주제는 One File Per Actor의 해시명에 대해서입니다. 앞에서도 잠깐 언급했듯이 이 기능은 1 Actor에 1 파일을 할당하는 기능입니다. Actor의 수가 수십만 개에 달할 가능성이 있는데, 그것들을 하나의 폴더에 몽땅 집어넣을 수는 없습니다. 언리얼 엔진은 Actor를 알 수 없는 연속 문자열인 이름으로 변환하여 콘텐츠 폴더 아래의 ExternalActors 폴더 아래에 분리하여 저장합니다. 이 폴더는 에디터 내의 Content Browser에서 보이지 않게 되어 있어 World Partition을 처음 사용하기 시작했을 때 몹시 당황하기 쉬운 부분입니다. 에디터의 버그나 크래시, 적절하지 않은 소스 컨트롤 작업에 의해 이러한 파일에 문제가 생기는 경우가 드물게 있습니다만, 이럴 때 이 해시명만 보고는 어느 Actor에 문제가 생겼는지 잘 모르는 경우가 있습니다.

 

 

One File Per Actor의 해시명으로부터 Actor 이름을 찾으려면 아웃라이너의 필터 창에 해시명을 붙여넣어 Package Short Name 컬럼에 히트시킬 수 있습니다. 이렇게 하면 해시와 Actor의 대응 관계를 확인할 수 있습니다.

 

그 외에는 소스 컨트롤의 Change List 안에 정보가 있다면 View Change 대화 상자를 열어서 변경한 파일 목록을 확인하고, 그 안에서도 마우스 커서를 올리면 경로를 확인하는 것이 가능합니다. 그 외에는 World Partition의 분할 로그가 있습니다. 앞에서 설명한 분할 로그 안에도 이 해시명이 나와 있으므로 약간 힘든 작업이긴 하지만 이러한 정보를 잘 활용하여 대처해 주시면 좋겠습니다.

 

참고로 이 슬라이드를 쓰면서 View Change라는 번역이 잘못되었다는 것을 솔직히 깨달았습니다. 정확하게는 Change List를 확인하는 것이겠죠. View Change 대화 상자의 기능 중 하나로서 Actor를 더블 클릭하면 해당 Actor의 위치로 레벨 Viewport를 이동시킬 수 있으므로 "이 파일을 건드린 적이 없는데?"라는 생각이 들 때는 해당 Actor를 더블 클릭하여 그 부분으로 이동하여 정말로 건드렸는지 확인하기 쉬워집니다. 활용해 주세요. World Partition의 셀에 대한 섹션은 여기까지입니다. 

 

Data Layer

다음으로 Data Layer에 대해 소개하겠습니다. Data Layer는 레벨 스트리밍에 대한 필터로서 기능하는 메커니즘입니다. 기존의 Sublevels Workflow에서 Sublevel과 가까운 이미지를 가지고 있다고 생각하시면 좋습니다.

 

이런 식으로 Actor를 할당해서 표시/숨김을 컨트롤할 수 있습니다. 이런 식으로, 이 빨간색 삼각형이 Actor라고 생각해 주세요. 너무 추상적인가요. 특정한 조건이 되면 빨간색 Actor가 나오고, 특정한 조건이 되면 사라지는 것 같은 것을 컨트롤할 수 있습니다.

 

Data Layer에는 크게 두 종류가 있습니다. 하나는 Runtime Data Layer이고, 또 하나는 Editor Data Layer입니다. 전자가 런타임에서의 수동 로드 관리에 사용하는 반면, 후자는 에디터에서의 편집 지원을 수행합니다. 지금 읽으면서 생각했는데, 런타임 쪽에서도 에디터 상에서 On/Off 할 수 있으므로, 어떤 의미에서는 Runtime Data Layer는 Editor Data Layer를 겸하고 있다고 말할 수도 있습니다. Editor Data Layer는 런타임에서는 없었던 일이 되므로 담당 섹션 작업과 관계없는 Actor는 필터링하는 등의 용도로 사용할 수 있습니다. 불필요한 Actor를 숨겨놓음으로써 에디터의 쾌적성을 유지할 수 있다고 생각합니다. Actor 상세 정보를 보면 알 수 있지만, Data Layer는 하나의 Actor에 대해 여러 개 할당할 수 있습니다.

 

여러 개의 Data Layer가 할당된 상태에서 Data Layer를 활성화하면 그중 하나가 활성화되면 Actor가 World에 나타납니다. 즉, OR 연산으로 동작합니다. 이해하기 어려울 수도 있는데, 색 조합으로 Actor가 나타납니다. 빨간색을 활성화하면 빨간색 계열 Actor가 나오고, 파란색을 활성화하면 파란색 계열 Actor가 나오는 것 같은 느낌입니다. 이해하기 어려울 수도 있지만, 이렇게 OR 연산을 하고 있다고 기억해 주시면 좋겠습니다.

 

언리얼 엔진 5.4부터는 이 연산이 확장되어, World 단위에서는 전체에 영향을 주지만 AND 연산, 즉 모든 Data Layers가 할당된 Data Layers가 모두 활성화되어야 표시되는 모드도 구현되었습니다. 더욱 복잡한 AND/OR을 조합한 조건에 관해서는 향후 과제가 될 것입니다. 이렇게 AND와 OR을 단순하게 전환하는 형태가 되어 있습니다만, World 전체에 영향을 주므로 쉽게 바꿀 수 있는 것은 아닙니다. 프로젝트 전체에서 합의를 거친 후에 전환하도록 해 주세요.

 

Level Instance

다음 섹션은 Level Instance입니다. Level Instance는 레벨을 통째로 하나의 Actor로 만들어 다른 World에 배치할 수 있는 기능입니다. 예를 들어 건물 단위로 하나의 Level Instance를 만들거나, 특정 영역을 Level Instance로 묶는 것 같은 사용법을 사용합니다. 물론 같은 레벨을 여러 개 배치할 수 있으므로 프리팹 (Prefab) 같은 복사/붙여넣기 같은 사용법도 가능합니다. 그 외에는 스냅샷처럼 작업 상태를 자신의 개발자 폴더 아래에 저장해 두는 것도 가능할 거라고 생각합니다.

 

배치된 Level Instance는 레벨 위에서 직접 편집할 수 있습니다. 이 때 한 단계를 거치는 작업이 필요하므로, 실수로 에셋을 움직여 버리는 사고를 줄이는 데도 사용할 수 있다고 생각합니다. 게다가 Level Instance로서 배치한 후에 분해해서 Persistent Level에 있는 Actor에 일일이 설정하는 것이 힘드므로, 묶어서 일괄적으로 설정할 때 Level Instance가 활용될 수 있습니다.

 

 

Level Instance 만드는 방법입니다. 이 낡은 사당을 Level Instance로 묶어보겠습니다. 먼저 불필요한 것을 숨긴 후 Actor를 모두 선택하고 오른쪽 클릭 메뉴의 컨텍스트 메뉴에서 레벨, Level Instance를 선택합니다. 레벨 이름을 물어보므로 적절하게 이름을 지으면 Level Instance가 만들어지고 Level Instance로 대체됩니다. 매우 간단한 조작으로 Level Instance를 만들 수 있습니다.

 

Level Instance 배치는 레벨 에셋을 콘텐츠 브라우저에서 드래그 앤 드롭하는 것이 간단합니다. 일반적인 Actor로 취급되므로 뷰포트에서 간단하게 복사를 수행할 수 있습니다. 배치한 후에는 Ctrl + E를 누르면 대상 Level Instance 이외가 흐릿하게 변하고 Level Instance 편집 모드로 들어갑니다. 이 안에서 조작을 하고 커밋을 하면 같은 Level Instance, 복사한 Level Instance 모두에 변경 사항이 전파됩니다. 화면에서는 사당 문을 여닫고 있는데, 사당 문을 여닫는 것이 모든 레벨에 커밋한 순간에 모든 Level Instance에 적용되고 있는 것을 알 수 있습니다.

 

Level Instance를 만들 때 흔히 있는 것이 모든 에셋을 선택했다고 생각했는데, 선택이 다 안 되어 있어서 Persistent Level에 Actor가 남아 버리는 사고입니다. 사실 Level Instance 밖에 있는 Actor를 Level Instance에 추가하는 방법이 있습니다. 화면에서는 사당 문 앞에 배치되어 있는 돌길과 돌등이 보이는데, 이것을 Level Instance 안에 포함시키겠습니다. Level Instance 편집 모드에 들어간 후 Viewport의 오른쪽 아래에 있는 Actor Editor Context Window가 보이시나요? 이 왼쪽에 나와 있는 Window를 보고 "이게 뭐지?"라고 생각할 수도 있는데, Actor Context Window라고 합니다. 이것을 조작해서 일단 Level Instance 편집 모드이지만 Persistent Level로 전환합니다. 이 상태에서 Level Instance 밖에 있는 Actor를 선택하고 선택한 부분에 대해 오른쪽 클릭한 후에 레벨의 Move Selection To를 선택하면 Actor를 Level Instance 안에 복사할 수 있습니다. 지금 추가한 곳이죠. 추가하고 저장하면 양쪽의 Actor에도 변경 사항이 전파되고 있다는 것을 알 수 있습니다.

 

 

Level Instance에는 거의 같은 기능을 가진 Packed Level Actor라는 것도 있습니다. 여기에 차이를 표로 나타내었습니다. 큰 차이점은 Packed Level Actor는 가져올 수 있는 Actor 종류에 제한이 있는 대신, 자동으로 Level Instance Static Mesh 등으로 바꾸어 Component 수를 줄이는 최적화 효과를 얻을 수 있다는 점입니다. 인라인 편집 등의 기능은 둘 다 그대로 사용할 수 있습니다. 어느 것을 사용해야 할지 자주 문의를 받는데, 모듈 구조로 레벨을 구성하고 있고 Actor 수가 매우 많아졌다면 Packed Level Actor를 이용하면 최적화 효과를 얻을 수 있으므로 추천합니다.

 

Level Instance 안에 Packed Level Actor를 넣어 계층 구조로 만들거나 Level Instance 안에 Level Instance를 넣는 것도 가능하므로 이러한 계층 구조를 만들어서 Packed Level Actor에 넣고 Packed Level Actor Level Instance 안에 Packed Level Actor를 넣는 등의 번거로운 구성을 검토해 보는 것도 좋습니다. Packed Level Actor 안의 Component가 ISM인지 HISM인지는 메시가 동일한지 여부에 따라 달라집니다.

 

Level Instance에 대해 언리얼 엔진 5.3에서 추가된 기능이 Level Instance Actor Filter입니다. Level Instance 안의 Actor를 필터링해서 베리에이션을 만드는 기능으로 Data Layers를 사용하여 필터를 조작합니다.

 

활성화하려면 환경 설정에서 Enable World Partition Actor Filter에 체크를 합니다. 게다가 에디터 Data Layer 안에 추가되어 있는 Supports Actor Filters에 체크를 합니다.

이렇게 해 나가면서 몇 가지 Data Layer를 정의하고 Level Instance 안의 Actor에 할당합니다. 이 예에서는 식탁 테이블 위에 놓인 과일에는 Fruits Data Layer, 빵에는 Bread Data Layer, 테이블 크로스에는 Tablecloth Data Layer를 할당해 놓았습니다.

 

Level Instance를 배치하면 Level Instance 안, Level Instance의 상세 패널 안에 Filter라는 항목이 있어 앞에서 할당한 Data Layers가 나열되어 있습니다. 배치한 각각의 Level Instance에 조합을 적용합니다. 앞쪽 테이블에는 과일이 없는 베리에이션, 오른쪽 테이블에는 빵이 없는 베리에이션, 왼쪽 테이블에는 테이블 크로스와 과일이 없는 베리에이션을 적용하고 있습니다. 예를 들어 이 기능을 사용하여 건물의 지붕 색깔을 바꾸거나 문이 열려 있는 버전과 닫혀 있는 버전을 전환하거나 하는 것도 가능할 거라고 생각합니다.

 

Level Instance의 기능 중 하나로 Level Streaming Mode라는 것이 있습니다. 이 모드를 설정해 놓으면 Cook 시에 Level Instance의 내용을 Persistent Level에 분리해 줍니다. World Partition 기능을 무효화하고 Level 그대로 다룰 수 있도록 합니다. Level 스트리밍, 기존의 Level Instance가 아닌... 죄송합니다. Level Instance, 동적인 레벨, Level Instance 스트리밍과 같은 기능을 구현할 수 있게 됩니다. 이것에 관해서는 기사화되어 있으므로 여기를 참고해 주시기 바랍니다.

 

이 스트리밍 모드에도 갱신이 있어 언리얼 엔진 5.4부터는 프로퍼티로서 편집 가능하게 되었습니다. 언리얼 엔진 5.3까지는 C++로 확장해야 했으므로 기쁜 변경이라고 생각합니다.

 

 

지금까지 설명해 온 것처럼 Level Instance는 편집 효율을 높여주지만, 종종 질문받는 내용 중에 Level Instance 안의 Actor를 참조해서 Persistent Level에서 사용하고 싶다는 것이 있습니다.

 

 

언리얼 엔진 5.4에서는 이 Level Instance 안의 Actor를 참조 대상으로 지정할 수 있는 기능, Editor Path가 추가되었습니다. INI 파일에 설정을 추가함으로써 활성화할 수 있습니다. 앞서와 마찬가지로 Level Instance 안의 Actor가 참조 대상의 드롭다운을 열었을 때 Level Instance 안의 Actor를 지정할 수 있게 된 것을 확인할 수 있습니다.

 

향후 예정으로서는 Level Instance에 대해 일부 파라미터를 오버라이드할 수 있도록 하는 메커니즘을 검토하고 있습니다. 아직 모습도 형태도 없으므로 어떤 것인지 잘 모르겠지만, 이름 그대로 실현된다면 Level Instance를 상당히 다루기 쉬워질 거라고 생각합니다.

 

HLOD

마지막으로 HLOD 섹션에 대해 배우겠습니다. 지금까지 슬라이드에도 여러 번 등장했습니다만 HLOD는 원형 렌더링용의 심플한 메시입니다. World Partition에서는 이것을 자동으로 작성하고 런타임에서 적절하게 전환하는 구조를 가지고 있습니다. 화면에 있는 디버그용의 표시 모드는 HLODColoration이라는 모드를 사용하고 있습니다.

 

HLOD는 World Partition Cell마다 작성되어 Static Mesh를 가진 HLOD Actor로서 레벨 안에 배치됩니다. 이것을 작성하기 위해서는 에디터에서 빌드 HLOD를 실행하거나 Commandlet으로 변환 처리를 합니다.

 

HLOD 설정은 HLOD Layer 에셋을 통해서 실행됩니다. HLOD Layer는 어떤 단순화를 할지를 나타내는 레이어 타입과 상주할지 스트리밍할지를 결정하는 Is Spatially Loaded가 있습니다.
Is Spatially Loaded로 해서 스트리밍을 실행하는 경우는 더욱 로딩 범위 등의 설정을 추가로 실행할 수 있게 됩니다.

 

레이어 타입은 이 4 종류와 커스텀 설정을 더해서 총 5개가 준비되어 있습니다. 커스텀에 대해서는 흥미가 있는 분은 City 샘플에서 이용되고 있으므로 샘플을 봐주시면 좋겠습니다. 이번에는 디폴트의 4개의 설정을 살펴보겠습니다.

 

우선 인스턴스입니다. 인스턴스란 셀내의 Static Mesh를 모아서 인스턴스 Static Mesh화합니다. 추가로 메시를 만들 필요는 없기 때문에 메모리의 부하가 적고 빌드 시간이 매우 빠른 것이 특징입니다. 원래부터 충분히 ISM화되어 있거나 유니크한 메시가 거의 없고 모듈화되어 있지 않아서 대부분이 유니크하거나 하면 최적화 효과를 그다지 얻을 수 없다는 점에 주의해 주시기 바랍니다.

 

다음은 Merged입니다. 셀 내의 메시를 모아서 하나의 거대한 Static Mesh를 작성합니다. 이 때 머티리얼 합성이 이루어지므로 머티리얼 표현에 영향을 줄 수 있다는 점에 주의해 주시기 바랍니다.

 

세 번째는 Simplified입니다. 머지드와 마찬가지로 메시를 모은 후 더욱 리덕션 (Reduction)을 수행합니다. 엄청나게 거대한 메시의 리덕션이 수행되므로 빌드 시간이 상당히 오래 걸립니다.

 

네 번째는 Approximate입니다. 모은 메시를 복셀화한 후 근사 메시를 얻습니다. 설정에 따르지만 실루엣이 무너져서 약간 흐릿해지기 때문에 꽤 멀리 떨어져 있는 것을 전제로 합니다.

 

표로만 봐서는 글로만 설명해서는 잘 모를 거라고 생각하므로 실제 출력을 살펴보겠습니다.

 

먼저 인스턴스입니다. 인스턴스란 왼쪽이 원본이고 오른쪽이 HLOD입니다. 인스턴스는 그대로 메시를 사용하므로 외형상의 차이는 거의 없습니다.

 

Merged는 메시 자체는 인스턴스와 같으므로 실루엣에는 변화가 없지만 머티리얼 합성에 의해 색감이 변화해 버리는 부분이 있습니다. 이번 예에서는 꽤 녹색이 되어 버렸기 때문에 좀 심하다는 생각도 들지만 메시에 따라서는 색감이 바뀐다고 생각해 주시면 좋을 것 같습니다.

 

다음은 Simplified입니다. 리덕션이 이루어지기 때문에 정점 수가 대폭 삭감되어 있습니다. 가느다란 파이프 같은 것이나 나무 같은 엉성한 면으로 되어 있다면 실루엣이 크게 무너지는 일이 있습니다. 덧붙여서 삭감률은 고정으로 되어 있으며 만약 이것을 조정하고 싶다면 커스텀 레이어 타입을 이용하여 구현해야 합니다.

 

이것이 Approximate입니다. 이 설정은 복셀 해상도를 지정할 수 있기 때문에 오른쪽으로 갈수록 큰 설정을 적용하고 있습니다. 원래의 정점 좌표, 정점 밀도가 불균등하거나 가느다란 부분에서는, 폴리곤 밀도가 낮은 부분에서는 구멍이 뚫려 있거나 해서 윤곽이 크게 무너지는 것을 확인할 수 있습니다. 또 전체적으로 약간 부풀어 오른 인상을 받습니다. 실제로 부풀어 올랐네요. 수백 미터 이상 떨어져 있는 셀의 표시에 대략적인 윤곽만 남아 있다면 선택지에 올릴 수 있다고 생각합니다.

 

HLOD 설정은 HLOD Layer를 연결함으로써 계층 HLOD를 구성할 수 있습니다. 약간 떨어진 곳에는 인스턴싱의 HLOD를 적용하고, 더욱 떨어진 곳에는 Simplified의 HLOD Layer를 적용하는 설정을 활용할 수 있습니다.

 

루멘 (Lumen)의 파 필드 (Far Field) 기능을 사용할 때 HLOD 1, 즉 두 번째 HLOD 이후를 적용하는 것은 두 번째 HLOD를 준비하지 않으면 안 된다는 제한이 있기 때문에 이 기능을 사용하는 경우에는 계층 HLOD 설정이 필수입니다.

 

HLOD는 디폴트로 월드 세팅에 설정된 HLOD Layer가 적용되지만 Actor마다 독자적인 HLOD를 설정하는 것도 가능합니다. 그런 경우에는 셀이 따로 분할되게 됩니다. 그 외에도 HLOD를 무효화하는 설정이나 특정 레벨 이후에는 포함시키지 않는다는 설정도 가능합니다.

 

그리고 HLOD에서 자주 문제가 되는 것이 HLOD의 빌드 시 소비 메모리와 처리 시간입니다. 아무렇지도 않게 HLOD를 빌드해 보면 100GB 이상의 메모리를 사용하여 아웃 오브 메모리 (Out of Memory)로 OS 자체가 죽거나 언리얼 엔진이 죽는 일이 자주 일어납니다. 몇 번을 해도 끝나지 않는다는 일이 자주 일어납니다.

 

HLOD 작성 시 메모리 소비의 대부분은 셀 내의 메시를 모을 때의 엄청나게 거대한 정점 버퍼입니다. 경우에 따라서는 100만 정점, 200만 정점, 더 엄청난 수치가 되기도 합니다. 따라서 셀 사이즈가 커지면 모아야 할 정점 수가 늘어나기 때문에 메모리를 배로 많이 사용하게 됩니다. 만약 HLOD 작성 시 어떻게 해도 크래시가 발생한다면 이 셀 사이즈를 삭감해 줌으로써 소비량을 크게 줄일 수 있습니다. 물론 처리, HLOD에 투입되는 정점 수가 줄어들면 작성 시간도 크게 줄일 수 있으므로 HLOD는 사실 메시의 LOD의 가장 마지막, 7, 8 번째라면 폴백 (Fallback) 메시가 HLOD에 투입되기 때문에 그러한 것을 미리 삭감하거나 숫자를 줄이거나 커스텀의 LOD를 배치해 둠으로써 HLOD의 사용 메모리와 작성 시간을 미리 삭감할 수도 있습니다. 대량으로 배치하는 나무 같은 것에 관해서는 미리 커스텀 LOD를 적용하거나 해두면 HLOD의 처리 시간을 크게 삭감하여 여러분의 소중한 시간을 절약할 수 있습니다.

 

자, 이렇게 고생해서 만든 HLOD입니다만 5.3까지는 에디터의 뷰포트 상에서 확인하려면 수고스러움이 따릅니다. 추천하는 방법으로는 미니맵에서 모든 Region을 언로드하고 아웃라이너에서 HLOD Actor를 핀으로 고정하는 것입니다. 이렇게 하면 일단 HLOD를 확인할 수 있습니다. 교체 등은 할 수 없으므로 편리하지는 않지만 적어도 뷰포트 상에 나열해 볼 수 있습니다.

 

그리고 5.4부터는 대망의 레벨 뷰포트 상에서의 HLOD 확인 기능이 구현되었습니다. 로드하고 있는 Region이 없는 경우에는 처음부터 HLOD가 표시된 상태가 됩니다. HLOD를 표시할지 여부는 뷰포트의 Show 메뉴 안에서 설정 가능합니다. 이것이 최고로 편리하므로 World Partition을 이용하고 있는 분은 꼭 언리얼 엔진 5.4를 이용해 주시기 바랍니다. 5.1 때부터 들어간다고 했지만 전혀 들어가지 않아서 애를 태웠는데 드디어 들어가게 되었으니 정말 기쁩니다.

 

이상 World Partition의 구조를 해설해 왔습니다.
마지막으로 정리를 해보겠습니다. 지금까지 설명한 내용을 바탕으로, World Partition을 사용할지 여부를 생각해보고 싶습니다.

World Partition은 일부 제한 사항이 있는 경우가 있으므로 검토 시 미리 염두에 두어야 합니다. 가장 큰 제한 사항은 스태틱 라이팅(Static Lighting), 즉 라이트 베이크(Light Baking)에 대응하지 않는다는 것입니다. 루멘(Lumen)을 전제로 하는 프로젝트라면 특별히 문제가 없지만, 그렇지 않은 경우에는 다이내믹 라이팅(Dynamic Lighting)만으로 충분한 표현이 가능한지 먼저 검토해야 합니다.

또한, 멀티플레이(Multiplay)를 고려하고 있고, 리슨 서버 모델(Listen Server Model)을 사용하고 싶을 경우에는 서버 측에서 모든 플레이어의 주변 셀(Cell)을 로드해야 하므로, 서버의 메모리 부하를 기준으로 맞춰야 한다는 점에 주의해야 합니다.

 

이러한 제한 사항을 고려하면서 World Partition을 사용할지 여부를 판단해야 합니다. 먼저 오픈 월드 게임을 만들 경우에는 World Partition을 사용하는 것이 좋습니다. 오픈 월드 게임이 아니더라도 레벨을 조작하는 회사가 많거나, 대규모 개발이거나, HLOD 기능 등을 사용하고 싶은 경우에는 World Partition을 사용하는 것을 검토해 보시기 바랍니다. World Partition을 사용하지 않아도 HLOD를 만드는 것은 가능하지만, 기존 워크플로는 유지 관리가 잘 되지 않아 문제가 발생할 가능성이 높습니다.

 

또한, 슬라이드에서는 구체적으로 언급하지 않았지만, "셀 사이즈(Cell Size)를 결국 얼마로 해야 하는가"라는 질문도 World Partition의 큰 고민거리 중 하나입니다. 실제로는 프로젝트에 따라 달라집니다. 예를 들어 이동 속도라든지, 어느 정도 멀리까지 보고 싶은지 등 크게 영향을 받습니다. 크게 설정하는 것과 작게 설정하는 것 모두 장점과 단점이 있습니다. 조정 방침으로는 로딩 범위 이하의 약간 큰 셀 사이즈를 먼저 선택하고 거기에서 프로파일을 보거나 HLOD를 작성해 보는 등의 테스트를 거쳐 미세 조정을 하는 것이 좋습니다.

그리고 맨 아래에 있습니다만, 스트리밍 성능을 확인하기 위해 Level Instance의 로딩에 얼마나 시간이 걸렸는지를 tsv 형식, 즉 CSV와 비슷한 것으로 출력해 줍니다. 이 값을 확인해서 스트리밍 시간이 너무 오래 걸리면 셀 사이즈를 줄여야겠다는 것을 확인할 수도 있습니다.

 

정리

그럼 마지막으로 정리하겠습니다. World Partition 기능 덕분에 큰 World를 만드는 메커니즘이 잘 갖춰지고 있는 상황입니다. 기존 워크플로에 익숙한 개발자도 비슷한 기능이 World Partition에 있으니 두려워하지 말고 사용해 주시면 좋겠습니다. 그리고 봄에 릴리스될 5.4에서는 다양한 개선 사항이 추가되니 기대해 주시기 바랍니다.

마지막으로 지금까지 World Partition에 대해 여러 슬라이드를 공개했으니 소개해 드리겠습니다. 커스텀 라이선스를 가지고 있다면 UDN 내에 저희 타이틀의 설정값 등이 자료로서 액세스할 수 있도록 되어 있으니 World Partition을 사용하기 전에 한 번 확인해 보시는 것을 추천합니다.