모바일 그래픽 리소스 제작 스펙이 나왔습니다.

길게 기다리셨습니다. 드디어 모바일 버전 제작을 위한 스펙이 많은 테스트 끝에 완성되었습니다.

그래픽 리소스 제작에서 고려할 부분은 당연하게도 한정되어 있는 '메모리' 와 '프레임' 이라고 할 수 있겠습니다.

그렇지만 애석하게도 프레임은 현재 게임이 제대로 돌아가고 있는 상태가 아니라서 체크하기가 매우 곤란하며, 또한 유동적이기 때문에 지금 테스트 자체가 큰 의미가 없습니다.

그렇기 때문에 현재로써 테스트 가능한 '메모리' 를 우선 기준으로 삼고, 프레임은 일단 감각적으로 예상만 하고 (-_-;) 나중에 실제 돌려보면서 세부조절을 해 보는 것으로 정하겠습니다.

우선 기초적으로 정해져 있는 제한사항을 알아보겠습니다.

그래픽에서 사용할 수 있는 메모리는 40메가다

이 의미는, 전체 게임 용량이 아니라, 실시간으로 메모리에 올려지는 용량의 한계입니다. 즉 한 번에 로딩되는 데이터의 양이지요. 프로그래밍에서도 사용해야 하고, 유니티도 좀 사용해야 하고 하다보니까, 그래픽에 할당된 안전메모리는 40메가입니다. 이 수치는 안드로이드에서는 조금 높다고 할 수도 있지만, 안드로이드에서도 결국 다른 어플들의 상관관계에 따라 왔다갔다 하는 데다가, 안드로이드보다 한계가 더 심한 IOS에 맞추는 것이 논리적일 것이기 때문에 40메가로 결정되었습니다.




즉 이 40메가에서 캐릭터 / 배경 / 인터페이스 / 이펙트를 사용해야 하는 것이지요.

대충 무식하게 따져보면 이 정도 느낌이 됩니다.

캐릭터 15메가
배경 15메가
인터페이스 / 이펙트 10메가

이 정도가 최대한의 예상 안전범위라고 할 수 있겠지요.





그래서 이 기준으로 어떻게든 맞춰 보려고 그래픽팀과 모바일팀을 많이많이많이 괴롭힌 끝에,
어느 정도 납득할만한 결론이 나왔습니다.
도와주신 두 팀 수고 많으셨습니다.


배경 테스트
http://intra.ndoors.com/center/board/view.asp?list_seq=284434&board_seq=329&page=3&search_option=&search_letter=


캐릭터 테스트
http://intra.ndoors.com/center/board/view.asp?list_seq=284994&board_seq=329&page=1&search_option=&search_letter=




그럼 이 결과를 바탕으로 최종 정리를 해 보겠습니다.





배경

배경은 한번에 버텍스를 많이 쓸 수 밖에 없는 부분입니다. 또한, 대부분 정적인 데이터로 이루어져 있는 배경의 데이터는 유동적인 요소가 매우 적기 때문에 최적화가 매우 유리하며, 때문에 배경에서 더 섬세한 최적화가 이루어지는 것이 효과가 보통 좋습니다.
 
그리고 연구결과, 텍스쳐보다 버텍스가 훨씬 더 메모리에 영향을 많이 끼치는 것으로 조사되었습니다. 
버텍스가 메모리에 영향을 많이 끼치는 이유는 2가지로 예상할 수 있습니다.

1. 버텍스가 기본적으로 2배 많이 차지한다 
   박부장님의 연구에 따르면, 버텍스는 'IOS에서 사용하는 버텍스 버퍼'와 '유니티 스크립트에서 사용하는 버텍스 버퍼' 가 2중으로 잡히는 관계로, 기본적으로 버텍스 버퍼가 2배로 잡힌다고 하십니다.

2. static 옵션
  static 옵션을 켜면, 오브젝트들의 빠른 렌더링 - 드로우콜을 줄이기 위해 - 을 위해서 같은 물체를 합쳐서 큰 하나의 물체로 만들어 버립니다. 이 작업은 버텍스의 버퍼 용량을 늘여 버리게 되어서, 역시 메모리의 기하급수적 증가를 유발시키는 문제를 발생시킨다고 합니다.

(이 부분은 http://intra.ndoors.com/center/board/view.asp?list_seq=282569&board_seq=329&page=1&search_option=user_id&search_letter=%BE%C8%C1%A4%B1%E6  연구와 대치되는 부분이 있지만, 어쨌건 폴리곤이 많아질 수록 기하급수적으로 증가한다는 증상은 맞기 때문에 더 조사하지는 않고 넘어가겠습니다. 또한 정말로 static 옵션을 끄면 메모리가 줄었습니다 )

그러므로 static 옵션을 끄면 동적 batch가 가동되면서 같은 모양/텍스쳐의 오브젝트를 인스턴트화 시켜 버림으로써 메모리를 매우 줄여버리는 특징을 가지고 있습니다. 단, 그에 비례해서 '동시에 출력했을 때' 드로우콜이 증가함으로써 프레임에는 불리한 특징을 가지고 있습니다.

그러므로 배경 작업에는 다음과 같은 기술 원칙을 지켜 주시면 좋습니다.  

- 폴리곤 기준 엄수
 현재 제작한 계성처럼, 대부분의 배경은 10,000 개 이하의 폴리곤 (버텍스 숫자가 중요하지만, 제작의 편의를 위해 폴리곤을 기준으로 합니다) 사용을 목표로 합니다. 물론, 적으면 적을 수록 좋으며, 낙양성 같이 큰 맵은 어쩔 수 없지만 가급적 폴리곤은 적을 수록 좋습니다.
 
- static을 끄고 같은 건물 / 오브젝트를 중복해서 사용하는 것을 추천합니다. 
static을 끈다는 얘기는 static batch(정적 배치) 를 끄고 , Dynamic batch(동적 배치) 를 가동시킨다는 말입니다.  동적배치 상태는 오브젝트가 많아도 메모리 증가가 매우 적은 대신, 한 화면에 같은 오브젝트가 많이 나와도 프레임 증가 효과가 전혀 없으므로. 같은 건물이라고 한 화면에 많이 보이게 찍는 것은 안됩니다.

즉, 같은 건물/ 오브젝트를 중복해서 가능한한 많이 쓰되, 한 화면에 많이 보이게 만들어서는 안됩니다.

- Vertex 용량을 줄이기 위한 팁
제작의 편의성을 위해 vertex 양이 아닌 폴리곤 양으로 제한했지만, 사실 vertex 양을 줄여주는 것이 원래의 목적이라고 할 수 있습니다. 그렇지만 버텍스 용량은 폴리곤과는 다르게, 여러 가지 요인으로 증가하곤 합니다. 기본적인 vertex 용량 증가 방지 팁을 지켜주시면 지켜주실수록 유리합니다.
 
        - 각진 면은 smooth로 없애 버리기! 
           면이 각졌다는 말은, 그 부분의 버텍스에 normal이 2개가 필요하게 되므로,
            vertex 용량이 증가하게 됩니다. 가급적 smooth처리로 vertex용량을 줄여주시기 바랍니다.
        - UV 복잡하게 펴지 않기!
            한 장의 텍스쳐라고 할지라도, 조각조각 내면서 복잡하게 UV를 배치하면 , 그 조각이 연결된 부분의
            vertex가 증가하게 됩니다. '가급적이면' 단순하게 UV를 펴는 것이 가장 좋습니다.
 

캐릭터

캐릭터는 현재 제작되어 있는 상태가 '사실 줄일 것이 거의 없습니다'
텍스쳐 사이즈만 빼놓고 말이지요. 일반적인 캐릭터가 300-400 개 폴리곤을 사용하며, 말이 포함된 군주는 약 700개 정도를 사용하고 있습니다.

단, 캐릭터는 위험한 것이 '움직인다' 라는 것입니다.
즉 가장 최악의 경우를 상정하고 디자인해야 하기 때문에 너무 많은 변수가 존재합니다.
그래서 배경과는 접근 방법이 다를 수 밖에 없고, 여유분도 좀 더 넉넉하게 준비해야만 합니다. (필요하면 이펙트나 UI를 머리위에 달고 다녀야 할지도 모르기 때문이지요!)

그래서 일반적으로 웹에서도 그렇게 했듯, "30마리의 아무 연관성 없는 캐릭터 데이터" 를 가지고 테스트한 결과를 가지고 최종 결과를 유추하는 식으로 접근하였습니다. 

같은 캐릭터로 보이지만, 사실은 기술적으로 전부 다른 메쉬와 전부 다른 텍스쳐를 가지고 있는 캐릭터입니다.

 
기본 정보는 , 캐릭터 1마리당 차지하는 메모리는 약 0.52 메가입니다. 이중에서 텍스쳐는 256*256 일때, PVRTC 4 bits 로 0.32 메가 정도입니다.

그리고 이런 데이터를 가지고 30마리의 '전혀 다른 캐릭터' 를 로드하였을 때에는 약 17.14 메가의 메모리를 차지한 것으로 보고되었습니다.
http://intra.ndoors.com/center/board/view.asp?list_seq=284994&board_seq=329&page=1&search_option=&search_letter=

그러므로, 만약 텍스쳐를 128*128로 줄인다면 절약할 수 있을 것으로 예상되는 메모리는 0.24*30 = 6.24 메가 이므로 , 이렇게 하고 나면 캐릭터 30마리가 차지하는 메모리는 약 11 메가 정도가 된다고 말할 수 있겠습니다.
그리고 또다시 여기에 텍스쳐 퀄리티를 PVRTC 2bit로 줄인다면 10메가 안쪽으로도 만들 수 있을 것으로 보입니다. 이것은 추후 결정해도 늦지 않으니 추후 상황을 봐서 진행하면 되겠지요 . 당장은 128로 줄이는 것만으로 오케이.

그리고 현재 동적 배치 (Dynamic batch) 상태이므로, 사실상 같은 캐릭터가 많이 나오면 나올수록 메모리는 훨씬 더 줄어들게 됩니다. (현재는 같은 캐릭터가 전혀 안나온다는 가정이므로)
동적 배치가 가동된 지금, 같은 캐릭터가 여러 마리 나오는 상황이라면
http://intra.ndoors.com/center/board/view.asp?list_seq=283520&board_seq=329&page=1&search_option=user_id&search_letter=%BE%C8%C1%A4%B1%E6

여기서와 같이 0.05 메가 정도의 메모리 추가로 한 마리의 캐릭터를 증가시킬 수 있다는 결론이 나옵니다.
즉 지금 상태에서 같은 캐릭터가 나온다면 화면 가득 캐릭터를 채워도 메모리 걱정은 전혀 안해도 될만큼이라는 뜻인데...

역시 여기에는 위에 배경에서 설명한 것과 같은 함정이 있습니다.
배경와 캐릭터는 마찬가지로 동적 배치 (Dynamic batch)  가 가동되면 메모리가 압도적으로 줄어드는데 비해, 초당 프레임 (FPS)가 떨어지는 단점도 동시에 가지고 있습니다.  

즉 메모리를 최대한 줄여버리는 지금 방식은, 결국 프레임 저하를 유발시킬 수도 있다는 말이 됩니다.

그러므로 지금 방식으로 일단 진행하되, 실제 머신에 올려봐서 프레임 테스트가 필수적으로 동반되어야 정확한 데이터를 알 수 있습니다. 이 테스트가 끝난 뒤 일부 정적 배치 (static batch)를 처리할 것인지, 추가적인 다른 기법을 동원할 것인지를 확실하게 결정할 수 있겠습니다. 어쨌건 지금 데이터는 최대한 절약된 상태이므로, 추가 최적화가 필요하지는 않을 것으로 보입니다.  


그러므로 현재까지의 제작원칙은 다음과 같겠습니다.

- 폴리곤은 지금처럼. 400개 이상 넘지 않도록 최대한 억제. 본수도 지금처럼 유지.
   발바닥이나 귀 뒷면 등, 더 줄일 수 있는 부분은 줄여주시면 땡큐입니다.

- 텍스쳐는 256으로 제작하되, 툴에서 최종적으로 128로 컨버팅
   추후 어떻게 변경되던지간에 대응할 수 있도록

- 에니메이션도 지금과 같이 유지
   더 줄일게 없군요 ...

- 말을 탄 군주는 일단 텍스쳐 2장으로 유지
   직사각형 텍스쳐가 GUI를 빼놓고 안되기 때문에, 다시 UV를 펴는 것보다 이쪽이 효율적입니다.
   이것 역시 추후 변화 대응 측면도 있습니다.

- 무기별 / 체형별 군주  따로 제작. 커스터마이징은 적용하지 않음 
   (말 탄 캐릭터 체형 4종 * 무기4종 ) + 말 안탄 캐릭터 체형 4종 = 20종의 군주를 제작합니다. 
 








인터페이스.

인터페이스는 현재 배정된 텍스쳐 사이즈를 최대한 지켜 주시는 것을 목표로 삼으면 되겠습니다.
현재 인터페이스는 2048*1024의 직사각형 텍스쳐 1장을 쓰고 있으며, 16비트 RGBA 를 사용하고 있습니다.
또한 1024*1024 월드맵을 사용하고 있으며, 월드맵은 PVRTC 4bit RGB 를 사용하고 있습니다.

- 인터페이스는 무조건 1장 . 16비트 RGBA
인터페이스의 모든 항목을 1장에 넣음으로써 드로우콜을 무조건 1로 만들 수 있는 장점을 가지고 있습니다.
이 1장을 넘지 않도록 모든 노력을 다 해 주시기 바랍니다. (현재 많이 남지요?)
또한 인터페이스는 넓은 면이 많이 보이는 관계로 압축을 했을때 생기는 아티펙트들의 문제 때문에 16비트까지로 타협하였습니다. 이렇게 해서 인터페이스에 4메가의 메모리를 사용하였습니다.

- 폰트
http://intra.ndoors.com/center/board/view.asp?list_seq=255968&board_seq=329&page=1&search_option=title&search_letter=font
에서 제작한 방식으로 사용하면 Alpha 8 1024*1024 를 사용하게 됩니다. 이게 지금도 가동되는지는 확인해보지 못했는데, 가동된다면 여기서 1메가 정도만 사용가능하게 됩니다. (만약 이게 사용불가능하다면 +3메가입니다)

- 월드맵
월드맵은 1024*1024로 PVRTC 4bit RGB 를 사용하고 있습니다. 예상은 0.5메가



이렇게 해서 현재 사용되리라고 예상되는 인터페이스 메모리는 약 6메가 정도입니다.








이펙트

이펙트는 현재 제작된 소스도 없고, 캐릭터 보다도 유동적인 관계로 예상이 불가능한 요소입니다.
할 수 없이 남은 용량 가지고 처리하는 수 밖에...

제가 기계에 넣을 수 있게 되고, 이펙트 데이터가 제작되어서 들어가게 되면 지속적으로 체크하겠습니다.
하여간 최대한 줄여주세요. 파티클 같은거 최대한 쓰시지 마시고... ㅎㅎ
지속적으로 지켜볼테니까...

지켜보고 있다

결론


그러므로,  현재 계성에서 30마리의 '다른' 캐릭터와 인터페이스가 전부 구현되었다고 예상해 본다면,
현재의 메모리 사용 구조는 다음과 같을 것입니다.

이펙트가 사용할 수 있는 여유 메모리가 17.22 메가씩이나 !!!!
이정도면 매우 좋은 결과입니다. 이펙트를 제외한 데이터가 절반 좀 더 썼을 뿐이라니...
이대로라면 오히려 텍스쳐 사이즈를 더 늘일까라는 욕심이 생길 정도로군요.

하지만 위에서 말씀드린대로, 아직 안심하기는 이릅니다.
지금 테스트는 프레임레이트를 희생하고 메모리 사용량을 최소화한 제작 방식이기 때문에,
나중에 제대로 테스트하면 프레임 레이트가 어떻게 나올지 알 수가 없기 때문이지요.
그리고 그 때에는 메모리를 희생하면서 프레임 레이트를 올리는 방식을 적용해야 할지도 모르기 때문에, 메모리의 여유분은 반드시 필요합니다.

어쨌건 지금의 제작 방식으로 계속 제작한다면, 퀄리티를 떨어뜨리지 않으면서 - 지스타 버전에서 퀄리티는 거의 떨어지지 않았지요 -  웬만한 변화에는 별로 문제 없이 저항 할 수 있는 데이터 용량이라고 할 수 있겠습니다.

저한테 마구 괴롭힘 당하면서 지원해주신 모바일팀과 TS팀께 감사드립니다.(그러니까 나한테 테스트 방법을 알려달란 ...)