월드를 자동으로 Grid Cell 단위로 나누고 필요한 영역만 로드/언로드하는 방식
핵심 개념
| 개념 | 설명 |
|---|---|
| World Partition | 월드를 Grid Cell 단위로 자동 분할하는 시스템 |
| Cell | World Partition이 나눈 최소 스트리밍 단위 |
| Streaming Source | 어떤 위치를 기준으로 Cell을 로드할지 결정하는 기준점 |
| Data Layer | Actor를 논리적 그룹으로 묶어 로드/언로드를 제어하는 기능 |
| HLOD | 멀리 있는 Actor들을 저비용 프록시 메시로 대체하는 시스템 |
| One File Per Actor | Actor 단위로 파일을 분리해 협업 충돌을 줄이는 시스템 |
기본 동작 흐름
flowchart TD
A[Persistent Level] --> B[World Partition]
B --> C[Grid Cell로 자동 분할]
C --> D[Streaming Source 확인]
D --> E[주변 Cell 로드]
D --> F[먼 Cell 언로드]
E --> G[게임플레이 Actor 활성]
F --> H[메모리 절약]
플레이어 또는 카메라 같은 Streaming Source가 이동하면, 해당 위치 주변 Cell은 로드되고 멀어진 Cell은 언로드된다.
Streaming Source
Streaming Source는 World Partition이 어떤 Cell을 로드할지 판단하는 기준이다.
| Streaming Source | 설명 |
|---|---|
| Player | 플레이어 주변 Cell 로드 |
| Camera | 카메라 기준으로 월드 로드 |
| Custom Actor | 특정 Actor 주변을 강제로 로드 |
| Blueprint / Component | 직접 Streaming Source Component를 붙여 제어 |
Streaming Source가 없으면 Runtime Grid의 Cell이 기대대로 로드되지 않을 수 있다.
flowchart TD
A[Streaming Source 위치] --> B[로드 반경 계산]
B --> C[반경 안 Cell Loaded]
B --> D[반경 밖 Cell Unloaded]
Runtime Grid
Runtime Grid는 월드를 어떤 Grid 기준으로 나눌지 정하는 설정이다.
| 항목 | 설명 |
|---|---|
| Cell Size | Cell 하나의 크기 |
| Loading Range | Streaming Source 주변 로드 거리 |
| Runtime Grid | Runtime에서 사용할 스트리밍 Grid |
| Spatially Loaded | 위치 기반 스트리밍 대상 여부 |
Cell Size가 너무 작으면 Cell 수가 많아져 관리 비용이 늘고, 너무 크면 불필요한 Actor까지 같이 로드될 수 있다.
| Cell Size | 특징 |
|---|---|
| 작음 | 세밀한 스트리밍 가능, Cell 수 증가 |
| 큼 | 관리 단순, 불필요한 로드 증가 가능 |
Spatially Loaded
Actor가 위치 기반 스트리밍 대상인지 결정.
| 설정 | 결과 |
|---|---|
| true | 위치 기반으로 Cell에 포함되어 로드/언로드됨 |
| false | 위치와 상관없이 항상 로드되거나 별도 조건으로 관리됨 |
항상 존재해야 하는 Manager, Game Rule Actor, 전역 시스템 Actor는 Is Spatially Loaded를 꺼야 하는 경우가 있다.
| Actor 예시 | 권장 |
|---|---|
| 나무, 바위, 건물 소품 | Spatially Loaded |
| 필드 몬스터 | 상황에 따라 Spatially Loaded |
| GameMode성 관리 Actor | Spatially Loaded 비권장 |
| Quest Manager | Spatially Loaded 비권장 |
| 맵 전역 설정 Actor | Spatially Loaded 비권장 |
Data Layer
Data Layer는 Actor를 논리적 그룹으로 묶는 기능
월드 위치와 별개로 “이 그룹의 Actor를 켤지 끌지”를 제어할 수 있다.
| 용도 | 예시 |
|---|---|
| 퀘스트 상태별 월드 변화 | 퀘스트 전/후 NPC, 오브젝트 변경 |
| 시간대 변화 | 낮/밤 오브젝트 구분 |
| 이벤트 연출 | 전투 후 파괴된 건물 표시 |
| 개발 편의 | 작업 구역별 Actor 숨김/표시 |
| 콘텐츠 분기 | 특정 스테이지 상태만 로드 |
flowchart LR
A[Actor] --> B[Data Layer]
B --> C[Editor에서 표시/숨김]
B --> D[Runtime에서 Load/Unload]
HLOD (Hierarchical Level of Detail)
멀리 있는 여러 Actor를 하나의 저비용 프록시 메시로 합쳐 렌더링 비용을 줄이는 기능
| 거리 | 처리 |
|---|---|
| 가까움 | 원본 Actor 로드 |
| 멀어짐 | 원본 Actor 언로드 |
| 원거리 | HLOD 프록시 표시 |
World Partition에서 넓은 월드를 만들면 멀리 보이는 지형, 건물, 숲 표현이 중요하다.
HLOD를 사용하면 원거리 시야는 유지하면서 실제 Actor 비용을 줄일 수 있다.
flowchart LR
A[여러 원본 Actor] --> B[HLOD Builder]
B --> C[Proxy Mesh 생성]
C --> D[원거리에서 Proxy 표시]
One File Per Actor
One File Per Actor는 Actor를 Level 파일 하나에 모두 저장하지 않고, Actor별 파일로 분리하는 시스템
| 기존 방식 | 문제 |
|---|---|
| 하나의 Level 파일에 많은 Actor 저장 | 여러 명이 같은 Level 수정 시 충돌 |
| OFPA 방식 | 장점 |
|---|---|
| Actor별 파일 분리 | 각자 다른 Actor를 수정하면 충돌 감소 |
| Source Control 친화적 | 대규모 팀 작업에 유리 |
| World Partition과 궁합 좋음 | Cell/Actor 단위 관리에 적합 |
'TIL' 카테고리의 다른 글
| UE Authority (0) | 2026.07.30 |
|---|---|
| MyaCat 발표 후 회고 (0) | 2026.07.24 |
| In Place 작업 (0) | 2026.07.22 |
| ABP → AnimInstance 전환 (0) | 2026.07.20 |
| UE Preload (0) | 2026.07.16 |