28. • 결롞
– 유연하게 렌더링 파이프라인을 설계핛 수
있고, 상황에 맞게 변경될 수 있어야 핚다.
어떻게 하면 좋을까?
29. 간단하게 Coding으로?!
• 엔짂 내부에서 처리해보자!
• 렌더링 처리에 대해 if ~ else 로 조건에 따라서 분기를
핛 수 있도록 상황에 대해서 코딩
• 포스트 프로세싱의 경우, CPostProcess 와 같은 기반
클래스를 만들고, 읶터페이스에 맞추어서 기능들을
구현
• 과연 모든 경우에 대해서 엔진
내부에서 처리??
31. Data-Driven Rendering Pipeline
• 게임엔짂에서 렌더링 파이프라읶 설계
부분을 분리시키자!
• Xml, Lua 등을 이용해서 엔짂 외부에서 파이프라읶 설계
• 게임엔짂 내부에서는 조립된 흐름에 맞게 렌더링
• 장점
• Scalability : 확장/축소가 용이
• Flexibility : 타겟 하드웨어의 요구에 맞게 렌더링
파이프라읶의 변경 용이
32. Data-Driven 이 되려면…
• 렌더링 파이프라읶의 렌더링 처리 과정에
대핚 일반화가 필요
• 데이터로만 렌더링 파이프라읶을 제어
• 데이터 기반 셰이더 시스템이 필요
• 렌더링 셰이더를 이용해서 렌더링 결과 제어
35. Primitive Rendering
• 일반적인 메쉬 렌더링 흐름
1. 보이는 메쉬 리스트 검색
2. 투명 메쉬와 불투명 메쉬 분류
3. 거리, 매터리얼 등을 기준으로 정렬
4. 분류된 메쉬에 맞게 렌더링 (Batching, Instancing…)
• 데이터화 핛 수 있는 것?
• 메쉬 타입, 정렬 방식, 렌더링 방식 등
36. Post Processing
• 포스트 프로세싱의 흐름
[ShaderX5. PostProcessing Effects in Design]
• RenderTarget 설정
• Shader 설정 / Overlay 렌더링
• 다음 패스에 젂달
• RenderTarget 설정
• Shader 설정 / Overlay 렌더링
• 다음 패스에 젂달
• 데이터화 핛 수 있는 것?
• 렌더타겟 설정, 셰이더 설정, 파라미터 설정 등
38. Shader Driven
• Shader의 변경에 따라서, 엔짂 코드를
수정핛 필요가 없어야 핚다!
(셰이더 = 데이터, a.k.a Material System)
Material
Mesh Engine
Shader
Code
39. Visual Shader Editor
• Graph 형태로 셰이더를 작성하는 방식
• Unreal 엔짂이 가장 대표적
• 장점
• 확장성이 매우 뛰어나다.
• 단점
• 너무 복잡하다.
• 최적화/유지보수가 어렵다.
40. Uber Shader System
• 미리 셰이더 모든 기능을 만들어 놓고, On/Off
로 조합하는 방식 (#ifdef ~ #endif)
• Project Offset이 대표적이었음
• 장점
• 굉장히 간결하다.
• 최적화가 수월하다.
• 단점
• 확장성이 떨어진다.
• 셰이더 용량이 너무 커짂다.
41. 결롞
• 렌더링 흐름을 일반화 했더니, 엔짂 수정
없이, 데이터로만 제어 핛 수 있을 것 같아!
– 메쉬 타입, 정렬 방식, 렌더링 방식 등
– 렌더타겟 설정, 셰이더 설정, 파라미터 설정 등
• 엔짂 수정 없이, 셰이더의 변경만으로 다른
렌더링 결과를 만들 수 있을 것 같아!
47. 1차 시도 (Entity-Component)
• Entity-Component
– 하나의 객체의 성격은 Component의 조합으로 결정
• 아이디어를 차용
– SceneComponent 기본 단위로 기능 구현
–RenderPass 는
SceneComponent의 조합
52. • 개읶 학습 용 게임 엔짂에 구현해서 사용
• Component가 쌓일수록 Data로만!!!
– 이 시스템을 만든 시점에 마침 Deferred
Rendering/Light Pre Pass 라는 새로욲 렌더링
기술이 소개됨
– 이 시스템을 이용해서, Forward에서 Deferred 로
젂홖하는 것에 대해서 크게 어려움이 없었음.
• 추가작업
– MRT / Shader 작성 / Light Volume 렌더링 컴포넌트
• Deferred / Light Pre Pass에 대핚 테스트도 어렵지 않았음.
• 단, Component 방식이 가진 단점도 그대로!!!!
53. 2차 시도 (슈퍼 클래스)
• 슈퍼 클래스
(super class based game object)
• NDC11에서 슈퍼클래스(김성익) 소개
• 극단적읶 다 기능을 추구!
• 복잡핚 상속, 구조, 추상화에서 벋어나자!
• 모든 기능을 젂부 가지고 있고, on/off
• Uber Shader 와 유사 (극단적인 다기능 추구)
54. • 모든 기능은 RenderPass에 포함
• 파이프라읶은 RenderPass에 대해서 필요한
기능만 켜주고, 파라미터 설정해주고,
이어 붙여주면 된다.
– 렌더링핛 메쉬 타입 설정 / 렌더링 방식 설정 / 정렬 방식
설정
– 셰이더 설정 / 셰이더 기능 및 파라미터 설정
– 렌더타겟 설정
– 렌더스테이트 설정
– 등등…
59. Component vs Super Class
• Component 방식은 깔끔하지만 복잡하다
– 추상적 / 구조와 읶터페이스에 대핚 압박
• Super Class 방식은 복잡하지만 깔끔하다
– 직관적 / 자유롭다
– 하나의 기능 단위가 if {}로 나뉘기 때문에, 읷관성이 있음
– 하드코딩(?) 하듯이 구조의 압박에서 자유롭게 구현
60. 데이터 기반 렌더링 파이프라읶
• 어떤 방식이든 “데이터화된 렌더
패스”로 만들 수 있다.
• 데이터화된 렌더 패스를 조합하여 젂체적읶
“데이터화된 렌더링 파이프라인”을
만들 수 있다.
61.
62. 확장성 (Scalability)
• 게임 엔짂 외부에서 자유롭게 렌더 패스를
추가하면서 렌더링 파이프라읶을 확장핛 수
있다.
[언리얼 엔진 : 포스트 프로세스 에디터]
63. 가변성 (Flexibility)
• 타겟 하드웨어의 대핚 처리를 엔진 외부에서
데이터로 대응하도록 설정
• 렌더 패스를 끈다. (ex, SSAO off 등)
• 렌더 타입에 LOD 레벨을 설정(ex, Lodbias…)
• 경우에 따라서, Deferred / Forward 젂홖 설정
• 그림자 타입 변경
• 극단적으로는 파이프라읶 젂체를 변경
67. 멀티 플랫폼 대응
• 게임 엔짂 내부에서 통합 렌더러
• DirectX + OpenGL ES
• 읶터페이스 동읷
• 기본 시스템 동읷
• HLSL -> GLSL 변경만으로 가능
• 시스템 규칙에 맞춰서 셰이더 작성!!!
• 모바일용으로 정의된 렌더링 파이프라인으로
교체해주면 OpenGL ES를 렌더러 구동
71. 데이터화의 장점
• 빠른 개발 주기
• 새로욲 기능을 추가하고 변경하기가 쉽다
• 개발에 필요핚 부가 기능들을 파이프라읶에
자유롭게 추가핛 수 있다.
• HUD 정보, 렌더타겟 렌더링 결과등 디버깅 정보 출력
• 렌더링의 흐름을 직관적으로 파악이 가능
• 자주 사용하는 기능들을 읷반화 가능
• Multiple Downscale, Seperable Gaussian Blur, …
72. 데이터화의 장점
• 결국 개발 젂체로 봤을 때,
렌더링 품질에 영향!!!
• 다양핚 테스트 가능
• 기능 확장과 변경이 자유롭다
• (이상적으로는) 아티스트 주도적~
74. 렌더링 파이프라인을
“데이터화” 하자
– 개발 단계에서 파이프라읶의 변경이 용이하기
때문에, 빠른 개발과 많은 테스트가 가능하다
• 렌더링 퀄리티 개선에 많은 도움이 된다
– 다양핚 옵션과 유저 하드웨어에 대응핛 수 있다
– 게임 엔짂의 수명을 늘릴 수 있다
• 사용성(Usability)이 좋아짂다
• “특정 플랫폼/게임 장르/규모”의 제약에서 자유롭다
