체셔's blog

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 후기로 넘어가며 이 흐름이 어떤 식으로 확장 및 결합하는지 이어서 보겠습니다.

다음글

이전글