[인벤게임컨퍼런스(IGC) 발표자 소개] 김영희 아티스트는 스튜디오 게일에서 각종 TV 시리즈의 애니메이션 Rig작업과 R&D 업무를 담당한 바 있다. 현재는 넷게임즈의 HIT에서 아트팀 TA로 근무 중이다.
김영희 TA는 8일 진행된 IGC 2016 셋째 날 행사에서 Unreal4 엔진을 사용하여 모바일 프로젝트를 제작하는 것에 대한 이야기를 나누기 위해 연단에 섰다. 먼저 그는 PC 프로젝트를 진행할 때와 달리 주의해야 하는 점들에 대해 소개하고, 몇 가지 팁들을 공유했다. 또한, 이를 HIT 프로젝트에는 어떻게 접목시켰는지에 대한 이야기를 이어갔다.
지난해 겨울 등장과 동시에 많은 게이머들에게 "모바일 게임에서도 이런 퀄리티의 그래픽을 구현하는 것이 가능하다"는 것을 알렸던 HIT, 과연 기존 모바일게임과 다르게 '쨍-한' 그래픽을 구현할 수 있었던 비결은 무엇이었을까? 이와 함께, 모바일 플랫폼에서 언리얼을 이용해 게임을 개발할 때 어떤 부분들을 중점적으로 고민해야 했는지 또한 들어볼 수 있었다.
■ 강연주제: Unreal4를 사용해 모바일 프로젝트 제작하기
⊙ PC와 모바일 플랫폼에서의 차이 이해하기
먼저, 모바일 플랫폼에서 언리얼4를 사용한 프로젝트를 제작하기 위해선 PC 플랫폼과 어떤 부분에서 차이가 나는지 살펴볼 필요가 있다. PC 플랫폼의 특징을 간단히 정리하면, 화려한 포스트 프로세싱이 가능해 그래픽이 더 풍부해 보이게끔 할 수 있고, DXT1/DXT5와 같은 품질 좋은 텍스처 압축방식을 사용한다. 또한, GPU에 있어 제조사 별 제약이 없는 편이며, 다이렉트X11 이후부터는 파이프라인 구조가 변하면서 테셀레이션 등도 쉽게 구현이 가능해졌다는 특징이 있다. 뿐만 아니라, PC 플랫폼은 스로틀링이나, 배터리 문제에 대해서도 크게 신경을 쓰지 않아도 된다.
반면, 모바일 플랫폼의 경우는 대부분 PC에서 가능했던 것들에 제약이 생기게 되는데, 우선 텍스처 압축 형식이 여러가지이기 때문에 모바일 플랫폼이라도 안드로이드, iOS 등에 따라서 다른 압축 형식을 사용하게 된다. 또한, 포스트 프로세싱 기능에도 제약이 생기게 되며, GPU에 따라 제조사 별 그래픽 제약 또한 존재한다. 가령, 말리 계열에서는 정상적으로 보이다가도 테그라 계열에서는 정상적으로 보이지 않는 등의 현상이 생기는 경우가 있다.
스로틀링과 배터리 등의 제약 또한 모바일 플랫폼에서 중요하게 생각해야 할 요소로, 발열이나 배터리 잔량에 따른 퍼포먼스 저하가 있을 수 있기 때문이다. 물론, PC 플랫폼에 비해 상대적으로 하드웨어 능력이 떨어지기 때문에 이 부분 또한 고려해야 한다.
여기까지만 이야기하고 보면 모바일 플랫폼의 개발 환경이 아주 열악해 보이지만, 언리얼을 접하게 되면 생각을 조금 바뀔 수도 있는데, 언리얼4는 버전업이 지속적으로 이뤄지면서 렌더링 관련 기능들이 많이 향상되는 중이다. 예를 들어 HIT(히트)를 개발할 당시에는 4.83 버전을 사용했는데, 이후 버전들을 살펴보면 여러 가지 렌더링 관련 기능들이 추가된 것을 확인할 수 있다.
⊙ 언리얼4로 모바일 프로젝트 제작하기
지원되는 기능을 미리 알아보자
우선, 언리얼4로 모바일 프로젝트를 제작할 때 유의해야 할 점을 살펴보면, 유니티와 언리얼 같은 차세대 게임엔진은 모두 PC 플랫폼의 기능 중 일부를 사용하는 식으로 모바일 플랫폼이 적용되어있고, 버전업에 따라서 몇 가지 기능들이 계속 추가되고 있다.
예를 들면, 4.8.3버전을 사용했던 히트 개발 당시에는 Movable Light, Dynamic Shadow 등과 같은 기능들을 지원하지 않았다면, 보다 최신 버전인 4.1.3에서는 지원이 되고 있다. 또한, 여러 포스트 프로세싱 관련 기능도 많이 지원하고 있다. 따라서, 모바일 프로젝트를 제작하기 전에 미리 지원되는 기능과 그렇지 않은 기능을 명확히 구별하는 것이 좋다.
쉐이딩 모델은 어떤 것을 쓰는게 좋을까?
모바일 프로젝트를 개발할 때 고민했던 것 중 하나는 쉐이딩 모델과 관련된 것이었다. 새롭게 쉐이딩 모델을 개발할지, 아니면 언리얼에서 제공하는 PBR(물리기반렌더링)을 사용하느냐 사이의 고민이었는데, 당시 고민을 네 가지로 정리해 보면 이렇다. 첫 번째는 'PBR은 비싸지 않을까?' 하는 생각이었고, 다음은 PBR을 아티스트가 다루기에 직관적일까? 하는 부분, 그리고 '우리 게임에 PBR까지 필요할까?'하는 의문과 마지막으로 자체적으로 무겁지 않고 직관적인 쉐이딩 모델을 만드는 것이 더 낫지 않을까 하는 생각이었다. 김영희 TA에 의하면 이 네 가지 생각들은 결국 의미가 없던 고민이 되었다고 한다.
이런 고민들을 해결하기 위해 PBR을 살펴봤더니, 이미 여러 가지 기본적인 코드가 준비되어 있었다. 모바일용 Environment BRDF Model은 근사 코드로 준비되어 있고, Directional Light 연산도 따로 준비되어 있다. 마찬가지로 Roughness 결과값을 미리 상수화 시켜놓은 코드 등, 모바일 플랫폼에서 PBR을 동작시킬 수 있도록 준비되어 있는 모습을 확인할 수 있었다.
이렇게 기본적으로 준비되어있는 코드들은 피씨 플랫폼에서 사용하는 것들 보다 인스트럭션도 적었고, 막연히 비싸다고만 생각했었지만 모바일용 PBR은 전혀 다른 코드들을 사용하고 있는 것을 보고 사용해도 괜찮을 것 같다고 판단할 수 있었다.
직관적일까? 하고 고민했던 의문에 대해서도 자연스럽게 해결이 됐는데, 언리얼에서 다루는 것은 베이크 컬러와 메탈릭, 러프니스 정도만 다루면 됐기 때문에 다루기가 비교적 직관적이었다. 또한, 게임에 PBR까지 필요가 없을지라도 상황에 따라 Fully Rough나 Unlit 메테리얼 등을 사용 가능했기 때문에 이런 고민도 금방 해결하게 됐다.
최적화는 퍼포먼스 측정에서부터
HIT의 프리뷰 단계에서는 탑다운 뷰 방식으로 제작하기로 했기 때문에, 상대적으로 Overdraw가 적게 발생한다고 판단했다. 또한, 고정된 뷰로 메쉬를 아낄 수 있었고 이펙트에는 많이 사용됐지만 배경과 캐릭터에는 Opacity 매테리얼을 사용할 필요가 없었다. 그렇게 놓고 보니 GPU자원보다 CPU자원을 더 사용하는 보틀넥 현상이 일어나는 걸 확인할 수 있었고, 일단 최적의 Draw Call을 찾는 것에 중점을 두기 시작했다.
모바일에서 퍼포먼스를 체크할 때 염두에 두어야 할 점은 실제 디바이스에서 퍼포먼스를 측정하는 것이 가장 정확하다는 것이다. 용량 측정 또한 PC플랫폼에서 해오던 방식이 아니라, 이미 쿠킹이 완료된 pak 파일의 크기나 자료를 분석해야 한다. 이유는 PC플랫폼에서 용량을 체크하게 되면 텍스쳐 등의 애셋들이 실제 모바일 디바이스에 들어갈 때의 용량과 차이가 생기기 때문이다.
그렇기 때문에 퍼포먼스를 측정하기 위해서는 타겟이 될 만한 레퍼런스 디바이스를 지정하는 것이 중요했다. HIT를 개발할 당시에는 많은 유저들이 보편적으로 사용한다고 생각되는 '갤럭시 S4'를 선택해 퍼포먼스를 측정하곤 했다.
퍼포먼스 측정에도 여러 가지 방법이 있는다. 그 중 한가지 추천하고 싶은 것은 GPU 프로파일러를 사용하는 방법이다. 제조사 별로 여러 퍼포먼스 프로파일러가 존재하는데, 개인적으로는 인텔에서 제작한 프로파일러를 가장 많이 사용했다.
퍼포먼스 측정을 통해 얻은 적정 Draw Call은 몬스터가 스폰되지 않은 상태에서 120±10, 몬스터가 스폰된 후 전투에 돌입했을 때 180±20, 그리고 로비 화면에서는 200±20정도가 적당하다고 판단했다. 로비 화면이 가장 Draw Call이 높은 이유는 슬레이트 UI가 상당히 많은 부분을 차지하고 있기 때문이다. 한가지 더, Draw Call을 낮추기 위한 방법으로는 Merge Actor 기능을 잘 활용하는 것이 중요하다.
패키지 용량 이슈
HIT는 상대적으로 작은 용량(출시 당시 750Mb)으로 시작했지만, 업데이트 규모가 커지면서 추후 데이터 크기가 상당히 커질 것으로 초기부터 예상하고 있었다. 그때부터 리소스 변화 추이를 계속 살펴봤더니, 배경과 관련된 리소스가 가장 많이 늘어나고 있는 것을 확인할 수 있었다. 액션 RPG이다 보니 스테이지가 늘어나는 점 때문에 그렇기도 했지만, 꼭 그렇지 않더라도 기본적으로 제작된 배경 관련 리소스가 가장 컸다.
배경 리소스는 크게 Static Mesh, Material Instance, Texture, Level 로 구성된다. Level을 제외한 부분은 아티스트들이 최적화해야 하는 부분이라고 한다면, Level의 리소스 크기는 어떻게 줄일 수 있을까? 먼저 레벨의 경우는 라이트 맵/섀도우 맵과 버텍스 컬러 등등으로 이뤄져 있는데, 이 중 라이트 맵/섀도우 맵이 레벨 용량에서 차지하는 비율이 가장 높다. HIT를 예로 들면 레벨 하나의 용량을 13Mb라고 한다면 라이트 맵/섀도우 맵이 11Mb를 차지하는 정도. 때문에 배경 리소스 제작 시 Light UV를 효율적으로 할당하는 것이 용량 절감에 도움이 될 수 있다. 또, 안드로이드 OS에 한정해서 섀도우맵이 ETC1 형식으로 압축이 안되는 것을 확인할 수 있었는데, 이 부분을 경로에 따라 직접 압축할 경우 상당히 용량을 줄일 수 있었다.
불필요한 리소스가 생겼을 때에는 어떻게 할까? 이 부분은 언리얼에서 쿠킹이 안되게끔 설정해 줄 수 있다. 이를 통해 제작 도중에 있는 에셋들을 쿠킹이 되지 않도록 설정하면 상당 부분 용량을 줄이는 데 도움이 된다.
다시 정리하면, 용량을 효율적으로 관리하기 위해 ETC1에서 되도록 Alpha Channel이 있는 텍스쳐 사용을 자제하고, 섀도우 맵이 압축이 안되는 현상을 수정하고, 텍스쳐 사이즈는 되도록 512 이하로 제한하는 등의 방법을 사용했다. 라이브 서비스가 계속되면서 레벨이 늘어나는 것은 어쩔 수 없는데, 결국 용량과 관련된 이슈는 잘못된 데이터가 들어가지 않게끔 하는 것이 관건이다.
⊙ HIT에서는 어떻게?
HIT를 개발할 당시 라이팅과 섀도우 환경은 스테이셔너리 라이트 한 개, 다수의 스태틱 라이트, 리플렉션 캡쳐 한 개였다. 4.8.3버전에서 지원하지 않던 Dynamic shadow같은 경우는 모듈레이트를 통해 자체 구현할 수 있었다.
하지만, 하나의 스테이셔너리 라이트로는 캐릭터와 배경을 동시에 풍부하게 표현하는 것이 힘들었고, 리플렉션 캡쳐 또한 환경이 좋지 않아서 PBR 쉐이더의 풍부한 표현을 구현하기에 좋지 않았다.
이를 해결하기 위해서, 엔진팀의 힘을 빌려(?) 2개의 기능을 하는 하나의 Directional Light를 사용할 수 있었는데, 하나의 라이트가 스태틱 메쉬를 비추는 기능과 무버블 메쉬를 비추는 기능을 모두 할 수 있도록 해 퍼포먼스가 소모되는 부분 없이 캐릭터와 배경을 동시에 표현하는 것을 만족시킬 수 있었다.
캐릭터 매테리얼 같은 경우 림 라이트, 앰비언트 베이스 컬러, 엠비언트 오클루전과 Fog 등의 기능을 사용했는데, 앰비언트 베이스 컬러는 메탈릭을 제외하고 다른 컬러을 넣어 라이팅 영역이 안보이게끔 하는 기능을 하는 데 사용했고, 앰비언트 오클루젼 같은 경우는 언리얼이 모바일에서 지원하지 않기 때문에 노멀맵을 사용해 약간 눈속임(?) 같은 형태로 만들었다. Fog는 언리얼에서 제공되는 것 이외에 메테리얼에서 자체적으로 구현, 저렴한 비용으로 작업하는 것을 목표로 했다.
러프니스를 낮게 했을 때 캐릭터의 메탈릭 부분에서 부분적으로 밝게 빛나는 현상이 목격됐는데, 이 부분은 블룸같이 높았기 때문에 일어난 문제로 이를 해결하기 위해서는 러프니스가 높아짐에 따라 함께 들어가는 퐁 쉐이딩 값을 클램프하는 작업이 필요했다.
인다이렉트 라이트 캐시와 관련된 이슈도 있었다. 인다이렉트 라이트 캐시는 곧 미리 연산해둔 캐시들로, 밝은 영역에서는 밝게, 어두운 영역에서는 어둡게 들어가는 캐시다. 무버블 오브젝트들이 움직일 때 밝기에 따라 밝아지고, 어두워지는 것이 당연한 결과지만, 어두운 영역에서 라이트 캐시가 다소 어둡게 구워지는 것을 막고 싶었다.
이를 해결할 방법으로는 오히려 인다이렉팅 라이트 캐시의 샘플링 수를 낮췄더니 일률적인 라이팅을 구현하는 것이 가능했다. 물론 이는 국소적인 레벨에서만 사용이 가능했는데, 큰 레벨의 샘플링을 낮출 경우는 결과가 별로 좋지 않았기 때문이다. 김영희 TA는 이후 언리얼 프로젝트와 관련한 기타 팁들을 소개한 후 강연을 마무리했다.
※ 강연의 전체 내용은 추후 강연 영상을 통해 공개할 예정입니다.
Frann@inven.co.kr
페이지 구독하기
다른 기사 보기
기사 제보하기
