Unity 최적화

 

드로우 콜

 

cpu에서 gpu로 그래픽 명령어를 전달할 때 발생하며, cpu의 overhead 상승과 함께 프레임에 나쁜 영향을 끼친다

프레임 영향은 드로우 콜 뿐 아니라 물리및 수치 연산, 스크립트, overdraw, fill late, 메모리, verts 등 종합적으로 검토해야 한다.

(verts 100k부터 프레임저하)

 

일단 드로우 콜은 메테리얼을 사용할때 마다 드로우콜이 1개씩 생성된다

 

1 material = 1 draw call

 

메테리얼 내부에 텍스쳐와 쉐이더 정보가 들어 있는데 간혹, 2pass 포함된 쉐이더는 draw call 1개가 아닌 2개까지 나오는 경우도 있음

( 스르륵 사라지게 할라고 렌더타입 opaque 몬스터한테 버텍스 알파 끼워넣으니 2 call ;;;)

 

 

 

 

위 그림을 보면 동일한 메테리얼을 사용하는데 왜 draw call 2 나오지? (실행 중임)

 

독립적인 Mesh Renderer 마다 개별적으로 계산되어 2 call 로 표시 되기 때문이다

떨어져 있는 개별적인 메쉬를 하나로 통합하려면 컴바인메쉬 상태가 되야하는데

맥스에서 보자면 attach 같은 기능이다.

 

구버전에서는 컴바인메쉬 스크립트로 수작업으로 적용 했지만, 지금은 스태틱 배칭을 통해 편하게 사용 할 수 있게 되었다.

(플레이 중  배칭 스태틱의 메쉬 렌더러를 살펴보면 컴바인메쉬라고 보임)

 

 

그림처럼 배칭 스태틱을 통해 떨어져 있는 메쉬를 하나로 통합하고 통합한 메쉬 들 중에 같은 메테리얼을 갖고 있는 녀석들을 자동으로 배칭하여

드로우콜을 절약하게 되는 것이다. ( pro 라이센스만 static batching 지원 -.,- )

 

 

 

컴바인 메쉬 상태가 중요한게 아니라 같은 메테리얼 갖은 개체를 얼마나 공유하는 가가 중요함

컴바인메쉬 상태는 배칭을 위한 조건일 뿐 직접적으로 드로우콜을 절약을 하는 것은 아님

 

열악한 모바일 개발 환경에서는 메테리얼 수량을 줄이기 위해 아틀라스 작업을 수행하고 있다

 

 

 

 

Culling

카메라 영역 밖에 있는 geometry 를 그리지 않음

 - 폴리곤 최적화의 절정

 

 

 

위 스피어의 메쉬의 차이는 개별mesh 인가, attach mesh 인가의 차이임

 

유니티로 넘어가기 전 attach 된 메쉬

 

attach 된 메쉬는 카메라 영역의 조금이라도 들어오면 가차없이 나머지 부분까지 그리기 때문에 culling (버프)효과를 못 받는다

다른경우는 맥스에서 디데치 된 메쉬들을 다중 선택하여 익스포트를 하면 culling 효과는 보지만, 관리와 활요성이 떨어지기 때문에 

개별적인 익스포트를 권장한다. (하이라키에서 하위 오브젝트를 편집할 수 있지만, 원본 fbx에 변화가 일어나면 지옥문이 열림)

 

배경에서는 프랍제작 후, 개별 익스포트 -> 유니티 fbx imporert에서 Generate Lightmap체크 -> 프리팹 생성 -> 씬배치 -> 라이트맵 -> 테스트

...이런 과정을 거치게 되면, 프랍 관리와 활용에 도움이 되고 지형이 바뀌어도 개별프랍으로 대응하기 용이하며 후반 아틀라스 작업도 수월하게 할 수 있다.

터레인이나, 타일링 텍스쳐를 사용하는 지형 등은 통으로 갖고와도 상관없으나 폴리곤 수가 많다면, 한 화면에 노출되는 공간을 염두하여 디테치하여 갖고오자

 

결과적으로 개별 메쉬 (하이라키에서 복사한 오브젝트 혹은 프리팹) 는 culling 효과를 받아 폴리곤 절약에 깨알 같은 도움을 준다