확장성 높은 멀티플랫폼 그래픽 실전 전략

이 문서를 관통하는 하나의 논점

중간에 나오는 대안 세 가지(DFAO / Skylight Fade Volume / Stationary 라이트 베이크)는 서로 달라 보이지만 전부 같은 질문에 대한 답입니다 — 루멘 없이 스카이라이트 오클루전을 어떻게 확보할 것인가.루멘을 끄는 것이 왜 “GI만 끄는 것”이 아닌지 이해하면 이 세 갈래가 한 줄기로 보입니다.

같은 게임을 낮은 티어까지 지원하는 것만으로 도달 가능한 유저가 25%에서 90%로 올라갑니다. 이 숫자 하나가 세션 전체의 명분입니다.

레이트레이싱 보급률도 같은 구조

레이트레이싱 대응 GPU는 Steam 유저의 상당수까지 보급됐지만, 반대로 말하면 나머지는 아직 레이트레이싱 미탑재 GPU를 쓰고 있습니다. 이 그룹에게도 게임을 전달하려면 하드웨어 레이트레이싱을 전제로 한 기능은 반드시 대안 경로를 함께 준비해야 합니다.^[2]

기초 다지기

루멘은 레이트레이싱 GPU가 없어도 돌아간다

루멘이 “레이트레이싱 기능”으로 오해되는 일이 많습니다. 공식 문서 기준으로 루멘은 두 개의 레이 트레이싱 방식을 갖고 있습니다. 기본값인 소프트웨어 레이 트레이싱은 메시 디스턴스 필드를 대상으로 추적하며, Shader Model 6(SM6)를 지원하는 모든 하드웨어에서 동작하고 프로젝트 설정의 Generate Mesh Distance Fields만 켜져 있으면 됩니다.

하드웨어 레이 트레이싱은 품질이 더 높지만 별도 요구사항이 있습니다 — 문서는 Windows 10 이상 + DirectX 12, NVIDIA RTX 2000 시리즈 이상 또는 AMD RX 6000 시리즈 이상, 그리고 PS5 / Xbox Series S·X / Switch 2를 지원 대상으로 명시합니다. 그리고 프로젝트 설정 설명이 “Lumen will fall back to Software Ray Tracing otherwise”입니다. 즉 미지원 환경에서 루멘이 꺼지는 게 아니라 소프트웨어 경로로 내려갑니다. 이 절의 40%가 곧 “루멘을 못 쓰는 유저”는 아니라는 뜻입니다.

세 개의 파일이 각각 하는 일

엔진 파일은 Base*, 프로젝트 파일은 Default*라는 규칙이 config 전체에 일관되게 적용됩니다. 프로젝트에서 엔진 기본값을 덮어쓰려면 같은 카테고리 이름을 유지한 채 접두어만 바꿔 파일을 만들면 됩니다.

프리셋의 실체 — sg.ShadowQuality를 열어보면

공식 문서가 sg.ShadowQuality의 각 단계에 어떤 CVar가 들어가는지 그대로 공개합니다. Low가 0, Epic이 3입니다.

; sg.ShadowQuality 0  (Low)
r.LightFunctionQuality=0
r.ShadowQuality=0
r.Shadow.CSM.MaxCascades=1
r.Shadow.MaxResolution=512
r.Shadow.RadiusThreshold=0.06

; sg.ShadowQuality 3  (Epic)
r.LightFunctionQuality=1
r.ShadowQuality=5
r.Shadow.CSM.MaxCascades=4
r.Shadow.MaxResolution=1024
r.Shadow.RadiusThreshold=0.03

기초 다지기

디바이스 프로파일은 스케일러빌리티보다 나중에 적용된다

두 시스템이 같은 CVar를 건드릴 때 누가 이기는지가 실무에서 매번 문제가 됩니다. 공식 문서의 답은 명확합니다 — “Scalability groups apply their console variable settings before device profiles. Settings defined in specific device profiles will override those in scalability groups chosen by the user.”엔진은 CVar마다 “누가 설정했는가” 우선순위를 들고 있고, SetByScalability가 SetByDeviceProfile보다 낮습니다.

그래서 실전 패턴은 이렇게 됩니다. 디바이스 프로파일에서 먼저 sg.PostProcessQuality 같은 그룹 값을 지정해 기준선을 잡고, 그 위에서 개별 CVar만 다시 덮어쓴다. 프로파일은 부모-자식 계층을 가지므로 Android 같은 상위 프로파일의 값이 먼저 적용되고, 그 아래 성능 버킷과 특정 GPU 프로파일이 순서대로 덮어씁니다.

; <프로젝트>/Config/DefaultDeviceProfiles.ini
[iPhone5S DeviceProfile]
DeviceType=IOS
BaseProfileName=IOS
+CVars=r.MobileContentScaleFactor=2
+CVars=r.BloomQuality=1
+CVars=r.DepthOfFieldQuality=1
+CVars=r.LightShaftQuality=1

BaseProfileName이 부모 프로파일을 가리키는 키이고, +CVars=가 config 배열에 항목을 덧붙이는 표준 연산자입니다. 엔진이 넣어둔 배열을 통째로 비우려면 !CVars=ClearArray를 씁니다.

짚어둘 점

플랫폼별 .ini는 파일 이름이 곧 경로 규칙이다

config 파일은 카테고리별로 계층 구조를 이루고, 같은 카테고리 안에서 중복된 키가 있으면 나중에 읽힌 파일이 이깁니다. 공식 문서가 12단계 로드 순서를 그대로 공개하는데, 그중 플랫폼 관련만 뽑으면 다음과 같습니다.

Engine/Config/Base.ini
Engine/Config/Base<CATEGORY>.ini
Engine/Config/<PLATFORM>/Base<PLATFORM><CATEGORY>.ini
Engine/Platforms/<PLATFORM>/Config/Base<PLATFORM><CATEGORY>.ini
<프로젝트>/Config/Default<CATEGORY>.ini
Engine/Config/<PLATFORM>/<PLATFORM><CATEGORY>.ini
<프로젝트>/Config/<PLATFORM>/<PLATFORM><CATEGORY>.ini
<프로젝트>/Platforms/<PLATFORM>/Config/<PLATFORM><CATEGORY>.ini

여기서 두 가지를 읽어야 합니다. 첫째, 프로젝트의 Default*보다 플랫폼 파일이 나중에 읽히므로 플랫폼 설정이 항상 이깁니다. 둘째, 파일 이름은 “플랫폼 + 카테고리” 조합으로 기계적으로 정해집니다. 그래서 안드로이드의 디바이스 프로파일은 Config/Android/AndroidDeviceProfiles.ini가 되고, 윈도우의 엔진 설정은 Config/Windows/WindowsEngine.ini가 됩니다. 규칙을 외우는 것이 아니라 조합을 이해하면 됩니다.

답 — 루멘이 계산하는 것은 GI만이 아니다

루멘은 스카이라이트 오클루전(스카이라이트의 그림자)을 동적으로 계산합니다. 공식 문서 표현이 정확히 이렇습니다 — “Sky lighting is solved as part of Lumen’s Final Gather process. It includes sky shadowing, allowing indoor spaces to be much darker than outdoor lighting, providing a much more natural effect.”

루멘을 끄면 간접광과 함께 하늘 그림자도 잃고, 화면에서 먼저 눈에 띄는 것은 하늘 그림자입니다.

기초 다지기

스카이라이트 오클루전이 왜 그렇게 중요한가

스카이라이트는 하늘 전체를 하나의 거대한 광원으로 취급하는 라이트입니다. 차폐 계산이 없으면 하늘이 보이지 않는 실내의 픽셀도 하늘이 그대로 보이는 실외 픽셀과 같은 양의 빛을 받습니다. 결과가 “어디를 봐도 밝은 회색”인 납작한 화면입니다.

디렉셔널 라이트의 그림자는 섀도 맵으로 해결됩니다. 광원이 하나고 방향이 하나이기 때문입니다. 반면 스카이라이트는 모든 방향에서 들어오므로 섀도 맵 한 장으로 표현할 수 없습니다. 반구 전체에 대해 “이 픽셀에서 하늘이 얼마나 보이는가”를 물어야 하고, 그것이 레이 트레이싱이나 디스턴스 필드 같은 공간 표현을 요구하는 이유입니다. 아래 대안 세 가지가 전부 “공간을 다르게 표현하거나, 아예 수작업으로 대체하는” 방향인 것도 여기서 나옵니다.

루멘 라이트(Lumen Lite) — 스케일러빌리티 Medium의 새 이름

스케일러빌리티의 GI Quality를 Medium으로 설정하면 자동으로 루멘 라이트가 됩니다. 즉 별도 토글이 아니라 스케일러빌리티 단계 자체입니다.

sg.GlobalIlluminationQuality 1   ; Medium = 루멘 라이트 경로
sg.ReflectionQuality 1           ; Medium = 루멘 리플렉션 대신 SSR

; Medium GI가 내부적으로 쓰는 파이널 개더 방식
r.Lumen.FinalGatherMethod 0

대안 A — DFAO (Distance Field Ambient Occlusion)

앰비언트 오클루전이므로 GI에는 영향을 주지 않습니다. 다만 스카이라이트 오클루전에 대해서는 근사적이지만 매우 좋은 효과를 냅니다. 공식 문서의 정의가 이 성격을 그대로 설명합니다 — “Shadowing for Movable Sky Lights is provided by using Signed Distance Field Volumes precomputed around each rigid mesh to generate medium scale Ambient Occlusion.”

대안 B — Skylight Fade Volume (수동 조정)

기본 아이디어 — 루멘이 없으면 스카이라이트에 그림자가 없어지므로, 건물 안에 들어가면 스스로 스카이라이트 인텐시티를 낮추는 커스텀 볼륨을 배치해서 넘깁니다. 알고리즘이 아니라 레벨 디자인으로 푸는 접근입니다.^[7]

대안 C — 라이트 베이크와 루멘의 하이브리드

해당 타이틀은 동적 라이트 변화나 동적 씬 변화가 거의 없어 라이트 베이크를 채용했습니다. 그러면서도 하이엔드 플랫폼에서는 루멘으로 고품질 GI와 반사를 얻고 싶었기 때문에, 루멘이 안 돌아가는 로우스펙 플랫폼에서만 베이크를 쓰는 하이브리드 구성을 취했습니다.

이 절의 결론

스카이라이트 오클루전에는 현재도 하나의 정답이 없습니다.여러 개발자가 각자 프로젝트에 맞는 접근을 모색하는 중이며, 위 세 갈래는 “선택지”이지 “권장 순서”가 아닙니다.

여기서 UE4 시절의 숙제가 되살아난다

폴백 메시는 곧 평범한 폴리곤 모델입니다. 따라서 UE4 시절과 마찬가지로 LOD를 주의 깊게 만들어야합니다. 이 세션이 “UE4 시절 기능이 여전히 유효하다”고 말하는 첫 번째 근거가 여기입니다.

기초 다지기

폴백 메시의 밀도를 결정하는 두 개의 손잡이

스태틱 메시 에디터의 Nanite 설정에는 Fallback Target이 있고, 여기서 어떤 기준으로 폴백을 만들지 고릅니다. 공식 문서가 정의하는 두 기준은 이렇습니다.

그리고 나나이트를 끈 환경을 흉내 내는 공식 방법이 있습니다 — “Nanite rendering can be enabled and disabled globally at runtime using the console variable r.Nanite 0. Disabling Nanite is a good way to emulate platforms where it is not supported.” 타깃 하드웨어를 구하기 전에 폴백 품질을 점검하는 가장 값싼 수단입니다.

r.Nanite 0                 ; 런타임에 나나이트 전체를 끔 (미지원 플랫폼 흉내)
r.Nanite.ProxyRenderMode 0 ; 폴백 메시 또는 스크린 스페이스 기반 LOD로 그림
                           ;   (스태틱 메시 에디터의 Min LOD 설정도 이때 반영됨)

자동 생성 vs 수동 제작

• 폴백 메시는 엔진이 내부적으로 자동 생성할 수 있고, 대부분의 에셋은 자동 생성으로 충분합니다.
• 다만 중요한 에셋처럼 아티스트가 정성껏 LOD 모델을 만들고 싶은 경우도 있습니다. 공식 문서도 이 필요를 인정합니다 — “there are times when it is desirable to use a manually specified fallback mesh, or a series of traditional LODs, rather than an auto-generated one.”
• 솔직히 말해 워크플로가 아직 잘 정비되어 있지 않고 설정이 독특합니다. 향후 개선될 수 있으나, 현재는 공식 문서에 절차가 공유되어 있으니 그것을 따라 시도해볼 것을 권합니다.

콜리전을 이 LOD에 맞추려면 General Settings의 LOD for Collision속성을 함께 지정합니다. Q&A에서 나온 “폴백 메시가 깨진다”는 현상도 결국 이 수동 경로로 해결하는 문제입니다.

파생 문제 — 메모리, 그리고 Mesh Streaming

폴백 메시로 오브젝트 단위 폴리곤 수는 조정했더라도, 통상 폴리곤 렌더링이 되면서 나나이트가 갖고 있던 스트리밍 기능이 사라집니다. 많은 에셋이 많은 LOD 모델을 보유하게 되어 메모리 소비량이 매우 커질 우려가 있습니다.

LOD는 아직도 스케일러빌리티의 1급 손잡이다

폴백 경로로 내려오면 “무엇을 언제 바꿔 그릴지”가 다시 프로젝트의 책임이 됩니다. 엔진이 스케일러빌리티 프리셋에서 직접 제공하는 손잡이도 그대로 살아 있습니다.

r.SkeletalMeshLODBias   ; 스켈레탈 메시의 LOD 레벨을 전역으로 바이어스
r.ViewDistanceScale     ; 컬링 거리에 곱해지는 전역 배율 (0.4 / 0.7 / 1.0 …)
r.DetailMode            ; 0=Low, 1=Medium, 2=High — 액터의 Detail Mode 기준선

사진 · 자료

r.SkeletalMeshLODBias — 거리 기반 LOD 위에 얹는 전역 바이어스

r.ViewDistanceScale 0.4 → 1.0

r.DetailMode

기초 다지기

가상 16k 해상도를 128×128 페이지로 쪼갠다

공식 문서 기준으로 VSM은 가상 해상도 16k × 16k의 섀도 맵입니다. 그만한 텍스처를 매 프레임 실제로 그리는 건 불가능하고 대부분 낭비이기도 합니다 — 화면에 보이는 픽셀을 셰이딩하는 데 쓰이는 텍셀만 의미가 있으니까요. 그래서 물리적으로는 128 × 128 텍셀 페이지 단위로 쪼개서 필요한 페이지만 할당해 그립니다.

멀티플랫폼 관점에서 중요한 문장은 비용 쪽입니다. 문서가 두 가지를 명시합니다 — “Non-Nanite geometry is much more expensive to render into VSMs than Nanite geometry.” 그리고 “Virtual Shadow Maps are designed to be used with Nanite. If your target platform or project does not use Nanite, Virtual Shadow Maps is likely not a good fit.” 즉 앞 절에서 나나이트를 끈 플랫폼은 자동적으로 VSM에도 맞지 않는 플랫폼이 됩니다. 두 결정이 사실 하나입니다.

미지원 플랫폼에서의 동작 — 매우 단순하다

엔진 쪽 스위치도 명시적입니다. 프로젝트 세팅의 Engine > Rendering > Shadows 섹션에 Shadow Map Method가 있고, Virtual Shadow Maps와 Shadow Maps(이전 릴리스에서 쓰던 기존 방식) 중 하나를 고릅니다. CVar는 r.Shadow.Virtual.Enable입니다.

r.Shadow.Virtual.Enable=0   ; 기존 섀도 맵 경로(CSM 포함)로 전환

; 그 다음부터는 CSM 손잡이를 직접 잡는다
r.Shadow.CSM.MaxCascades    ; 캐스케이드 최대 개수 (sg.ShadowQuality가 1/1/2/4로 설정)
r.Shadow.MaxResolution      ; 섀도 뎁스 렌더링의 최대 정사각 크기 (512 / 1024 …)
r.Shadow.RadiusThreshold    ; 너무 작은 오브젝트를 그림자 대상에서 제외
r.Shadow.DistanceScale      ; 디렉셔널 라이트의 그림자 거리 vs 성능 트레이드오프

캐스케이드 섀도 맵을 손으로 조율하는 법

CSM은 뷰 프러스텀을 거리 기반 캐스케이드로 나누고, 카메라에서 멀어질수록 해상도를 낮추는방식입니다. 디렉셔널 라이트 액터의 Cascaded Shadow Map 카테고리에서 조절하는 항목들이 곧 이 세션이 말하는 “캐스케이드 수나 크기 등 가능한 조정”입니다.

더 깊이

VSM은 LOD보다 나나이트에 가깝다

Q&A에서 “VSM과 LOD의 차이”를 묻는 질문이 나왔고, 답이 이 기법의 성격을 잘 정리해줍니다. VSM은 버추얼 텍스처라는 “텍스처”의 기능이고 LOD는 폴리곤 “모델”의 기능이므로 서로 다릅니다. 다만 사고방식은 가깝습니다 — 가까운 것은 정밀하게, 먼 것은 거칠게.

오히려 VSM이 더 가까운 것은 LOD보다 나나이트입니다.VSM이 하는 일은 같은 한 장의 텍스처 안에서도 화면에 표시되는 부분만 고밀도 밉맵을 내고, 멀리 비치는 부분은 저해상도로 처리하는 것입니다 — 랜드스케이프처럼 하나의 거대한 대상에서 특히 강력합니다. 나나이트가 하나의 메시 안에서 클러스터 단위로 디테일을 배분하는 것과 구조가 같습니다. 두 기능이 “세트로 설계됐다”고 문서가 말하는 이유도 여기 있습니다.

모든 라이트를 항상 정확히 평가하지 않습니다. 라이트 수가 아주 많아지면 제한된 샘플 안에서 전부를 충분히 평가할 수 없어 샘플링 노이즈나 부정확함이 보일 수 있습니다.

지원 범위 — 문서가 명시적으로 선을 긋는다

프로젝트 세팅의 Rendering > Direct Lighting에서 켜며, 이때 엔진이 Support Hardware Ray Tracing도 함께 켜라고 안내합니다. 문서는 이를 권장 설정으로 기술합니다.

멀티플랫폼에서 가장 중요한 주의점

제시된 선택지는 두 가지였습니다 — 모든 플랫폼에서 일률적으로 유효화 또는 무효화하거나, 스케일러빌리티를 고려해 플랫폼별로 거동을 바꿀 수 있는 독자적인 라이트를 직접 구현하거나.

기초 다지기

AA 방식은 하나의 CVar로 갈아끼운다

안티에일리어싱 방식은 r.AntiAliasingMethod 하나로 전환됩니다. 엔진의 EAntiAliasingMethod 열거형이 값을 그대로 정의합니다.

r.AntiAliasingMethod 0   ; AAM_None
r.AntiAliasingMethod 1   ; AAM_FXAA
r.AntiAliasingMethod 2   ; AAM_TemporalAA   (TAA / TAAU)
r.AntiAliasingMethod 3   ; AAM_MSAA         (포워드 셰이딩에서만 지원)
r.AntiAliasingMethod 4   ; AAM_TSR

r.ScreenPercentage            ; 내부 렌더 해상도
r.TSR.History.ScreenPercentage ; TSR 히스토리 해상도 (Epic/Cinematic AA 그룹은 200)
r.TemporalAA.Quality          ; TAA 품질 0 / 1 / 2

여기서 실무적으로 중요한 것은 이 전환이 CVar 하나라는 사실입니다. 그래서 플랫폼별 디바이스 프로파일에서 방식을 바꿀 수 있고, PC라면 유저 설정 화면에 그대로 노출할 수도 있습니다. TAAU 쪽은 별도 CVar가 아니라 프로젝트 세팅의 Temporal Upsampling 항목으로 켜고 끕니다.

하지만 TSR도 비용이 든다

공식 문서가 TSR의 비용 구조를 정확히 지목합니다 — “The History Update is the most expensive pass in TSR’s total GPU cost because the history is rendered at display resolution.” 즉 TSR의 주 비용은 내부 해상도가 아니라 출력 해상도에 붙습니다. 내부 해상도를 낮춰도 이 부분은 줄지 않습니다. 그래서 저스펙 환경에서는 내부 해상도를 과도하게 낮춰야 하는 상황이 되어 본말전도가 됩니다.

짚어둘 점

얇은 메시의 플리커링은 업스케일러로 해결되지 않는다

Q&A에서 “가는 선이나 얇은 메시에서 플리커링이 심하고 안티에일리어싱을 걸어도 변하지 않는다”는 질문이 나왔습니다. 답은 현재 TSR 등 업스케일링 메서드의 제약사항 중 하나이며 해소가 매우 어렵다는 것이었습니다. 저해상도로 렌더된 프레임에는 그 얇은 형상의 정보가 프레임마다 들어오거나 빠지고, 시간축 누적은 그 진동을 없애지 못합니다.

현장에서 쓰는 우회책은 렌더러가 아니라 에셋 쪽입니다 — 멀어지면 해당 오브젝트를 교체하는 LOD를 만들어, 세밀한 고주파 오브젝트 자체를 만들지 않는 것. 버추얼 텍스처도 동일합니다. 세밀한 버추얼 텍스처를 쓰면 같은 플리커링이 발생하므로, 고주파 텍스처에는 버추얼 텍스처를 쓰지 않는 방법을 취하는 개발자도 있습니다. 업스케일링 시대에도 LOD 설계가 화질 문제의 답이 되는 사례입니다.

두 가지 G-Buffer 포맷

공식 문서 표현은 “Substrate supports two different GBuffer formats for storing material data, Blendable GBuffer and Adaptive GBuffer”이고, 프로젝트 세팅 항목 이름이 Substrate GBuffer Format (Project)입니다.^[12]

r.Substrate.BytesPerPixel      ; 자동 단순화 전까지 허용할 픽셀당 저장 바이트 (기본 80)
r.Substrate.MaxClosureCount    ; 픽셀당 클로저 개수 상한
r.Substrate.BlendableGBuffer   ; 강제로 모든 머티리얼을 레거시 G-Buffer로 변환

멀티플랫폼 실무상의 결론

두 G-Buffer 포맷을 플랫폼별로 전환해 쓰는 것 자체는 가능합니다. 문제는 도구 쪽입니다.

참고로 새 프로젝트의 기본값은 Blendable이고, Automotive·Architectural 템플릿이 Adaptive를 씁니다. 게임 프로젝트라면 엔진의 기본 선택이 이미 “성능 중시 쪽으로 통일”이라는 뜻입니다.

방식 1 — 머티리얼 기반 VRS

1. 머티리얼의 Allow Variable Rate Shading을 활성화합니다(기본적으로 ON).
2. 머티리얼에 대해 어느 셰이딩 레이트를 쓸지 설정합니다.

방식 2 — Contrast Adaptive Shading (CAS)

이전 프레임의 묘화 결과를 보고 변화가 적고 시각적으로 매끄러운 영역을 자동 검출해, 그런 영역의 셰이딩 레이트를 자동으로 낮춰 GPU 부하를 삭감합니다. 엔진의 공식 릴리스 노트 설명이 “a new approach that analyzes the preceding frame to determine which areas can be rendered at rougher shading rates”입니다.

기초 다지기

공식 문서가 확인해주는 부분과 확인해주지 않는 부분

“모바일 렌더러가 PC에서 돌아간다”는 것 자체는 공식 문서로 확인됩니다. 모바일 디퍼드 셰이딩 문서의 디바이스 호환성 서술이 “Unreal Engine supports Mobile Deferred shading on all platforms that use the Mobile renderer, including PC platforms, iOS, Android Vulkan, and Android GLES.”입니다. including PC platforms가 이 절의 핵심 단어입니다.

전환 자체도 CVar 하나입니다 — “You can set which mobile shading model you want to use in your Engine.ini file with the CVar r.Mobile.ShadingPath”. 0이 모바일 포워드 셰이딩, 1이 모바일 디퍼드 셰이딩입니다.

; <프로젝트>/Config/DefaultEngine.ini
[/Script/Engine.RendererSettings]
r.Mobile.ShadingPath=1   ; 0 = Mobile Forward, 1 = Mobile Deferred

공식 문서가 확인해주지 않는부분은 “PC에서 성능 옵션으로 모바일 렌더러를 쓰라”는 권장입니다. 문서는 가능하다는 사실만 기술하고, 어떤 타이틀이 그렇게 하고 있는지는 다루지 않습니다.

더 깊이

포워드와 디퍼드 사이에서 무엇이 트레이드되는가

모바일 포워드는 공식 문서 설명대로 “라이팅과 그림자를 런타임에 처리하며, 미리 계산된 라이팅을 쓰는 프로젝트에 적합”합니다. 라이트마다 셰이딩을 다시 하므로 동적 라이트 개수에 민감합니다.

모바일 디퍼드는 라이트 수에 강하지만 G-Buffer를 만들어야 합니다. 모바일 하드웨어에서는 이 G-Buffer가 GPU 타일 메모리에만 존재하도록 설계되어 시스템 메모리 대역폭을 아끼는데, 그 대가로 나중에 도는 패스가 G-Buffer를 읽을 수 없습니다. PC에서 이 경로를 “경량 렌더러”로 쓸 때도 같은 제약을 물려받는지가 실무 검증 포인트입니다. 데스크톱 디퍼드에서 당연하게 쓰던 포스트 프로세스가 그대로 동작하지 않을 수 있습니다.

이 절을 이 문서의 결론과 연결하면

모바일 렌더러 재평가는 이 문서 전체와 같은 형태의 주장입니다. 로우엔드 대응의 실질적 도구는 신기능 목록이 아니라, 이미 엔진에 있으면서 이름 때문에 검토 대상에서 빠지는 기능들 쪽에 있습니다. LOD, 캐스케이드 섀도 맵, 라이트 베이크, 그리고 모바일 렌더러가 모두 같은 자리에 있습니다.

GPU 외에 CPU·SSD·메모리도 고려해야 하는가

세션이 보여준 것은 GPU 스펙 비교표뿐이었지만, SSD와 메모리도 매우 중요한 문제라는 답이 돌아왔습니다. 특히 콘솔은 메모리가 이상하게 적거나 디스크 로드가 매우 느린 등 고유하게 편중된 시스템인 경우가 있어 반드시 고려해야 합니다.

이 답이 앞의 Mesh Streaming 절과 이어집니다. 폴백 메시로 인한 LOD 증가가 메모리 문제로 번지는 것이 정확히 이 유형의 위험입니다.

폴백 메시가 깨지는 현상

질문자는 “하나의 메시 안에서 트라이앵글 고밀도 부분과 저밀도 부분이 크게 나뉠 때 발생하는 것 같다”고 짚었고, 답은 그대로 맞다였습니다. 폴백 메시 자동 생성에는 한도가 있고, 엔진이 자동으로 잘 만들어내지 못하는 것은 수동으로 준비하는 수밖에 없습니다. 앞 절의 수동 LOD 워크플로가 이 답의 실행 절차입니다.

AI 도구로 최적화를 자동화할 수 있는가

어느 정도의 최적화 지시는 가능하다고 보지만, 현재로서는 GPU에 맞춰 조정했을 때 “그대로 출시해도 좋다”고 할 수 있는 상황은 아니다는 답이었습니다. 여전히 세밀한 수동 조정이 필요합니다.

세션에서 직접 언급된 이전 강연

스케일러빌리티와 설정 구조

루멘과 라이팅

지오메트리 · 그림자 · 업스케일링 · 머티리얼

각주

1. 티어별 Steam 유저 커버리지 수치 — 세션은 포트나이트 권장 GPU 스펙을 Steam 하드웨어·소프트웨어 서베이와 대조해 약 25% / 약 75% / 90% 이상이라는 값을 제시했습니다. 두 출처 모두 실재하고 접근 가능하지만(에픽의 포트나이트 시스템 요구사항 페이지, Valve의 store.steampowered.com/hwsurvey), Steam 서베이는 월 단위로 갱신되고 포트나이트 요구사항도 개정되므로 특정 퍼센트를 고정값으로 확인할 수 없습니다. 티어 폭을 넓힐 때 도달 유저가 크게 늘어난다는 논지 자체는 두 자료의 구조에서 그대로 성립합니다. ↩
2. 레이트레이싱 대응 GPU 보급률 — 세션은 약 60% 보급 / 약 40% 미대응이라는 값을 제시했습니다. 위와 같은 이유로 고정 수치로는 확인되지 않습니다.다만 “미대응 GPU가 상당 규모로 남아 있다”는 전제는 루멘이 소프트웨어 레이 트레이싱 경로를 기본값으로 유지하는 공식 설계와 일치합니다. ↩
3. 프로젝트 스케일러빌리티 오버라이드 파일 이름 — 공식 문서가 안내하는 파일명은 DefaultScalability.ini이며, 프로젝트의 Config 폴더에 새로 만들라고 기술합니다. Scalability.ini라는 이름의 프로젝트 오버라이드 파일은 공식 문서에서 확인되지 않았습니다. 엔진 원본이 BaseScalability.ini라는 점은 문서에 반복해서 명시됩니다. ↩
4. 루멘 라이트의 개별 실측 수치 — 세션은 Unreal Insights의 Diffuse Indirect and AO 기준으로 1.4ms → 0.7ms라는 값을 제시했습니다. 에픽의 공식 발표는 “Lumen High Quality 대비 2배 빠르다”는 상대 비교만 기술하고, 개별 밀리초 수치는 공식 자료에서 확인되지 않습니다. 세션의 테스트 씬에서 측정된 값으로 보이며, 발표에서도 씬 구성에 좌우된다는 단서가 함께 달렸습니다. ↩
5. 새 개더 알고리즘의 명칭— 세션 정리 단계에서 이 알고리즘을 “Radiance Field Gather”로 추정했으나, 공식 자료에서 이 명칭은 확인되지 않습니다. 공식 성능 가이드가 쓰는 표현은 Irradiance Field Gather(같은 문서 안에서 “Irradiance Final Gather”로도 표기)이며, 활성화 CVar는 r.Lumen.FinalGatherMethod 0입니다. 반대편의 Screen Probe Gather는 공식 문서에 그대로 등장하는 명칭입니다. 본문은 혼동을 피하기 위해 확정된 쪽만 고유명으로 적었습니다. ↩
6. DFAO와 루멘의 비용 비교 — 세션이 제시한 약 0.75ms 대 약 7ms는 동일 플랫폼 테스트 케이스의 실측값이며 공식 자료에는 대응하는 수치가 없습니다. 다만 스케일을 내릴 때 DFAO가 루멘 GI를 대체하는 관계는 공식 성능 가이드에 기술되어 있어, 두 기법이 비용 계층상 다른 급이라는 논지 자체는 문서와 일치합니다. ↩
7. 대안 B·C의 출처 세션— 각각 “2년 전 언리얼 페스트”와 “2025년 언리얼 페스트” 발표 사례로 언급됐으나 정확한 개최지와 세션명은 확인되지 않았습니다. 두 사례의 기법 설명은 발표 내용을 그대로 옮긴 것이며, 원 강연을 찾으려면 언리얼 페스트 아카이브에서 별도 확인이 필요합니다. ↩
8. Stationary 라이트 한계 초과 시의 동작 — 세션은 겹치는 라이트가 5개 이상이 되면 일부를 Movable로 전환하는 사양이라고 설명했습니다. 공식 문서의 서술은 “Once the channel limit is reached, only dynamic (or whole scene shadows) are used, which brings with it considerable performance cost”로, “정적 섀도잉을 잃고 동적 그림자만 쓰게 된다”는 결과를 기술합니다. 결과적으로 해당 라이트가 동적으로 처리된다는 점은 같지만, “랜덤하게 Mobility가 바뀐다”는 표현은 문서에서 확인되지 않습니다. 한계를 넘기지 않도록 반경을 줄이는 대응책의 유효성은 어느 서술에서도 동일합니다. ↩
9. Mesh Streaming의 프로덕션 사용 사례 — 세션은 이 기능이 실제 대규모 타이틀에서 사용 중이라 안정적이라고 소개했습니다. r.MeshStreaming CVar가 존재하고 프로젝트 세팅이 이를 DefaultEngine.ini에 기록하는 것, 스태틱 메시의 Num Streamed LODs 속성이 있는 것은 확인됩니다. 다만 이 기능을 다루는 전용 공식 문서 페이지와, 특정 타이틀이 사용 중이라는 공식 서술은 확인되지 않았습니다. 엔진 개발자의 포럼 답변에서 실험적 표기가 제거됐다는 언급만 확인됩니다. ↩
10. 플랫폼별 라이트 무효화 구조의 부재— 세션은 “플랫폼별로 특정 라이트나 그 그림자를 무효화하는 구조가 표준으로 준비되어 있지 않다”고 문제를 제기했습니다. 문서 정리 시점의 공식 메가라이트 문서에는 r.MegaLights.Allow 0(스케일러빌리티 단계·디바이스 프로파일 단위), 라이트 컴포넌트의 Allow MegaLights, MegaLights Shadow Method 세 가지가 기술되어 있습니다. 발표 시점의 엔진 버전과 문서 상태가 달랐을 가능성이 있어 본문에는 양쪽을 모두 남겼습니다. 조기 검증을 권하는 실무적 결론은 어느 쪽이든 유효합니다. ↩
11. TSR과 TAAU의 실측 비교 — 내부 해상도 70%에서 1080p로 업스케일할 때 TSR 7.0ms, TAAU 1.3ms라는 값은 세션의 동일 하드웨어 테스트 케이스 결과이며 공식 자료에 대응하는 수치는 없습니다. TSR의 주 비용이 디스플레이 해상도에서 도는 History Update라는 구조적 설명, 그리고 저스펙 GPU를 위해 TAA를 남기라는 권고는 공식 문서로 확인됩니다. ↩
12. 서브스트레이트 두 G-Buffer 모드의 명칭 — 세션 정리 단계에서는 두 모드의 정확한 명칭을 확정하지 못했습니다. 공식 문서가 쓰는 명칭은 Blendable GBuffer와 Adaptive GBuffer이며, 프로젝트 설정 항목은 Substrate GBuffer Format (Project)입니다. 본문의 기능적 구분은 이 공식 명칭에 맞춰 다시 정리했습니다. ↩
13. 성능 중시 모드와 하드웨어 레이트레이싱의 관계 — 세션은 두 모드 중 성능 중시 쪽이 하드웨어 레이트레이싱에 대응한다는 구분을 제시했습니다. 공식 문서에서 하드웨어 레이트레이싱 지원을 특정 G-Buffer 포맷에 묶는 서술은 확인되지 않았습니다. 확인되는 것은 Adaptive GBuffer의 지원 플랫폼이 한정되어 있고, 미지원 플랫폼에서는 머티리얼이 단순화되어 Blendable로 동작한다는 서술입니다. ↩
14. Contrast Adaptive Shading의 추가 비용 — 세션은 판정 이미지를 만들기 위해 별도의 컴퓨트 셰이더가 돌아간다고 설명했습니다. 공식 릴리스 노트는 이 기법이 “이전 프레임을 분석해 거친 셰이딩 레이트로 그릴 수 있는 영역을 판정한다”고만 기술하고, 별도 컴퓨트 패스라는 구현 세부와 그 비용은 공식 자료에서 확인되지 않습니다. 어느 쪽이든 “아낀 만큼과 판정 비용을 실측해 비교하라”는 결론은 그대로 유효합니다. ↩
15. PC 퍼포먼스 모드가 모바일 디퍼드 렌더러를 쓴다는 사례 — 세션은 이를 작년 언리얼 페스트 올랜도 발표에서 공개된 포트나이트 사례로 인용했습니다. 특정 타이틀의 퍼포먼스 모드가 어떤 렌더러를 쓰는지에 대한 공식 문서 서술은 확인되지 않았습니다. 반면 모바일 렌더러가 PC 플랫폼에서도 동작한다는 사실은 공식 문서로 명확히 확인되므로(“including PC platforms”), 이 절의 논지인 “경량 렌더러 옵션으로 재평가할 가치가 있다”는 유지했습니다. ↩