체셔's blog

UE5, 성능 손실 없이 더 많은 디테일을.
그리고 완전한 동적 라이팅을 향해.

 UE4 후기에서 DX11(SM5)은 Compute Shader로 고정된 파이프라인의 틀을 느슨하게 만들었습니다. 반면 Tessellation은 더 많은 기하 디테일을 가능하게 했지만 성능, 크랙, 편차라는 숙제를 남겼습니다.

 UE5는 DX12 시대의 조건에서 "성능 손실 없이 더 많은 디테일을, 그리고 완전한 동적 라이팅을" 이라는 도전을 하게 됩니다. 언제나 핵심은 구조 변화입니다. DX12는 GPU 작업을 드라이버가 자동 최적화해주던 시대에서 엔진이 명시적으로 자원을 배치하고 스케줄링하는 시대로 전환시켰습니다. 그렇게 Nanite와 Lumen은 이 전환을 전제로 설계되었습니다. 그 결과, 렌더링 파이프라인의 고정된 경계가 이전보다 훨씬 약해질 수 있었습니다.

UE4에서 남은 숙제: 디테일과 라이팅

 UE4 후기의 DX11(SM5)은 Compute Shader를 통해 고정 파이프라인 외 연산 모델을 제공했고, Tessellation은 기하 디테일을 실시간으로 늘릴 수 있게 했습니다. 하지만 이 두 축은 어디까지나 가능성이었지 기본값은 아니었습니다. Tessellation은 성능 비용이 컸고, 크랙과 균열 문제와 하드웨어 편차도 존재했습니다. 또한 동적 라이팅은 여전히 제작 파이프라인에서 타협이 요구되는 영역이었습니다.

UE5는 이 숙제를 DX12 시대의 운영방식 위에서 다시 설계하였습니다.

 많은 최적화가 드라이버 레이어에서 흡수되었던 DX11과는 달리 DX12에서는 자원 상태 전이(배리어), 파이프라인 상태(PSO), 리소스 바인딩 같은 비용을 엔진이 더 직접 관리하는 방향으로 움직였습니다. 이 변화는 기능 하나의 추가라기보다는 렌더러 설계가 CPU와 GPU의 협업(Scheduling, Batch, Caching) 중심으로 이동했다는 의미가 큽니다.

 여기에 SM6의 Wave Intrinsics는 같은 웨이브(실행 그룹) 안의 lane들이 데이터를 교환 / 집계하는 연산을 가능하게 해 컬링이나 희소 데이터 패킹 같은 알고리즘에서 유리한 도구가 되었습니다. UE5의 바로 이런 Compute 중심, 데이터 지향 설계가 전제된 시대에 맞춰 Nanite와 Lumen가 탄생하게 되었습니다.

Nanite: 기하 디테일 문제를 바꾸다.

 에픽게임즈는 Nanite를 가상화된 기하(Virtualized Geometry) 시스템으로 정의했습니다. 내부 메시 포맷과 렌더링 기술을 사용해 픽셀 스케일 디테일과 높은 오브젝트 수를 목표로 하며 화면에 보이는 디테일만 처리하도록 설계되었습니다. 또한 포맷은 고압축일뿐더러 세밀한 단위의 스트리밍과 자동 LOD까지 지원합니다.

 이러한 내용이 중요한 이유는 UE4의 Tessellation이 표면을 더 쪼개는 증분적 디테일이었다면 Nanite는 디테일을 가진 원본을 받아들이되 런타임에서 가시성과 스트리밍으로 비용을 제어한다는 운영적 디테일로 축이 이동했기 때문입니다. 즉, UE5는 디테일을 늘리는 기술을 셰이더 단계의 기교가 아니라 데이터 포맷과 스트리밍, 그리고 컬링 파이프라인 전체의 문제로 끌어올리게 됩니다.

 Nanite가 해결하려는 문제는 삼각형을 더 그리는 법이 아닙니다. 삼각형이 너무 많아진 시대에 "그것을 어떻게 운영할 것인가?"라는 물음에 대한 해법입니다. 즉, 내부 포맷으로 잘게 쪼개진 기하 데이터를 필요한 순간에만 스트리밍하고, 화면에 기여하지 않는 단위를 대규모로 컬링하며, 그 결과를 GPU 중심으로 빠르게 누적하고 결정해야 합니다.

 이런 구조에서는 리소스 상태 전이나 바인딩, 파이프라인 상태 같은 비용이 반복적으로 등장할 수 밖에 없고, 이를 엔진이 명시적으로 통제하지 못하면 운영 자체가 불가능해집니다. 그래서 Nanite는 DX11처럼 드라이버 최적화에 기대기보다는 DX12의 명시적 모델 위에서 스케줄링, 배치, 캐싱을 엔진이 직접 설계하는 방향을 전제로 하게 됩니다. 또한 SM6의 웨이브 단위 협업은 이런 대규모 컬링과 패킹 과정에서 같은 실행 그룹 내부의 데이터 집계를 더 효율적으로 만들 수 있는 기반이 됩니다.

 이 지점에서 DX12(SM6)는 선택이 아니라 조건이 됩니다. 왜냐하면 Nanite는 얼마나 많은 삼각형을 그릴 수 있는지를 넘어, 보이는 클러스터만 남기고 나머지는 버리는 GPU 주도 파이프라인을 전제하기 때문입니다.

Lumen: Bake 대신 Realtime을 기본값으로

 에픽 문서를 보게되면 Lumen은 디퓨즈 간접광을 해결하며, 표면에서 반사된 색이 주변에 번지는 컬러 블리딩과 메시가 간접광을 가려 생기는 간접 그림자까지 포함한다고 하였습니다. 또한 반사(Reflections)까지 포함해 "동적 GI + 동적 반사"를 하나의 시스템으로 다룬다는 것을 설명합니다.

 Lumen의 핵심은 동적 GI와 동적 반사를 옵션으로 더하는 것이 아니라 장면 변화(시간, 조명, 오브젝트, 카메라)에 따라 라이팅을 지속적으로 갱신하는 것을 기본 전제로 둔다는 점입니다. 이때 엔진은 광원, 표면, 가시성 정보를 반복적으로 업데이트하고, 그 과정에서 생성되는 데이터를 안정적인 GPU 작업으로 스케줄링 해야 합니다.

 DX11처럼 많은 비용이 드라이버 레이어에서 흡수되던 모델에서는 이런 지속 갱신이 커질수록 제어가 어렵고, 반대로 DX12에서는 엔진이 배리어와 PSO, 리소스 바인딩을 포함한 실행 흐름을 명시적으로 설계할 수 있기 때문에 시스템 차원에서 동적 라이팅을 기본값으로 유지하는 운영 방식을 만들 수 있었습니다.

 즉, Lumen은 단지 새로운 조명 기법이 아니라 DX12 시대의 엔진이 운영하는 방식을 전제로 성립하는 시스템입니다.

 그렇기에 UE5 신규 프로젝트에서는 기본적으로 활성화되지만 기존 레거시로 인해 UE4에서 UE5로 변환한 프로젝트에서는 자동으로 활성화되지 않습니다. 이는 기존 프로젝트의 라이팅 패스를 망가뜨리거나 변경하지 않기 위한 조치로 명시되어 있습니다. 즉, Lumen은 단순한 옵션이 아니라, 제작 파이프라인의 기준선을 바꾸는 기능으로 취급됩니다.

 UE4에서 동적 광원 수를 늘리는 접근이 CS 기반 컬링 같은 최적화를 요구했다면, UE5는 그 연장선에서 "동적 라이팅 그 자체를 기본값으로 두려면 무엇이 필요한가?"를 끊임없이 고찰하여 시스템차원으로 풀어낸 결과로 Lumen을 선보이게 됩니다.

맺음말

 UE4(DX11 / SM5)는 고정 파이프라인을 깨기 시작했지만, 여전히 LOD는 사람이 설계하고, 라이팅은 베이크에 기대어 있었습니다. 하지만 UE5의 Nanite와 Lumen은 이 전제를 흔들었습니다.

• 기하는 LOD 설계에서 가상화와 가시성 기반 운영으로 이동한다.
• 라이팅은 베이크된 정답에서 실시간 해답을 기본 목표로 둔다.

 따라서 UE5를 이해하는 핵심은 기능 소개가 아닙니다. DX12(SM6) 시대에 엔진이 GPU를 운영하는 방식이 바뀌어버렸고, Nanite와 Lumen은 그 운영 방식에 맞춰 렌더링을 데이터와 시스템 문제로 재정의 했다는 점에서 시사하는 바가 큽니다.

고정된 형식을 넘어 유연함을 추구하며 발전하는 GPU와 언리얼 엔진. 발전에는 끝이 없겠지만, 앞으로가 기대가 되는 GPU의 역사 시리즈를 마치겠습니다.

긴 시리즈를 마무리하며, 이 기술적 흐름에 공감해 주신 분들이 어떤 분들인지 궁금합니다.
아래 중 어디에 해당하시나요? 번호로 댓글만 남겨주시면 큰 힘이 됩니다.

1. 취준생 / 학생: 엔진 내부 원리를 파헤쳐 압도적인 포트폴리오를 만들고 싶다.
2. 현업 개발자: UE5 운영에서 최적화 vs 효율 사이에서 고민 중이다.
3. 기술 결정권자: 엔진과 GPU 흐름을 읽고 팀의 기술 방향을 정해야 한다.
4. 그 외 / 관심 독자: 일단 시리즈가 재미있어서 계속 보고 싶다.

특정 주제로 더 깊게 다이브하거나, 실무 적용 관점의 정리가 필요하다면 방명록(또는 이메일)로 편하게 노크해 주세요.

방명록 바로가기

이메일 주소 : chessire@naver.com

이전글

DX11(SM5)은 UE4에게 ‘업데이트’가 아니라 구조 전환이었다.
Compute Shader가 파이프라인의 고정관념을 깨고,
Tessellation·PBR은 포토리얼리즘을 “실무”로 만들었다.

 이전 글에서 다룬 DX11(SM5)의 등장은 UE4에게 단순한 라이브러리 업데이트 이상의 의미를 가지고 있습니다. UE3가 DX9 기반의 고정된 파이프라인에서 벗어나려 애썼다면, UE4는 Compute Shader와 Tessellation이라는 핵심 기능을 도입하며 '리얼타임 포토리얼리즘'에 도전했던 시기이기 때문입니다.

렌더링 파이프라인의 파괴적 혁신

 DX11(SM5)의 도입에서 가장 파괴적인 변화는 역시 Compute Shader(CS)의 등장이었습니다. 이전까지의 GPU가 정해진 그래픽스 파이프라인(VS / PS)에 종속되어 있었다면, CS는 GPU에 고정 파이프라인 외 연산 모델을 제공했습니다.

• Deferred Shading의 고도화 (Tiled/Clustered): UE4는 수천 개 수준의 동적 광원을 다루기 위한 흐름에서 타일 / 클러스터 기반의 라이트 컬링 같은 접근과 함께 CS 활용이 중요한 선택지로 부상했습니다. 화면을 타일 단위로 나누고, 해당 타일에 영향을 주는 광원만 추려내 연산량을 획기적으로 줄이는 Tiled Deferred Shading이 다수 광원 처리를 위한 대표 전략으로 자리 잡았습니다. 이는 단순한 속도 향상을 넘어, 복잡한 실내외 환경에서도 라이팅 설계의 제약을 완화하는 데 기여했습니다.
• Niagara와 GPU 시뮬레이션: 기존의 Cascade가 CPU의 연산 능력에 갇혀 수천 개의 파티클도 버거워했다면, UE4 후반부에 Niagara가 확장되면서, 특히 GPU 시뮬레이션 경로에서는 입자를 GPU에서 직접 처리하는 접근이 본격적으로 활용되었습니다. Vector Field 추종이나 입자 간 상호작용 등, 이전보다 복잡한 동작을 실시간으로 다루려는 시도가 가능해졌습니다.
• Post-Processing의 재정의: 후처리 영역에서는 PS/CS를 상황에 따라 혼용할 수 있게 되면서, 블러·DoF·시간축 누적(TAA)처럼 연산량이 큰 효과를 더 적극적으로 시도할 수 있는 기반이 마련되었습니다. 특히 TAA는 이전 프레임의 정보를 현재 프레임에 투영(Reprojection)하는 복잡한 계산을 수행하며, 계단 현상을 제거하는 동시에 포토리얼리즘의 기반이 되는 부드러운 화질을 제공하는 방향으로 작동했습니다.

디테일의 혁명과 Nanite를 향한 여정

 DX11의 핵심 기능 중 하나인 Hardware Tessellation은 메시의 기하학적 복잡도를 GPU가 실시간으로 결정하게 만들었습니다. 이는 UE4에서 지형(Landscape)과 캐릭터 디테일을 표현하는 핵심 전략이 되었습니다.

• Displacement Mapping의 실현: 아티스트가 평면적인 노멀 맵(Normal Map)에 의존하던 시대에서 벗어나, SM5의 Hull Shader와 Domain Shader를 통해 실제 폴리곤을 쪼개고 솟아오르게 하는 Displacement Mapping이 가능해졌습니다. 덕분에 근거리에서의 돌과 흙의 질감은 눈속임이 아닌 실제 기하학적 굴곡을 가진 입체물로 변모했습니다.
• 최적화의 딜레마와 유산: 하지만 하드웨어 테셀레이션은 공짜가 아니었습니다. 과도한 폴리곤 분할은 성능 저하를 일으켰고, 테셀레이션된 메시 간의 균열(Crack)이나 하드웨어 성능 편차는 개발자들에게 끝없는 최적화 과제를 던져주었습니다. 역설적으로, 이 시기의 고민인 '어떻게 하면 성능 손실 없이 무한한 폴리곤을 그릴 것인가' 는 훗날 하드웨어를 직접 제어하여 수십억 개의 폴리곤을 처리하는 UE5 Nanite의 개념적 초석이 됩니다.

하드웨어 가속과 PBR(Physically Based Rendering)의 정착

 DX11 세대에 이르러 GPU의 부동소수점 연산 성능과 메모리 대역폭이 유의미하게 향상되면서, UE4의 상징인 PBR(물리 기반 렌더링) 파이프라인이 실무적으로 안정화되기 시작했습니다.

• 에너지 보존 원칙의 수치화: 과거에는 아티스트의 직관(속칭 '감')에 의존해 스펙큘러 값을 조정했습니다. 하지만 UE4 후기 파이프라인은 빛이 표면에 닿아 반사되고 흡수되는 물리적 법칙을 Roughness, Metallic, Specular라는 정제된 데이터로 제어하게 했습니다.
• 표준화된 제작 환경: 하드웨어 가속 덕분에 복잡한 BRDF(Bidirectional Reflectance Distribution Function) 모델을 실시간으로 계산할 수 있게 되었고, 이는 곧 '어떠한 라이팅 환경에서도 재질이 일관되게 보인다'는 신뢰성을 확보해주었습니다. 결과적으로 아티스트는 기술적 제약보다 창의적인 표현에 더 집중할 수 있는 환경을 맞이하게 되었습니다.

맺음말

 결국 UE4 후기의 역사는 DX11(SM5) 세대의 제약을 엔진 소프트웨어가 어디까지 극대화하여 활용할 수 있는가를 증명해온 과정이었습니다.

 Compute Shader를 통한 연산의 자유는 그래픽 파이프라인의 고정관념을 깨뜨렸고, 테셀레이션과 PBR의 정착은 실시간 렌더링과 오프라인 렌더링(CGI) 사이의 간극을 획기적으로 좁혀놓았습니다. 우리가 지금 당연하게 여기는 ‘포토리얼리즘’은, 사실 이 시기에 성능 제약을 전제로 한 최적화가 강하게 요구되던 흐름 위에서 성립했습니다.

 하지만 기술의 발전은 늘 새로운 갈증을 불러옵니다. DX11 기반의 하드웨어 테셀레이션은 성능과 디테일 사이의 아슬아슬한 줄타기를 반복해야 했고, 수천 개의 광원을 처리하려는 시도는 동적 라이팅의 완전한 구현이라는 숙제를 남겼습니다.

 이러한 DX11 시대의 고민과 유산은 이제 DirectX 12와 Vulkan, 그리고 이를 집대성한 UE5의 나나이트(Nanite)와 루멘(Lumen)으로 계승됩니다. 가상화된 마이크로 폴리곤 렌더링과 실시간 레이 트레이싱의 시대가 열린 지금, 우리가 지나온 이 DX11의 연대기는 단순한 과거가 아니라 현대 그래픽스 기술의 가장 단단한 뿌리라고 할 수 있을 것입니다.

다음글

이전글

워크로드 불균형을 흡수한 공용 코어 풀,
엔진 데이터 모델이 된 PBR 머터리얼,
언리얼엔진의 전제가 바뀌었다.

 지난 글에서 DX10 / SM4 시점의 Unified Shader(공용 셰이더 코어 풀) 전환을 다뤘습니다. 이 변화는 "파이프라인 단계가 사라졌다."가 아니라 Programmable 단계(VS, GS, PS)가 같은 실행 자원을 공유하게 됐다는 의미였습니다.

 엔진 관점에서 중요한 건, 이 하드웨어 변화가 단순히 GPU 내부 구조에 그치지 않고 렌더러 설계의 전제를 바꿨다는 점입니다. UE4의 초기 렌더링 설계는 이 전제를 강하게 반영한 사례라고 볼 수 있습니다.

UE3 시대의 한계

 UE3는 DX9(SM3) 중심 세대에서 성장했고, 그 시절 GPU는 VS / PS가 상대적으로 분리된 구조를 갖는 경우가 많았습니다. 그래서 한 프레임에서 픽셀 작업이 과도해지거나(혹은 반대로 정점 / 기하 작업이 과도해지면) 특정 단계가 병목이 되고 다른 단계 자원은 놀게 되는 로드 불균형이 구조적으로 발생하기 쉬웠습니다.

 또한 당시에는 "픽셀 단계에서 하고 싶은 일"이 지금만큼 과감하게 커지기 어려웠습니다. 화면 해상도, 셰이딩 복잡도, 포스트 프로세스 규모 자체가 지금보다 작았고, GPU가 이를 감당하기 위한 동적 스케줄링 / 대규모 병렬 실행 기반도 점진적으로 성숙해가는 중이었습니다.

UE4, 화면 품질은 픽셀 작업이 만든다.

DX10(SM4) 이후에는 Programmable 단계가 공용 코어 풀을 공유하면서, 프레임마다 달라지는 부하를 더 유연하게 흡수할 수 있는 기반이 생겼습니다. 엔진 입장에서 이건 간단히 말해

1. 픽셀 작업을 더 공격적으로 늘려도 하드웨어가 그 부담을 흡수할 여지가 커졌다.
2. 결과적으로 "화면 품질"을 픽셀 단계 / 화면 공간 패스에서 더 많이 만들 수 있게 됐다.

입니다.

 UE4의 초기 렌더링 방향은 이 흐름과 맞물립니다.UE4는 초기부터 Deferred Rendering을 기본 축으로 가져가고, 머티리얼 / 조명 / 후처리를 "여러 패스의 조합"으로 구성하는 쪽으로 무게가 실립니다.

UE4 전기의 핵심

 UE4의 초기 렌더러를 이해할 때 중요한 포인트는 "한 번에 끝내는 파이프라인"이 아니라, 프레임을 여러 단계의 화면 공간 처리로 쪼개는 방식입니다. 대표적인 흐름은 다음처럼 요약할 수 있습니다.

• GBuffer 생성 (기하 정보 / 머티리얼 속성 저장)
• 조명 계산 (여러 광원을 누적)
• 후처리 (톤매핑, 블룸, 컬러 그레이딩 등)

 이 구조는 "픽셀 단계가 프레임 비용의 큰 비중을 차지한다."는 현실과 자연스럽게 연결됩니다. 즉, UE4 전기의 렌더링 설계는 픽셀 작업 비중 증가를 전제로 안정적으로 동작하도록 구성되어 있습니다.

머티리얼 시스템

 UE4는 머티리얼을 단순한 셰이더 코드가 아니라, 엔진 내부에서 관리되는 일관된 모델(그래프 / 파라미터 / 퍼뮤테이션)로 다루는 비중이 커집니다. 이 변화의 의미는 다음입니다.

• 머티리얼이 복잡해질수록 "코드 몇 개"로 관리하기 어렵다.
• 렌더링이 여러 패스로 쪼개질수록, 동일한 머티리얼 정보가 여러 단계에서 재사용된다.
• 결국 엔진은 머티리얼을 데이터 모델로 표준화하고, 필요에 따라 셰이더 코드를 생성 / 변형하는 쪽으로 구조가 이동한다.

 UE4 전기에서 "렌더러의 복잡도"가 증가하는 만큼, 이를 감당하기 위한 엔진 내부 구조(머티리얼 / 셰이더 관리)가 같이 강화됩니다.

Physically Based Rendering (PBR)

 PBR은 머티리얼을 "예쁜 값 몇 개"가 아니라 물리 기반 파라미터 집합으로 강제합니다.

• Base Color
• Metallic
• Roughness
• Specular / IOR 성격의 값
• Normal
• AO 등

 즉, 조명 / 환경이 달라도 일관된 반응을 내기 위해, 엔진은 머티리얼 입력을 표준화하고 그 의미를 고정해야 합니다. 이게 머티리얼 시스템을 "엔진의 핵심 데이터 모델"로 끌어올린 큰 이유 중 하나입니다.

 하지만 머티리얼 시스템에는 PBR 말고도 “엔진이 감당해야 하는 운영 요소”가 같이 들어갑니다.

• 머티리얼 그래프를 셰이더 코드로 변환(코드 생성/컴파일)
• 다양한 렌더 패스에서의 동일 머티리얼 재사용(GBuffer, Depth, Shadow, Velocity 등)
• Feature/플랫폼별 퍼뮤테이션 관리(옵션 조합 폭발)
• 파라미터/인스턴싱(런타임 조정)

그래서 관계는 보통 이렇게 보는 게 안전합니다.

• PBR은 머티리얼 시스템의 의미 / 표준 입력을 강제한 핵심 원인
• 머티리얼 시스템은 거기에 더해 엔진 운영(생성/컴파일/퍼뮤테이션/패스 재사용)까지 포함하는 더 큰 구조

맺음말

 정리하면 UE4 전기의 렌더링 전제는 파이프라인 단계가 바뀌어서가 아닌 Unified Shader 이후의 GPU에서 Programmable 단계가 공용 코어 풀을 공유하게 되면서 프레임 워크로드를 더 유연하게 흡수할 수 있게 된 점에서 시작합니다. 그 위에서 UE4는 Deferred + 다중 패스 + 머티리얼 / 셰이더 관리 구조를 엔진레벨로 끌어올렸고, PBR은 그 머티리얼 시스템의 표준 입력과 그 의미를 고정하는핵심 축으로 작동했습니다. 다음 글에서는 DX11 / SM5 그리고 UE4 후기로 넘어가며 이 흐름이 어떤 식으로 확장 및 결합하는지 이어서 보겠습니다.

다음글

이전글

UE3는 하드웨어를 이기려 하지 않았다.
Hybrid는 당시의 타협이었고, Full Deferred는 결국 도착한 최적해였다.
GPU 친화적인 구조로 수렴할 수밖에 없었다.

앞선 글에서 GPU가 SIMD / SIMT 구조로 동작하며,
분기(Branch Divergence)에 매우 취약하다는 이야기를 했습니다.
이 특성은 단순히 셰이더 코드 작성에만 영향을 주는 것이 아니라,
엔진 전체의 렌더링 파이프라인 설계에도 직접적인 제약으로 작용합니다.

이러한 GPU 아키텍처의 제약이 실제 엔진 설계에
어떻게 반영되었는지 보여주는 대표적인 사례가
Unreal Engine 3입니다.
이번 글에서는 UE3의 렌더링 구조 변화를 살펴보겠습니다.

UE3 초기

2006년 처음 출시된 Unreal Engine 3는
완전한 Forward Rendering 기반의 엔진이었습니다.

Lightmap과 Static Lighting 중심의 구조였고,
다양한 Post Effect까지 폭넓게 지원했습니다.

다만 라이팅이 많아질수록
Pixel 수에 비례해 연산 비용이 증가하는
Forward Rendering 특유의 문제도 함께 가지고 있었죠.

그럼에도 불구하고,
당시의 낮은 해상도와
제한적인 메모리·대역폭 환경에서는
Forward Rendering이 현실적인 선택이었고,
실제로 많은 주목을 받게 됩니다.

하지만 해상도가 올라가고,
동적 라이팅에 대한 요구가 커지면서
Forward Rendering의 한계는 점점 더 뚜렷해지기 시작합니다.

UE3 중기

이러한 한계 속에서 Unreal Engine 3는 중기에 접어들며
Multiple Render Targets(MRT)을 활용한
G-Buffer 기반의 Deferred Lighting을 도입하게 됩니다.

메시 위에 또 다른 텍스처를 덧씌워 표현하던 Decal 기능 역시
Deferred Decal이라는 형태로 진화하게 됩니다.

이를 Deferred Lighting과 결합함으로써
라이팅 연산 비용을 줄이는 동시에,
Z-Fighting 문제를 완화하는 성과를 거두게 됩니다.

다만 G-Buffer가 요구하는 메모리 비용이 상당했기 때문에,
UE3는 Full Deferred Rendering이 아닌
Hybrid Rendering 구조를 채택하는 선택을 하게 됩니다.

이 Hybrid Rendering 구조는
당시 하드웨어 환경에서는 합리적인 선택이었지만,
동적 라이팅의 규모가 더 커지면서
결국 또 다른 한계를 드러내게 됩니다.

UE3 후기

그래픽카드의 메모리는 지속적으로 증가했습니다.
결국 Unreal Engine 3는 후기 단계에 들어서
Full Deferred Lighting 구조로 귀결합니다.

모든 Geometry Pass에서 동일한 G-Buffer를 생성하고,
Lighting Pass에서는 화면 공간 기준으로
동일한 라이트 연산을 수행하는 방식으로 전환됩니다.

이 과정에서 픽셀 간 분기 가능성이 크게 줄어들며,
Branch Divergence를 최소화한,
GPU 구조에 가장 잘 맞는 형태로 수렴하게 됩니다.

이러한 흐름 속에서 등장한 대표적인 기법이
Screen Space Ambient Occlusion(SSAO)입니다.
화면 공간 기준으로 빛의 차폐를 계산함으로써,
그림자 표현의 퀄리티는 한 단계 도약하게 됩니다.

맺는말

오늘은 Forward Rendering에서 Deferred Rendering으로 이어지는 흐름 속에서,
Unreal Engine 3의 렌더링 구조 변화를 살펴보았습니다.

메모리 사용량과 컴퓨팅 연산을 맞바꾸며
그래픽스 퀄리티를 끌어올린 과정은,
엔진 설계에서의 Optimizing이 무엇인지 보여주는
좋은 사례라고 생각합니다.

다음 글에서는 SIMT 구조를 전제로,
본격적으로 문제를 해결하기 시작한
Unreal Engine 4의 렌더링 구조에 대해 다뤄보겠습니다.

다음글

이전글

Determinism은 기능이 아니라
파이프라인의 합의 속에서 드러난다.
Lockstep을 통해 오차 발산을 구조로 막는다.

개요

 언리얼엔진의 물리연산은 Determinism(결정론적 동작)을 보장하고 있지 않지만 Physics Divergence(물리 연산의 오차 발산)을 막기 위해 어느정도 고려하고 있습니다. 특히 네트워크 동기화에서는 매 Frame마다 물리 연산이 조금이라도 달라지면 짧게는 수 Frame, 길게는 수 초 후의 결과가 완전히 달라지기 때문에 여러 구조적 개선을 지속적으로 진행해왔습니다. 이 글은 그러한 언리얼 엔진의 Physics를 Determinism 관점으로 오차 최소화를 어떻게 달성하였는지에 대해 정리한 글입니다.

언리얼엔진의 물리, 각 스텝 정리

[1] PrePhysics

Actor Tick (PrePhysics Group)

• 입력 처리 / 이동 요청 확정
• 물리에 들어가기 전 게임 상태 정리(게임 로직 기반 상태 업데이트)
• Determinism 관점
  • Lockstep에서 "동일한 입력"이 보장되어야 하므로 이 단계가 핵심입니다.
  • 모두 같은 프레임에서 같은 입력을 받고 동일한 초기 상태를 맞춰야 Physics Divergence를 방지할 수 있습니다.

▼  (Barrier: 모두 완료 시 다음 단계)

[2] StartPhysics

• Chaos Physics 엔진에 Step 시작 명령
• Substep 준비
• Collision BroadPhase 준비
• Determinism 관점
  • Substep 개수, Step 간격, BroadPhase(충돌 탐색 알고리즘 순서)가 플랫폼과 스레드에 영향을 받지 않게 유지될수록 Determinism이 향상된다.
  • UE5에서 이곳의 안정성을 강화하고 있습니다.

▼

[3] DuringPhysics

• Substep 단위로 Physics Integration
• 강체를 이동시킨 후, 충돌 감지, 반응 계산을 병렬로 수행
• Solver 수행
• Chaos Simulation 실행
• Determinism 관점
  • 가장 Non-deterministic한 단계로 이 단계에서는 Divergence가 아래의 세가지 이유로 발생합니다.
    • Floating point차이
    • 멀티스레드 스케줄링 차이
    • Solver 순서 차이
  • 그렇기에 Lockstep 구현 시에는 Fixed Step, Fixed Seed, 동일 Substep을 강제로 통일합니다.

▼  (Barrier: 모든 물리 연산 완료 시 다음 단계)

[4] EndPhysics (PostPhysics)

• Physics 결과를 게임 월드로 반영
• Transform Sync
• CharacterMovement / VehicleMovement 이동 보정(RootMotion/Prediction 보정)
• PostPhysics Tick 실행
• Determinism 관점
  • Physics가 만든 결과가 실제 게임 로직으로 흘러 들어가는 구간으로 Lockstep에서의 값들이 모든 클라이언트에 동일해야 이후 Prediction/Interpolation이 안정적으로 작동합니다.

▼

[5] PostUpdate

• During Physics의 모든 병렬 스레드를 대기하여 정리
• Rendering 준비
• Determinism 관점
  • 물리 결과가 렌더링 이전에 완전히 확정되는 곳입니다. 즉 Lockstep에서는 Frame Boundary가 되는 지점입니다.

Solver란?

 물리 연산 과정에서 발생한 힘, 속도, 충돌 등을 정리하여 게임에 맞게 보정하는 단계입니다. Chaos에서는 충돌 후의 위치, 속도, 반응을 반복 계산(Iterative Solve)하여 안정적인 결과로 수렴시키며, 최종적으로는 게임 월드에 반영하기 적합한 형태로 물리 상태를 정제하는 역할을 합니다.

Substep이란?

 하나의 물리 Frame을 여러개의 더 작은 시간 단위로 나누어 여러 번 시뮬레이션을 수행하는 구조입니다. 그로 인해 PhysicsThread는 고정된 시간 간격(Fixed Step)으로 더 촘촘하게 물리를 계산할 수 있습니다. 기본적으로 GameThread의 Tick 속도와 관계없이 진행됩니다. 하지만 PrePhysics와 PostPhysics가 GameThread에 종속되어 있기 때문에 시작과 끝으로 동기화 된다고 보시면 됩니다.

 Substep은 다음 목적에서 사용됩니다.

• 빠르게 움직이는 객체의 충돌 누락 방지
• 폭발, 충돌 등 입출력이 빠르게 변하는 상황에서 안정적인 결과 유지
• Lockstep에서 모든 클라이언트가 동일한 수의 Substep을 수행하도록 강제하여 Determinism을 향상시킴

실무 사례

 실제로 자율주행 시뮬레이터를 개발할 때, 여러 대의 차량 에이전트가 동일한 시나리오에서 항상 같은 결과를 내는 것은 매우 중요했습니다. 특정 센서 데이터의 타이밍이 미세하게 어긋나거나, 물리 연산의 비결정성으로 인해 차량의 궤적이 1cm만 달라져도 자율주행 알고리즘의 판단은 완전히 뒤바뀔 수 있기 때문입니다.

 이를 해결하기 위해 위에서 언급한 Fixed Timestep 설정과 Lockstep 기반의 동기화 구조를 설계했고, 덕분에 하드웨어 성능이 다른 환경에서도 동일한 테스트 케이스를 재현할 수 있는 기반을 마련할 수 있었습니다.

결론

 이처럼 물리 파이프라인의 각 단계를 통일된 방식으로 처리하여 Lockstep 구조에서 발생하는 Physics Divergence를 크게 줄일 수 있습니다. 또한 UE5가 지속적으로 강화하고 있는 Substep·Solver·Tick 구조는 Determinism을 향상시키는 방향으로 설계되어 있어 언리얼엔진에 있어 네트워크 게임에서의 물리 불일치 문제를 완화하는 핵심 축이 되었습니다.

UE2는 FFP 위에 셰이더를 ‘겹쳐’ 올린 시대였다.
Combine 기반 Overlay, 머티리얼 시스템의 씨앗

UE2의 등장

 UE2는 2001년에 빌드 633 형태로 처음 공개되었습니다. 2001년 이전의 GPU는 대부분 FFP(Fixed Function Pipeline) 기반이었지만, DirectX 8 세대에 들어서면서 픽셀 셰이더와 버텍스 셰이더를 활용할 수 있게 되었습니다. UE2는 이러한 변화에 맞추어 GPU 가속 렌더링과 멀티플랫폼을 고려한 구조로 설계되었고, 이때부터 고정 함수 결과에 셰이더 출력을 조합(Combine) 하는 형태의 Material 처리 방식이 자리 잡기 시작했습니다. 이 과정에서 지금의 Material System으로 이어지는 초기 형태의 조합 기반 효과(= Add, Mul, Lerp 등을 활용한 간단한 Overlay 스타일 처리)가 사용되었고, 이후 언리얼 엔진 3에서 노드 기반 Material Editor로 확장되며 우리가 알고 있는 Overlay 계열 블렌딩이 정식 기능으로 자리 잡게 됩니다.

Fixed-Function Pipeline

 앞서 설명드린 것 처럼 DirectX8 이전 버전은 FFP 기반이었고, DirectX9 초기까지도 FFP를 기반한 Rendering Pipline형태였습니다. (위 이미지 참고) Diffuse Lighting, Lightmap 같은 연산은 여전히 하드웨어 단계에서 단계적으로 수행하였죠. 여기까지는 Programmable Shader가 개입할 수 없었습니다.

Execute Shader

 완전한 형태의 Programmable은 아니었지만 Pixel Shader Stage가 생기면서 UE2에도 부분적으로 Shader가 들어오기 시작했습니다. 조명 보정을 위한 NormalMap, Overlay에 쓰일 추가 색 계산까지, 드디어 Pixel Shader Stage가 하드웨어에 고정된  형식이 아닌 프로그래머가 작성한 코드를 통해 하드웨어에서 실행할 수 있게 된 것입니다.

Combine Process

 그렇게 Pixel Shader Stage에서 실행된 코드가 Combine Process를 타고 FFP의 결과물에 Overlay되게 됩니다. UE2 시절의 Overlay는 Add/Multiply 기반의 단순 조합이었음에도 언리얼엔진의 초기 머터리얼 시스템의 개념적 기반이 될 수 있었습니다. 즉, 텍스처 샘플링 결과와 셰이더에서 계산된 값을 다양한 방식으로 섞어 최종 색을 만드는 개념이 이때 자리를 잡기 시작한 것입니다. 이 개념은 UE3에서 노드 기반 머터리얼 시스템으로 확장되며 지금과 같은 형태까지 발전하게 됩니다.

Pixel Output

 그렇게 최종적으로 픽셀이 화면에 출력되게 됩니다. Pixel Output은 GPU 파이프라인의 End Point이지만, 그 이전 단계에서 FFP 연산, 쉐이더 계산, 조합 과정 등 다양한 처리가 누적되며 최종적인 화면이 구성됩니다. 즉, 우리가 보는 한 장의 화면은 여러 단계의 계산이 겹쳐 만들어진 결과물인 셈입니다.

Post Process Effect

 UE2 후반에 와서 카툰 렌더링(셀 셰이딩 + 외곽선 추출)을 비롯한 다양한 Post Process Effect가 가능해졌습니다. UE2당시의 Post Process는 단순히 화면 렌더링을 한번 더 샘플링 하는 단순 스크린 패스 수준이었지만 UE3에서 실질적인 체계가 확립되고 UE4에서 영화 렌더러 수준까지 진화할 정도의 무서운 약진이라 할 수 있습니다.

맺는 말

기술을 배울 때 그 변화의 흐름을 함께 이해하면 구조가 더 명확하게 잡히고, 어떤 설계 철학으로 발전해 왔는지도 선명하게 드러납니다. 언리얼 엔진은 이제 게임뿐 아니라 영화, 건설, 시뮬레이션 등 다양한 분야에 활용되는 범용 실시간 엔진이 되었고, 그중 UE2는 렌더링 시스템의 기반이 형성되던 중요한 시기였습니다.

 오늘은 UE2의 Overlay와 Post Process Effect를 간단히 정리해보았습니다. 다음 글에서는 UE3에서 본격적으로 확립된 머티리얼 시스템과 렌더링 변화에 대해 이어 설명하겠습니다.

다음글

이전글