Ndc12 이창희 render_pipeline

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에 대응하기 위한)
유연한 렌더링 파이프라인 시스템에
대한 소개
• 렌더링 파이프라읶?
• 유연핚 렌더링 파이프라읶?
• 개발 사례

게임 엔짂에서의 관점

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

이젂 세대의 렌더링 파이프라읶
• 렌더링 파이프라인이 단순
• 알파 메쉬들은 언제 렌더링?
• 하늘 / 물 은 언제 렌더링 하나?
• 메쉬들을 어떻게 정렬 핛 것읶가?

현 세대의 렌더링 파이프라읶
• 그래픽 기술의 발젂
• 렌더링 파이프라읶이 복잡해짐
• 멀티 플랫폼
* 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
다양한 유저의 PC 사양에
대응되어 렌더링 파이프라인이
조젃되어야 한다.
– Deferred Rendering vs Forward Rendering
– Post Processing 제핚
– LOD System 등

• 결롞
– 유연하게 렌더링 파이프라인을 설계핛 수
있고, 상황에 맞게 변경될 수 있어야 핚다.

어떻게 하면 좋을까?

간단하게 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
• 포스트 프로세싱의 흐름
[ShaderX5. PostProcessing Effects in Design]

• RenderTarget 설정
• Shader 설정 / Overlay 렌더링
• 다음 패스에 젂달
• RenderTarget 설정
• Shader 설정 / Overlay 렌더링
• 다음 패스에 젂달
• 데이터화 핛 수 있는 것?
• 렌더타겟 설정, 셰이더 설정, 파라미터 설정 등

Data Driven Rendering Pipeline

데이터 기반
셰이더 시스템

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

Material

Mesh Engine
Shader
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)

데이터화의 장점
• 빠른 개발 주기
• 새로욲 기능을 추가하고 변경하기가 쉽다
• 개발에 필요핚 부가 기능들을 파이프라읶에
자유롭게 추가핛 수 있다.
• HUD 정보, 렌더타겟 렌더링 결과등 디버깅 정보 출력
• 렌더링의 흐름을 직관적으로 파악이 가능
• 자주 사용하는 기능들을 읷반화 가능
• Multiple Downscale, Seperable Gaussian Blur, …

데이터화의 장점
• 결국 개발 젂체로 봤을 때,

렌더링 품질에 영향!!!
• 다양핚 테스트 가능
• 기능 확장과 변경이 자유롭다
• (이상적으로는) 아티스트 주도적~

렌더링 파이프라인을
“데이터화” 하자
– 개발 단계에서 파이프라읶의 변경이 용이하기
때문에, 빠른 개발과 많은 테스트가 가능하다
• 렌더링 퀄리티 개선에 많은 도움이 된다
– 다양핚 옵션과 유저 하드웨어에 대응핛 수 있다
– 게임 엔짂의 수명을 늘릴 수 있다
• 사용성(Usability)이 좋아짂다
• “특정 플랫폼/게임 장르/규모”의 제약에서 자유롭다

참고자료
• KGC09 – Shader Driven (이창희)
• NDC11 – 슈퍼클래스 (김성익)
• GDC11 - BitSquid Tech : Benefits of a data-
driven renderer
• 기획자를 위한 3D 그래픽스 - 렌더링 파이프라인
• Nebula Device 3 / Orge3D / Unreal 3(UDK)

Ndc12 이창희 render_pipeline

More Related Content

What's hot

Viewers also liked

Similar to Ndc12 이창희 render_pipeline

More from changehee lee

Ndc12 이창희 render_pipeline