NDC 2014 [야생의 땅: 듀랑고]에서의 유니티를 이용한 렌더링 개발 이터레이션과 최적화

154,839 views

Published on

Published in: Technology
  • Be the first to comment

NDC 2014 [야생의 땅: 듀랑고]에서의 유니티를 이용한 렌더링 개발 이터레이션과 최적화

  1. 1. <야생의 땅: 듀랑고>에서의 유니티를 이용한 렌더링 개발 이터레이션과 최적화 넥슨 코리아 왓 스튜디오 김혁
  2. 2. 발표자 소개 • 김혁 – 게임 클라이언트 프로그래머 – 주 분야: 컴퓨터 그래픽스, GPU – 넥슨 <배틀스타: 리로드> 오픈 베타 – 넥슨 <야생의 땅: 듀랑고> 개발 중
  3. 3. <야생의 땅: 듀랑고> • 개척형 MMORPG • 모바일 게임 • 유니티 3D 실버바인 아닙니다 • 2014년 5월 22일 첫 티저 공개
  4. 4. 발표의 방향과 개론
  5. 5. 고사양 PC 온라인게임처럼 그냥 멋져 보이는 ‘최신 기술’을 탑재 할 수는 없다 모바일에서의 렌더링
  6. 6. 모든 것이 제약 • CPU/GPU 제약 • 메모리 제약 • 대역폭 제약 • 네트워크 제약
  7. 7. 모바일이라는 환경 • 제약된 환경에서 가장 괜찮은 룩을 찾자! (전통적인 방법 보다는 꼼수(?)를 써보자) • 제약된 환경에서 최대한 성능을 뽑아내자
  8. 8. 사실 더 어렵다 • 제약된 환경에 맞게 발전한 모바일 아키텍쳐에 대한 이해가 필요 • 도대체 누가 모바일을 쉽다고 했나요?
  9. 9. 다루지 않는 것 • 디테일한 렌더링 기법들 이제 티저 한번 공개 됐을 뿐이라서.. • 새로운 스샷 아…주 조금은 있습니다만…
  10. 10. 다룰 것 • 유니티 3D를 이용한 모바일 렌더링 개발 방법론에 대한 이야기 • 몇 가지 최적화 사례
  11. 11. 어쩌면 뻔한 얘기들… • 유니티를 통해 얻게 된 교훈 • 편의성/생산성의 중요성
  12. 12. 유니티가 제공하는 생산성과 편리함에 대해 생각해보는 기회가 되었으면 좋겠습니다 꼭 유니티를 안 쓰시더라도요
  13. 13. 준비물 • 유니티 3D • 훌륭한 아티스트 • 게으른 프로그래머
  14. 14. 만약 누군가가 프로그래머에게… “디버깅을 왜 하나요? 프로그램에 버그는 당연히 없어야 하는 것 아닌가요? 디버깅에 일정을 할애하지 말고 처음부터 버그 없게 만들어주세요.”
  15. 15. (게임 디자이너에게) “그렇게 만들면 재미있어요? 확실해요?” 가끔은 게임 디자이너와 아티스트에게 이런 것을 요구합니다
  16. 16. (아티스트에게) “게임에 올리면 바로 쓸 수 있도록 리소스를 만들어주세요.” 가끔은 게임 디자이너와 아티스트에게 이런 것을 요구합니다
  17. 17. 중요한 것은 반복(이터레이션)과 피드백 • 게임에 올려봐야 한다 • 프로그래머에게 디버깅이 중요한 스킬이듯이, 게임의 재미와 아트 또한 한번에 이루어지지 않는다
  18. 18. 물론 이 강연에서 게임 디자인 이터레이션에 대해서는 다루지 않습니다 게임 디자인에 대해서는 이러한 시도를 했습니다 • Web (HTML5) 게임 • 재미 검증을 위한 프로토타입
  19. 19. 요청과 피드백, 이터레이션은 자유롭고 빨라야한다 그렇다고 누구 한쪽이 ‘갑’이 되어서는 안됩니다
  20. 20. 어차피 좋은 게임을 만드는 것이 공통된 목표 • 하지만 프로그래머 입장에서 모든 요청을 다 처리해주기에는 사실 가끔은 좀 귀찮…
  21. 21. 사실 문제는 불확실성 • 구현을 했을 때 결과가 괜찮을지 사실 잘 모른다 • 결과가 괜찮을 것이라는 확신이 있는 경우는 많지 않다 • 현실적으로 모든 요청을 다 들어주고 일일이 검증하긴 좀...
  22. 22. 생산성, 편의성이 낮은 환경이라면 • “이걸 정말 구현 해봐야 하나?” • “구현을 하기로 했을 때 어느 정도의 완성도로 구현을 해야 하나?” • 때로는 좋은 방법도 부족한 완성도로 인해 폐기 되는 경우도 있다 • 좋은 툴을 제작하는 것은 정말 정말 큰 작업
  23. 23. 그러다보니까.. 프로그래머가 자주 하는 말.. “그거 안돼요”
  24. 24. “그거 안돼요” = 진짜 안돼요 = 성능 문제로 (모바일에서) 힘들어요 = 그거 오래 걸려서(작업 시간에 비해 결과가 미미해서) 힘들어요
  25. 25. 그래서 결국은 생산성에 관한 이야기 • 생산성이 좋을 때는 (비프로그래머가 보기에) 그 동안 안 됐던 것이 되는 경우가 있다
  26. 26. 탐험(Exploration)과 활용(Exploitation)
  27. 27. 활용(Exploitation) • 현재 방법 대로 최선을 찾아 밀고 나가는 것 • 예, PC 온라인 게임은 이미 많은 제작 사례가 있다
  28. 28. 탐험(Exploration) • 현재 방법이 좋지 않을 수 있다 • 다른 방법도 찾아보고 • 재빨리 검증하고 확인해보자
  29. 29. 탐험(Exploration)과 활용(Exploitation) 결국은 이곳을 찾고 싶어하는 것
  30. 30. 모바일 게임은 활용(exploitation) 보다는 더 많은 탐험(exploration)의 여지가 있는 분야
  31. 31. 탐험을 위해서는 • 다양한 시도를 해봐야 한다 • 그 시도의 진입 장벽이 최대한 낮을 수록 좋다 • 높은 생산성/편의성이 필요하다
  32. 32. 생산성 & 성능 • 다양한 시도를 위해서는 생산성, 접근성이 높아야 한다 • 생산성이 성능과 대비 되는 경우도 많고 • 유니티는 성능까지 최고로 내주는 엔진은 아니다
  33. 33. 결국은 좋은 퀄리티를 내려면… • 높은 생산성 (탐험) – 이것저것 시도해봐야죠 • 끈질긴 연구 및 최적화 (활용) – 주어진 상황에서 최선을... … 이렇게 개발 중에 있습니다 생산성 성능
  34. 34. • 높은 성능을 내는 것만이 좋은 퀄리티를 내주는 것이 아니다 • 높은 생산성 속에서 아티스트가 주어진 상황에서 최대한의 퀄리티를 뽑아내는 것도 똑같이 중요하다
  35. 35. 유니티
  36. 36. 유연한 구현 • 코드의 재사용성 • 하드코딩이 아닌 다양한 값에 대한 유동적인 처리 • 커스텀 GUI를 쉽게 만들 수 있는 환경을 제공 유니티의 컴포넌트 시스템이 이를 잘 뒷받침해준다
  37. 37. 유니티의 장점 • 유니티 자체가 통합 된 툴이며, 툴에 새 기능을 추가하기가 매우 쉽다 (= 새로운 툴을 만드는 것이 쉽다) • 에디트 모드에서 다양한 것을 해볼 수 있다
  38. 38. 에디트 모드란? • vs 플레이 모드 • 플레이 상태와 대비 되지만, 유니티에서는 많은 부분 플레이 상태와 비슷하게 구현/처리 가능
  39. 39. 애니메이션 활용 예 • 캐릭터 스폰 • 원하는 애니메이션 재생 • 런타임에서 자유롭게 수정
  40. 40. 1. 에디트 모드 제공 2. 아티스트 퀄리티 업 3. 상세 구현 및 최적화 기타. 성능 테스트
  41. 41. • 사실 베테랑 프로그래머들은 많은 구현에 대해 수정 가능성을 염두하고 구현한다 • 하지만 정작 수정은 힘들거나 프로그래머만 가능할 때가 많다 • 특히 아티스트 편의적인 ‘툴(컨트롤러)’를 제공하는 것은 굉장히 귀찮은 일
  42. 42. 유니티에서는 훨씬 쉽게 됩니다
  43. 43. 사례 1. 식생 분포
  44. 44. 목표: 식물들이 적절한 분포로 배치 되도록 하기 • 적절한 분포(예, 풍성한 분포)가 되는 비율을 만들자 • 식생 들이 적절하게 분포 되었을 때 잘 어울리도록 리소스 개선
  45. 45. 모든 지형은 자동 생성 되어야 한다 지형 생성은 “유저 수만큼 다양한 섬을 만들자! <야생의 땅: 듀랑고>의 절차적인 섬 생성 기법”, 진선웅 강연을 참고
  46. 46. 식생(나무, 관목, 돌)들 또한 적절한 분포로 자동 배치 되어야 한다 적절치 못한 분포의 예 각 군계(예, 설원, 사막, 숲)에 대해 어울리는 식생들이 적절한 조합 되어야 함
  47. 47. 서버에 접속하지 않은 로컬 모드 에디트 모드 플레이 상태 식생 생성 플레이 (식생 생성) 플레이 분포 조절 후 재생성
  48. 48. 피드백을 받고 & 개선 • 잔디를 넣고 분포를 개별적으로 조절할 수 있게 해주세요 • 물체들에 랜덤 변화(variation)를 넣게 해주세요 (크기, 색깔) • 위치 좀 섞어주세요 • 바닥 마스킹은 어떤 방법을 쓸까?
  49. 49. 오프라인 용 커스텀 지형도 제공 • 아티스트가 색깔로 군계(지질)를 결정 (PNG 파일) • 서로 다른 군계간의 이질감을 어떻게 풀지를 서로 고민 • 게임에서 전반적으로 보여질 모습을 계속 수정해가면서 살펴 볼 수 있음
  50. 50. • 전반적인 식생의 어울림 • 숲에 맞는 풍성한 분포
  51. 51. • 군계간 타일 블렌딩 • 잔디 표현 • 갈대의 군집 표현
  52. 52. 왜 이런 툴 들이 중요 할까요?
  53. 53. 아티스트가 생각하는 최상의 퀄리티 프로그래머의 초기 세팅 값 좋은 퀄리티를 원한다 변경 요청?
  54. 54. 자유롭게 조절하는 환경을 제공
  55. 55. 게임에서의 최상의 퀄리티 작업 환경과 게임에서의 결과물이 다르다면... 작업 환경에서의 최상의 퀄리티 Export? 변환 작업?
  56. 56. • 작업자(아티스트)에게 편의를 제공하는 것은 매우 중요하다 • 편의를 제공하는 것은 때로는 (특히 GUI) 작지 않은 작업 • 유니티는 그 편의를 기본 제공하는 것만으로도 정말 큰 장점을 지닌다
  57. 57. 이러면 끝?
  58. 58. 사례 1-2 스프라이트 최적화
  59. 59. • 스프라이트를 다루는 어셋(라이브러리) 들은 많이 있다 • 덕분에 높은 생산성으로 작업
  60. 60. • 하지만 필 레이트(fill rate)가 높아서 더 좋은 성능을 위해 고민 – 알파테스팅? 알파블렌딩? – 스프라이트를 직사각형이 아닌 커스텀 메쉬로 바꾸면?
  61. 61. 알파테스팅이 느리니 알파블렌딩을 쓰라고 하는데.. • 알파블렌딩을 그냥 쓸 초창기 드로우 콜이 200개가 넘음 • 알파블렌딩이 빠른 이유는 독특한 모바일 아키텍쳐(TBDR) 구조에서 기인 • 그럼 정말 알파테스팅을 쓰지 말고 알파블렌딩만을 써야할지?
  62. 62. 알파테스팅 vs 알파블렌딩 • 일반적인 알파블렌딩은 – 렌더링을 위해 물체를 정렬 하기 때문에 – 배칭이 안된다는 치명적인 단점이 있다 • 알파테스팅은 얼라이어싱의 문제가 있다
  63. 63. 그래서? • 잔디 등의 스프라이트는 여러 개를 하나로 합쳐 풍성한 룩을 연출 • 바닥의 일부 물체들에 대해서는 정렬을 하지 않고 배칭 되는 알파블렌딩 쉐이더를 제작 – Render Queue <= 2500: 불투명, 정렬 안됨 > 2500: 투명, 정렬 됨 (back to front)
  64. 64. 그래서? • 변경 된 쉐이더를 사용해서 드로우콜 몇 십 개 절약! • 현재는 대체적으로 드로우 콜 100개 한참 미만을 유지
  65. 65. 그래도 부족하다 • 사실 <야생의 땅: 듀랑고>는 드로우콜 보다는 필 레이트에 병목이 심한 게임 • 높은 필 레이트 = 픽셀 당 계산이 많다 (over draw)
  66. 66. 메쉬를 자르자 • 전반적인 식생 룩은 프로세스가 잡혔다 • 일반적인 사각형 스프라이트를 버리고 수동으로 자른 메쉬를 사용할 수도 있다
  67. 67. 성능 테스트만 먼저 해봤습니다 • 추가 작업량을 생각해서 현재는 고민 중... 직사각형 스프라이트 커스텀 메쉬 비교 갤3 FPS 41 58 41% Draw Calls 107 108 1% Triangles 314 1200 282% Vertices 572 1500 162%
  68. 68. 중간 결론 • 개발 중인 게임의 특성을 파악하자 – 남이 하는 말로 바로 결론을 내릴 것이 아니라 직접 테스트 해보고 원인을 파악한 후 게임의 특성이 맞게 개발하자
  69. 69. 중간 결론 • 병목이 어디인가를 파악하자 – 드로우 콜 개수가 병목인가? • 텍스쳐와 배칭을 최적화 – 필 레이트가 문제인가? • 메쉬를 자르거나 픽셀 쉐이더 최적화를 해보자 • 이 이외의 CPU 최적화는 항상 기본으로... (...) – CG, Object Pooling 등...
  70. 70. 사례 2 바다 렌더링
  71. 71. + ?
  72. 72. • 이미 기본적으로도 다양한 세팅을 조절해 볼 수 있다 • 이제 우리 게임에 맞게 개선!
  73. 73. 이터레이션.. 마스킹부터 시작합시다 물가 범위를 지정할 수 있으면 좋을 것 같은데... 커스틱(caustic)을 넣읍시다 젖은 물가도 넣어주세요
  74. 74. • 물 스샷으로 설명
  75. 75. 데모 프로토타입 시절 영상
  76. 76. 시작은 쉬웠으나 끝엔 고생하리라
  77. 77. 최적화 • 퀄리티 위주로 만들었으므로, 최적화는 필수 (게다가 기본 패키지에 여러 기능을 추가했다) • 최적화에 대한 테크빚이 잔뜩 남아 있는 상태 • 쉐이더 코드는 모두 일일이 체크하여 코드 정리
  78. 78. 최적화 • 로우 퀄리티 버전을 변경/제작 – VTF(Vertex Texture Fetch)를 쓰지 않는 버전 – Grab(Render Target Switching)이 없는 알파블렌딩 버전 • 초창기 커스틱 애니메이션을 단일 커스틱 텍스쳐로 변경 • 바다 메쉬를 잘게 나눠서 최대한 컬링이 되도록 작업 (Vertex Shader에 대한 부하를 줄임)
  79. 79. 최적화 • 아티스트 친화적인 파라미터들 중 대다수는 상수화 해도 된다. 정적인 파라미터(uniform variable)를 삭제 해주는 최적화 툴 간단 제작 • 정적 uniform 변수들을 상수화 했을 경우 • 바다 주변에서 전체 프레임 10% 향상 D3D 9 GLES 전 203 ALU 901-578 = 323 lines 후 174 ALU 739-481 = 258 lines
  80. 80. 마무리
  81. 81. 준비물 • 유니티 3D • 훌륭한 아티스트 – 아트 감각 & 적극적으로 요청하고 소통
  82. 82. 준비물 • 게으른 프로그래머 – 최대한 자동화, 간편한 환경을 만들고 파라미터 조절이나 배치는 아티스트에게 미루자 – 유니티의 편리함과 어셋스토어를 적극 활용하자 – 그래도 최적화는 열심히...
  83. 83. 마무리 • 아티스트에게 빠른 피드백을 제공해주면 좋은 퀄리티가 나온다 – 큰 이터레이션은 독립적으로 진행 될 수 있도록 – 작은 작업은 요청 없이 할 수 있도록 • 유니티의 편리함을 통해 프로그래머 또한 편리해진다
  84. 84. 마무리 • 협업이 긴밀하게 개선이 되는 동시에, 작업도 독립적으로 진행할 수 있다 (툴 제공 해드릴테니 이거 가지고 노세요…) • 편리함을 제공했으면 최적화로 마무리하자
  85. 85. 마무리 2 - 학생들에게 • 학생 참관 가능 발표였는데 발표 자료를 만들고 보니까 학생들에게는 그다지 도움이...
  86. 86. 마무리 2 - 학생들에게 • 유니티는 분명 편리한 툴입니다 – 컴퓨터(CPU, GPU, 알고리즘)를 깊게 알면 알 수록 많은 것들이 보이고 더 많은 것들을 할 수 있습니다 – 엔진과 툴은 도구일 뿐 끌려 다니지 마세요 – 끗

×