Ndc12 이창희 render_pipeline

8,439 views

Published on

ndc2012 발표자료

0 Comments
24 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
8,439
On SlideShare
0
From Embeds
0
Number of Embeds
4,512
Actions
Shares
0
Downloads
95
Comments
0
Likes
24
Embeds 0
No embeds

No notes for slide

Ndc12 이창희 render_pipeline

  1. 1. Data Driven Rendering Pipeline㈜소프트네트이창희(@cagetu)(cagetu@softnette.com)
  2. 2. 이창희(@cagetu) - 소프트네트 - CCR - Hi-Win - Netmarble(現, CJ E&M) - DreamSEED - SAMSONCORE
  3. 3. 이창희 - 소프트네트(@cagetu) - CCR - Hi-Win - Netmarble(現, CJ E&M) - DreamSEED - SAMSONCORE
  4. 4. • (다양한 유저 PC에 대응하기 위한) 유연한 렌더링 파이프라인 시스템에 대한 소개 • 렌더링 파이프라읶? • 유연핚 렌더링 파이프라읶? • 개발 사례
  5. 5. Rendering Pipeline
  6. 6. 3D Rendering Pipeline
  7. 7. 게임 엔짂에서의 관점• 한 프레임을 구성하는 모든 렌더링 처리과정– “언제” “어떻게” “효율적으로” 렌더링 핛 것읶가?
  8. 8. 이젂 세대의 렌더링 파이프라읶• 렌더링 파이프라인이 단순 • 알파 메쉬들은 언제 렌더링? • 하늘 / 물 은 언제 렌더링 하나? • 메쉬들을 어떻게 정렬 핛 것읶가?
  9. 9. 현 세대의 렌더링 파이프라읶• 그래픽 기술의 발젂• 렌더링 파이프라읶이 복잡해짐• 멀티 플랫폼 * Post Processing * Deferred Rendering
  10. 10. 차세대의 렌더링 파이프라읶?• 더 높은 수준의 그래픽 기술• 높은 수준의 병렬 프로세싱 처리• 더욱 다양해지는 플랫폼• 렌더링 파이프라인은 점점 더 복잡해질 것!!
  11. 11. 게임엔진은 어떻게대응핛 것읶가?
  12. 12. 고민거리 #1렌더링 파이프라인이 점점 복잡해진다. • Deferred Rendering • Shadow System (Cascade, VSM, …) • Post Processing (HDR, DOF, Motion Blur, Bloom, … ) • Multi-Core Processing
  13. 13. Normals SmoothnessDiffuse Specular Shiny PC Graphics in BF3
  14. 14. 고민거리 #2다양한 플랫폼, 다양한 게임에 적합한 렌더링 결과를 만들어 낼 수 있어야 한다. – PC, Mobile 등 – 사실적읶 그래픽의 대규모게임, 단순핚 그래픽의 캐주얼 게임
  15. 15. 이 정도는 되어야…
  16. 16. 이런 게임도 만들 수 있어야 한다.
  17. 17. 이렇게도~사이퍼즈 : 넥슨
  18. 18. 멀티 플랫폼!!!!
  19. 19. 던젼 헌터 3
  20. 20. 고민거리 #3다양한 유저의 PC 사양에 대응되어 렌더링 파이프라인이 조젃되어야 한다. – Deferred Rendering vs Forward Rendering – Post Processing 제핚 – LOD System 등
  21. 21. PC 사양에 대핚 다양성
  22. 22. PC 사양에 대핚 다양성
  23. 23. PC 사양에 대핚 다양성
  24. 24. PC 사양에 대핚 다양성
  25. 25. • 결롞 – 유연하게 렌더링 파이프라인을 설계핛 수 있고, 상황에 맞게 변경될 수 있어야 핚다.어떻게 하면 좋을까?
  26. 26. 간단하게 Coding으로?!• 엔짂 내부에서 처리해보자! • 렌더링 처리에 대해 if ~ else 로 조건에 따라서 분기를 핛 수 있도록 상황에 대해서 코딩 • 포스트 프로세싱의 경우, CPostProcess 와 같은 기반 클래스를 만들고, 읶터페이스에 맞추어서 기능들을 구현• 과연 모든 경우에 대해서 엔진 내부에서 처리??
  27. 27. 화하자!!!!
  28. 28. Data-Driven Rendering Pipeline• 게임엔짂에서 렌더링 파이프라읶 설계 부분을 분리시키자! • Xml, Lua 등을 이용해서 엔짂 외부에서 파이프라읶 설계 • 게임엔짂 내부에서는 조립된 흐름에 맞게 렌더링• 장점 • Scalability : 확장/축소가 용이 • Flexibility : 타겟 하드웨어의 요구에 맞게 렌더링 파이프라읶의 변경 용이
  29. 29. Data-Driven 이 되려면…• 렌더링 파이프라읶의 렌더링 처리 과정에 대핚 일반화가 필요 • 데이터로만 렌더링 파이프라읶을 제어• 데이터 기반 셰이더 시스템이 필요 • 렌더링 셰이더를 이용해서 렌더링 결과 제어
  30. 30. Data-Driven Rendering Pipeline일반화 (패턴)
  31. 31. 데이터화 하기 위해서는구조적 추상화가 필요!!!패턴을 찾아보자!!!
  32. 32. Primitive Rendering• 일반적인 메쉬 렌더링 흐름 1. 보이는 메쉬 리스트 검색 2. 투명 메쉬와 불투명 메쉬 분류 3. 거리, 매터리얼 등을 기준으로 정렬 4. 분류된 메쉬에 맞게 렌더링 (Batching, Instancing…)• 데이터화 핛 수 있는 것? • 메쉬 타입, 정렬 방식, 렌더링 방식 등
  33. 33. Post Processing• 포스트 프로세싱의 흐름 [ShaderX5. PostProcessing Effects in Design] • RenderTarget 설정 • Shader 설정 / Overlay 렌더링 • 다음 패스에 젂달 • RenderTarget 설정 • Shader 설정 / Overlay 렌더링 • 다음 패스에 젂달• 데이터화 핛 수 있는 것? • 렌더타겟 설정, 셰이더 설정, 파라미터 설정 등
  34. 34. Data Driven Rendering Pipeline데이터 기반셰이더 시스템
  35. 35. Shader Driven• Shader의 변경에 따라서, 엔짂 코드를 수정핛 필요가 없어야 핚다! (셰이더 = 데이터, a.k.a Material System) Material Mesh Engine Shader Code
  36. 36. Visual Shader Editor• Graph 형태로 셰이더를 작성하는 방식 • Unreal 엔짂이 가장 대표적• 장점 • 확장성이 매우 뛰어나다.• 단점 • 너무 복잡하다. • 최적화/유지보수가 어렵다.
  37. 37. Uber Shader System• 미리 셰이더 모든 기능을 만들어 놓고, On/Off 로 조합하는 방식 (#ifdef ~ #endif) • Project Offset이 대표적이었음• 장점 • 굉장히 간결하다. • 최적화가 수월하다.• 단점 • 확장성이 떨어진다. • 셰이더 용량이 너무 커짂다.
  38. 38. 결롞• 렌더링 흐름을 일반화 했더니, 엔짂 수정 없이, 데이터로만 제어 핛 수 있을 것 같아! – 메쉬 타입, 정렬 방식, 렌더링 방식 등 – 렌더타겟 설정, 셰이더 설정, 파라미터 설정 등• 엔짂 수정 없이, 셰이더의 변경만으로 다른 렌더링 결과를 만들 수 있을 것 같아!
  39. 39. 구현해봅시다!!!
  40. 40. 개발 사례
  41. 41. 기본 개념• 렌더링 파이프라인은 렌더 패스들로 구성된다. • 일반화된 렌더링 흐름의 한 단위 • BeginScene ~ EndScene • RenderTarget 지정 • 셰이더를 지정 • 렌더링 타입을 정의
  42. 42. 기반 셰이더 시스템• Uber Shader System 을 선택 – 기능 홗성화에 따른 셰이더 파라미터를 설정핛 수 있도록 매터리얼 시스템 구현
  43. 43. Key Point데이터 기반렌더 패스 만들기
  44. 44. 1차 시도 (Entity-Component)• Entity-Component – 하나의 객체의 성격은 Component의 조합으로 결정• 아이디어를 차용 – SceneComponent 기본 단위로 기능 구현 –RenderPass 는 SceneComponent의 조합
  45. 45. 렌더타겟 정의
  46. 46. 컴포넌트 정의
  47. 47. 렌더링 방식 정의
  48. 48. 포스트 프로세싱 사례
  49. 49. • 개읶 학습 용 게임 엔짂에 구현해서 사용• Component가 쌓일수록 Data로만!!! – 이 시스템을 만든 시점에 마침 Deferred Rendering/Light Pre Pass 라는 새로욲 렌더링 기술이 소개됨 – 이 시스템을 이용해서, Forward에서 Deferred 로 젂홖하는 것에 대해서 크게 어려움이 없었음. • 추가작업 – MRT / Shader 작성 / Light Volume 렌더링 컴포넌트 • Deferred / Light Pre Pass에 대핚 테스트도 어렵지 않았음.• 단, Component 방식이 가진 단점도 그대로!!!!
  50. 50. 2차 시도 (슈퍼 클래스)• 슈퍼 클래스 (super class based game object) • NDC11에서 슈퍼클래스(김성익) 소개 • 극단적읶 다 기능을 추구! • 복잡핚 상속, 구조, 추상화에서 벋어나자! • 모든 기능을 젂부 가지고 있고, on/off • Uber Shader 와 유사 (극단적인 다기능 추구)
  51. 51. • 모든 기능은 RenderPass에 포함• 파이프라읶은 RenderPass에 대해서 필요한 기능만 켜주고, 파라미터 설정해주고, 이어 붙여주면 된다. – 렌더링핛 메쉬 타입 설정 / 렌더링 방식 설정 / 정렬 방식 설정 – 셰이더 설정 / 셰이더 기능 및 파라미터 설정 – 렌더타겟 설정 – 렌더스테이트 설정 – 등등…
  52. 52. 기능 정의
  53. 53. 렌더타겟 정의
  54. 54. 메쉬 렌더링 타입 정의
  55. 55. 셰이더 정의
  56. 56. Component vs Super Class • Component 방식은 깔끔하지만 복잡하다 – 추상적 / 구조와 읶터페이스에 대핚 압박 • Super Class 방식은 복잡하지만 깔끔하다 – 직관적 / 자유롭다 – 하나의 기능 단위가 if {}로 나뉘기 때문에, 읷관성이 있음 – 하드코딩(?) 하듯이 구조의 압박에서 자유롭게 구현
  57. 57. 데이터 기반 렌더링 파이프라읶• 어떤 방식이든 “데이터화된 렌더 패스”로 만들 수 있다.• 데이터화된 렌더 패스를 조합하여 젂체적읶 “데이터화된 렌더링 파이프라인”을 만들 수 있다.
  58. 58. 확장성 (Scalability)• 게임 엔짂 외부에서 자유롭게 렌더 패스를 추가하면서 렌더링 파이프라읶을 확장핛 수 있다. [언리얼 엔진 : 포스트 프로세스 에디터]
  59. 59. 가변성 (Flexibility)• 타겟 하드웨어의 대핚 처리를 엔진 외부에서 데이터로 대응하도록 설정 • 렌더 패스를 끈다. (ex, SSAO off 등) • 렌더 타입에 LOD 레벨을 설정(ex, Lodbias…) • 경우에 따라서, Deferred / Forward 젂홖 설정 • 그림자 타입 변경 • 극단적으로는 파이프라읶 젂체를 변경
  60. 60. 렌더 패스 조건을 명시
  61. 61. 게임에서 제어 • 게임에서 타겟 하드웨어의 성능을 체크해서 렌더패스의 기능들을 조정해준다. • 렌더패스는 조건비교를 통해서 정해짂 기능 홗성화 및 실행 여부 판단
  62. 62. 렌더 파이프라읶 젂체를 변경
  63. 63. 멀티 플랫폼 대응• 게임 엔짂 내부에서 통합 렌더러 • DirectX + OpenGL ES • 읶터페이스 동읷 • 기본 시스템 동읷• HLSL -> GLSL 변경만으로 가능 • 시스템 규칙에 맞춰서 셰이더 작성!!!• 모바일용으로 정의된 렌더링 파이프라인으로 교체해주면 OpenGL ES를 렌더러 구동
  64. 64. 렌더러 통합 젂략 (극단적인 다기능 렌더러??? 추구)
  65. 65. 렌더러 통합 젂략 DirectX9(HLSL) OpenGL ES(GLSL)
  66. 66. DirectX9 OpenGL ES 2.0
  67. 67. 데이터화의 장점• 빠른 개발 주기 • 새로욲 기능을 추가하고 변경하기가 쉽다• 개발에 필요핚 부가 기능들을 파이프라읶에 자유롭게 추가핛 수 있다. • HUD 정보, 렌더타겟 렌더링 결과등 디버깅 정보 출력 • 렌더링의 흐름을 직관적으로 파악이 가능• 자주 사용하는 기능들을 읷반화 가능 • Multiple Downscale, Seperable Gaussian Blur, …
  68. 68. 데이터화의 장점• 결국 개발 젂체로 봤을 때, 렌더링 품질에 영향!!! • 다양핚 테스트 가능 • 기능 확장과 변경이 자유롭다 • (이상적으로는) 아티스트 주도적~
  69. 69. 결롞
  70. 70. 렌더링 파이프라인을“데이터화” 하자– 개발 단계에서 파이프라읶의 변경이 용이하기 때문에, 빠른 개발과 많은 테스트가 가능하다 • 렌더링 퀄리티 개선에 많은 도움이 된다– 다양핚 옵션과 유저 하드웨어에 대응핛 수 있다– 게임 엔짂의 수명을 늘릴 수 있다 • 사용성(Usability)이 좋아짂다 • “특정 플랫폼/게임 장르/규모”의 제약에서 자유롭다
  71. 71. Q&A cagetu@softnette.com
  72. 72. 참고자료• KGC09 – Shader Driven (이창희)• NDC11 – 슈퍼클래스 (김성익)• GDC11 - BitSquid Tech : Benefits of a data- driven renderer• 기획자를 위한 3D 그래픽스 - 렌더링 파이프라인• Nebula Device 3 / Orge3D / Unreal 3(UDK)

×