삼품 퍼포먼스 테스트 결과보고 3부

결론 Conclusion

권장사양으로 삼고있는 듀얼코어 , 1G, 6600 에서 보통 20프레임대 이상이 꾸준히 나와줘야 유저가 느리다는 느낌을 받지 않기 때문에, 이 사양에 맞춰 기본적인 맵을 테스트 해 봐서 옵션 내역을 정하고, 그 옵션에 맞춰 이번에는 각 맵을 세부테스트 하여 확실하게 기준을 수립하는 작업을 하였습니다.
카메라의 각도에 대한 확고한 기준을 아직 아무도 결정하지 못하여, 제가 임의대로 최대 줌아웃 상태가 가장 부하가 크다라는 전제로 작업하였습니다. (만약 백뷰까지 가능하게 된다면 얘기가 좀 많이 달라집니다. 그리고 변수도 크고요. 그래서 백뷰는 고려하지 않았습니다. 제작 단계시에도 백뷰나 숄더뷰는 고려하지 않고 배경이 제작되었기도 하고요. 일단 저는 백뷰까지 보이는 것은 안된다고 결정해 두었습니다. 이후에도 의견이 모아지지 않으면 진우씨에게 얘기해서 카메라를 고정해 버릴 생각입니다.)

이 테스트 결과에 따르면, 현재까지 알아내서 정할 수 있는 제작 기준안은 다음과 같다고 할 수 있겠습니다.

기준인 GOOD 옵션 (픽셀라이트 2개, 그림자 끔) 에서는 배경팀에 할당된 드로우콜이 약 300-400 정도라고 볼 수 있겠습니다. 물론 캐릭터가 별로 안나오는 맵이라던가 연출 맵 같은 경우는 그보다 더 쓰셔도 됩니다만, 일반적으로 캐릭터가 20-30 마리 정도 출몰할 곳이라면 배경팀에서 제작할때 최대 줌아웃시 드로우콜을 저 안쪽으로 맞춰주시도록 해주시면 감사하겠습니다. 지금 제작된 배경들의 대부분이 저 기준에 잘 맞아 있습니다 ) 배경 제작에서 퍼포먼스 테스트 할 때는 저 정도 기준을 체크하시면서 하시면 편하겠습니다.
캐릭터는 30-40 마리까지 출현이 한계 . 현재로써는 캐릭터가 30마리 정도가 권장사양에서 한계입니다. 한계를 넘어가는 캐릭터는 어떻게 처리할 것인지에 대한 구체적인 계획이 필요합니다. 제가 결정할까요?
물론 캐릭터는 추가적인 이슈가 있습니다만 그건 좀 아래에.
텍스쳐 사이즈는 좀 더 커도 됩니다. 다운로드 밴드위스에 문제만 없다면, 좀 더 큰 텍스쳐를 사용해도 됩니다. 자체적으로 텍스쳐 크기를 줄이는 기능이 있는데, 현재 최대 사이즈로 올린다 하더라도 그래픽 카드 메모리 사용량이 100메가를 넘어가지 않습니다.
모델링은 적합하지만, 드로우콜을 좀 더 줄이면 퍼포먼스에 유리할 수 있습니다. 텍스쳐를 좀 더 써도 되니, 지금보다는 좀 더 과감하게 한 장에 합쳐 버린다던가 하는 식으로 제작하게 되면 조금 더 유리할 수도 있습니다. (특히 모바일용으로는 추후 과감하게 합쳐야 할 것으로 예상됩니다 )
라이트 효과에 맞춰 면 분할 . 모두 하나의 오브젝트로 만들면 퍼포먼스에 이익이 되는 것과 반대로, 너무 크거나 길게 만들게 되면 컬링이 동작하지 않고 라이트도 섬세하게 적용되지 않는 문제가 있습니다.
크기로 굳이 따지면 한 화면에 온전히 보일만큼의 단위로 잘라주면 좋을 것으로 보이니다.
이펙트는 이번에도 경우에 따라 간혹 무거운 결과가 나올 수 있습니다. 이건 뭐 경우에 따라 다 달라서.. 이펙트 팀에는 퍼포먼스 체크 방법을 따로 알려 드리겠습니다.
고로 전체 퍼포먼스의 약 30~40% 정도를 배경에 배분한다고 쳤을 때,순수하게 배경에 허용될 것으로 예상되는 퍼포먼스는 약 10ms 정도입니다. (캐릭터에 10 ms, 인터페이스를 비롯한 기타에 13ms 배분…)

앞으로의 예상가능한 변수들

위 데이터는 지금까지 나온 결과만으로 만든 내용으로, 앞으로 더 프로젝트가 진행되면 좀 더 다른 결과가 추가될 가능성도 있습니다. 앞으로 변수가 될 내용은 아래와 같습니다.

긍정적인 변수

캐릭터 라이팅을 버텍스라이트로 고정하면 , 30마리일때 각각 10개씩, 즉 300 드로우콜을 절약할 수 있는 아이디어가 있습니다. 캐릭터에 한해 버텍스 라이트 쉐이더로 바꾼다면 속도가 향상될 가능성이 있습니다.
캐릭터 메쉬 LOD 를 적용하면 스키닝 부분의 퍼포먼스가 증가하면서 대폭 프레임이 증가한다는 보고가 올라와 있습니다. 본 LOD도 3ms 정도의 효과가 있습니다만, 이건 정말 한 프레임이라도 아까울때 하면 좋겠고, 일단 메쉬 LOD만 적용하면 성능향상이 있을 수 있습니다.
라이팅을 1개만 더 줄여도 1/3 의 드로우콜이 날라갑니다. 퍼포먼스가 안난다면 이 한방으로 올리는 법도 있습니다.

부정적인 변수

인터페이스의 퍼포먼스가 어떻게 될지 모릅니다. 지금 프로그램팀 모두가 이 문제를 해결하기 위해 집중하고 있습니다.
현재는 로직이 들어가 있지 않은 상태라, 나중에 AI등 여러 로직이 들어가게 되면 CPU의 부하가 좀 더 있게 될 예정입니다.
기타 알지 못하는 변수가 어디서 튀어나올지 알수 없습니다.