출처 : http://mentum.tistory.com/53
1. 드로우콜(Draw Call)
- CPU가 GPU에게 어떠한 물체를 그리라고 요청하는 것
- 그 값이 적을수록 가벼운 게임이라고 할 수 있으며, 기기의 성능에 따라서 특정 갯수를 넘어가면 프레임 저하가 나타남.
- 모바일의 경우 100개정도를 상한선으로 잡는다고 보면 된다.
- 일반적으로 오브젝트를 그릴 때, 오브젝트단위로 한 개씩 증가, 그 외에도 쉐이더에 따라서 추가로 증가할 수 있음.
2. 배치 (Batches)
- 많은 사람들이 Draw call과 많이 혼용해서 사용하지만 사실 드로우콜을 포함하는 상위 개념
- Draw Call + Set VB/IB + Set Transform + Set Pass Call (Set Shader + Set Texture 0~7 + Set Blending + Set Z enable..)
※ 배치 갯수는 어떻게 결정되는가 ? 직접 실험해봤다.
1. 메쉬의 갯수 x 라이트의 갯수 + 재질의 갯수 - 동적배칭으로 절약된 갯수
2. 파티클은 머테리얼이나 메쉬에 관계없이 개당 1개로 계산된다. (하위로 더 달려있으면 그것 하나당 1개씩)
3. Set Pass Call
- Material과 Shader와 관련된 것에 대한 Batch를 말함.
※ 배칭이 따로 일어나지 않을 때, Set Pass Call과 Material의 관계
예시1 : Material을 공유하는 오브젝트가 10개
- Batch는 10개, Set Pass Call을 1개로, 총 Batch는 11개다.
예시2 : Material이나 Shader가 다른 오브젝트가 10개
- Batch는 10개, Set Pass Call이 10개로, 총 Batch는 20개다.
- 때문에, 아틀라스를 활용하여 여러 오브젝트들을 한개의 Material로 묶어서 Set Pass Call을 줄이는 것이 중요하다.
4. 배칭(Batching)
- 복수의 드로우 콜을 하나의 드로우 콜로 묶어서 처리하는 작업
4-1) 다이나믹(동적) 배칭 (Dynamic Batching)
- 동일한 Material을 공유하고, 특정 조건들을 만족했을 때, 유니티에서 자동적으로 일어나는 배칭을 말한다.
- 정적 배칭에 비해서 조건도 까다롭고 눈에띄는 효율이 아니므로 사실 크게 신경쓰지 않아도 되는 부분이다.
- 동일한 모델의 모양일 필요가없다. 부스러기들을 한번에 모아서 렌더링한다고 생각하면 된다.
조건 1 : 버텍스 갯수가 총 900 이하의 메쉬만 적용가능하다.
하지만 쉐이더가 정점 위치와 법선이나 다른 UV 정보를 사용하면 300 이하.
정점위치, 법선, UV0, UV1, 탄젠트까지 사용한다면 180 이하.
(해당 제한값을 넘으면 정보가 너무 많아져서 오히려 배칭을 안하는 편이 더 이득이라고 한다.)
조건 2 : 오브젝트가 Mirror의 Transform 값을 가지고 있으면 함께 배칭 되지 않는다. 예를들어 +1 스케일과 -1 스케일.
조건 3 : Material의 인스턴스가 다를 경우(동일한 Material이더라도) 배칭이 이루어 지지 않는다.
조건 4 : 동적으로 라이트매핑된 오브젝트가 동일한 라이트 맵의 위치가 아닌 한 배칭이 이루어 지지 않는다.
조건 5 : 멀티 패스 쉐이더는 배칭이 이루어지지 않는다. ( 대표적으로 카툰 쉐이더의 아웃라인 )
조건 6 : Skinned Mesh 사용 불가
조건 7 : 리얼타임 쉐도우의 영향을 받는 오브젝트는 배칭이 이루어지지 않는다.
- 받아도 이루어지는 것으로 실험상 나타나서 사실 잘 모르겠음.
※ 동적 배치 갯수는 어떻게 결정되는가 ? 직접 실험해봤다.
- 메쉬의 정점은 98개로 동적배치가 일어날 수 있는 조건에 맞는다.
메쉬수 |
스케일 |
쉐이더 |
라이트 |
배칭수 |
해석 |
1 |
1 |
OutLine |
1 |
3 |
메쉬 1 x 라이트 1 x 멀티패스 2 + setPass 1 = 3 |
1 |
1 |
Standard |
1 |
2 |
메쉬 1 x 라이트 1 + setPass 1 = 2 |
2 |
1 |
OutLine |
1 |
5 |
메쉬 2 x 라이트 1 x 멀티패스 2 + setPass 1 = 5 |
2 |
1 |
Standard |
1 |
2 |
메쉬 2 x 라이트 1 + setPass 1 - 동적배칭 1 = 2 |
6 |
1 |
Standard |
1 |
2 |
메쉬 1 x 라이트 1 + setPass 1 - 동적배칭 5 = 2 |
6 |
1 |
Standard |
1 |
13 |
메쉬 6 x 라이트 1 x 멀티패스 2 + setPass 1 = 13 |
6 |
한개만 -1 |
Standard |
1 |
4 |
? 원래는 3이 될 것 같지만.. |
- 스케일의 경우 양의 값이기만 하면 각자 다른 스케일을 가지고 있어도 동적 배칭이 일어났다.
- 모델링 자체에 있는 Scale Factor는 영향을 주지 않는 듯 하다.
- 스케일이 한개만 -값이 될경우 Set Pass Call이 2개가 증가하면서 드로우콜이 2가 증가한다.
- 고찰
많은 메쉬를 가진 캐릭터가 복사 형태로 많이 존재한다고 할 때, 그 캐릭터에 본 스킨이 붙을 필요가 없는 오브젝트가 있다고 해서 그것을 분리할 필요는 없다.
배치는 '드로우콜'을 줄이기 위한 것이니까.
합쳐서 하든, 나눠서 배칭되서 1개가 되든 드로우콜이 한 개니까.
4-2) 스태틱(정적) 배칭 (Static Batching)
- 동일한 Material을 공유하고, 움직이지 않는 오브젝트가 Inspector에서 Static을 체크해줄 경우 일어나는 배칭을 말한다.
- 메쉬를 강제적으로 합쳐서 넘겨주는 식이라서 메모리에 부담을 준다. 때문에 너무 규모가 크다면 오히려 렌더링 쪽을 희생시키는게 나을지도.
- 눈에 띄는 효과가 나오기 때문에, CPU 파워를 줄일 필요가 있을 경우 꼭 정적 배칭을 사용해야한다.
'Unity' 카테고리의 다른 글
유니티랑 nodejs 간단 연동 테스트 해보기. (1) | 2016.10.31 |
---|---|
[펌] 유니티 리소스들 최적화 TIP (0) | 2016.08.04 |
[펌] 유니티 메쉬 정점 갯수 최적화 (0) | 2016.08.04 |
NGUI input 한글 입력이 재대로 안될경우. (0) | 2016.07.23 |
앱을 잠시 내렸을때, 종료할때 등등의 처리 함수.. (1) | 2016.07.23 |