unity 그래픽 성능 최적화

그래픽 성능 최적화

Desktop

게임이 끊김 없이 부드럽게 동작하는 것은 게임의 성공 여부에 매우 중요 합니다. 유니티가 이를 위해 존재합니다. 저희들은 다양한 하드웨어에 유니티 iOS가 빨리 동작하도록 많은 시간과 노력을 기울였습니다. 아래에는 게임의 스피드를 최대화 하기 위한 몇몇 간단 한 안내서를 소개합니다.

줄여서 얘기하면 – 통합(combine), 통합, 통합

• 성능을 신경 쓰신다면, 메쉬들을 통합하세요.
• 성능을 신경 쓰신다면, 통합된 메쉬들이 같은 재료(material)와 질감을 공유하도록 확인하세요.
• Profiler와 Rendering Statistics 창이 유용할 것입니다!

자세히 살펴보면:

현대의 그래픽 카드들은 많은 다각형을 표현해 내는데 익숙하지만, 그래픽 카드에 모든 일괄처리(batch)들은 많은 과부하를 야기 합니다. 만약, 100개의 삼각형 오브젝트가 있는 것은 1500개의 삼각형을 표현해 내는 것만큼 많은 성능 소모가 일어 납니다. 최적의 표현 성능을 내는 이상적인 장소는 메쉬당 1500-4000개의 삼각형입니다.

Mesh Renderer가 부탁된 오브젝트들을 표현하는 것은 성능의 일정한 대가를 치러야 합니다. 보기 절두체(view frustum)내에서 그 대가를 치릅니다. 장면(scene)내에서 빈 GameObjects들을 많이 가지고 있는 것은 표현 비용이 없습니다.

• 표현 성능을 향상 시키는 가장 좋은 방법은 오브젝트들을 결합해서 각 메쉬가 1500개 또는 더 이상의 오브젝트를 가지고, 전체 메쉬를 위해 하나의 Material를 사용하는 것입니다.

재료를 공유하지 않는 두개의 오브젝트들을 결합하는 것은 성능의 부하를 주지 않는다는 것을 이해해야 합니다. 효율적으로 결합하려면, 메쉬가 통합 후에 하나의 재료를 쓴다는 것을 확인하시기 바랍니다.

오브젝트들을 결합 할 때 한가지는 알아야 합니다. 장면에 많은 조그마한 빛들을 사용하면, 근접한 오브젝트들을 결합 하는 것이 더 합리적입니다.

많은 재료를 가지는 메쉬를 표현하는 비용은, 각 재료로 다수의 렌더러(renderer)를 가지는 것과 같은 비용 입니다. 다수의 재료들을 가지는 가장 보편화된 이유는 두 개의 메쉬들은 같은 질감들을 공유하지 않습니다. 표현 성능을 최적화 시키려면, 통합하는 오브젝트들이 같은 질감을 공유하도록 하셔야 합니다.

• 유니티는 많은 다각형을 밀어 표현 하는것에 강점이 있다. 유니티는 모든 기하를 그래픽 카드로 업로드 하는데, 이는 좋은 캐쉬(cache) 효율과 최적화된 데이터 배열을 위해서이다.
• 단지 그래픽 카드는 많은 수의 일괄처리를 다룰 필요가 없음을 확인해야 한다.
• 전면 렌더링 통로 Forward rendering path를 사용하면, 오브젝트에 영향을 주는 Pixel Lights의 개수는 성능에 많은 영향을 준다.

전면 렌더링 통로에서의 픽셀 불빛들

주의: 이는 오직 전면 렌더링 통로 Forward rendering path 에서만 적용이 됩니다.

픽셀 불빛을 사용하면, 각각의 GameObject는 오브젝트에 영향을 주는 픽셀 불빛의 갯수 만큼 표현되어야 합니다. 멀리 떨어져 있는 두 오브젝트를 결합하면, 오브젝트의 크기가 증가할 것이고, 이 큰 오브젝트에 영향을 주는 많은 물빛들을 가지게 될 것입니다. 오브젝트들이 분리되어있으면, 멀리 떨어진 메쉬의 부분에 빛들이 적용될 필요는 없습니다.이는 통합된 메쉬를 표현하는데 통합되지 않는 메쉬(따라서 아무것도 저장하지 않는) 의 개수 만큼 표현하는 결과가 생깁니다. 이런 이유로, 멀리 떨어진 GameObjects들을 각각의 메쉬들로 보존해야 합니다.

메쉬를 표현할때, 유니티는 메쉬 주위의 모든 불빛을 찾습니다. 그리고, 어떤 빛들이 메쉬에 가장 영향을 미치는지 알아냅니다. QualitySettings은 얼마나 많은 빛이 픽셀 빛과 정점 (vertex) 빛으로 도래되는지를 변경할 때 사용합니다.

모든 빛들은 메쉬로부터 얼마나 떨어지고, 얼마나 강도가 있는지에 기반하여 중요성을 계산합니다.

어떤 빛들은 다른 빛들보다 게임의 맥락에서 더 중요합니다. 이러한 이유로, 모든 빛은 Render Mode 설정을 가집니다. 이 설정은 Important 와 Not Important로 나눠집니다.

헤드 라이트를 가진 게이머의 차가 밤에 운전하는 것을 상상해 보십시오. 헤드 라이트들은 게임에서 가장 중요한 불빛들입니다. 이러한 이유로, 헤드라이트의 렌더 상태는 Important로 설정되어야 합니다.

별로 중요하지 않는 불빛을 가지고, 픽셀 빛으로부터 시각적으로 얻는 것이 없다면 렌더 상태는 Not Important로 설정합니다. 이런 방식으로 렌더링 성능이나 시각적 성능을 낭비하지 않습니다.

레이어당 누락 거리

그리기 호출의 개수를 줄이기 위해 작은 오브젝트들을 누락시키고 싶을 때가 있습니다. 예를 들어, 조그만 바위나 잔재는 커다란 빌딩보다 작은 거리에서는 보이지 않습니다. 이를 위해서는, 작은 오브젝트들을 분리된 레이어에 놓고, 레이어당 누락거리를 Camera.layerCullDistances 스크립트 함수를 사용하여 설정하십시오.

그림자들

데스크톱 플랫폼에서 배치한다면, 그림자들에 신경을 써야 합니다. 그림자들은 일반적으로 (성능상의)비용이 많이 듭니다. 그림자들이 정확하게 사용되지 않으면 게임의 성능에 많은 부하를 줍니다. 그림자들에 대한 더 많은 정보는 Shadows page를 읽으시길 바랍니다.

주의: 그림자들은 현재 iOS 나 Android 디바이스들에는 지원되지 않습니다.

더 살펴보기

• 드로우콜 배치 (Draw Call Batching)
• 최적화된 캐릭터 모델링 (Modeling Optimized Characters)
• 렌더링 통계 (Rendering Statistics)

iOS

iOS를 위해서 컨텐트의 최적화를 원한다면 learn more about iOS hardware devices 페이지를 참조 하십시오.

알파 테스팅

데스크톱과는 반대로, 알파테스팅 (또는 픽셀 쉐이더에서 discard$ / clip$$ 연산)은 iOS에서 성능상 비용이 많이 듭니다. 알파 테스트 쉐이더를 알파 블렌드로 교체를 원하시면, 그렇게 하십시오. 알파 테스트가 정말 필요하시면, 보이는 알파 테스트 픽셀 지역을 최소로 유지 시키십시오.

정점 성능

일반적으로 iPhone 3GS 나 새로운 디바이스들을 타겟으로 할때, 프레임당 40K나 더 적은 정점을 목표로 합니다. MBX GPU가 장착된iPhone, iPhone 3G, 1세대 2세대 iPod Touch 경우 프레임당 10K나 더 적은 정점을 목표로 합니다.

라이팅 성능

픽셀당 동적 라이팅(lighting)은 모든 영향 받는 픽셀에 중요한 비용이 추가 되고, 다중 패스들에 렌더링 오브젝트들을 이끌 수 있습니다. 하나의 오브젝트에 영향을 주는 하나의 Pixel Light보다 픽셀 라이트를 더 가지는 것을 피하시고, 방향성 빛을 선호하시길 바랍니다. Pixel Light 는 Render Mode 설정이 Important로 설정되어 있음을 명심하시기 바랍니다.

정점당 동적 라이팅은 정점 변환에 많은 비용이 더 추가 됩니다. 하나의 오브젝트에 영향을 줄때는 다중 불빛을 피하시기 바랍니다. 정적 오브젝트들을 위해서는 베이크 라이팅 (bake lighting)을 사용하십시오.

모델 기하 최적화

모델 기하를 최적화 할 때, 두 가지 기초 룰이 있습니다:

• 필요하지 않다면, 더 많은 추가 면을 사용하지 마세요.
• UV매핑솔기(seam)의 수를 유지하고, 하드 모서리(hard edge)를 가능한 적게 하십시오.

그래픽 하드웨어가 프로세싱하는 실질적인 정점의 개수는 3D 어플리케이션에 표시되는 것과는 같지 않습니다. 모델링 어플리케이션들은 모델을 이루는 포인트들, 즉 기하 정점 카운트를 표시합니다.

그래픽 카드들은, 몇몇 정점들은 구분 되어야 합니다. 정점이 다중의 법선(normal)들 (하드 모서리 위에서) 을 가지거나, 다중의 UV 좌표를 가지거나, 다중의 꼭지점 색상을 가지면, 이는 분리되어야 합니다. Unity에서 보는 정점의 숫자는 3D 어플리케이션에서 진열 되는 것과 항상 다릅니다.

질감 압축

iOS 의 네이티브 PVRT compression formats 압축 포맷을 사용하십시오. 질감의 사이즈를 감소시킬 뿐만 아니라(더 빠른 불러오기 시간과 더 작은 메모리 사용), 렌더링의 성능을 증가 시킵니다. 압축된 질감은32bit RGBA에 비교해서 메모리 대역폭의 아주 일부분만 필요합니다. 성능 비교를 위해서는 iOS Hardware Guide를 참조하십시오.

몇몇 이미지는 PVRT 압축 질감의 알파 채널에서 시각적 조형물로 되기 싶습니다. 그런 경우 이미지 소프트웨어에 PVRT 압축 변수들의 직접적인 변경을 원할 수 있습니다. PVRT 포맷을 만든 Imagination Tech의 PVRTexTool을 사용하여 PVR export plugin을 설치해서 직접적인 변경이 가능합니다. ..pvr 확장을 가진 압축 이미지는 유니티 에디터에 가져오기 될 것이며, 수동으로 설정된 압축 변수들은 보존 될 것입니다.

PVRT 압축 포맷이 충분한 시각적 질을 전달하지 않는다면, UI 질감과 같은 추가의 이미지 작업이 필요합니다. 이 경우 32bit RGBA 질감대신 16bit 질감의 사용을 고려해야 합니다. 최소한, 메모리 대역폭이 반으로 줄 것입니다.

성능 좋은 쉐이더를 작성하기 위한 팁들

iPhone3GS 이후로 GPU들은 픽셀과 정점 쉐이더(shader)들을 충분히 지원하지만, 복잡한 픽셀당 기능을 가진 데스코톱 쉐이더의 성능과 초당 30프레임들을 동작하는 iOS디바이스의 성능을 추월하는 기대는 하면 안됩니다. 대부분 쉐이더 들은 편리하게 최적화 되어있고, 연산과 질감은 좋은 프레임 비율을 달성하기 위해서는 최소화 하여야 합니다.

복잡한 수식 연산들

수식 연산들(pow,, exp, log, cos, sin, tan)은 GPU에 많은 부하를 줍니다. 최고의 방법은 부분당(per fragment) 하나의 연산 이상을 가지지 않는 것입니다. 때로는 질감 찾기(lookup)가 더 좋은 대안입니다.

자신만의 규격화된 normalize, dot, inversesqrt 사용을 회피하십시오. 항상 내장되어있는 연산들을 사용하십시오. 이것이 더 좋은 코드를 생성할 것입니다.

Disscard 연산은 부분들(fragments)을 느리게 만들것입니다.

부동소수 연산들

사용자 쉐이더들을 작성할 때 부동 소수 변수들의 소수점 자리를 명시하십시오. 좋은 성능을 위해서는 작은 포맷이 더 중요하다는 것은 매우 중요합니다.

쉐이더가 GLSL ES로 쓰여지면, 소수점 자리는 다음과 같습니다:

• highp - full 32 비트의 부동소수 포맷입니다. 정점변환에 적합하지만 가장 느립니다
• mediump - 16비트의 부동소수 포맷입니다. 질감 UV 좌표에 적합합니다. 대략 highp보다 x2 빠릅니다.
• lowp - 비트의 부동소수 포맷입니다. 색상과 빛 연산, 그리고 고성능 연산에 적합합니다. highp보다는 __x4 배 정도 빠릅니다.

쉐이더가 GG또는 표면 쉐이더로 쓰여지면, 소수점은 다음과 같습니다:

• float - - GLSL ES 에서 highp 와 유사, 가장 느림
• half - GLSL ES 에서 mediump와 유사, float보다 _x2__ 빠름
• fixed - GLSL ES 에서 lowp와 유사, float보다 4x4 빠름

일반적인 쉐이더 성능을 알아보시려면 Shader Performance page 페이지를 참조하세요.

하드웨어 문서

Apple hardware 문서를 공부하고 쉐이더를 작성best practices for writing shaders하는데 시간을 가지시길 바랍니다. 부동 소수점의 힌트를 더 공격적으로 사용하길 권유합니다.

Lightmaps으로의 Bake Lighting

정적 라이팅의 장면을 Unity내의 내장된 Lightmapper를 사용해서 베이크(bake)하십시오. lightmapped 환경을 생성하는 과정은 Unity에서 장면에 빛을 배치하는 것보다 더 시간이 걸립니다. ¬¬그러나:

• 더 많이 빠릅니다 (2-3 배, 2 픽셀 라이트)
• 더 좋게 보입니다. 왜냐하면, 전체적 조명을 베이크 할수 있고, lightmapper는 결과들을 부드럽게 할 수 있습니다

재료들 공유

다수의 오브젝트들이 같은 카메라로 표현되면, 유니티 iOS는 더 다양한 내부적 최적화를 할 수 있을 것입니다. 예:

• 다양한 렌더 상태들을 OpenGL ES로 하는 것을 피함.
• 정점과 픽셀 프로세싱에 필요한 다양한 종류의 변수들 연산을 피함
• 그리기(draw)호출들의 감소를 위한 작은 오브젝트들의 일괄처리
• 그리기 호출을 줄이기 위한 정적 속성을 가능하게 하는 크고 작은 오브젝트들의 일괄 처리

모든 이런 최적화들은 CPU 사이클들을 줄여줄 것입니다. 그러므로, 질감들을 하나의 지도로 합하고 같은 재료(material)을 사용하기 위한 다수의 오브젝트를 만드는 것은 비용을 줄이므로, 권유합니다!

게임을 빠르게 하기 위한 간단한 체크리스트

• 정점 카운트를 아래로 유지하세요:
  • iPhone 3GS와 더 최신의 디바이스를 타겟으로 할때는 프레임당40K 를 하세요 (SGX GPU를 사용).
  • 더 오래된 디바이스들은 프레임당10K 로 하세요 (MBX GPU를 사용)
• 내장 쉐이더를 사용한다면, Mobile 카테고리를 살펴보세요. Mobile/VertexLit 는 현재 가장 빠른 쉐이더입니다.
• 장면당 다른 재료(material)의 개수를 낮게 유지하세요- 가능하면 다른 오브젝트들 사이에서 더 많은 재료를 공유하세요.
• 내부 최적화를 위해서 움직이지 않는 오브젝트들에게 Static 속성을 설정하세요.
• 가능한 질감들을 위해서는 PVRTC 포맷을 사용하세요. 아니면, 32bit 대신 16bit 질감을 선택하세요.
• 통합기(combiners)또는 픽셀 쉐이더를 사용하세요. 이는 다중 패스 접근법 대신에 부분당 몇몇 질감을 혼합하기 위함입니다.
• 사용자 설정 쉐이더를 작성시에는, 항상 가장 작은 부동 소수점을 사용하세요:
  • fixed / lowp -- 칼라와 라이팅 정보, 법선들을 위해서는 완벽합니다,
  • half / mediump -- 질감 UV 좌표들을 위해서 쓰입니다,
  • float / highp -- 픽셀 쉐이더에서는 피합니다. 정점 쉐이더에서 정점 위치 계산을 위한 사용에 괜찮습니다.
• 픽셀 쉐이더에서 복잡한 수식 연산(pow, sin, cos 등)을 최소화 합니다.
• 필요하지 않으면 Pixel Lights는 쓰지 않습니다. – 기하에 영향을 주는 (가능한 방향성의) 하나의 픽셀 라이트를 선택하세요.
• 필요하지 않으면 동적 라이트를 사용하지 않습니다 – 베이크 라이트를 대신 선택하세요.
• 부분당 (per fragment) 더 작은 질감을 사용하세요.
• 알파 테스팅을 피하세요. 알파 블렌딩(alpha-blending)을 대신 사용하세요.
• 필요하지 않으면 안개를 사용하지 마세요.
• 폐색 누락(Occlusion culling) 의 장점을 알아보시고, 복잡한 정적 장면에 많은 폐색이 있을 시에는 가시 기하와 그리기 호출의 양을 줄이기 위해서 사용하세요. 폐색 누락으로부터 어떤 이득의 단계를 얻을 것인지 계획하세요.
• 원거리 기하를 “위장(fake)” 위해서는 스카이박스(skybox)들을 사용하세요.

더 살펴보기

• iOS성능 최적화 Optimizing iOS Performance
• iOS 하드웨어 안내 iOS Hardware Guide
• iOS 자동 그리기 호출 일괄처리 iOS Automatic Draw Call Batching
• 최적화 캐릭터들의 모델링 Modeling Optimized Characters
• 렌더링 통계 Rendering Statistics

Android

라이팅 성능

픽셀당 동적 라이팅(lighting)은 모든 영향 받는 픽셀에 중요한 비용이 추가 되고, 다중 패스들에 렌더링 오브젝트들을 이끌 수 있습니다. 하나의 오브젝트에 영향을 주는 하나의 픽셀 라이트 보다 Pixel Light를 더 가지는 것을 피하시고, 방향성 빛을 선호하시길 바랍니다. Pixel Light는 Render Mode 설정이 Important로 설정되어 있음을 명심하시기 바랍니다.

정점당 동적 라이팅은 정점 변환에 많은 비용이 더 추가 됩니다. 하나의 오브젝트에 영향을 줄때는 다중 불빛을 피하시기 바랍니다. 정적 오브젝트들을 위해서는 베이크 라이팅 (bake lighting)을 사용하십시오.

모델 기하 최적화

모델 기하를 최적화 할 때, 두 가지 기초 룰이 있습니다:

• 필요하지 않다면, 더 많은 추가 면을 사용하지 마세요
• UV매핑솔기(seam)의 수를 유지하고, 하드 모서리(hard edge)를 가능한 적게 하십시오

그래픽 하드웨어가 프로세싱하는 실질적인 정점의 개수는 3D 어플리케이션에 표시되는 것과는 같지 않습니다. 모델링 어플리케이션들은 모델을 이루는 포인트들, 즉 기하 정점 카운트를 표시합니다.

그래픽 카드들은, 몇몇 정점들은 구분 되어야 합니다. 정점이 다중의 법선(normal)들 (하드 모서리 위에서) 을 가지거나, 다중의 UV 좌표를 가지거나, 다중의 꼭지점 색상을 가지면, 이는 분리되어야 합니다. Unity에서 보는 정점의 숫자는 3D 어플리케이션에서 진열 되는 것과 항상 다릅니다.

질감 압축

모든OpenGL ES 2.0 를 지원하는 안드로이드 디바이스들은 ETC1 compression format을 지원합니다. 그러므로, ETC1을 선호하는 질감 포맷으로 사용하길 권유합니다. 압축된 질감은 질감의 사이즈를 줄이는데 중요할 뿐만 아니라(빠른 불러오기 시간과 더 작은 메모리 사용), 렌더링 성능의 향상도 크게 기여합니다. 압축된 질감은32bit RGBA에 비교해서 메모리 대역폭의 아주 일부분만 필요합니다.

만약Nvidia Tegra 나 Qualcomm Snapdragon과 같은 그래픽 구조를 타겟으로 하면, 그러한 구조에 전속적인 압축 포맷을 사용하는 것도 고려해 볼만 합니다. 안드로이드 마켓은질감 압축 포맷의 지원의 필터링을 허락합니다. DXT compressed textures와 같은 .apk와 같은 배포파일은 지원하지 않는 디바이스에서는 압축이 허용되지 않을 수 있습니다.

Mip Maps 허용

항상 Generate Mip Maps 를 허용하는 것이 좋습니다. 질감 압축이 GPU 렌더링시 질감 데이터의 전송의 한계를 돕듯이, mip mapped 질감은 GPU가 더 작은 삼각형으로 낮은 해상도를 사용하게 하는 것을 가능하게 합니다. 이 규칙의 예외는 texel(texture pixel)이 UI 요소들이나 순수 2D게임에서 렌더된 스크린 픽셀에 1:1 매핑하는 것입니다.

성능 좋은 쉐이더를 작성하기 위한 팁들

모든 안드로이드OpenGL ES 2.0 GPU들은 픽셀과 정점 쉐이더(shader)들을 충분히 지원하지만, 복잡한 픽셀당 기능을 가진 데스코톱 쉐이더의 성능과 초당 30프레임들을 동작하는 안드로이드 디바이스의 성능을 추월하는 기대는 하면 안됩니다. 대부분 쉐이더 들은 편리하게 최적화 되어있고, 연산과 질감은 좋은 프레임 비율을 달성하기 위해서는 최소화 하여야 합니다.

복잡한 수식 연산들

수식 연산들(pow, exp, log, cos, sin, tan)은 GPU에 많은 부하를 줍니다. 최고의 방법은 부분당(per fragment) 하나의 연산 이상을 가지지 않는 것입니다. 때로는 질감 찾기(lookup)가 더 좋은 대안입니다.

자신만의 normalize, dot, inversesqrt 연산들의 사용을 회피하십시오. 항상 내장되어있는 연산들을 사용하십시오. 이것이 더 좋은 코드를 생성할 것입니다.

Discard 연산은 부분들(fragments)을 느리게 만들 것입니다.

부동소수 연산들

사용자 쉐이더들을 작성할 때 부동 소수 변수들의 소수점 자리를 명시하십시오. 좋은 성능을 위해서는 작은 포맷이 더 중요하다는 것은 매우 중요합니다.

쉐이더가 GLSL ES로 쓰여지면, 소수점 자리는 다음과 같습니다:

• highp - 32비트의 부동소수 포맷입니다. 정점변환에 적합하지만 가장 느립니다
• mediump - 16비트의 부동소수 포맷입니다. 질감 UV 좌표에 적합합니다. 대략 highp보다 x2 배 빠릅니다
• lowp - 10비트의 부동소수 포맷입니다. 색상과 빛 연산, 그리고 고성능 연산에 적합합니다. highp보다는 x4 배 정도 빠릅니다

쉐이더가 GG또는 표면 쉐이더로 쓰여지면, 소수점은 다음과 같습니다:

• float - GLSL ES 에서highp와 유사, 가장 느림
• half - GLSL ES 에서 mediump와 유사, float보다 x2 빠름
• fixed - GLSL ES 에서 lowp와 유사, ffloat보다 x4 배

일반적인 쉐이더 성능을 알아보시려면 Shader Performance page 페이지를 참조하세요. 인용된 성능 그림들은즉 삼성 Nexus S와 같은 기기들에 사용가능한PowerVR 그래픽 환경을 기반으로 합니다. 다른 하드웨어 환경들은 레지스터 정밀(precision)의 감소로부터 덜 혹은 더 수혜를 받을 것입니다.

Lightmaps 으로의 Bake Lighting

정적 라이팅의 장면을 Unity내의 내장된 Lightmapper를 사용해서 베이크(bake)하십시오. lightmapped 환경을 생성하는 과정은 Unity에서 장면에 빛을 배치하는 것보다 더 시간이 걸립니다, 그러나:

• 더 많이 빠릅니다 (2-3 배, 2 픽셀 라이트)
• 더 좋게 보입니다. 왜냐하면, 전체적 조명을 베이크 할수 있고, lightmapper는 결과들을 부드럽게 할 수 있습니다

재료들 공유

다수의 오브젝트들이 같은 카메라로 표현되면, 유니티 안드로이드는 더 다양한 내부적 최적화를 할 수 있을 것입니다. 예:

• 다양한 렌더 상태들을 OpenGL ES로 하는 것을 피함.
• 정점과 픽셀 프로세싱에 필요한 다양한 종류의 변수들 연산을 피함
• 그리기(draw)호출들의 감소를 위한 작은 오브젝트들의 일괄처리
• 그리기 호출을 줄이기 위한 정적 속성을 가능하게 하는 크고 작은 오브젝트들의 일괄 처리

모든 이런 최적화들은 CPU 사이클들을 줄여줄 것입니다. 그러므로, 질감들을 하나의 지도로 합하고 같은 재료(material)을 사용하기 위한 다수의 오브젝트를 만드는 것은 비용을 줄이므로, 권유합니다!

게임을 빠르게 하기 위한 간단한 체크리스트

• 내장 쉐이더를 사용한다면, Mobile 카테고리를 살펴보세요. Mobile/VertexLit 는 현재 가장 빠른 쉐이더입니다.
• 장면당 다른 재료(material)의 개수를 낮게 유지하세요- 가능하면 다른 오브젝트들 사이에서 더 많은 재료를 공유하세요.
• 내부 최적화를 위해서 움직이지 않는 오브젝트들에게 Static 속성을 설정하세요.
• 가능한 질감들을 위해서는 ETCI 포맷을 사용하세요. 아니면, 32bit 대신 16bit 질감을 선택하세요.
• mipmaps를 사용하세요.
• 통합기(combiners)또는 픽셀 쉐이더를 사용하세요. 이는 다중 패스 접근법 대신에 부분당 몇몇 질감을 혼합하기 위함입니다.
• 사용자 설정 쉐이더를 작성시에는, 항상 가장 작은 부동 소수점을 사용하세요:
  • fixed / lowp -- 칼라와 라이팅 정보, 법선들을 위해서는 완벽합니다,
  • half / mediump -- 질감 UV 좌표들을 위해서 쓰입니다,
  • float / highp -- 픽셀 쉐이더에서는 피합니다. 정점 쉐이더에서 정점 위치 계산을 위한 사용에 괜찮습니다
• 픽셀 쉐이더에서 복잡한 수식 연산(pow, sin, cos등)을 최소화 합니다.
• 필요하지 않으면 Pixel Lights 는 쓰지 않습니다. – 기하에 영향을 주는 (가능한 방향성의) 하나의 픽셀 라이트를 선택하세요.
• 필요하지 않으면 동적 라이트를 사용하지 않습니다 – 베이크 라이트를 대신 선택하세요.
• 부분당 (per fragment) 더 작은 질감을 사용하세요.
• 알파 테스팅을 피하세요. 알파 블렌딩(alpha-blending)을 대신 사용하세요
• 필요하지 않으면 안개를 사용하지 마세요.
• 폐색 누락(Occlusion culling) 의 장점을 알아보시고, 복잡한 정적 장면에 많은 폐색이 있을 시에는 가시 기하와 그리기 호출의 양을 줄이기 위해서 사용하세요. 폐색 누락으로부터 어떤 이득의 단계를 얻을 것인지 계획하세요.
• 원거리 기하를 “위장(fake)” 위해서는 스카이박스(skybox)들을 사용하세요.

더 살펴보기

• iPhone그래픽 성능 최적화 iPhone Optimizing Graphics Performance (그래픽 환경이 Imagination Tech's PowerVR로 알려진경우)