역자의 말: 2019년 겨울 모어펀 스튜디오 테크니컬 아트 디렉터(홍콩사람)가 보직해임 되어 그 후보자에 제가 추천을 받아 인터뷰 진행 하고 합격했었던 스튜디오입니다. 보직 해임된 모어펀 스튜디오 테크니컬 아트 디렉터가 소후에 홍콩 민주화 시위에 대한 자신의 생각을 올렸는데 그 사건으로 바로 보직 해임된 사건이 있었죠. 중국은 역시 중국이네요. 텐센트가 아무리 큰 회사라고 해도 중국 정부에게는 그냥 까라면 까는 그런 회사일 수 밖에 없더군요.
모어펀 스튜디오 소개.
텐센트 모어펀 스튜디오 그룹(MoreFun Studios)은 2010년 12월 설립된 텐센트 인터랙티브 엔터테인먼트(IEG) 산하의 게임 개발 스튜디오입니다. 액션, 슈팅, RPG, 캐주얼 등 다양한 장르를 아우르며, 심천·베이징·상하이에 거점을 두고 있습니다.
대표작으로는 10년 이상 서비스 중인 나루토 모바일, 높은 자유도의 전술 슈팅 게임 암구돌파(Escape from Tarkov류) 등이 있으며, 현재는 UE5 기반의 신작 이인지하(異人之下) 와 멀티플레이 액션 수(狩) 를 개발 중입니다. 특히 AI 기술을 게임 개발에 적극 접목하고 있다는 점도 주목할 만합니다.
웹 게임으로 출발해 모바일로의 전환이라는 어려운 과도기를 거쳤지만, 꾸준한 투자와 도전으로 현재는 텐센트 자체 개발 라인업의 핵심 축을 담당하고 있습니다.
저자: 电话微波炉
제 1 부

스크린샷

스크린샷

스크린샷
록왕국 세계 모바일 렌더링 파이프라인 설계 및 최적화
一、 렌더링 파이프라인 총람 (Rendering Pipeline Overview)
1. 프로젝트 배경과 기술 선정
- 게임 타입: 오픈월드, 정령 수집 육성, 스타일화된 아트.
- 엔진 버전: Unreal Engine 4.26.
- 기본 파이프라인: 모바일 전방향 렌더링 파이프라인 (Mobile Forward Rendering Pipeline) 기반으로 깊이 커스터마이징 및 최적화.
2. 핵심 아트와 렌더링 요구사항
- 스타일화된 표현: 캐릭터와 이펙트의 렌더링은 씬과 독립되어야 하며, 특정 아트 효과(스킬 발동 시 씬 암 처리, 후처리 단계별 분리 처리 등)를 실현해야 함.
- 고성능 동시 화면: 모바일에서 50개 이상의 캐릭터와 정령 동시 렌더링 지원.
- 동적 환경: 완전한 주야 변환 (Time of Day - TOD) 및 복잡하고 다양한 날씨 시스템 실현.
- 조명과 디테일:
- 씬의 암부 디테일 표현 향상.
- 동적 점광원, 수면 반사 등 고급 효과 지원.
3. 전방향 파이프라인 개조와 도전 과제
- 신규 렌더링 특성:
- 화면 공간 환경광 차폐 (SSAO).
- 화면 공간 반사 (SSR).
- 색 보정 (Color Grading).
- 완전한 동적 TOD 시스템 (실시간 동적 조명과 그림자).
- 모바일 동적 점광원.
- 핵심 도전 과제: "~도 만족시키면서 ~도 만족시켜야 하는" 모순.
- 만족시켜야 할 것: 위의 고품질·고비용 아트 요구사항.
- 동시에 보장해야 할 것: 파이프라인이 주류 모바일 기기에서 원활하게 동작 (목표 30FPS, 고급 기기 60+ FPS).

스크린샷

스크린샷

스크린샷

스크린샷

스크린샷

스크린샷
二、 Scene Color 방안: 픽셀 레벨에서 캐릭터와 씬 구분
1. 요구사항과 페인 포인트
- 핵심 요구사항: 후처리 등 단계에서 하나의 픽셀이 씬에 속하는지 캐릭터/정령에 속하는지 정확히 구분.
- 활용 시나리오 1: 스킬 발동 시 절차적으로 씬을 암 처리하면서 캐릭터/정령 밝기는 유지.
- 활용 시나리오 2: 씬에 초해상도 샤프닝을 적용하되 캐릭터는 제외하여 캐릭터 외곽에 부자연스러운 샤프닝 아티팩트를 방지.
- 성능 병목: 50+ 캐릭터 동시 렌더링이라는 엄격한 조건 하에서 이 기능을 실현해야 함.
2. 일반적 방안: Custom Depth / Stencil
- 구현 원리:
- 추가 Render Pass를 열어 구분이 필요한 모든 오브젝트(예: 캐릭터)를 독립된 Custom Depth 맵에 렌더링.
- 동시에 Custom Stencil 버퍼에 특정값을 기록.
- 후속 Pass(예: 후처리)에서 Custom Depth/Stencil 맵을 샘플링하여 픽셀 소속을 판단.
- 모바일에서의 성능 문제:
- 추가 Pass 오버헤드: Custom Depth Pass 자체가 상당한 성능 소모를 발생시키며, 모바일에서는 아무것도 그리지 않아도 0.5ms 이상 소모 가능.
- 대역폭과 메모리: 화면 크기의 맵 두 장(Depth + Stencil)이 필요하며 720P 기준 대역폭은 약 3.35MB.
- Draw Call 급증 (가장 심각한 문제):
- 게임 내 캐릭터와 정령은 정밀한 다파트 스켈레톤 모델이며 외곽선 효과를 포함해本身就 Draw Call 수가 많음 (단일 캐릭터당 9개 DC 가능).
- 다인 동시 화면에서 Custom Depth Pass로 인해 Draw Call 수가 폭발적으로 증가 (100-200+ 도달 가능), 모바일 CPU에 막대한 부하.
3. 록왕국의 해결 방안: Alpha 채널 인코딩 활용
- 핵심 아이디어: 추가 Pass와 Buffer를 피하고 구분 정보를 메인 렌더 타깃(Scene Color Buffer)에 직접 인코딩.
- 기술 선정: Scene Color 포맷을 일반 RGBA8에서 **RGB10A2**로 변경.
- RGB (각 10 bit): HDR 색상 정보 저장, 정밀도 충분.
- A (2 bit): 원래 잘 쓰이지 않던 Alpha 채널을 2-bit ID 저장 영역으로 활용. 2비트면 여러 카테고리를 구분하기에 충분(예: 00=씬, 01=캐릭터, 10=이펙트 등)하며 추가 비용은 거의 없음.
- 장점:
- 추가 Pass 제로: Custom Depth Pass가 불필요하여 고정 오버헤드와 Draw Call 두 배 문제를 근본적으로 제거.
- 추가 대역폭 없음: 데이터가 Scene Color 맵에 통합되어 추가 메모리 및 대역폭 점유 없음.
제 2 부

스크린샷

스크린샷
RGB10A2를 활용한 캐릭터와 씬 구분 최적화
1. 문제 배경: 높은 외곽선 렌더링 비용
- 게임 내 캐릭터와 정령(Sprite)은 정밀한 다파트 스켈레톤 모델이며 모두 외곽선 효과를 포함.
- 전통적인 외곽선 방법(예: Custom Depth Buffer 사용)은 외곽선이 필요한 오브젝트마다 깊이 맵에 한 번 더 렌더링해야 하여 Draw Call 수가 급증.
- 성능 병목: 캐릭터와 정령이 많은 씬에서 Draw Call 수가 단일 캐릭터 9개에서 수백 개까지 폭발적으로 증가, 모바일 기기에 막대한 부하.
2. 해결 방안: Alpha 채널을 마스크(Mask)로 활용
- 핵심 아이디어: Custom Depth를 포기하고 메인 컬러 버퍼(Scene Color Buffer)의 Alpha 채널을 활용해 캐릭터와 비캐릭터 픽셀을 구분.
- 구체적 구현:
- 메인 컬러 버퍼 포맷을 **RGB10A2**로 설정. 10비트 RGB와 2비트 Alpha를 가진 포맷.
- Base Pass 렌더링 시 캐릭터/정령 머티리얼이 특정 Alpha 값 출력(예: a=1.0).
- 씬 내 다른 오브젝트는 기본 Alpha 값 출력(예: a=0.0).
- 렌더링 완료 후 Scene Color 버퍼의 Alpha 채널이 무료 캐릭터 마스크가 되며, 후속 외곽선·후처리 등 효과는 이 Alpha 채널을 샘플링하여 픽셀이 캐릭터인지 판별.
3. 장점
- 추가 비용 제로: 거의 무료로 캐릭터와 씬 픽셀 구분 능력을 획득.
- 추가 Render Pass 불필요: Custom Depth를 위한 추가 렌더링 과정을 완전히 제거.
- 대역폭 절약: 추가 깊이 텍스처 읽기/쓰기 불필요.
- Draw Call 감소: 외곽선으로 인한 Draw Call 증가 문제를 근본적으로 해결.

스크린샷

스크린샷
RGB10A2의 한계 해결
1. 고동적 범위(HDR) 색상 클램핑 문제
- 문제 설명: RGB10A2는 UNORM (Unsigned Normalized) 포맷으로 색상 채널이 [0, 1] 범위 값만 표현 가능. 씬에 하이라이트나 자발광 오브젝트(색상 값 > 1.0)가 존재하면 밝기가 **강제로 1.0에 클램프(Clamp)**됨.
- 부정적 영향: 이로 인해 Bloom 등 하이라이트 정보에 의존하는 후처리 효과가 완전히 무효화되거나 잘못된 결과를 출력.
- 해결 방안: 고정소수점 인코딩/디코딩 (Fixed-Point Encoding/Decoding)
- 색상을 RGB10A2 텍스처에 기록하기 전에 먼저 인코딩하여 더 큰 범위(예: [0, ColorRange])를 [0, 1]로 압축.
- 인코딩 공식:
- 디코딩 공식: 후속 읽기 단계에서 다시 원래 범위로 디코딩.
2. 소수 정밀도와 색 단계(Banding) 문제
- 문제 설명: 위 고정소수점 방안은 색상 범위를 확장했지만 정밀도를 희생. 제한된 10비트에서 표현 범위가 넓어질수록 소수 부분의 정밀도가 낮아짐. 이는 색 그라데이션이 완만한 영역(예: 스카이박스)에서 특히 영(0)에 가까운 암부 영역에서 뚜렷한 색 단계(Color Banding) 현상을 발생시킴.
- 해결 방안: 비선형 인코딩 (제곱근)
- 핵심 사상: 비선형 함수(예: 제곱근)로 색상을 인코딩하여 암부 영역에 더 많은 정밀도 비트를 할당하면서 하이라이트 영역의 범위를 유지. 감마 보정과 원리가 유사.
- 인코딩 공식 (기록 시):
- 디코딩 공식 (읽기 시):
- 효과: 이 방식을 통해 하늘 등 영역의 색 단계 문제가 효과적으로 수정되어 화면 전환이 더 부드러워짐.

스크린샷

스크린샷

스크린샷

스크린샷
스크린 공간 안개 방식 (Post-Process Fog)
1. 문제: SSAO와 전통적인 버텍스 안개의 렌더링 충돌
- 배경: 씬의 암부 디테일을 강화하기 위해 포워드 렌더링 파이프라인(Forward Pipeline) 에 스크린 공간 주변광 차폐(SSAO) 를 도입했다.
- 렌더링 순서 충돌:
- 전통적인 버텍스 안개(Vertex Fog) 는 Base Pass 의 버텍스 셰이더에서 계산되며, 멀리 있는 오브젝트 색상을 안개 색과 섞는다.
- SSAO 는 후처리 효과이므로 Base Pass 렌더링이 끝나 전체 씬 깊이를 얻은 뒤에 계산할 수 있다.
- SSAO가 안개 효과 이후에 적용되면, 이미 안개 색으로 덮인 픽셀을 다시 어둡게 만들어 먼 거리의 안개 영역에 부자연스러운 어두운 얼룩이 생긴다. 이는 시각적으로 잘못된 결과다.
2. 해결책: 후처리 안개 (Post-Process Fog)
- 핵심 아이디어: 안개 계산을 버텍스 셰이더 단계에서 후처리 단계 로 옮겨, SSAO 이후에 실행되도록 한다.
- 새 렌더링 흐름:
- Base Pass: 씬을 정상 렌더링하되 버텍스 안개를 계산하지 않는다.
- 후처리:
- 먼저 SSAO를 계산하고 적용한다.
- 이후 같은 Pass 또는 다음 Pass에서 씬 깊이 맵을 이용해 픽셀의 월드 위치를 재구성하고, 카메라와의 거리를 계산해 안개 색 을 구한 뒤 씬 색상과 섞는다.
- 장점:
- 시각적 정확성: SSAO가 안개 자체의 색상에 영향을 주지 않아 올바른 렌더링 결과를 보장한다.
- 성능 최적화: 정점 수가 매우 많은 장면(다수 캐릭터와 정령이 동시에 등장하는 경우)에서는 안개 계산을 per-vertex에서 per-pixel(풀스크린 후처리)로 옮겨 버텍스 셰이더 부담을 크게 줄일 수 있다. 부하가 큰 장면에서 Base Pass Vertex Stage 비용을 약 10% 최적화 할 수 있다.
3. 버텍스 안개의 유지와 확장
- 버텍스 안개를 유지하는 예외:
- 스카이박스(Skybox): 스카이박스는 SSAO의 영향을 받지 않으며, 정점 수가 픽셀 수보다 훨씬 적다. 따라서 풀스크린 후처리보다 버텍스 안개 비용이 더 낮아 계속 유지한다.
- 후처리 이후 렌더링되는 오브젝트: 후처리 안개가 합성된 뒤 렌더링되는 반투명 오브젝트나 이펙트는 자체적으로 버텍스 안개를 계산해야 한다. 보통 이런 오브젝트는 모델이 단순해 비용이 관리 가능하다.
- 커스텀 버텍스 안개 (Custom Vertex Fog):
- 언리얼 엔진의 머티리얼 에디터를 확장해 아티스트가 버텍스 안개를 커스터마이즈 할 수 있도록 했다.
- 이를 통해 아티스트는 더 풍부한 아트 효과를 만들 수 있다. 예를 들어 뇌우 구름의 하단과 상단에 서로 다른 안개 색과 전환을 설정해 씬과 더 자연스럽게 섞이도록 할 수 있다.

스크린샷
렌더링 흐름 연결 최적화 (Subpass Chaining)
- 핵심 목표: 모바일에서는 Tile-Based Rendering 구조의 장점(예: 온칩 메모리)을 최대한 활용하기 위해, 가능한 한 많은 렌더링 작업을 하나의 Render Pass 안에서 완료 해야 한다. 비싼 메모리 읽기/쓰기를 피하기 위해서다.
- 렌더링 작업 체인 예시: 하나의 Pass 안에서 여러 후처리 단계를 순서대로 실행한다.
- Base Pass의 출력(인코딩된 색상)을 읽는다.
- 색상 디코딩 (Decode).
- SSAO 합성.
- 후처리 안개(Post-Process Fog) 합성.
- 컬러 그레이딩(Color Grading) 수행.
- 투명 오브젝트 렌더링(예: 수면).
- 독립 반투명 오브젝트(Separate Translucency) 렌더링. 보통 후처리 영향을 받지 않는 이펙트다.
- 최종적으로 Bloom 과 Distortion 이 포함된 이미지를 출력한다.
제 3 부분

스크린샷

스크린샷

스크린샷
모바일 렌더링 파이프라인의 성능 병목과 최적화
1. 전통적인 멀티 Pass 렌더링 흐름의 과제
- 표준 렌더링 흐름 개요:
- Base Pass: 씬의 기본 색상을 출력한다.
- 후처리 단계:
- 색상 디코딩(Color Decode).
- 스크린 공간 주변광 차폐(SSAO) 합성.
- 후처리 안개(Post-Process Fog).
- 컬러 그레이딩(Color Grading).
- 투명 오브젝트 렌더링:
- 수면, 반투명 이펙트 등을 렌더링.
- Separate Translucency 큐의 오브젝트 렌더링. 보통 후처리 영향을 받지 않게 하려는 이펙트다.
- 최종 합성: Bloom, Distortion(왜곡), Tone Mapping 결과를 합성한다.
- 핵심 성능 문제: 잦은 Render Pass 전환
- 모바일에서는 Render Pass 를 전환할 때마다 중간 결과를 시스템 메모리(그래픽 메모리)에 다시 기록(Write back) 해야 하며, 이 과정에서 큰 대역폭과 시간 비용이 발생한다.
- 복잡한 장면에서는 이로 인해 기기 발열, 프레임 저하, 전력 소모 증가가 발생한다.
- 초기 파이프라인은 1차 병합을 거친 뒤에도 여전히 5개의 Render Pass 와 4번의 중간 결과 메모리 write back 이 필요했다.
- 문제의 근본 원인: Pass를 끊는 요소
- 후처리 머티리얼(Post-Process Material): 이전 단계의 렌더링 결과를 샘플링해야 하므로 현재 Pass를 강제로 중단하고 결과를 메모리에 쓴 뒤, 새 Pass를 열어 처리하게 만든다.
- 왜곡 효과(Distortion): 합성 단계에서 역시 씬 색상을 샘플링해야 하므로 Pass가 끊긴다.

스크린샷

스크린샷

스크린샷

스크린샷
2. 최적화 방안 1: Subpass 후처리 머티리얼
- 문제 분석:
- 전통적인 후처리 머티리얼은 PostProcessInput0(이전 Pass의 렌더링 결과)을 샘플링해야 한다. 이 때문에 자연스럽게 세 개의 독립적인 Pass로 나뉜다.
- Pass 1: 씬 렌더링.
- Pass 2: Pass 1의 결과를 메모리에 기록.
- Pass 3: 후처리 머티리얼이 메모리에 있는 결과를 읽어 계산.
- 전통적인 후처리 머티리얼은 PostProcessInput0(이전 Pass의 렌더링 결과)을 샘플링해야 한다. 이 때문에 자연스럽게 세 개의 독립적인 Pass로 나뉜다.
- 핵심 아이디어와 통찰:
- 핵심 통찰: 프로젝트의 대부분 후처리 머티리얼은 현재 픽셀의 색상만 샘플링 하면 되며, 주변 픽셀을 샘플링할 필요가 없다.
- 해결책: 모바일 GPU의 Framebuffer Fetch (FBF) 기능을 활용한다.
- Framebuffer Fetch 는 셰이더 실행 중 Tile Memory(온칩 메모리) 에 이미 존재하는 현재 픽셀 위치의 데이터(예: 색상)를 직접 읽을 수 있게 해준다. 따라서 현재 Render Pass를 끝낼 필요가 없다.
- 구현과 효과:
- Subpass 후처리 머티리얼 개발: 전통적인 텍스처 샘플링 대신 Framebuffer Fetch 로 이전 계산 색상을 가져오는 새로운 머티리얼 타입을 제공했다.
- 최적화 결과: Color Grading, 반투명 렌더링, 후처리 머티리얼 같은 여러 렌더링 단계를 하나의 Render Pass 안으로 병합했다. 모든 계산은 효율적인 Tile Memory 안에서 수행되고, 마지막에 최종 결과만 한 번 시스템 메모리에 기록한다.
- 성능 이득 (iPhone X):
- 테스트 장면: 쓰기 대역폭 23% 최적화, GPU 시간 31.6% 최적화.
- 실제 게임 장면: GPU 시간 5.5% 최적화, 쓰기 대역폭 14.8% 최적화, 읽기 대역폭 16.5% 최적화.

스크린샷

스크린샷

스크린샷
3. 최적화 방안 2: Distortion 계산 병합
- 문제 분석:
- 전통적인 Distortion 은 두 단계로 나뉜다.
- 누적(Accumulation): 모든 왜곡 효과의 오프셋 값을 하나의 RT에 렌더링한다.
- 합성(Merge): 새 Pass를 열고 누적된 오프셋으로 씬 색상을 샘플링해 왜곡 효과를 구현한다. 이 샘플링 작업이 렌더링 흐름을 끊는다.
- 전통적인 Distortion 은 두 단계로 나뉜다.
- 핵심 아이디어:
- 합성 계산을 뒤로 미루기: Distortion의 합성 계산 로직을 이후 단계 중 원래부터 씬 색상을 샘플링해야 하는 Pass로 옮긴다.
- 대상 Pass: Bloom 과 Tone Mapping. 두 Pass는 원래 씬 색상을 읽어야 하므로, 읽을 때 Distortion의 UV 오프셋을 추가 적용하는 비용은 낮다.
- 구현과 트레이드오프:
- 구현 방식: Bloom 과 Tone Mapping 셰이더에서 씬 색상을 샘플링하는 UV 좌표에 Distortion 텍스처의 오프셋 값을 적용한다.
- 결과: 독립적인 Distortion 합성 Pass를 제거해 메인 렌더링 흐름이 더 이상 끊기지 않게 했다.
- 표현상의 트레이드오프: 합성 시점이 뒤로 밀리면서, 원래는 왜곡의 영향을 받지 않던 이펙트(예: Separate Translucency)도 이제 왜곡된다. 프로젝트에서는 이 시각적 결과를 허용 가능한 것으로 판단했다.
- 성능 이득 (iPhone X):
- GPU 시간 13.8% 최적화.
- 읽기·쓰기 대역폭 약 30% 최적화.

스크린샷

스크린샷

스크린샷
4. 궁극적 최적화: 단일 Pass 기반 저사양 HDR 파이프라인
- 최적화 성과 정리:
- 위 두 최적화를 통해 렌더링 흐름을 5개의 Render Pass / 4번의 메모리 write back 에서 2개의 Render Pass / 1번의 메모리 write back 으로 줄였다.
- Color Grading 부터 Separate Translucency 까지 대부분의 작업을 하나의 Render Pass 안에서 완료했다.
- 추가 병합 아이디어:
- Pass 병합 효과가 이렇게 크다면, 더 앞 단계인 Pre-Pass, Base Pass 와 이후 Tone Mapping 등도 모두 하나의 Render Pass로 합칠 수 있지 않을까?
- “저사양 버전” 단일 Pass 파이프라인 구현:
- 핵심 기술:
- Framebuffer Fetch: 이후 계산에서 현재 픽셀의 색상 정보를 가져오는 데 사용.
- Depth Stencil Fetch: 이후 계산에서 현재 픽셀의 깊이 정보를 가져오는 데 사용.
- 구현 원리: 두 Fetch 기술을 활용해 Pre-Pass부터 Tone Mapping까지 모든 계산을 Tile Memory 안에서 이어서 수행한다. 중간 결과를 메인 메모리에 write back 하지 않는다.
- 기술적 희생(Trade-offs):
- 이 방식은 주변 픽셀 샘플링이 필요한 후처리 효과 를 구현할 수 없다.
- SSAO, 스크린 공간 반사(SSR), Bloom 같은 효과를 비활성화하거나 제거해야 한다.
- 일부 고급 효과를 희생하지만, 화면에 큰 영향을 주는 핵심 후처리(예: 컬러 그레이딩, 안개 효과 등)는 유지해 극한 성능을 위한 렌더링 파이프라인을 구현했다.
- 핵심 기술:
제 4 부분

스크린샷

스크린샷
저사양 HDR 렌더링 파이프라인 최적화
핵심 아이디어와 목표
- 목표: 저사양 기기를 대상으로 HDR 렌더링 파이프라인을 최적화한다. 핵심 비주얼 스타일은 유지하면서 성능 비용, 특히 메모리 대역폭 비용을 크게 낮추는 것이 목표다.
- 핵심 전략: 렌더링 패스 병합(Pass Consolidation) 을 통해 여러 후처리 단계를 하나의 Render Pass 로 통합하고, 모바일 GPU(TBDR 구조)의 특성을 활용해 Tile Memory(온칩 메모리) 안에서 계산을 완료한다.
구체적 최적화 전략
- 비용이 큰 후처리 효과 제거
- 단일 Pass 통합을 실현하기 위해, 멀티 Pass 나 복잡한 계산에 의존하는 후처리 효과를 선택적으로 제거했다.
- 주요 제거 효과:
- 스크린 공간 주변광 차폐(SSAO)
- 스크린 공간 반사(SSR)
- 블룸(Bloom)
- TBDR 특성을 활용한 계산 병합
- Framebuffer Fetch / Subpass Load: 같은 Render Pass 의 프래그먼트 셰이더 안에서, 현재 픽셀 위치에 이미 프레임버퍼에 기록된 색상 데이터를 직접 읽을 수 있게 한다.
- Depth/Stencil Fetch: 마찬가지로 현재 픽셀의 깊이와 스텐실 값을 직접 읽을 수 있게 한다.
- 구현 방식: 위 기능을 사용해, 원래는 여러 Pass가 필요했던 계산(예: 씬을 먼저 렌더링한 뒤 G-Buffer/Color Buffer를 다시 읽어 후처리)을 모두 하나의 Pass 안으로 집중시킨다.
- 핵심 비주얼 표현 유지
- 일부 효과를 제거했지만, 화면 스타일에 큰 영향을 주는 핵심 후처리 단계는 유지했다.
- 유지한 효과:
- 후처리 안개(Post-Processing Fog)
- 컬러 그레이딩(Color Grading)
- 톤 매핑(Tonemapping)
- 결과: 최적화된 파이프라인에서도 원래의 화면 분위기와 아트 스타일을 잘 유지할 수 있었다.
성능 이득과 분석
- 중간 결과 write back 감소 (Reduced Write Bandwidth):
- 가장 큰 성능 향상 요인이다. 계산이 Tile Memory 안에서 닫힌 루프로 완료되므로, 중간 결과(예: 씬 색상, 깊이)를 시스템 메모리에 쓴 뒤 이후 Pass가 다시 읽는 과정을 피할 수 있다.
- 깊이 버퍼 최적화: 깊이 정보를 위한 별도 Render Target 을 만들고 시스템 메모리에 저장할 필요가 없다.
- Memoryless Depth/Stencil: 깊이/스텐실 첨부(Depth/Stencil Attachment)를 Memoryless 로 설정할 수 있다. 이렇게 하면 해당 내용은 렌더링 중에만 Tile Memory에 존재하고 렌더링 종료 후 폐기되므로 write back 대역폭 비용을 완전히 제거할 수 있다.
- 성능 테스트 데이터 (Remix 2 기준):
- 렌더링 시간(Render Time): 3% 최적화
- 읽기 대역폭(Read Bandwidth): 15.1% 최적화
- 쓰기 대역폭(Write Bandwidth): 30% 최적화(가장 큰 이득)
'TECH.ART.FLOW.IO' 카테고리의 다른 글
| [번역] UE6 Verse 첫 탐색 1: 총람과 문법 (0) | 2026.06.22 |
|---|---|
| [번역] Gdc2024 Open World Rendering Techniques in 'Hogwarts Legacy' (1) | 2026.06.22 |
| [번역] RenderDoc For VSCode: 에디터를 떠나지 않고 GPU Debug (0) | 2026.06.22 |
| [번역] RecaNoMaho 처음부터 시작하는 체적광 렌더링 (1) | 2026.06.19 |
| [번역] 텐센트 델타포스 대형 월드 RVT 지형 렌더링 분석과 재현 (0) | 2026.06.18 |