MUDANG GAME — In-Game Leveling & Lighting

01 / OVERVIEW

프로젝트 개요 & 설계 원칙

세 가지 독립적인 문제 · 하나의 공통 원칙

복층 구조의 실내 레벨에서는 라이트 중첩·대규모 어셋 배치·레벨 스트리밍 문제가 동시에 발생했다. 문제들을 분석했을 때 공통점이 있었다. 하나의 구조가 여러 역할을 동시에 담당하면서 각각에서 한계가 생기는 패턴이었다.

설계 원칙

하나의 구조에 여러 역할을 동시에 맡기지 않는다

직접광 / 간접광 분리 · 레벨 단위 / 메시 단위 인스턴싱 분리 · Streaming 단위 / 렌더링 단위 분리 — 세 영역 모두 같은 원칙으로 접근했다.

GPU Frame Time

12.6 ms

11.1 ms

↓ 12%

Draw Call

2,500

1,950

↓ 22%

Draw Call (스트리밍)

위 기준

추가 절감

↓ 8–13% 추가

라이트 수

기준값

–30–40%

↓ 약 35%

세 영역의 독립적 역할 분리

02 / INDOOR LIGHTING & EMISSIVE GI

실내 라이팅 최적화

직접광 · 간접광 역할 분리 — Spot Light 최소화 + Emissive GI 이중 구조

복층 실내 특성상 좁은 공간에 라이트가 중첩된다. 라이트를 줄이면 GPU 비용은 낮아지지만 간접광이 사라지면서 공간의 깊이감 자체가 무너진다. 문제의 본질은 하나의 라이트가 직접광과 간접광을 동시에 담당하고 있다는 점이었다. 역할을 분리하면 두 조건을 동시에 만족할 수 있다고 판단했다.

실내 라이팅 적용 결과 — Spot Light 최소 배치 + Emissive GI 보완

복층 복도 구간 — 암부 보정 후 공간 가독성 확보

이중 구조 설계 — 왜 Emissive GI인가

UE5 Lumen 환경에서 Emissive 머티리얼은 GI 연산에 직접 기여한다. 즉 Emissive 표면이 일종의 면광원 역할을 해 주변 암부를 채울 수 있다. 명시적인 라이트 오브젝트를 추가하지 않고도 간접광 효과를 만들 수 있다는 것이 핵심이다. 라이트 중첩으로 발생하는 GPU 비용 없이 간접광을 보완할 수 있다.

기존 — 라이트 하나가 모든 역할

직접광 + 간접광 혼재

라이트 하나가 직접 조명과 암부 채움을 동시에 담당한다. 라이트를 줄이면 직접광과 간접광이 동시에 사라지기 때문에 줄일 수가 없다. 중첩이 쌓일수록 GPU 비용이 누적된다.

재설계 — 역할 분리

Spot Light 직접광 + Emissive GI 간접광

Spot Light는 직접 조명만 담당하고 최소한으로 배치한다. 간접광(암부 보완)은 Emissive GI가 담당한다. 직접광 라이트 수를 줄여도 Emissive GI가 공간의 깊이감을 유지한다.

이중 구조 — Spot Light 직접광 · Emissive GI 간접광

Emissive GI 머터리얼 구조

Emissive로 간접광을 대체하려면 발광 범위를 정밀하게 제어해야 한다. 수치만 높이면 의도하지 않은 영역까지 빛이 번진다. 오브젝트 크기는 제각각이기 때문에 고정 UV 좌표로는 크기마다 마스크 기준이 달라지는 문제도 있다.

BoundingBoxBased_0-1_UVW · Remap 노드 구성 — 크기 무관 마스크 정규화

1

BoundingBoxBased_0-1_UVW — 크기 정규화

메시의 월드 크기와 무관하게 UV 좌표가 항상 0~1 범위로 정규화된다. 소형 소품부터 대형 천장 구조물까지 동일한 마스크 파라미터를 그대로 적용할 수 있다.

WorldPosition → BoundingBox 정규화 → UV 0–1

없으면 오브젝트 크기마다 머티리얼을 따로 세팅해야 한다. 레벨 단위 재사용이 불가능해진다.

2

Remap 노드 — 마스크 경계 통일

BoundingBox 정규화 이후 마스크 범위 경계를 오브젝트 크기와 무관하게 동일한 파라미터로 조정한다. 경계의 날카로움, 페이드 범위 모두 하나의 파라미터로 제어된다.

UV 0–1 → Remap(MinIn, MaxIn, MinOut, MaxOut) → 마스크 범위 출력

3

Blueprint 파라미터 노출 — 레벨 단위 제어

Mesh 타입별로 emissive 강도와 mask 범위를 Blueprint에서 파라미터로 노출했다. 레벨 배치 단계에서 값을 직접 조정하거나 같은 타입의 오브젝트에 재사용할 수 있다.

BP → SetScalarParameterValue(Emissive, Mask) → Material Instance

BB

BoundingBoxBased_0-1_UVW

Material Node

메시 크기와 무관하게 UV를 0~1로 정규화. 어떤 크기의 오브젝트에도 동일한 마스크 기준 적용 가능.

→ 레벨 전반 머티리얼 재사용

RM

Remap 노드

Material Node

마스크 범위 경계를 오브젝트 크기와 무관하게 동일한 파라미터로 조정. 발광 페이드 범위 통일.

→ 크기 무관 일관된 마스크 기준

EM

Emissive 파라미터

Blueprint Parameter

Blueprint에서 발광 강도를 Mesh 타입별로 직접 제어. 씬 전체 밝기 밸런스 조정 가능.

→ 레벨 단위 강도 조정

MK

Mask 파라미터

Blueprint Parameter

Blueprint에서 발광 영역 범위를 Mesh 타입별로 제어. 의도한 영역 밖으로 빛이 번지는 것을 방지.

→ 발광 영역 정밀 제어

결과

GPU Frame Time

12.6ms → 11.1ms

↓ 11.9% 개선

라이트 수

기준값 → –30~40%

↓ 약 35% 감소 · 시각적 품질 유지

재사용 가능한 시스템으로 설계 — BoundingBoxBased UVW + Remap + Blueprint 파라미터 구조는 특정 오브젝트에 종속되지 않는다. 이후 실내 레벨 작업에도 동일한 머티리얼 시스템을 그대로 적용할 수 있다.

03 / INSTANCE OPTIMIZATION

인스턴스 최적화

PLI + ISM 이중 구조 — 레벨 단위 · 메시 단위 드로우콜 계층별 절감

동일한 메시가 개별 Static Mesh Actor로 분산 배치되면, 같은 데이터를 GPU가 오브젝트 수만큼 반복 처리한다. 실내 레벨에서는 가구·소품·조형물 같은 반복 자산이 많기 때문에 어느 시점부터 드로우콜이 급격히 쌓였다. 레벨 단위 묶음과 메시 단위 인스턴싱을 서로 다른 계층에서 독립적으로 처리해 드로우콜을 줄이는 방향으로 접근했다.

PLI vs ISM — 역할이 다르다

두 방식을 함께 쓴 이유가 있다. 각각 담당하는 문제의 계층이 다르기 때문에 병행 적용이 유효하고, 한쪽으로만은 해결되지 않는 부분이 있다.

PLI · ISM — 계층별 역할 분리 구조

Packed Level Instance (PLI)

레벨 단위 자산 묶음 관리

여러 종류의 Actor를 하나의 레벨 인스턴스로 묶어 관리하는 방식이다. 일반 레벨 배치는 Actor마다 개별 트랜스폼 데이터를 관리하지만, PLI는 그룹 단위로 묶어 레벨 시스템 차원에서 일괄 처리한다.

핵심 역할: 구역 단위로 쓰이는 자산 묶음을 하나의 단위로 처리해 레벨 관리 비용을 줄인다. 서로 다른 메시가 섞인 그룹에도 적용할 수 있다는 점이 ISM과의 차이다.

Instanced Static Mesh (ISM)

메시 단위 드로우콜 일괄 처리

동일한 메시를 공유하는 오브젝트들을 GPU 입장에서 한 번의 드로우콜로 일괄 처리하는 방식이다. 같은 메시 100개가 별도 Actor로 있으면 드로우콜 100회지만, ISM으로 묶으면 1회가 된다.

핵심 역할: 메시가 동일한 오브젝트에 한정된다는 제약이 있다. 다양한 메시가 섞인 구역에는 PLI가 필요하다.

두 방식을 병행하는 이유 — PLI는 서로 다른 메시가 섞인 구역 단위 그룹을 다루고, ISM은 동일한 메시의 반복 배치를 다룬다. 담당하는 계층이 다르기 때문에 한쪽만으로는 커버하지 못하는 영역이 남는다. 병행 적용하면 두 계층에서 독립적으로 드로우콜이 절감된다.

결과

Draw Call

2,500 → 1,950

↓ 22% 감소 · 프레임 드랍 구간 완화

04 / LARGE-SCALE DATA MANAGEMENT

대규모 데이터 관리 / Level Streaming

동선 기반 로드·언로드 기준 정의 · Streaming 단위 / ISM 단위 분리

레벨 규모가 커질수록 어셋 전체를 단일 기준으로 관리하는 방식의 한계가 드러났다. 플레이어가 볼 수 없는 구역의 어셋까지 메모리에 올라와 있는 상태가 지속됐고, 리소스가 한꺼번에 집중되면서 성능 병목이 생겼다. 항상 활성화되어야 하는 공간과 상황에 따라 진입하는 공간의 사용 패턴이 다름에도 동일하게 처리하는 것이 근본 원인이었다.

동선 기반 레벨 구역 분리

카메라 이동 경로를 기준으로 레벨을 두 영역으로 구분했다. 기준은 "항상 있어야 하는가"가 아니라 "플레이어 동선상 언제 필요한가"였다.

동선 기반 Level Streaming 구역 분리

구역 유형	정의	처리 방식
상시 로드 영역	항상 활성화되어야 하는 핵심 공간	메모리 상시 유지. 언로드 없음
선택적 로드 영역	특정 상황에서만 진입하는 공간	진입 시 Load → 이탈 후 Unload
비 가시구간	플레이어가 지나간 구역 또는 현재 볼 수 없는 구역	순차적 비활성화 → 메모리 해제

Streaming 단위와 인스턴싱 단위 분리

Streaming과 ISM을 함께 적용하면서 두 단위를 분리해서 관리한 이유가 있다. 역할이 다른 두 단위를 섞어서 관리하면 한쪽을 최적화할 때 다른 쪽에 영향이 생긴다.

Streaming 단위

어느 구역을 메모리에 올릴지 결정

메모리 관리 담당. 카메라 동선에 따라 구역 단위로 로드·언로드 시점을 결정한다. 렌더링 방식과 독립적으로 동작해야 한다.

인스턴싱(ISM) 단위

메모리에 올라온 오브젝트를 효율적으로 렌더링

렌더링 효율 담당. 이미 메모리에 올라온 오브젝트를 드로우콜 최소화 방식으로 처리한다. Streaming 단위 변경과 무관하게 독립 동작한다.

협업 구조 정비

최적화된 구조도 다른 작업자가 이해하지 못하면 협업에서 유지되지 않는다. 폴더 구조와 명명 규칙을 정리해 데이터 흐름을 직관적으로 파악할 수 있도록 구성하고, 기준을 문서화해 팀 내에 공유했다. 수치 개선만이 목표가 아니라, 누구나 이해하고 유지보수할 수 있는 레벨 데이터 구조를 만드는 것이 이 작업의 본래 목적이었다.

결과

Draw Call (스트리밍 적용분)

인스턴싱 후 기준 → 추가 절감

↓ 8–13% 추가 감소 (ISM 분리 구성 병행)

8~13% 수치가 ISM+Streaming 병행 결과인 이유 — S3에서 측정한 Draw Call 22% 절감은 인스턴싱 구조 단독 기여분이다. 스트리밍 적용으로 추가되는 8~13%는 비 가시구간 Unload로 렌더링 커맨드 자체가 줄어드는 효과다. 두 측정은 독립적인 구조 변경에서 나왔기 때문에 수치를 분리해서 제시했다.

05 / SUMMARY

핵심 정리

세 영역의 역할 분리 원칙이 만든 합산 결과

설계 결정 정리

Emissive GI — 직접광·간접광 분리

직접광 라이트를 줄여도 간접광이 유지된다. 역할을 분리하면 두 조건을 동시에 만족할 수 있다. Lumen에서 Emissive는 GI에 직접 기여하기 때문에 라이트 오브젝트 없이도 암부를 채울 수 있다.

BoundingBoxBased UVW — 크기 무관 정규화

오브젝트 크기와 무관하게 UV를 0~1로 정규화해 레벨 전반에 동일한 마스크 파라미터를 적용한다. 없으면 오브젝트마다 머티리얼을 따로 세팅해야 한다.

PLI + ISM — 다른 계층, 다른 역할

PLI는 서로 다른 메시가 섞인 구역 단위 그룹을 담당하고, ISM은 동일 메시의 반복 배치를 담당한다. 계층이 달라 병행 적용이 유효하고, 한쪽만으로는 커버되지 않는 영역이 남는다.

Streaming · ISM 단위 분리

Streaming은 메모리 로드 기준, ISM은 렌더링 효율을 담당한다. 역할이 다른 두 단위를 섞어 관리하면 한쪽을 최적화할 때 다른 쪽에 영향이 생긴다.

동선 기반 로드 기준 — 패턴별 처리

항상 있어야 하는 공간과 상황에 따라 진입하는 공간의 사용 패턴이 다르다. 동일하게 처리하는 것 자체가 비효율이었다. 카메라 동선 기준으로 구역을 분리했다.

세 영역의 개선이 합산되는 구조

라이팅·인스턴싱·스트리밍 각각의 최적화가 서로 간섭 없이 독립적으로 동작하기 때문에 개별 수치가 합산되어 전체 퍼포먼스로 이어진다.

이 작업에서 적용한 원칙은 하나다 — 하나의 구조에 여러 역할을 동시에 맡기지 않는다. 라이팅에서 직접광과 간접광을 분리했고, 인스턴싱에서 레벨 단위와 메시 단위를 분리했으며, 데이터 관리에서 로드 기준과 렌더링 기준을 분리했다. 역할이 명확히 나뉘어진 구조는 하나를 수정해도 다른 하나에 영향이 없다. 최적화 이후에도 유지보수가 가능한 이유다.