Skip to content

Unity Optimization

Jump to bottom
JungSu Kim edited this page Jan 27, 2016 · 1 revision

Reference

최적화 프로세스(The optimization process)

  • 예측하지 말고 계측하라!
  • 프로파일러로 어플리케이션을 측정하라(Take measurements of your application with a profiler.)
  • 병목지점을 분석하라(Analyze the data to locate the bottleneck.)
  • 어떤부분의 최적화를 적용할지 결정하라(Determine the relevant optimization to apply.)
  • 최적화된 작업을 검증하라(Verify that the optimization works.)
  • 최적화 작업된 결과가 만족스럽지 못하다면 Step1로 돌아가라(If the performance is not acceptable return to step 1 and repeat the process.)

최적화 포인트(The optimization point)

  • 스크립트(Script)
  • 에니메이션(Animation)
  • 그래픽스(Graphics) / 쉐이더(Shader)
  • 물리(Physics)
  • 플랫폼 종속 부분(Platform Specific)

우리팀에서 시도해볼만한 최적화 포인트

성능 프로파일링

  • 도구
    • 유니티 프로파일러
    • AP벤더별 프로파일러(Adreno, Nvidia, ARM, PowerVR)
    • Android Studio Monitor
    • Xcode Instruments
  • 확인내용
    • 모델 렌더링 시간 확인
    • 포스트 이펙트 시간 확인
    • 이펙트 시간 확인

최적화 방법

  • LOD(Level of Detail)
  • Occlusion Culling
  • LightMap
  • Static/Dynamic Batching
  • Combined Mesh
    • SharedMaterial
    • SharedMesh
  • Procedural Mesh
  • Procedural Material
  • Mesh Baker
  • Texture Compression

Mobile GPU vendors

  • Imagination Technologies
    • PowerVR
    • Series 5, 5XT, 6, 6XT, Wizard
  • ARM
    • Mali
    • Utgard (Mali400), Midgard (Mali T624)
  • Qualicomm
    • Adreno
    • Adreno 2xx, 3xx, 4xx
  • nVidia
    • Tegra
    • Tegra 2, 3, 4, K1

모바일 최적화(Mobile Optimization)

GPU 측면(Focus on GPUs)

Good practice

  • Keep the number of materials as low as possible.
  • This makes it easier for Unity to batch stuff. Use texture atlases (large images containing a collection of sub-images) instead of a number of individual textures.
  • These are faster to load, have fewer state switches, and are batching friendly.
  • Use Renderer.shaderedMaterial instead of Renderer.material if using texture atlases and shared materials.

Forward rendered pixel lights of realtime lights where ever possible.

  • Use light mapping instead of realtime lights where ever possible.
  • Adjust pixel light count in quality settings. Essentially only the directional light should be per pixel, everything else - per vertext. Certainly this depends on the game.
  • Experiment with Render Mode of Lights in the Quality Settings to get the correct priority.
  • Avoid Cutout (alpha test) shaders unless really necessary.
  • Keep Transparent (alpha blend) screen coverage to a minimum.
  • Try to avoid situations where multiple lights illuminate any given object.
  • Try to reduce the overall number of shader passes (Shadows, pixel lights, reflections).

Rendering order is critical. In general case:

  • fully opaque objects roughly front-to-back.
  • alpha tested objects roughly front-to-back.
  • skybox.
  • alpha blended objects (back to front if needed.)
  • Post Processing is expensive on mobiles, use with care.
  • Particles: reduce overdraw, use the simplest possible shaders.
  • Double buffer for Meshes modified every frame:
void Update()
{
  // flip between meshes
  bufferMesh = on ? meshA : meshB;
  on = !on;
  bufferMesh.verticles = vertices; // modification to mesh
  meshFilter.sharedMesh = bufferMesh;
}

Shader optimizations

  • Avoid alpha-testing shaders; instead use alpha-blended versions.
  • Use simple, optimized shader code (such as the "Mobile" shaders that ship with Unity).
  • Avoid expensive math functions in shader code (pow, exp, log, cos, sin, tan, etc). Consider using pre-calculated lookup textures instead.
  • Pick lowest possible number precision format (float, half, fixedin Cg) for best performance.

CPU 측면(Focus on CPUs)

Good practice

  • Don't use more than a few hundred draw calls per frame on mobiles.
  • FindObjectsOfType (and Unity getter properties in general) are very slow, so use them sensibly.
  • Set the static property on non-moving objects to allow internal optimizations like static batching.
  • Spend lots of CPU cycles to do occlusion culling and better sorting (to take advantage of Early Z-cull).

Physics

  • Physics can be CPU heavy. It can be profiled via the Editor profiler. If Physics appears to take too much time on CPU:
  • Tweak Time.fixedDeltaTime (in Project settings -> Time) to be as high as you can get away with. If your game is slow moving, you probably need less fixed updated than games with fast action. Fast paced games will need more frequent calculations, and thus fixedDeltaTime will need to be lower or a collision may fail.
  • Physics.solverIterationCount (Physics Manager).
  • Use as little Cloth objects as possible.
  • Use Rigidbodies only where necessary.
  • Use primitive colliders in preference mesh colliders.
  • Never ever move a static collider (ie a collider without a Rigidbody) as it causes a big performance hit. It shows up in Profiler as "Static Collider.Move" but actual processing is in Physics.Simulate. If necessary, add a Rigidbody and set isKinematic to true.
  • On Windows you can use NVidia's AgPerfMon profilling tool set to get more details if needed.
Clone this wiki locally