[유니티 TIPS] 모바일 게임 성능 최적화 - 2편

[유니티 TIPS] 모바일 게임 성능 최적화 - 2편

 

• Asset 
  • 이미지는 tga, jpg, png, psd, psb... 뭘 써도 전혀 상관이 없다. 어차피 유니티에서 TextureFormat을 변환해서 쓰기 때문이다 
    • 오히려 psd를 사용하는게 관리 측면에서 좋을 수 있다. 이미지 수정 후 다시 png같은걸로 짤라 쓸 필요가 없기 때문. 
    • (하지만 확인해보니 psd가 1개의 아틀라스가 되기 때문에 사용하지 않는 이미지도 아틀라스로 묶이므로 관리가 더 힘들어질 수 도 있을 것 같다) 
  • 사운드도 mp3, ogg... 뭘 쓰더라도 상관없다. 오히려 mp3같은걸 import하면 유니티가 압축을 풀었다가 다시 압축하므로 손실이 발생할 수 있으므로 wav를 쓰는게 좋다 
  • 기본 텍스쳐포맷보다는 각 플랫폼에서 override해서 사용한다 
    • Max Size는 아무리 최신폰이라도 4096은 쓰지말자. 최대 2048을 쓰고, 베스트는 1024 

    • 

  • 1장의 이미지는 POT로 쓰거나, 작은 여러장의 이미지는 아틀라스를 사용한다 
  • read/write enabled는 텍스쳐를 조작할 일이 없으면 체크하지 않는다 
    • 텍스쳐는 VRAM에 상주하지만, read/write가 체크된다면 조작을 위해 RAM에도 상주하기 때문에 거의 2배로 메모리를 잡아먹게 된다 
  • 2D게임에서는 mipmap을 사용하지 않는다 
  • 저사용폰을 지원하지 않는다면 ASTC 사용을 고려해보자 
  • Mesh 
    • 조작할 일이 없다면 read/write enabled를 체크해제한다 
    • 움직임이 없다면 rigs를 체크해제한다 
    • 얼굴표정같은 형태 변화가 없다면 BlendShape을 체크해제한다 
  • 폴리곤 카운트를 체크한다 
    • CPU bound, GPU bound인지는 꼭 확인한 후 체크한다 
  • preset을 만들어서 AssetPostprocessor를 통해 설정값들을 커스터마이징해서 사용하자 
• URP 
  • 신규 프로젝트는 URP를 사용 고려해보자 
  • 동적 라이팅에 대한 draw call 처리가 최적화되었다 
    • 그래도 정적 라이팅보단 무거우므로 사용할때 조심하자 
  • 배경 오브젝트나 움직이지 않는건 static batching을 사용 고려해보자.  
    • 메모리가 늘어나는건 참고하자. 한 종류의 메시가 화면에 n개 있으면 메모리에 1개만 올라가지 않고 n개만큼 올라간다 
  • Shadow는 왠만하면 끄자. 

    • 

    •  
      그림자를 우회하자 표현하자. flat한 texture를 캐릭터 밑에 깐다던가... 
  • Light 맵이나 light probes사용을 고려해보자 
    • 동적 라이팅방식은 사용이 비싸다. light맵을 사용하면 빛 결과물을 texture로 가지고 있어서 성능이 좋다 

    • 

    •  
      Light probes는 객체의 위치에 따라 빛을 표현할 수 있다 

      • 

      •  
        Light probes는 숫자를 저장하기 때문에 성능이 좋지만, Reflection probes는 면적을 저장하기 때문에 성능에 좋지 않다 
  • 오클루전 컬링에 상황에 맞게 사용하자 
    • 인도어처럼 객체끼리 가려질게 많은 장소에서 사용하면 좋다 
    • 아웃도어처럼 광활한 영역에서는 서로 가려질게 거의 없으므로(조금이라도 삐져나옴) 불필요한 오클루전 컬링 데이터 및 연산이 발생한다 
  • Screen.SetResolution을 사용하자 
    • 하지만 UI는 뭉개져보일 수 있다. 그러므로 UI는 원래 해상도로 그리고 3D공간만 적용되게 할 수 있다 
      • URP : Reder Scale ! 
      • GitHub - ozlael/UpsamplingRenderingDemo: Upsampling Rendering is old school but common trick for low end devices.  
  • 카메라 사용대수를 제한하자 
    • 카메라 1대당 컬링연산을 각자 하기 때문이다. 
    • Cinemachine은 1대의 카메라를 여러개의 가상카메라가 사용하는 것이기 때문에 상관없다 
  • 쉐도우는 심플하게 사용하자 
  • 오버드로우를 피하자 
  • 포스트 프로세싱은 종류마다 성능이 천차만별이기 때문에 상황에 맞게 사용하자 
  • Renderer.material 은 복사본을 만든다. (배칭이 깨짐) 그렇기때문에 Renderer.sharedMaterial을 사용하자 
• UI 
  • 배칭은 canvas단위로 일어난다 
  • 동적, 정적 canvas로 구분한다 
    • Canvas 단위 아래에서 자식이 1개만 변경되도 canvas자체에서 폴리곤을 다시 구성하기 때문에 canvas 전체 리빌드가 일어난다 
  • Canvas 하위에 인터렉션이 전혀 없다면 Graphic Raycaster는 꺼주는것이 좋다. 
  • Image나 Text에 Raycast Target도 인터렉션이 없다면 꺼준다 
  • 레이아웃 그룹 계열은 왠만하면 사용하지 않는다 
    • 작업할땐 사용했다가 작업완료 후엔 꺼준다 
  • 스크롤 아이템들은 갯수대로 만들지 말고 재사용을 하자 
• 디바이스 시뮬레이터는 적극적으로 활용하자 
  • 노치같은거 확인할때 유용하다 
• Audio 
  • 모바일은 왠만하면 Force To Mono를 체크하자 
  • 원본 wav파일을 사용하자 
    • 위에서 이유를 설명했음 
  • Compression Format은 왠만하면 Vorbis를 사용한다 
    • FMOD엔진이 압축을 풀며 플레이를 해준다 
    • 짧은 사운드는 ADPCM을 사용한다 
  • Load Type이 가장 중요하다 
    • 사운드를 로드 후 메모리에 어떻게 올릴 것인지에 대한 방법 
      • Decompress on Load 
        • 사운드를 메모리에 모두 올린다 
        • 짧은 사운드에 사용 
      • Compressed in Memory 
        • 압축된 채로 메모리에 올린다 
        • 중간 길이의 사운드에 사용 
      • Streaming 
        • 메모리에 올리지 않고 플레이할때마다 꺼내서 사용한다 
        • 배경음에 사용 
  • Volume이 0이더라도 연산을 하기 때문에 아예 enabled를 꺼야한다 
• Animation 
  • Humanoid가 Generic보다 cpu를 30~50%더 먹기 때문에 가능하다면 generic을 쓰는게 좋다 

  • 

• Physics 
  • PlayerSettings > Prebake Collision Meshes를 체크해두면 좋다 
    • 충돌처리하는 데이터들을 미리 구워놓는 기능 
  • Collision Matrix를 잘 체크하자 
    • 체크를 덜 함으로써 연산을 덜 하게 된다 
  • Collider는 기본도형 collider를 쓰는게 연산을 덜 하게 된다 
  • Physics Debug 창을 잘 사용하자