본문 바로가기

Unity/Optimization

물리엔진 최적화 물리엔진 최적화 · Fixed Update 주기 조절(Update와 별도로 주기적으로 불리며 주로 물리 엔진 처리) - 디폴트는 0.02초, 즉 1초에 50번 호출 - TimeManager에서 수정 가능 - 게임에 따라 0.2초 정도(혹은 이상)로 수정해도 문제 없음 · 움직이지 않는 배경 물체는 static으로 설정 · 리지드 바디가 없는 고정 충돌체를 움직이면 CPU 부하 발생 - 리지드 바디를 추가하고, IsKinematic 옵션 사용 · Maximum Allowed timestep 조정 - 시스템에 부하가 걸려 지정된 시간보다 오래 걸릴 경우, 물리 계산을 건너 뛰는 설정· Solver Iteration Count 조정 - 물리 관련 계산을 얼마나 정교하게 할지 지정 (높을수록 정교) - Edit.. 더보기
셰이더 유니티 셰이더 · 기본 셰이더는 모바일용 셰이더 사용(Mobile > VertexLit은 가장 빠른 셰이더) · 라이트 맵 사용 복잡한 수학 연산 · pow, exp, log 같은 수학 함수들은 고비용 · 픽셀별 그런 연산을 하나 이상 사용하지 않는 것이 좋다 · 텍스쳐 룩업테이블을 만들어 사용하는 방법도 좋다 · 알파 테스트 연산(discard)는 느리다. · 기본적인 연산보다는 최적화 시키고 간략화시킨 공식들을 찾아서 사용할 수 있다. 실수 연산 · float : 32bit - 버텍스 변환에 사용. 아주 느린 성능(픽셀 셰이더에서 사용은 피함) · Half : 16bit - 텍스쳐 uv에 적합. 대략 2배 빠름 · fixed : 10bit - 컬러, 라이트 계산과 같은 고성능 연산에 적합. 대략 4배.. 더보기
Lighting and Overdraw Lighting · 고정된 라이트와 오브젝트의 경우 라이트 맵을 최대한 활용 - 아주 빠르게 실행 (Per Pixl Light보다 2~3배, GI와 Light Mapper를 사용할 수 있음) · 라이팅 별로 Render Mode : Important / Not Important 설정 가능 - 게임에서 중요한 동적 라이팅만 Important 설정 (Per-Pixel Light), 그렇지 않은 라이트들은 Not Important로 설정 Overdraw · 화면의 한 픽셀에 두번 이상 그리게 되는 경우 (Fill rate) - DP Call의 문제 만큼이나 프레임 저하의 중요한 문제 - 특히 2D 게임에서 DP Call보다 더욱 큰 문제 · 기본적으로 앞에서 뒤로 그린다 - Depth testing으로 인해서.. 더보기
Batch Batch Static Batch · Edit>Project Setting>Player 에서 설정 · 움직이진 않는 오브젝트들은 static으로 설정해서, 배칭이 되게 함 · Static으로 설정된 게임 오브젝트에서 동일한 재질을 사용할 경우, 자동으로 통합 · 통합되는 오브젝트를 모두 하나의 커다란 메쉬로 만들어 따로 저장(메모리 사용량 증가) Dynamic Batch · 움직이는 물체를 대상으로 동일한 재질을 사용하는 경우, 자동으로 통합 · 동적 배칭은 계산량이 많으므로, 정점이 900개 미만인 오브젝트만 대상이 됨 더보기
그래픽스 최적화 그래픽스 최적화 Culling · 프러스텀(Frustum) 컬링 - 각 Layer 별로 컬링 거리를 설정하는 것이 가능 - 멀리 보이는 중요한 오브젝트는 거리를 멀게 설정, 중요도 낮은 풀이나 나무 등은 컬링 거리를 짧게 설정 · 오클루젼(Occlusion) 컬링 - Window->Occlusion Culling 메뉴에서 설정 가능 오브젝트 통합(Combine) · 드로우콜은 오브젝트에 설정된 재질의 셰이더 패스당 하나씩 일어남 · 렌더러에 사용된 재질의 수만큼 드로우 콜이 발생 · 성질이 동일한 오브젝트들은 하나의 메쉬와 재질을 사용하도록 통합 · Script 패키지 - CombineChildren 컴포넌트 제공 - 하위 오브젝트를 모두 하나로 통합 · 통합하는 경우 텍스쳐는 하나로 합쳐서, Textu.. 더보기
리소스 최적화 리소스 최적화 · 권장 압축 텍스쳐 사용 - 아이폰(PowerVR) : PVRCT - 안드로이드(Tegra) : DXT - 안드로이드(Adreno) : ATC - 안드로이드(공통) : ETC1 · 텍스쳐 사이즈는 무조건 2의 제곱 (POT - Power of Two) - POT가 아닌 경우 POT 텍스쳐로 변환되어 로딩 · 텍스쳐 아틀라스 활용 (UI만 아니라, 같은 재질의 오브젝트들을 묶음) · 압축된 텍스쳐와 밉맵 사용 (대역폭 최적화) · 32bit가 아닌 16bit 텍스쳐 사용도 고려 · 텍스쳐 메모리 사용량 프로파일링 Mesh · Import시에 언제나 Optimize Mesh 옵션 사용 -변환 전/변환 후 버텍스 캐쉬를 최적화 해준다 · 언제나 Optimize Mesh Data 옵션을 사용한다.. 더보기
가비지 컬렉터(Garbage Collector) 가비지 컬렉터(GC) · Mono의 동적 메모리 관리 때문에, 메모리 해제를 위해 GC가 자동 호출 · GC는 언제 일어날지 모른다 · GC가 일어나면 렉이 발생함 · 동적 메모리 해제가 가능한 일어나지 않게 해야 하는게 GC 관리의 핵심 · 문자열 병합은 String + String(임시 문자열 생성) 대신 StringBuilder.Append() 함수 사용 · 문자열 비교할 때 bool string.Equals(string a, string b) 함수를 사용한다. · 일반 array에 한해서 foreach 대신에 for문 사용 - forach 한번 돌 때마다 24byte의 쓰레기 메모리 생성, 속도도 for문보다 느림 · for문으로 루프문 작성 못할 경우 enumerator를 쓴다. · 태그 비교에.. 더보기
스크립트 최적화 스크립트 최적화 · 유니티의 핵심 기능은 모두 C++ (ex> Transform은 C#, position은 c++) · 유니티 객체들 캐싱 (FindObject 느리다) · 객체의 이동과 변형에 대한 처리를 캐싱하고 매 프레임에서 딱 한번 처리 (ex. Move()) · Instantiate, Destroy 대신 Object Pool(오브젝트 풀) 사용 · Update 대신 Coroutine 활용 · 빈 콜백 함수는 제거 (Start()나 Update() 같은 콜백함수는 비어있어도, 성능에 영향) · 나눗셈보다 곱셈이 몇 십 배 빠름 · 박싱과 언박싱은 부하가 큰 작업 · magnitue 보다는 sqrMagnitude를 사용해서 비교 · 삼각함수의 값은 상수로 저장하고 사용 · 문자열은 readonly .. 더보기
Bottleneck 병목현상 · CPU - 너무 많은 DP Call, 복잡한 스크립트나 물리 연산 · Vertex Processsing - 너무 많은 버텍스들, 버텍스 당 너무 많은 연산(버텍스 셰이더) · Fragment Processing - 너무 많은 픽셀, 오버 드로우(OverDraw), 프래그먼트당 너무 많은 연산 (프래그먼트 셰이더/픽셀 셰이더) · Band Width - 크고, 압축되지 않은 텍스쳐, 고해상도 프레임 버퍼 더보기