Unity 썸네일형 리스트형 셰이더 유니티 셰이더 · 기본 셰이더는 모바일용 셰이더 사용(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 - 크고, 압축되지 않은 텍스쳐, 고해상도 프레임 버퍼 더보기 Addmob 애드몹· 배너 혹은 전면 광고. · 다운로드와 상관없이 시청 수 만 가지고 정산 받는 데에 유리. · 그러나 다운로드에 대한 정산이 없음. 따라서 DAU(Daily Active User)가 중요. · 소소한 수익률. · 애드몹 정책에 따라 애드몹과 함께 보상형광고(ex. 유니티애즈)를 같이 쓰는 것이 금지 플러그인 사이트 : https://github.com/googleads/googleads-mobile-plugins/releases 더보기 UnityAds · 동영상 광고. · 시청하는 단말에서 시청수 만 늘고 광고된 어플의 설치가 늘지 않으면 정산효율이 떨어짐. 영상을 보고 다운을 받는 유저가 있을 때 비보상광고 수익을 지급(CPI 방식) · 설치율이 높아야 의미가 있긴 하지만 설치 당 단가가 괜찮음. · 하드코어 혹은 미드코어한 RPG 게임 광고가 주이기 때문에 캐쥬얼하거나 여성 유저가 주 고객층인 게임에서는 효율이 낮음. · 광고에 대한 reward 허용. · 일반형광고 - 스킵버튼 활성화. 5초 후부터 광고 스킵 가능. (5초 이외에 원하는 시간으로 설정 가능) · 보상형광고 - 스킵버튼이 나오지 않아 사용자는 무조건 광고를 봐야 함 · 유니티애즈가 동영상 광고 중에서 가장 많은 국내 광고를 갖고 있다 함 (said 유니티애즈 담당자) UnityAd.. 더보기 이전 1 2 다음