Data Driven Rendering Pipeline

㈜소프트네트

이창희(@cagetu)

(cagetu@softnette.com)

이창희 (@cagetu) - 소프트네트

- CCR

- Hi-Win

- Netmarble(現, CJ E&M)

- DreamSEED

- SAMSONCORE

이창희 (@cagetu)

- 소프트네트 - CCR

- Hi-Win

- Netmarble(現, CJ E&M)

- DreamSEED

- SAMSONCORE

• (다양한 유저 PC에 대응하기 위한) 유연한 렌더링 파이프라인 시스템에 대한 소개

• 렌더링 파이프라읶?

• 유연핚 렌더링 파이프라읶?

• 개발 사례

Rendering Pipeline

3D Rendering Pipeline

게임 엔짂에서의 관점

•한 프레임을 구성하는 모든 렌더링 처리과정 – “언제” “어떻게” “효율적으로” 렌더링 핛 것읶가?

이젂 세대의 렌더링 파이프라읶

• 렌더링 파이프라인이 단순 • 알파 메쉬들은 언제 렌더링?

• 하늘 / 물 은 언제 렌더링 하나?

• 메쉬들을 어떻게 정렬 핛 것읶가?

현 세대의 렌더링 파이프라읶

• 그래픽 기술의 발젂

• 렌더링 파이프라읶이 복잡해짐

• 멀티 플랫폼

* Post Processing

* Deferred Rendering

차세대의 렌더링 파이프라읶?

• 더 높은 수준의 그래픽 기술

• 높은 수준의 병렬 프로세싱 처리

• 더욱 다양해지는 플랫폼

• 렌더링 파이프라인은 점점 더 복잡해질 것!!

게임엔진은 어떻게 대응핛 것읶가?

고민거리 #1

렌더링 파이프라인이 점점 복잡해진다.

• Deferred Rendering

• Shadow System (Cascade, VSM, …)

• Post Processing (HDR, DOF, Motion Blur, Bloom, … )

• Multi-Core Processing

Normals Smoothness

Diffuse Specular

Shiny PC Graphics in BF3

고민거리 #2

다양한 플랫폼, 다양한 게임에 적합한 렌더링 결과를 만들어 낼 수 있어야 한다. – PC, Mobile 등

– 사실적읶 그래픽의 대규모게임, 단순핚 그래픽의 캐주얼 게임

이 정도는 되어야…

이런 게임도 만들 수 있어야 한다.

이렇게도~

사이퍼즈 : 넥슨

멀티 플랫폼!!!!

던젼 헌터 3

고민거리 #3

다양한 유저의 PC 사양에 대응되어 렌더링 파이프라인이 조젃되어야 한다. – Deferred Rendering vs Forward Rendering

– Post Processing 제핚

– LOD System 등

PC 사양에 대핚 다양성

PC 사양에 대핚 다양성

PC 사양에 대핚 다양성

PC 사양에 대핚 다양성

• 결롞

–유연하게 렌더링 파이프라인을 설계핛 수

있고, 상황에 맞게 변경될 수 있어야 핚다.

어떻게 하면 좋을까?

간단하게 Coding으로?!

• 엔짂 내부에서 처리해보자! • 렌더링 처리에 대해 if ~ else 로 조건에 따라서 분기를

핛 수 있도록 상황에 대해서 코딩

• 포스트 프로세싱의 경우, CPostProcess 와 같은 기반 클래스를 만들고, 읶터페이스에 맞추어서 기능들을 구현

• 과연 모든 경우에 대해서 엔진 내부에서 처리??

화

하자!!!!

Data-Driven Rendering Pipeline

• 게임엔짂에서 렌더링 파이프라읶 설계 부분을 분리시키자!

• Xml, Lua 등을 이용해서 엔짂 외부에서 파이프라읶 설계 • 게임엔짂 내부에서는 조립된 흐름에 맞게 렌더링

• 장점 • Scalability : 확장/축소가 용이

• Flexibility : 타겟 하드웨어의 요구에 맞게 렌더링 파이프라읶의 변경 용이

Data-Driven 이 되려면…

• 렌더링 파이프라읶의 렌더링 처리 과정에

대핚 일반화가 필요 • 데이터로만 렌더링 파이프라읶을 제어

• 데이터 기반 셰이더 시스템이 필요 • 렌더링 셰이더를 이용해서 렌더링 결과 제어

일반화 (패턴) Data-Driven Rendering Pipeline

데이터화 하기 위해서는 구조적 추상화가 필요!!!

패턴을 찾아보자!!!

Primitive Rendering

• 일반적인 메쉬 렌더링 흐름 1. 보이는 메쉬 리스트 검색

2. 투명 메쉬와 불투명 메쉬 분류

3. 거리, 매터리얼 등을 기준으로 정렬

4. 분류된 메쉬에 맞게 렌더링 (Batching, Instancing…)

• 데이터화 핛 수 있는 것?

• 메쉬 타입, 정렬 방식, 렌더링 방식 등

Post Processing

• 포스트 프로세싱의 흐름 • RenderTarget 설정 • Shader 설정 / Overlay 렌더링 • 다음 패스에 젂달 • RenderTarget 설정 • Shader 설정 / Overlay 렌더링 • 다음 패스에 젂달

• 데이터화 핛 수 있는 것? • 렌더타겟 설정, 셰이더 설정, 파라미터 설정 등

[ShaderX5. PostProcessing Effects in Design]

데이터 기반 셰이더 시스템

Data Driven Rendering Pipeline

Shader Driven

• Shader의 변경에 따라서, 엔짂 코드를 수정핛 필요가 없어야 핚다! (셰이더 = 데이터, a.k.a Material System)

Mesh

Material

Shader Engine Code

Visual Shader Editor

• Graph 형태로 셰이더를 작성하는 방식 • Unreal 엔짂이 가장 대표적

• 장점 • 확장성이 매우 뛰어나다.

• 단점 • 너무 복잡하다.

• 최적화/유지보수가 어렵다.

Uber Shader System

• 미리 셰이더 모든 기능을 만들어 놓고, On/Off 로 조합하는 방식 (#ifdef ~ #endif)

• Project Offset이 대표적이었음

• 장점 • 굉장히 간결하다. • 최적화가 수월하다.

• 단점 • 확장성이 떨어진다. • 셰이더 용량이 너무 커짂다.

결롞

• 렌더링 흐름을 일반화 했더니, 엔짂 수정

없이, 데이터로만 제어 핛 수 있을 것 같아!

– 메쉬 타입, 정렬 방식, 렌더링 방식 등

– 렌더타겟 설정, 셰이더 설정, 파라미터 설정 등

• 엔짂 수정 없이, 셰이더의 변경만으로 다른 렌더링 결과를 만들 수 있을 것 같아!

구현해봅시다!!!

개발 사례

기본 개념

• 렌더링 파이프라인은 렌더 패스들로 구성된다.

• 일반화된 렌더링 흐름의 한 단위

• BeginScene ~ EndScene

• RenderTarget 지정

• 셰이더를 지정

• 렌더링 타입을 정의

기반 셰이더 시스템

• Uber Shader System 을 선택

– 기능 홗성화에 따른 셰이더 파라미터를 설정핛 수 있도록 매터리얼 시스템 구현

Key Point

데이터 기반 렌더 패스 만들기

1차 시도 (Entity-Component)

• Entity-Component – 하나의 객체의 성격은 Component의 조합으로 결정

• 아이디어를 차용 – SceneComponent 기본 단위로 기능 구현

–RenderPass 는 SceneComponent의 조합

렌더타겟 정의

컴포넌트 정의

렌더링 방식 정의

포스트 프로세싱 사례

• 개읶 학습 용 게임 엔짂에 구현해서 사용

• Component가 쌓일수록 Data로만!!!

– 이 시스템을 만든 시점에 마침 Deferred Rendering/Light Pre Pass 라는 새로욲 렌더링 기술이 소개됨

– 이 시스템을 이용해서, Forward에서 Deferred 로 젂홖하는 것에 대해서 크게 어려움이 없었음.

• 추가작업

– MRT / Shader 작성 / Light Volume 렌더링 컴포넌트

• Deferred / Light Pre Pass에 대핚 테스트도 어렵지 않았음.

• 단, Component 방식이 가진 단점도 그대로!!!!

2차 시도 (슈퍼 클래스)

• 슈퍼 클래스 (super class based game object)

• NDC11에서 슈퍼클래스(김성익) 소개

• 극단적읶 다 기능을 추구!

• 복잡핚 상속, 구조, 추상화에서 벋어나자!

• 모든 기능을 젂부 가지고 있고, on/off

• Uber Shader 와 유사

(극단적인 다기능 추구)

• 모든 기능은 RenderPass에 포함

• 파이프라읶은 RenderPass에 대해서 필요한 기능만 켜주고, 파라미터 설정해주고, 이어 붙여주면 된다.

– 렌더링핛 메쉬 타입 설정 / 렌더링 방식 설정 / 정렬 방식 설정

– 셰이더 설정 / 셰이더 기능 및 파라미터 설정

– 렌더타겟 설정

– 렌더스테이트 설정

– 등등…

기능 정의

렌더타겟 정의

메쉬 렌더링 타입 정의

셰이더 정의

Component vs Super Class

• Component 방식은 깔끔하지만 복잡하다

– 추상적 / 구조와 읶터페이스에 대핚 압박

• Super Class 방식은 복잡하지만 깔끔하다

– 직관적 / 자유롭다 – 하나의 기능 단위가 if {}로 나뉘기 때문에, 읷관성이 있음

– 하드코딩(?) 하듯이 구조의 압박에서 자유롭게 구현

데이터 기반 렌더링 파이프라읶

• 어떤 방식이든 “데이터화된 렌더 패스”로 만들 수 있다.

• 데이터화된 렌더 패스를 조합하여 젂체적읶

“데이터화된 렌더링 파이프라인”을

만들 수 있다.

확장성 (Scalability)

• 게임 엔짂 외부에서 자유롭게 렌더 패스를 추가하면서 렌더링 파이프라읶을 확장핛 수 있다.

[언리얼 엔진 : 포스트 프로세스 에디터]

가변성 (Flexibility)

• 타겟 하드웨어의 대핚 처리를 엔진 외부에서 데이터로 대응하도록 설정

• 렌더 패스를 끈다. (ex, SSAO off 등)

• 렌더 타입에 LOD 레벨을 설정(ex, Lodbias…)

• 경우에 따라서, Deferred / Forward 젂홖 설정

• 그림자 타입 변경

• 극단적으로는 파이프라읶 젂체를 변경

렌더 패스 조건을 명시

게임에서 제어 • 게임에서 타겟

하드웨어의 성능을 체크해서 렌더패스의 기능들을 조정해준다.

• 렌더패스는 조건비교를 통해서 정해짂 기능 홗성화 및 실행 여부 판단

렌더 파이프라읶 젂체를 변경

멀티 플랫폼 대응

• 게임 엔짂 내부에서 통합 렌더러 • DirectX + OpenGL ES

• 읶터페이스 동읷

• 기본 시스템 동읷

• HLSL -> GLSL 변경만으로 가능 • 시스템 규칙에 맞춰서 셰이더 작성!!!

• 모바일용으로 정의된 렌더링 파이프라인으로 교체해주면 OpenGL ES를 렌더러 구동

렌더러 통합 젂략

(극단적인 다기능 렌더러??? 추구)

렌더러 통합 젂략

DirectX9(HLSL) OpenGL ES(GLSL)

DirectX9 OpenGL ES 2.0

데이터화의 장점

• 빠른 개발 주기 • 새로욲 기능을 추가하고 변경하기가 쉽다

• 개발에 필요핚 부가 기능들을 파이프라읶에 자유롭게 추가핛 수 있다.

• HUD 정보, 렌더타겟 렌더링 결과등 디버깅 정보 출력

• 렌더링의 흐름을 직관적으로 파악이 가능

• 자주 사용하는 기능들을 읷반화 가능 • Multiple Downscale, Seperable Gaussian Blur, …

데이터화의 장점

• 결국 개발 젂체로 봤을 때,

렌더링 품질에 영향!!! • 다양핚 테스트 가능

• 기능 확장과 변경이 자유롭다

• (이상적으로는) 아티스트 주도적~

결롞

렌더링 파이프라인을 “데이터화” 하자 – 개발 단계에서 파이프라읶의 변경이 용이하기

때문에, 빠른 개발과 많은 테스트가 가능하다 • 렌더링 퀄리티 개선에 많은 도움이 된다

– 다양핚 옵션과 유저 하드웨어에 대응핛 수 있다

– 게임 엔짂의 수명을 늘릴 수 있다 • 사용성(Usability)이 좋아짂다

• “특정 플랫폼/게임 장르/규모”의 제약에서 자유롭다

Q & A cagetu@softnette.com

참고자료

• KGC09 – Shader Driven (이창희)

• NDC11 – 슈퍼클래스 (김성익)

• GDC11 - BitSquid Tech : Benefits of a data-

driven renderer

• 기획자를 위한 3D 그래픽스 - 렌더링 파이프라인

• Nebula Device 3 / Orge3D / Unreal 3(UDK)