IPAD 용 데이터 제작을 위해 연구한 내용입니다. 일단 이것으로 종료 (프로그램팀이 삼품쪽으로 지원나가서) 하고 추후 다시 진행합니다.
IPAD(iphone)용 게임을 유니티에서 만드실 때에는 다음 내용을 숙지하심이 좋을 것 같습니다.
IOS용 데이터는 라이트 연산을 하기 어렵습니다. (거의 불가능합니다)
: IOS는 타일 기반 디퍼드 렌더러 (Tile-Based Deferred Renderer) 를 사용합니다.
: 라이트의 실시간 연산에 대한 부담이 매우 큰 편이며, 때문에 캐릭터 외엔 라이트 연산을 하지 않는 것이 좋습니다.
배경은 모두 라이트맵을 굽거나, Texture only로 작업해야 합니다.캐릭터에 사용될만한 쉐이더는 Diffuse fast 입니다.
: 일반 라이트 연산보다도 훨씬 가벼운 Diffuse fast 쉐이더가 캐릭터용으로 권장됩니다.배경에 사용되는 쉐이더 기능은 텍스쳐 , 라이트맵 , 리플렉션 , 알파 , 버텍스 칼라 입니다.
: 보통 위의 기능들을 조합한 쉐이더들이 있습니다. 자세한건 쉐이더 기능문서가 올라와 있습니다.
Opengl 기반의 기기이기 때문에 일반적으로 사용되는 쉐이더를 사용할 수 없습니다. 또한 조명 연산이 힘들기 때문에
실시간 조명 연산 쉐이더는 가급적 사용하지 말아야 합니다.
: Vertex shader까지 지원되므로 사실 스페큘러나 저수준의 노말맵도 사용할 수 있습니다. 하지만 효과에 비해 자원소모가
크기 때문에 그다지 추천하지는 않습니다.
- IOS 용 데이터는 엔진에서 내장된 라이트맵 기능을 이용할 수 없습니다.
: 사실은 구동이 가능하긴 합니다만, 엔진에서 자동으로 지원하는 라이트맵 텍스쳐 자동 적용 기능들이 사용불가능해집니다.
복사한 건물 같은 경우 엔진 자체내에서 건물의 라이트맵만 다르게 구워서 입혀주지만, IOS 용 쉐이더로 바꾸면 깨집니다.
맥스의 RTT (렌더투 텍스쳐) 기능을 이용하면 간편하고 최적화된 라이트맵을 생성할 수 있습니다.
: RTT 기능을 이용하는 것이 유지보수에도 훨씬 유리하며, 후처리도 용이합니다.
게다가 엔진에서는 사용 불가능한 point light 를 이용한 그림자도 사용할 수 있습니다.
: 또한 엔진에 내장된 비스트 기능으로 만들어진 라이트맵은 일반적 텍스쳐가 아니라 채널당 32비트의 HDR 파일인
exr 파일입니다. 아이폰 쉐이더에서는 이 이미지를 그대로 쓰기 어렵습니다.
- 텍스쳐는 무조건 한 장
: 텍스쳐를 여러 장으로 그리면 드로우콜이 대폭 증가하게 됩니다. 가능한한 DPcall을 줄여주도록 계획되어야 하며,
그룹지어져야 합니다. 캐릭터 커스터마이징은 상당한 부하를 유발합니다.
: 사실은 총 8장의 텍스쳐를 블렌딩 할 수 있습니다… 하지만 할 수 있다는 것이고, 멀티 패스로 그려야 하므로
시스템 부하를 각오해야만 합니다.
화면에 보이는 폴리곤은 10000 개 내외. 드로우콜은 10-30개 정도
: 관련자료를 못찾겠네요. 대략 저 정도의 데이터가 사용되어야 속도를 보장할 수 있습니다.FOG는 사용금지.
: 느리답니다.알파 블렌딩이 테스팅보다 빠르다
: 신기하게도 PC와는 반대로 알파 블렌딩이 테스팅보다 빠르다고 합니다. 아직 테스트는 안해봤지만…
테스팅을 위한 옵티마이즈 과정이 더 느리다던가… IOS 렌더러에서 알파 테스팅은 ‘대단히’ 비싸고 느리다고 합니다.텍스쳐는 PVRTC 포맷을 사용합니다.
: 애석하게도 IOS 라이센스를 가지고 있는 머신에서밖에 이 옵션을 볼 수 없습니다. 일반적으로는 그냥 신경쓰지 않고 작업하는
수 밖에 없겠습니다.
====================================================================
그리고 위 내용을 근거로 만들어진 예제입니다.
RTT 라이트맵을 사용했고, 배경은 큐브맵을 이용한 스카이박스입니다.
나무는 뒷면 때문에 저런 모양으로 만들지 않는 것이 좋을 것 같습니다.
위에서 얘기한대로, 배경은 라이팅 계산을 ‘전혀’ 하지 않습니다. 오직 텍스쳐와 라이트맵만 사용합니다.
각종 Asset들은 황재철군이 만들었고, 라이트와 각종 베이킹들은 제가 제작했습니다.
본격적으로 그래픽 팀이 붙어 제작한다면 최소 이 정도 퀄리티 이상이 나올 것입니다.
이 정도가 약 13000 개 정도의 폴리곤입니다. 즉 한 번에 보일 수 있는 한계치라고 보시면 됩니다.
거리는 약 가로 세로 100미터로, 실제로는 이것을 1/4 로 나누어 50미터 단위로 끊어서 만들어 주면 안보이는 블럭을 컬링해
가면서 속도를 보장할 수 있을 것입니다. 블럭 사이즈 등에 의해서도 이 기준은 달라질 것입니다.(현재 한 블럭 사이즈는 1.7미터입니다) 또한 지형은 터레인을 사용못하고 매쉬만 사용가능하므로, 이동하지 못하는 지역의 폴리곤등은 최적화를 시켜줄 수 있습니다.
현재 캐릭터를 제외하면 1만개 정도이므로, 약 이정도 폴리곤이 ‘한 번에’ 그려질 수 있도록만 신경써 주면 됩니다.
즉 카메라 각도만 잘 조정하고 컬링만 신경쓰면 512 미터의 넓은 지형도 표현가능하다는 말씀입니다.
배경에서 사용된 드로우콜은 단 3개.
지형. 건물(들), 나무(들)
현재 저 화면에서는 캐릭터 3마리 덕분에 드로우콜이 30이 넘어 버렸습니다. 캐릭터 커스터마이징은 막아야 할 듯.건물들과 나무들은 한 번에 로딩되는 녀석들끼리 Attach를 시켜놓는 것이 좋습니다.
PC 버전처럼 프리팹으로 복사되는 것을 기대할 수 없습니다. 그렇게 되면 라이트맵이 제대로 먹지 않습니다.라이트맵도 3장이며, 각각 128*128로 만들어졌지만 효과는 그럴 듯 합니다.
일반 텍스쳐도 3장이며, 지형만 1024*1024 이고 건물과 나무는 256*256 으로 되어 있습니다.아이폰에서 돌려서 테스트 해 보고 싶었지만, 현재 아이폰 팀이 삼품 작업에 올인하고 있는 관계로 수치상으로만 확인한 결과입니다. 추후 실제로 돌려서 테스트 해 보겠습니다.
최적화 링크 페이지
텍스쳐 데이터 일람.
* 지형 텍스쳐를 타일링 식으로 하면 이쁘지는 않아도 용량은 더 줄일 수 있습니다.