[발표 번역] UF2025(Shanghai)—《델타포스》글로벌 일루미네이션 기술 심층 분석: Lightmap에서 Lumen까지 크로스플랫폼 구현의 여정

텐센트 델타포스 글로벌 일루미네이션 기술 심층 분석: Lightmap에서 Lumen까지 크로스플랫폼 구현의 여정

제목: [UFSH2025] 《델타포스》의 글로벌 일루미네이션 방안 | 위동신 텐센트 TiMi J3 스튜디오 엔진 개발 엔지니어

1. 서론: 크로스플랫폼 게임의 글로벌 일루미네이션 도전

강연 오프닝

현대 AAA 게임 개발에서 글로벌 일루미네이션(Global Illumination, GI) 시스템의 선택은 종종 게임 비주얼 퀄리티의 상한선과 제작 효율의 하한선을 결정한다. 텐센트 TiMi J3 스튜디오의 엔진 개발 엔지니어 위동신은 2025년 UFSH 컨퍼런스에서 크로스플랫폼 슈팅 게임 《델타포스》의 글로벌 일루미네이션 방안에 대한 기술적 선택과 구현 세부 사항을 공유했다.

프로젝트 소개

위동신은 2015년 텐센트에 입사한 이후 《LEGO 인피니티》, 《크로스파이어 모바일》, 《PUBG: 뉴스테이트》 등 여러 프로젝트의 개발에 참여하며 풍부한 그래픽 렌더링 경험을 쌓았다. 《델타포스》은 PC와 모바일 양 플랫폼을 대상으로 한 멀티플레이어 대전 게임으로, 그 기술적 과제는 이렇다: 성능 차이가 극심한 플랫폼들에서 모든 플레이어가 볼 수 있는 영역에 고품질의 글로벌 일루미네이션을 어떻게 제공할 것인가?

2. 프로젝트 요구사항 분석: 듀얼 플랫폼 동기화의 기술적 제약

프로젝트 특징

《델타포스》은 기획 첫날부터 "최대한 넓은 플랫폼을 지원해 모두 함께 플레이"라는 설계 철학을 확립했다. 이는 모든 맵이 PC와 모바일 플랫폼에서 동시에 출시되어야 하며, 특정 맵이 특정 플랫폼에서만 독점 출시되는 일은 없다는 의미다.

GI 커버리지 요구사항

더욱 엄격한 요구사항도 있다: 각 맵에서 플레이어가 볼 수 있는 모든 영역에 반드시 글로벌 일루미네이션 커버리지가 있어야 한다는 것이다. 이 "전 영역 커버"라는 요구는 PC와 모바일의 성능 차이가 극심한 배경에서 GI 방안 선택에 엄청난 기술적 갈등을 불러일으켰다.

2.1 PC 플랫폼의 기술적 기대

PC 요구사항

PC 플랫폼에 대해 개발팀이 기대하는 것들:

고화질 효과: Lightmap이든 Volume GI든 정밀도를 높이면 VRAM 소비가 기하급수적으로 늘어난다. 따라서 VRAM 제어에 항상 주의를 기울여야 한다.

제작 비용 절감: PC 맵 구조는 더욱 복잡하기 때문에 전부 Lightmap 베이크를 사용하면 제작 비용이 매우 높아진다. 그래서 Volume GI가 제작 효율상의 장점을 발휘하기를 기대한다(별 4개 수준의 기대치).

2.2 모바일 플랫폼의 특수 제약

모바일 게임 플랫폼에 대해서는 우선순위가 다르다:

용량 제어: 모바일 플레이어 경험을 보장하는 데 매우 중요한 요소다. 전체 맵에 Lightmap을 깔고 TOD(Time of Day, 주야 시스템)를 지원하면 용량이 지나치게 커진다.

성능 제어: 모바일 성능은 PC에 비해 크게 낮으므로 GPU 사용량을 엄격히 제어해야 한다. 현재 대부분의 모바일 게임이 GPU 병목 상태이므로, Volume GI 방안을 채택할 경우 그 소비가 Lightmap에 비해 크게 증가해서는 안 된다.

Lightmap 사용 범위가 더 넓다: 성능 고려로 인해 모바일에서 Lightmap의 사용 범위가 PC보다 실제로 더 크다.

3. GI 방안 전반 조망: 전통에서 현대로

GI 방안 비교

구체적인 기술 로드맵을 정하기 전에 팀은 현재 주류 GI 솔루션들을 체계적으로 정리했다:

3.1 Lightmap: 가장 전통적인 고효율 방안

Lightmap 방안

Lightmap은 가장 단순하고, 가장 전통적이며, 가장 클래식한 방안이다. 핵심 장점:

• 런타임 성능 최고: UV 좌표 하나를 주면 텍스처 샘플링으로 조명 데이터를 바로 얻을 수 있어 매우 효율적이다
• 제어 가능한 정밀도: 아티스트가 국소적으로 Lightmap 텍셀 밀도를 높여 매우 높은 정밀도를 얻을 수 있다
• 성숙한 워크플로: 업계의 사용 경험이 풍부하고 툴체인이 완비되어 있다

그러나 Lightmap의 단점도 분명하다:

• 프로젝트 비용 높음: UV2 제작이 필요하고 조명 베이크 과정에 시간이 소요된다
• 이터레이션 효율 낮음: 조정할 때마다 다시 베이크해야 하며, 대형 맵의 경우 수 시간에서 수 일이 걸릴 수 있다
• 대형 맵에 불친절: 창공 맵 같은 대규모 씬을 전부 Lightmap으로 깔면 메시 수가 감당할 수 없는 수준에 달한다

3.2 Volume GI: 성능과 효율의 균형점

Volume GI는 PC에서 희소화 저장 복셀 구조를 사용할 수 있어 고정밀도와 제어 가능한 VRAM이라는 특징을 갖는다. 팀의 경험상 GTX 1660급 그래픽 카드에서 1080P 해상도로 Volume GI를 구동하면 샘플링 비용이 약 3ms 정도로 허용 가능한 수준이다.

《어쌔신 크리드》, 《고스트와이어: 도쿄》 등 현대 게임들이 이 방식을 광범위하게 채택했다. 모바일 플랫폼에서는 정규 3D 텍스처 저장 방식의 Volume GI를 사용할 수 있는데, 3D 텍스처 정규 샘플링 덕분에 GPU에 더 친화적이고 성능도 더 좋다.

3.3 동적 GI: Lumen으로 대표되는 미래 방향

Lumen 방안

Unreal Engine 5의 Lumen으로 대표되는 완전 동적 GI 방안의 최대 장점:

• 이터레이션 효율 극대: 아티스트 조정 결과를 실시간으로 확인할 수 있어 기다릴 필요가 없다
• 뛰어난 효과: 진정한 동적 간접 조명을 구현할 수 있다

단점도 명확하다: 광선 추적 수가 앞 두 방식보다 한 자릿수 많아 성능 소비가 막대하다.

3.4 성능과 비용의 스펙트럼 분석

성능 비용 비교

성능 관점에서 Lightmap이 단연 최고다 — UV 하나를 주면 데이터가 즉시 샘플링되어 나오니 매우 효율적이다. Volume GI의 데이터 획득은 조금 더 복잡하다: 셰이더에서 트리형 복셀 구조에 접근하고 Position으로 조명을 쿼리한 뒤 법선에 따라 디코딩해야 한다. 그러나 프로젝트 비용 관점에서는 상황이 완전히 반대다:

제작 비용 비교

Lightmap의 프로젝트 비용:

• UV2 제작이 필요하며 이는 매우 인력 소모적인 작업이다
• Lightmap 조명 베이크 자체에서 문제가 매우 쉽게 발생한다
• 어느 Lightmap에서 더 많은 텍셀을 할당할지 이터레이션하는 건 시간 블랙홀이다
• 대형 맵(창공 맵 등)의 경우 전부 Lightmap으로 깔기란 사실상 불가능한 임무다

Volume GI의 장점

Volume GI의 제작 장점:

• UV2가 필요 없다
• Position만 주어지면 알고리즘으로 즉시 필요한 데이터를 조회할 수 있다
• 창공 같은 대규모 맵의 경우 자동화 파이프라인으로 매일 롤링 베이크도 가능하다
• 아티스트는 최신 데이터를 풀받기만 하면 필요한 조명을 얻을 수 있다

동적 GI 비용

동적 GI의 제로 비용:

Lumen 같은 완전 동적 방안은 제작 비용을 거의 제로로 압축한다 — 기다림 없이, 보이는 게 곧 결과다.

이 스펙트럼에서 볼 수 있는 것: 왼쪽(Lightmap)에 가까울수록 런타임 효율은 높지만 제작 비용도 높고, 오른쪽(동적 GI)에 가까울수록 개발 플로우는 유쾌하고 이터레이션도 빠르지만 성능 소비도 크다.

방안 선택

주목할 만한 것은, 《델타포스》, 《원광》, 《콜 오브 듀티》 등 현대 AAA 게임들이 거의 모두 이 스펙트럼 위에서 자신만의 선택을 했다는 점 — "다 쓴다"는 것이다. 이는 일종의 트렌드라고도, "구간 최적화" 전략이라고도 할 수 있다.

4. 기술 선택 원칙: 런타임 효율 우선

선택 원칙

듀얼 플랫폼 요구사항 분석을 바탕으로 팀은 명확한 선택 원칙을 수립했다:

각 플랫폼에서 런타임 효율을 우선 보장: 멀티플레이어 경쟁 게임은 120~144fps를 달성해야 하며, 그 기반 위에서 제작 속도를 최대한 높인다.

멀티플레이어 대전 모드: 모든 대전 맵에 Lightmap + Volume GI 조합 방안을 적용한다. PC에서는 Volume GI 사용 비율이 더 높다.

싱글 캠페인 모드: PVP 경쟁의 프레임레이트 압박이 없으므로 Lumen을 직접 사용해 높은 효과를 추구하고, 이터레이션 효율 장점을 살려 더 높은 아트 퀄리티를 달성한다.

5. PC Lightmap 구현: 국소 정밀도 제어

PC Lightmap

팀은 《크로스파이어 모바일》 시절부터 자체 GPU 광선 추적 베이커를 개발해왔으며, 여러 프로젝트를 거쳐 《델타포스》에 이르러 성숙한 GPU 베이크 방안으로 발전했다.

Lightmap은 사랑과 미움이 공존한다: 효율과 품질은 좋지만, 씬이 커지면 오프라인 제작도 막대한 시간을 잡아먹는다. 따라서 국소적으로 정밀도를 높이고 싶은 곳에서만 Lightmap을 사용한다.

창공 맵 커버리지

가장 넓은 창공 맵을 예로 들면, 연한 노란색으로 표시된 영역만 Lightmap을 사용했다. 이 Lightmap에는 인공광과 하늘광의 가시성만 담겨 있으며, 주로 실내 조명을 담당한다.

이 전략의 장점:

• 맵을 부분적으로 분할할 수 있어 아트 통괄이 독립적으로 베이크를 진행할 수 있다
• 전체적인 태양광 방향 변경의 영향을 받지 않는다
• 정밀도가 필요한 실내 씬에서 Lightmap의 장점을 발휘한다

제작 효율의 한계

대형 맵에 Lightmap을 사용하는 주된 한계는 제작 효율이다. 창공 같은 규모의 맵 전체를 Lightmap으로 베이크하면 맵이 영원히 출시되지 못할 수도 있다. 특히 TOD 시스템이 있는 경우에는 더욱 그렇다.

6. PC Volume GI: 핵심 기술 방안

Volume GI 방안

Volume GI는 PC에서 커버리지가 가장 넓은 기술 방안이자 이번 공유의 핵심이다. 제작 효율을 대폭 향상시키면서 품질도 Lightmap에 근접할 수 있다는 게 최대 장점이다.

6.1 누광 방지: 프로젝트 성공의 핵심 요소

누광 방지의 중요성

구체적인 알고리즘 설명에 앞서 여러 프로젝트를 통해 얻은 교훈을 반드시 강조해야 한다: 누광 방지는 Volume GI가 프로젝트 관점에서 성공할 수 있는가를 결정하는 핵심 요소다.

가로축은 제작 비용, 세로축은 GI 방안의 종합 효과(화면 + 이터레이션 효율)로 설명하자면:

Lightmap은 제작 비용이 높지만 종합 효과도 확실히 좋다. 이상적인 Volume GI라면 제작 효율은 크게 향상(비용이 큰 폭으로 감소)하되 종합 효과 저하는 최소화해야 한다.

그러나 매우 쉽게 함정에 빠진다: Volume GI가 아티스트의 작업량을 줄여주고 개발자도 스스로 잘했다고 생각하지만, Volume GI 자체에는 누광이라는 고유한 문제가 있다. 이 문제를 잘 처리하지 못하면:

• 제작 비용은 내려갔지만 화면 품질도 저하된다(누광 아티팩트 발생)
• 혹은 화면은 유지했지만 런타임 성능이 크게 저하된다(값비싼 알고리즘으로 누광 해결 필요)

이러한 Volume GI는 Lightmap 대비 전체 성비가 크게 개선되지 않는다. 하지만 제작팀은 각자의 "쾌감 포인트"가 있어 전체 성비 향상을 체감하기 어렵다.

가장 무서운 건 QA 피드백이 돌아올 때 효율이 좋지 않다는 걸 발견하고, 수많은 버그가 생기는 것이다. 이 버그들을 고치기 위해 각종 핵 솔루션으로 이리저리 치이다 보면 Volume GI의 저비용 장점이 사라져버린다.

누광 방지 전략:

누광 원인

누광은 Volume GI의 흔한 아티팩트다. 복셀 너비가 벽 두께보다 클 때 누광이 발생할 수 있다. 언제 누광이 생길지 예측할 수 없다면 제작 버그 티켓이 쏟아져서 저비용이라는 장점을 상쇄시킬 수 있다.

따라서 방안 자체가 이를 안정적으로 해결하고, 아티스트에게 알려줄 수 있어야 한다: 어떻게 만들면 누광을 완전히 피할 수 있는가.

누광 방지 기준

말로는 단순하다:

1. 복셀 정밀도를 최대한 높이되 성능 예산을 넘지 않는다
2. 《델타포스》은 0.25m 정밀도를 채택했다
3. 아티스트에게 알린다: 모든 벽의 두께가 0.25m를 넘으면 절대 누광이 생기지 않는다

이 0.25m 기준은 대부분의 건축물에 대해 수용 가능한 방안이다. 런타임 샘플링 보간 시 카메라는 어떤 경우에도 벽 너머를 샘플링할 수 없다. 벽이 복셀보다 두껍기 때문이다.

이터레이션 과정에서 0.25m 미만이 불가피한 경우(예: 철판 건물)라면 다른 방법을 찾으면 된다. 하지만 이처럼 매우 명확한 기준이 존재하면 제작 단계에서 대부분의 누광을 방지할 수 있다.

이 작업은 프로젝트 첫날부터 시작해야 한다. 그렇지 않으면 런타임에서 알고리즘으로 누광을 막아야 하는데(월드 스페이스 반경 인코딩 등), 그 경우 성능 비용이 매우 크다.

6.2 기본 데이터 요소: 6방향 Irradiance

데이터 구조

각 복셀에 6개 방향의 Irradiance를 담은 Irradiance Map(IMNQB)을 저장한다. 이 반구면 구조는 매우 클래식하며, 《콜 오브 듀티: 블랙 옵스》 시리즈도 이 구조를 사용했다.

런타임에 법선을 기준으로 6개 방향을 보간해 최종 결과를 얻는다. 각 방향에는 해당 방향의 입사광 강도가 저장되므로 서로 다른 방향의 표면에 대응할 수 있다.

6.3 희소 저장: OpenVDB에서 영감받은 방안

저장 도전

0.25m는 매우 높은 밀도다. 규칙적인 3D 텍스처로 저장하면 VRAM이 금방 폭발해 8GB, 16GB에 쉽게 달한다. 따라서 희소 저장 방안이 필요하다: 메시 표면에 가까울수록 고정밀 복셀을 저장하고, 0.25m라는 고밀도 데이터는 메시 표면 근처에만 붙어있는 게 좋다.

OpenVDB 방안

팀은 언리얼 엔진의 OpenVDB 저장 인코딩을 연구하면서 효율적인 방안을 참고해 구현했다. OpenVDB는 Houdini의 핵심 컴포넌트로 볼 렌더링 분야에서 매우 성숙한 솔루션이다.

계층 저장 구조:

데이터 블록의 가로 크기는 64×64m로, 오프라인 분할 저장의 기본 단위다. 각 데이터 블록 내부는 4m 정밀도로 규칙적인 거친 복셀 요소를 저장한다. 규칙적 구조이지만 수량은 제어 가능하다.

계층 세분화

각 4m 복셀을 64개의 1m 복셀로 분열시킨다. 단, 이번에는 메시 표면에 가까운 것들만(예: 3m 이하) 보존하고 나머지는 삭제한다.

최고 정밀도 레이어

한 번 더, 1m 복셀을 계속 분열시켜 0.25m 복셀을 형성한다. 이번에는 임계값을 더 압축해 메시 표면에 아주 가까운 것들만(0.3m) 보존한다. 이렇게 하면 기본적으로 메시 표면에 딱 붙어있게 된다.

6.4 데이터 인덱싱: Bitmask 가속 접근

트리 구조

이렇게 하면 논리적으로 위에서 아래로 내려가는 트리 데이터 구조가 형성된다 — 64진 트리. 루트 노드는 4m부터 시작한다(실제 최상위 루트 노드는 없음).

접근 알고리즘

World Position이 주어졌을 때 어떻게 해당하는 0.25m 고정밀 복셀을 찾아갈까? OpenVDB 알고리즘을 참고한다:

1. 복셀 트리를 BFS(너비 우선 탐색) 순서로 평탄화해 시퀀스를 만든다
2. 트리 구조를 인덱스로 사용한다

각 데이터 노드에 64bit의 Exist Mask(비트마스크)를 정의한다. 해당 노드의 64개 자식 노드 중 어느 것이 보존되었는지(1=보존, 0=메시와 너무 멀어 버려짐)를 표시한다.

이 Bitmask는 규칙적인 4×4×4 = 64개 자식 노드의 존재 여부를 담은 소형 국소 dense volume이다. 부모 노드 기준의 로컬 좌표를 주면 Bitmask의 어느 bit에 해당하는지 빠르게 알 수 있다.

해당 자식 노드가 보존되었다면, 몇 번째 자식 노드인지 알아야 한다. Bitmask 시작부터 해당 위치까지 1이 몇 개 있는지 세면 된다. GPU에는 Count Bits 명령어가 있어 이를 빠르게 처리할 수 있다.

각 노드는 첫 번째 자식 노드의 인덱스 M을 저장하며, M + Count Bits 결과(예: 2)를 더하면 M+2가 되어 매우 낮은 비용으로 자식 노드의 시퀀스 상 인덱스를 얻을 수 있다.

이는 BFS의 성질을 활용한 것: 한 노드의 자식 노드들은 시퀀스에서 반드시 연속으로 배열된다. 이 과정을 최대 3번 반복하면 0.25m 정밀도의 복셀에 접근하거나 Miss가 된다.

트리의 시퀀스 순서에 따라 해당하는 조명 시퀀스도 정렬한다. 어느 Position에 대응하는 트리 인덱스를 얻으면 조명 시퀀스의 데이터를 조회할 수 있다.

6.5 데이터 압축: 그레이디언트 최적화 기반 방안

압축 필요성

희소 저장을 거쳐도 전체 용량은 여전히 꽤 크다. 각 복셀은 48바이트(6방향 IMNQ, 방향당 8바이트)다. 맵이 TOD를 지원하면 복셀당 더 많은 데이터를 저장할 수도 있다. 추가 압축이 필요하다.

Support 포인트 방안:

Probe 생성

오프라인에서 OpenVDB를 호출해 메시 표면을 따라 Probe 레이어를 support 포인트 데이터로 생성한다. 이 Probe들의 밀도는 복셀보다 훨씬 희소하며, 각 Probe에 48바이트짜리 IMNQ를 베이크한다. 여러 시간대(예: 하루 8개 시간대)가 있으면 8개를 베이크해 모두 게임 패키지에 저장한다.

Probe 데이터는 매우 희소할 수 있으며, 수량이 많아도 문제없다.

선형 조합

각 복셀은 가장 가까운 4개 Probe의 IMNQ 조명을 선형 조합해 원래 결과를 근사할 수 있다. 이렇게 하면 각 밀집 복셀은 4개 인덱스(어떤 4개 Probe를 가리키는지)와 4개 float(조합 가중치)만 저장하면 되므로 고정 16바이트로, 48바이트보다 훨씬 작다.

인접 복셀의 인덱스도 유사하므로 Run-Length Encoding 방식으로 추가 압축하기 쉽다.

전역 최적화 문제:

최적화 목표

모든 복셀의 가중치와 모든 Probe의 support 벡터 데이터를 변수로 삼는다. 이 데이터들을 조정해 각 복셀의 선형 조합 결과와 원래 데이터의 차이를 최소화하는 것이 목표다(미분 계산을 위해 차이의 제곱 형태를 사용).

모든 복셀의 차이 제곱을 합산해 이 합이 최소화되기를 바란다 — 이는 전역 최적화 문제다.

그레이디언트 최적화

어렵게 보이지만, 이 함수는 가중치든 Probe 데이터든 편미분을 쉽게 구할 수 있다. 함수 자체가 이차 형식이고 병적 구조가 없으므로, 미분 기반의 그레이디언트 최적화를 직접 활용할 수 있다.

구체적으로는 켤레 기울기법(Conjugate Gradient)을 사용하며 특별히 어려운 점은 없다.

최적화 구현:

최적화 성능

SIMD와 데이터 지향 설계 기반의 켤레 기울기 최적화 기를 구현했다. 64×64m 데이터 블록 하나를 단일 코어로 9초 만에 최적화할 수 있다(실제 프로덕션에서는 멀티코어 병렬 처리). 데이터 블록 하나당 평균 0.5초도 안 걸려 베이커의 베이크 시간보다 훨씬 짧다.

6.6 VRAM 제어 및 최적화 사고

VRAM 통계

모든 최적화 이후 VRAM 점유: 도검 맵은 데이터의 수직 높이가 크지만 Volume GI의 총 VRAM은 200MB 내외로 제어되어 허용 가능한 수준이다.

사고 순서를 강조해야 한다: Volume GI 방안의 성비를 먼저 고려하고, 0.25m 복셀이 필요하다는 결론을 도출한 뒤, 이후의 모든 효율 최적화를 진행한다. 개발 중 어떤 게 더 멋있어 보이는지로 접근하지 말 것. 그러면 다른 함정에 빠질 수 있다.

7. 전체 씬 커버리지: 신경망 기반의 원경 GI

원경 요구사항

PC에서는 GI의 가시 거리(특히 태양광 간접광)가 맵 전체를 커버하기를 원한다. 앞서 언급한 고정밀 GI 데이터는 일정 범위만 커버하므로 전체 맵을 커버할 수 없다.

해도 맵 가시 거리

해도 맵처럼 가시 거리가 더 먼 맵의 경우, 모든 가시 거리에서 GI 커버리지를 원한다. 근경 Volume GI 정도의 데이터 크기지만 맵 전체 GI를 모두 커버하는 데이터가 필요하다.

7.1 거대 복셀 방안

거대 복셀

여전히 희소 복셀 데이터 저장을 사용하되 복셀 한 변의 크기가 8m(더 크게 조정 가능)에 달한다. 전체 씬을 커버해도 총 수량은 많지 않다. 각 복셀의 저장 데이터량은 여전히 48바이트와 같은 자릿수여야 한다(2~3배는 괜찮지만 10~20배는 안 됨).

그냥 Ambient Q 하나를 저장하면 어떨까? 가능하지만 충분히 좋지 않다.

정밀도 문제

대형 복셀에 데이터가 하나뿐이라면 어떻게 샘플링해도 같은 데이터가 나와 멀리서 보면 뭉개져 보인다. 근경에 가까운 정밀도를 제공하기를 원한다.

7.2 소형 신경망 표현 함수

함수 요구사항

큰 Cube 안에서 임의의 XYZ 로컬 좌표를 주었을 때, XYZ를 입력하면 해당 위치의 조명을 반환하는 비교적 컴팩트한 함수 F를 원한다. 이 반환값이 꽤 정확해야 한다.

건물 차폐

건물을 제거하면 함수가 반환하는 것은 하늘광의 상방 가시성이다. 건물 차폐가 있는 상태에서 내부는 상당히 어둡게 표현되며 이 시뮬레이션이 꽤 정확하다. 큰 Cube에 데이터가 하나뿐이라면 이런 변화는 없을 것이다.

신경망 구조

이 함수는 소형 심층 신경망을 사용한다: 폭 4, 히든 레이어 2개, 활성화 함수는 Leaky ReLU. 복셀 내부를 베이커로 밀집 베이크해 대량의 훈련 데이터를 제공(대량의 XYZ와 그에 해당하는 조명값)하고, 이 데이터로 소형 신경망을 훈련한다.

이 네트워크의 저장량은 몇 개 행렬(2개의 행렬 곱 연산)이면 된다. 입력은 XYZ, 히든 레이어 2개, 출력은 단일 수치 Luminance(RGB가 아닌 이유는 훈련 정밀도를 높이기 위함).

추론 오버헤드

신경망이지만 매우 작으므로 런타임 부하가 크지 않다. 8m 범위 내에서 충분히 높은 정밀도를 제공할 수 있다.

훈련 구현:

레이어 수가 매우 적어 복잡한 프레임워크나 자동 미분이 필요 없다. 각 파라미터의 미분을 수동으로 작성하고 켤레 기울기 최적화기를 계속 사용하면 된다. GPU 서버 파이프라인에 배포할 필요가 없어 오프라인 베이크 파이프라인이 망가지는 걸 피할 수 있다.

7.3 신경망 효과 시연

외부 효과

외부에서 보면 신경망의 하늘광 가시성 근사가 베이커의 베이크 효과에 매우 근접하며 정밀도가 상당히 높다.

내부 누광

건물 내부에서 보면 물론 여전히 누광이 생기지만, 원경 데이터로서는 괜찮다 — 원경 아래에서는 모두 실외에서, 먼 거리에서 실내를 바라보게 된다. 조명은 반드시 더 밝은 곳에서 더 어두운 곳으로 누광되므로(더 밝은 곳의 수치 변화가 최적화기에서 더 큰 그레이디언트를 만들기 때문), 알고리즘은 반드시 더 밝은 곳을 우선 처리한다. 원경 데이터로서는 문제없다.

분단 선형 특성:

Leaky ReLU의 비선형성은 MAX(0.2x, x)에서 오므로 함수 전체 출력은 분단 선형 함수다. 내부 누광 구조에서도 꺾은선들로 이루어진 형태다. 여러 꺾은선으로 건물 형태를 근사하는 것은 마치 소묘처럼 — 최대한 많은 직선으로 형태를 근사한다. 물론 직선이 무한히 많지는 않고, 꺾은선 수는 Leaky ReLU의 수와 같다.

7.4 원경 커버리지 효과

커버리지 비교

비교를 보면, 전체 씬 커버리지 방안이 맵 전체의 간접 조명에 커버리지를 제공한다는 걸 알 수 있다. 해도 맵은 더 먼 가시 거리 커버리지 효과를 보여준다.

감옥 비교

감옥 씬의 비교가 매우 뚜렷하며 원경 조명 디테일이 풍부하다.

VRAM 점유

전체 씬 방안의 VRAM 점유(UASSET에 저장된 원시 데이터 크기, 비압축):

• 폭풍의 눈: 22MB
• 도검: 11MB
• 감옥: 8MB

이 데이터량은 전체 맵 커버리지 치고는 매우 합리적이며 완전히 수용 가능하다.

8. 성능 분석: Depth Pre-Pass에 근접한 오버헤드

성능 통계

3080 그래픽 카드에서 테스트한 결과, Base Pass가 0.85ms일 때 전체 GI(원경 GI + 근경 + 전부 포함)의 총 소비는 0.35ms로, Depth Pre-Pass의 0.32ms에 더 가깝다.

성능 결론:

Depth Pre-Pass에 근접한 성능 오버헤드로 전체 GI를 구현했으며, 이 비용은 수용 가능하다. 여기에 더해:

• 누광 방지가 이미 제작 단계에서 대부분 해결되었다
• 런타임에 누광을 특수 처리하는 값비싼 Pass가 전혀 없다
• 총 VRAM을 200MB 내외로 제어할 수 있다

이래야 비로소 성비 높은 GI 방안이라 할 수 있다. 이 모든 문제에 걱정이 없어진 뒤에야 대폭 낮아진 제작 비용이 의미 있어진다.

9. 모바일 방안: 규칙적 텍스처 + IVY 누광 방지

모바일 방안

모바일의 전체 방안은 여전히 Lightmap + Volume GI 조합이다. Volume GI를 PC만큼 눈을 즐겁게 할 수 없으므로 모바일에서 Lightmap의 사용 범위가 실제로 더 크다.

커버리지 범위

Lightmap에는 여전히 인공광과 하늘광 가시성만 담겨 있고, 태양광의 간접광은 Volume GI가 담당한다.

9.1 CPU-GPU 협동 비동기 방안

아키텍처 설계

모바일은 일반적으로 GPU 병목 상태이므로 GPU에 부담을 너무 많이 줄 수 없다. GPU가 실시간으로 복셀 트리에 접근하면 너무 소비가 크다.

반면 모바일의 CPU는 현재 대개 8코어(빅코어 4개 + 리틀코어 4개)인 경우가 많다. 비교적 여유 있는 리틀코어 하나를 사용해 비동기로 3D 텍스처를 조립하는 것이 적합하다. 따라서 카메라를 둘러싼 3D 텍스처를 비동기로 조립하면 GPU는 그냥 샘플링만 하면 되어 조명 데이터를 즉시 꺼낼 수 있다.

이것이 Volume Texture 샘플링보다 얼마나 더 소비가 클까? 기존에는 2D 텍스처를 샘플링했고 이제는 3D 텍스처를 샘플링할 뿐, 오버헤드 증가는 미미하다.

9.2 분단 연속 저장

저장 구조

모바일도 마찬가지로 오프라인 분할 저장 데이터가 필요하다. 그러나 각 데이터 블록 내부는 희소 저장을 사용할 수 없고(패키지 용량은 절약되지만 CPU 접근 시 cache miss가 많아 CPU 비친화적), 단순 규칙적 저장도 사용할 수 없다(CPU 접근은 편리하지만 공간 점유가 매우 커서 패키지 용량 소모가 크다).

절충 방안

절충안을 사용한다: 각 데이터 블록 내부를 분단 연속 저장으로 한다. 각 분단 내부는 규칙적인 직육면체 격자, 즉 소형 로컬 3D 텍스처이지만 자신의 로컬 공간만 포함한다.

카메라를 둘러싼 3D 텍스처를 실시간 조립할 때, 각 데이터 블록을 3D 텍스처의 해당 위치에 정렬해 데이터를 복사한다. 이 3D 텍스처는 각종 이음새 처리를 통해 안정적인 VRAM 점유를 추구하며, 계층별로 GPU에 업로드한다.

모바일 ARM의 반정밀도 부동소수점 SIMD 명령어를 적극 활용하면 조립 과정을 크게 가속할 수 있다.

9.3 IVY 누광 방지 방안

누광 도전

모바일 누광 방지는 전체 GI 방안에서 가장 어려운 부분이다. 3D 텍스처 정밀도는 1m인데 벽 두께가 1m가 되는 건 불가능하므로 제작으로 해결할 수 없다.

IVY 개념

Tier Volume(IVY)이라는 볼륨을 정의한다. IVY는 건물과 함께 제작되며, 단순화된 메시로 건물 형태를 대략적으로 표현한다. IVY는 다면체로 여러 면으로 구성된다.

제작 요건:

• 하나의 건물에 여러 IVY를 조합할 수 있다
• 각 IVY는 반드시 볼록 다면체여야 한다
• IVY의 각 면은 벽 안에 위치해야 한다

IVY 면과 복셀 위치를 기반으로 오프라인에서 실제로 누광을 일으킬 수 있는 복셀들을 찾아 해당 복셀들을 면과 연결한다.

런타임 판단

런타임에 카메라가 면의 앞뒤 어느 쪽에 있는지에 따라, 해당 복셀이 벽의 반대편에 있는지 판단한다. 그렇다면 해당 복셀의 수치를 날려버린다(0으로 설정).

누광 영역이 3D 텍스처 곳곳에 산재해 있고 텍스처는 프레임을 나눠 업로드할 수밖에 없어 지연 업데이트 현상을 허용해야 한다. PVP 대전 중에 플레이어들은 이 디테일을 눈치채지 못하며, 어쩔 수 없는 부분이다.

9.4 모바일 데이터 압축

압축 방안

모바일의 데이터 압축은 PC와 유사하되, Probe가 더 희소하다. 메시 근처에는 데이터 블록이 있고, 메시에서 멀리 떨어진 곳에 데이터가 필요하면 가장 가까운 Probe의 조명을 직접 사용한다. 따라서 메시에서 멀리 떨어진 곳에는 가장 가까운 Probe를 가리키는 Distance Field를 동적으로 생성해야 한다.

9.5 패키지 용량과 성능

패키지 용량 제어

패키지 용량 제어는 모바일에서 가장 중요한 지표다. 가장 큰 맵의 GI 데이터가 334MB에 달한다. 이를 Lightmap으로 했다면 GI 패키지 용량이 5배 이상 불었을 것이다(물론 이렇게 큰 맵 전체를 Lightmap으로 하는 건 현실적으로 불가능하다).

순수 Lightmap 대비 패키지 용량이 대폭 줄어 목적을 달성했다. IVY 방식의 누광 방지도 큰 부작용 없이 해결되었다. 태양광 간접광의 강도는 Lightmap 대비 실제로 소폭 증가했지만(카메라 기준 64m 범위만), 모바일에서는 충분하다. 총체적 성비 OK, 문제없다.

10. 원경 방안: 평균값에서 방향 텍스처까지

원경 방안

원경에는 평균값이 바닥에 깔리며, 고사양 기기에서는 구면 조화 함수(Spherical Harmonics)로 구운 2D Texture로 디테일을 추가할 수 있다.

매우 중요한 점은 SIMD 최적화를 대량으로 활용했다는 것이다. 언리얼 엔진의 SIMD 래핑은 매우 완성도가 높아 함수 이름만으로 바로 호출할 수 있으며, SIMD intrinsic 함수의 암호 같은 코드를 직접 작성할 필요가 없다.

11. 싱글 캠페인: Lumen의 무대기 체험

Lumen 방안

싱글 캠페인 모드에서 할 말은 그리 많지 않다. Lumen 자체의 개발 시간은 매우 짧았다. 아무도 기다릴 필요 없는 실시간 방안으로서 아티스트가 조정하면 즉시 조명 효과를 확인할 수 있어 반복 조정 효율이 매우 높고 조명 품질도 더 높다.

구현 세부사항

이차 개발 없이 언리얼 엔진 기본 Lumen을 사용했다. 소프트 레이 트레이싱을 사용하며 하드웨어 레이 트레이싱은 켜지 않았다. 실험 결과 3080급 이상 그래픽 카드에서 하드웨어 레이 트레이싱 Lumen의 성능이 소프트 레이 트레이싱을 넘어서므로, 저사양 그래픽 카드를 소폭 배려했다.

12. 결론 및 전망

정리

12.1 핵심 경험

Lightmap과 Volume GI의 트레이드오프: 성능과 효과 요구사항을 만족하는 한 Volume GI를 더 많이 사용해 제작 효율을 높이는 게 좋다. 0.25m에서 0.1m(Lightmap의 일반적인 텍셀 정밀도)로 억지로 올리면 한계 효용이 다소 체감하므로 Volume GI를 더 많이 활용해 효율을 높일 수 있다.

누광 방지가 핵심: 누광 방지를 잘하는 것이 Volume GI가 성비 함정에서 벗어나는 열쇠다. Volume GI를 할 때 누광 방지를 먼저 고려한 뒤 다른 알고리즘을 생각해야 한다고 해도 과언이 아니다.

플랫폼 차별화 전략:

• PC에서는 VRAM 제어에 집중
• 모바일에서는 패키지 용량 제어에 집중

12.2 기술 트렌드

Lumen의 미래: Lumen처럼 제작 효율을 크게 향상시키는 방안은 몇 년 후 최저사양 그래픽 카드가 3080급이 되는 때가 오면 반드시 시장에서 매우 보편적인 방안이 될 것이다.

혼합 방안이 주류: 《델타포스》, 《원광》, 《콜 오브 듀티》 등 현대 게임들의 실천을 보면, Lightmap, Volume GI, 동적 GI라는 스펙트럼 위에서 혼합 방안을 채택하고 씬과 플랫폼에 따라 "구간 최적화"를 하는 것이 이미 하나의 트렌드가 되었다.

맺음말

《델타포스》의 글로벌 일루미네이션 방안은 현대 크로스플랫폼 게임 개발의 기술적 지혜를 보여준다: 모든 문제를 해결할 수 있는 단 하나의 방안은 없지만, 서로 다른 기술에 대한 깊은 이해와 합리적인 조합을 통해 성능, 효과, 제작 효율 사이의 최적 균형점을 찾을 수 있다.

제작 프로세스 관점에서 0.25m 누광 방지 기준, OpenVDB 기반 희소 저장, 그레이디언트 최적화를 통한 데이터 압축 등 모든 기술 세부사항이 "아티스트가 기다릴 필요 없게 한다"는 핵심 목표를 위해 존재한다. 알고리즘 혁신 관점에서 소형 신경망으로 원경 GI 커버리지를 구현하고, 모바일에서 CPU 비동기 조립 + IVY 누광 방지 방안을 채택한 것은 하드웨어 특성에 대한 깊은 이해를 보여준다.

이러한 "수요에서 출발해, 성비를 핵심으로, 다중 방안 조합 최적화"라는 엔지니어링 사고방식은 게임 그래픽 개발 전체 분야에 중요한 참고 가치가 있다. 하드웨어 성능의 지속적인 향상과 알고리즘의 꾸준한 발전과 함께, 앞으로 더 많은 게임이 플레이어에게 아름답고 부드러운 빛과 그림자 경험을 제공할 수 있으리라 믿는다.

본 문서의 내용은 위동신이 UFSH 2025 컨퍼런스에서 발표한 기술 내용을 기반으로 정리했습니다. 전체 영상은 다음 주소에서 확인할 수 있습니다:

[UFSH2025] 델타 작전의 글로벌 일루미네이션 | 웨이동첸 텐센트 톈메이 J3 스튜디오 엔진 개발 Engineer_Game 인기 영상

[UFSH2025]《三角洲行动》中的全局光照方案 | 蔚东辰 腾讯天美J3工作室 引擎开发工程师_游戏热门