시네머신은 직접 프로그래밍을 하지 않더라도 인스펙터에 있는 속성들을 세팅만 해주면 피사체의 움직임 혹은 사용자의 컨트롤에 따른 카메라 움직임 처리를 쉽게 할수있도록 유니티에서 제공하는 패키지 이다.

현재 최신 정식배포가 된 버전은 시네머신2 인데. 시네머신2에서 아쉬운 부분은 인스펙터의 복잡한 속성들과 모르는 용어들도 많아서 처음 접하여 사용하는 느낌은 난감한 부분이 많다.

이러한 부분들을 좀 더 개선해서 업그레이드 되서 나온것이 시네머신3 이다.

다만 현재 시네머신3는 유니티 2023.2버전부터 사용이 가능하며 프리버전 즉 아직 베타버전 이라 문제점이 있을수도 있다라는 부분을 유의해야 할것 같다.

기본적으로 크게 시네머신의 구성은 시네머신 카메라, 시네머신 컴포넌트, 시네머신 익스텐션 으로 나뉜다.

우리는 메인 카메라가 있고 이 메인카메라를 컨트롤할수 있어야하는데 그 역할이 시네머신 카메라이다.

동시에 이 메인카메라가 피사체를 따라가거나 회전하거나 그러한 역동적인 추가적인 기능을 할수있도록 하는 역할이 시네머신 컴포넌트이다.

시네머신 컴포넌트를 이용해서 우리가 촬영하는 피사체를 다양한 기능을 통해 이쁘게 촬영할수 있지만 이러한 기능을 좀더 효율적이고 확실하게 제어할수 있도록 몇가지 자그만한 확장도구를 추가할수 있는데 이것이 시네머신 익스텐션이다.

컴포넌트는 예를들어 포지션이면 포지션 로테이션이면 로테이션 1대1로만 붙을수 있지만. 익스텐션은 한꺼번에 여러개를 붙일수 있다.

종류는 아래 링크에서 확인해볼수 있다.

https://docs.unity3d.com/Packages/com.unity.cinemachine@3.0/api/Unity.Cinemachine.CinemachineExtension.html

또 시네머신3 에서 달라진점은 기존 시네머신에서는 돌리 트랙을 이용해서 카메라가 이 트랙을 따라 이동하면서 장면을 비춰 주기 위해서 제공되는 기능인데. 하지만 돌리 트랙에는 약간의 제한이 있다.

트랙의 곡률 이라던지 직각적인 움직이라던지 이런것이 안되고 내부적으로 자체 개선을 하여 트랙을 자연스럽게 만들어 주기 때문이다.

시네머신3 에서는 스플라인 패키지를 제공해서 좀 더 자연스럽게 트랙을 세팅할수 있도록 제공한다.

스플라인은 직선과 곡선 데이터를 쉽게 만들수 있도록 제공하는 패키지이다.

확실히 시네머신3까지 와서 2보다 간결해졋고 더 쉽게 사용할수 있는 기능이 많이 제공되는듯 하다.

다만 아직 베타버전이라는 점에 유의해서 사용해야 할것 같다.

-게임 인스턴스 (컨텐츠에 관여하는 용도로 사용하기보다, 어플리케이션의 데이터를 관리하는 용도로 많이 사용)

-에셋 매니저

-게임 플레이 관련 액터 (게임모드, 게임 스테이트)

-프로젝트에 싱글톤으로 등록한 언리얼 오브젝트

언리얼에서는 런타임에 빠른 타입 체킹과 클래스 검색을 위해, 컴파일 타임에서 클래스와 타입 등의 메타 정보를 생성한다.

생성한 메타정보는 UClass라는 언리얼 클래스에 보관된다. UClass에는 클래스의 계층구조, 멤버 변수, 멤버 함수에 대한 정보가 들어있다.

이러한 UClass를 사용하면 런타임에서 인스턴스의 멤버 변수값을 변경하거나 멤버 함수를 호출할수 있다.

이러한 기능은 C#에서 제공되는 리플렉션과 유사하다.

모든 언리얼 오브젝트의 실행 초기 런타임과정에서는 UClass 인스턴스와, 언리얼 오브젝트 인스턴스가 생성된다.

이러한 인스턴스는 언리얼 오브젝트의 기본 세팅을 지정하는데 사용되는데

이를 클래스 기본 객체 (Class Default Object) CDO라고 한다.

CDO를 만드는 이유는 언리얼 오브젝트를 생성할때마다 매번 초기화 시키지 않고

기본 인스턴스를 미리 만들어놓고 복제해서 사용하는 방식으로 매커니즘이 구성되어 있기 때문이라고 한다.

예를 들어 100명의 캐릭터를 스폰시킨다고 했을때 1명, 1명마다 생성하고, 초기화를 시키는것은 비효율적이다.

이러한 문제를 해결하기 위해 처음에 생성시킨 기본 인스턴스를 복제해서 속성만 변경하여 사용하는것이 훨씬 효율적이기 때문이다.

언리얼 오브젝트의 생성자 구문에는 인스턴스를 초기화해서 CDO를 제작하기 위한 용도로 사용이 된다.

즉 생성자 코드는 초기화에서만 실행이되고 이후 게임을 실제로 플레이하는 타임에서는 생성자 코드를 사용할일이 없다고 보면 된다.

게임 플레이시 사용할 초기화 함수는 생성자 대신 Init이나 BeginPlay라는 별도의 함수가 제공이 된다.

무압축 RGBA

압축하지 않은경우 R, G, B, A 채널에 각 8비트를 사용하여 알파가 존재하는 경우 픽셀당 32비트, 알파가 없는 경우 픽셀당 24비트를 사용한다.

2048x2048 RGBA 이미지의 용량 : 2048 * 2048 * 32 = 134.217,728 (약 16MB)
2048x2048 RGB 이미지의 용량 : 2048 * 2048 * 24 = 100,663,296 (약 12MB)

* 유니티는 텍스처를 자체적으로 한번 더 압축하기 때문에 원본 텍스쳐의 용량과 형식에 관계없이 용량이 동일하다. 때문에 PSD나 TGA등을 써도 무방하지만 대부분의 경우 프로젝트 자체의 로컬 용량을 줄이기 위해 보통 PNG를 사용한다. 

밉맵

텍스쳐가 그려질 때 카메라와 거리가 멀 경우 원래 사이즈로 표시하여도 자세히 보이지 않으니 메모리가 낭비될 것이다. 이를 위해 밉맵이라는 최적화 기술이 존재한다.  

- 텍스쳐의 작은 버전을 미리 생성해놓고, 카메라에 표시되는 텍스쳐의 크기가 작을경우 작은 버전의 텍스쳐를 불러와서 대역폭을 절약한다.

- 원본이 2048x2048 이라면, 1024x1024, 512x512, 256x256.... 순으로 절반의 크기를 재귀적으로 생성한다.

- 미리 생성해놓기 때문에 텍스쳐의 용량이 약 33% 증가한다. 

- 유니티에서는 Generate MipMaps 를 체크하면 자동으로 생성되며, default값이 체크이기 때문에, 밉맵이 필요없는 2D 프로젝트에서는 체크해제해야 용량을 절약할 수 있다.

모바일 기기의 텍스쳐 압축 종류

ASTC가 압도적으로 좋은 품질과 적은 용량을 사용하지만 유니티에서 기본설정이 아직도 ETC2 인 이유는 구형 디바이스에서는 ASTC를 사용할 수 없기 때문이다.

ASTC의 지원 기준은 다음과 같다.

글로벌 서비스를 하는 2D 게임이라면 ETC2 유저를 포기할 수 없겠지만, 3D게임의 경우에는 갤럭시 S6 보다도 낮은 기기는 과감하게 버려서 ASTC를 선택하는 경우가 많아지고있다.

구글 공식 개발자 페이지에서 제공하는 안드로이드 OpenGL ES 기기 비율은 아래 주소에서 확인할 수 있다.

http://developer.android.com/about/dashboards/index.html#Platform

2의 승수만 압축하는 ETC, PVRTC

ETC와 PVRTC는 2의 승수(Power of two) 형식만 압축가능하기 때문에, 기본 압축설이 ETC2나 PVRTC라면 POT가 아닌 텍스쳐를 사용할 때 메모리 폭탄을 맞을 수 있다. (ASTC는 2의 승수와 관계없이 압축이 가능하다)

아래의 예시에서

왼쪽은 609x1024로 NPOT 라서, 압축을 하지 못해 무손실 형식으로 2.4 MB가 되었고
오른쪽은 1024x1024로 POT 라서, 왼쪽의 이미지보다 큰데도 압축이 가능해져서 1.0 MB의 용량만을 차지한다. 

* 작은 이미지라면 텍스쳐 아틀라스를 사용하여 강제로 POT이미지에 포함시키면 이를 방지할 수 있다.

가변 블록을 지원하는 ASTC

ASTC는 압축블록의 크기를 자유롭게 조정이 가능하며, 블록크기가 작을수록 품질이 좋아진다.
UI 이미지는 4x4, 3D 오브젝트 텍스쳐 등에는 6x6, 이펙트 등에는 8x8 이상을 사용하면 좀 더 메모리를 절약할 수 있다. 
(기본 값은 6x6)

* ETC2의 기준 용량은 1 MB

예시 사진을 보면 좌측 상단부분의 압축별로 선이 뭉개지는 것을 확인할 수 있다.
특히나 PVRTC는 iOS의 기본 포맷인데도 ETC2에 비해 심하게 뭉개지는 것을 확인할 수 있다.

ASTC 6x6 는 ETC2와 비슷한 품질을 보여주지만 용량은 절반수준을 보여주는것을 알수 있다.

결론은, 안드로이드에서는 3D 게임이거나 팀내에 TA가 있다면 ETC2대신 ASTC를 고려하고,
iOS에서는 PVRTC대신 ASTC를 사용하는 것을 고려해볼만 하다.

출처 :https://mentum.tistory.com/583