효율적인 텍스쳐 압축 이해하기

 

Texture

 

True Color(32bpp)

우리가 일반적으로 생각하는 이미지

R + G + B + A (각각 8비트) = 32

 

bpp

Bit per Pixel

 

한 픽셀당 32비트를 쓴다 

근데 이걸 그대로 사용하진 않음

 

 

 

PNG

비손실 압축

이미지에 들어있는 색상의 수 차이에 따라 용량 차이가 심함

유사한 색상이 많을수록 압축 효율이 올라감

 

JPG

손실 압축

 

이 이미지를 그대로 GPU 메모리에 올리게 되면 4MB를 먹는다

GPU에서 사용하는 텍스처들은 ETC/PVRTC 등 GPU 전용 포맷들로 변환해서 사용하게 됨

그렇기 때문에 원본이 PNG든 JPG든 PSD든 다 상관 없음 어차피 유니티에서 바꿔서 올리기 때문!

 

 

 

여기 있는 이 포맷으로 변환된다

 

 

GPU 입장에서 이미지를 GPU에서 사용해서 렌더링할 때 사용하게 되면 이걸 텍스쳐라고 부른다

텍스쳐는 보통 Shader에서 사용함

Pixel Shader에서 한 프레임을 그리기 위해서 여러가지 텍스쳐를 접근하고 해당 Color를 읽어오는게

수천만번~억단위 엄청나게 많이 일어남 -> 굉장히 빠른 속도로 읽어와야함

이게 PNG/JPG랑 GPU에서 사용하는 Texture랑 다른 점

 

 

 

Texture Compression의 제약 조건

 

- 빠른 디코딩

- 랜덤 액세스

특정 UV 좌표가 있을 때, 그 UV 좌표에 있는 해당 지점에 접근해서 빠르게 Color를 얻어와야함

처음부터 순차적으로 읽는거 X, 특정 지점에 바로 접근해서 읽는거 O

 

- 인코딩 상태로 메모리에 존재

압축이 풀린 상태로 올라가는게 아니고, 메모리에는 압축되어 있는 상태로 올라가야함

GPU는 그 압축되어 있는 텍스쳐에 랜덤하게 액세스해서 데이터를 빠르게 얻어와야함

 

- 사이즈 절약(메모리, 저장장치)

 

-> 이러한 제약 조건들 때문에 텍스쳐에 필요한 별도의 포맷이 생기게 된 것

 

가변 비율 압축 VS 고정 비율 압축

가변 비율 압축

RLE(Run-Length Encoding, 실행 길이 인코딩)

 

데이터가 중복된 단위로 나눠서

A가 4개면 4A 이런 식으로 줄여서 씀

데이터가 단조로울수록 효율이 올라감/데이터가 복잡할수록 효율 떨어짐

-> 가변 비율

가장 기본적인 압축 알고리즘

 

고정 비율 압축

텍스처는 랜덤 액세스를 해야하기 때문에 고정 비율 인코딩이 필요함

어떤 데이터가 들어오든 4:1 8:1 16:1 등 고정 비율 압축

밑에 나오는 ASTC가 메인, 그 위는 좀 예전 방식

블럭 기반 압축(DXT : Direct X Texture)

 

 

하나의 이미지가 있을 때 4x4 pixel block 단위로 쪼갬

-> 랜덤 액세스 할 때 해당 블럭으로 찾아가서, 그 블럭만 압축 풀어서 읽을 수 있게됨!

 

이 예시 사진에서 뽑아온 블럭을 보면 대표 컬러(빨강, 검정) 2개를 뽑음

그리고 해당 픽셀에 어떤 컬러를 가지고 있냐를 Index로 Blend 값을 갖고 있음

최종적으로 대표 컬러 2개/모듈레이션 데이터(이 두 컬러를 어떻게 섞을건지)를 가지고 있음

 

이 예시는 DXT1 방식을 사용하고 있는데, 64/(4*4) = 4bpp (한 픽셀을 표현하기 위해 4비트밖에 사용하지 않음!)

하지만 이미지가 굉장히 복잡할 때는 대표 컬러 2개를 뽑으면 컬러가 날아가버리는 문제가 발생한다,,,

-> 이 문제 때문에 텍스처 자체 크기를 올려버리는 경우가 있는데 그러면 안된다!

 

지금은 DXT라는 이름 말고 BC라는 이름을 사용한다 (근데 BC7은 전혀 다른 포맷임)

DXT5 까지는 DX9 / 그 이후로는 DX11~ 

사용 목적에 따라 다르게 설정해야함

무조건 포맷을 높여쓴다고 좋은게 아니다

 

PVRTC : PowerVR Texture Compression

모바일에서는 PVRTC/ETC/ASTC냐,,

PVRTC는 주로 애플에서 사용

PowerVR 칩셋을 애플에서 썼었음 그 때부터 쓰던 포맷

근데 지금은 다른 회사 칩셋을 쓰기 때문에 안드로이드에서도 이 포맷을 쓸 수 있다구 함

POT, 정사각형 사이즈만 지원

 

 

 

 

DXT랑 방식이 흡사함

 

 

하지만 얘는 이미지를 블러링을 시켜줌

DXT(S3TC)는 블럭 기반으로 되어있기 때문에 확대하면 블럭이 티가 남

PVRTC는 그 블럭 경계를 한 번 더 뭉갬 근데 이러면 컬러가 서로 침범하는 문제가 있음(UI에는 비추)

 

ETC : Ericsson Texture Compression

Ericsson이라는 회사에서 만들었음

주로 안드로이드에서 사용

얘는 위 두 방식이랑 방식이 다름

 

사람의 눈은 채도 변화에 둔감하고, 명도 변화에 민감함

이걸 이용한 방식

 

 

색상은 저해상도로 저장, 밝기만 고해상도로 저장

이걸 모듈레이션함

ETC2가 ETC1에 비해 퀄리티가 많이 좋아짐

 

 

Crunched Mode

메모리 절약X, 디스크 용량을 아끼기 위함

근데 이건 GPU에서 지원하는 압축 방식이 아니기 때문에 그대로 올리지 않고 ETC 방식으로 압축을 푼 후 올림

저장 용량을 아낄 수 있지만, 로딩할 때 압축 푸는 과정이 한 번 더 발생하기 때문에 조금 더 오래걸리게 됨

 

ASTC : Adaptive Scalable Texture Compression

요즘은 ASTC로 다 통일되었다

유연하고 확장성있는 텍스쳐 포맷

이거 쓰는거 추천!!!!

 

 

블럭 사이즈 지정이 가능함

위에 나온 포맷들은 4x4 고정

128bit 기준 자유롭게 설정 가능

블럭이 작을수록 퀄리티가 좋고 클수록 메모리 절약 가능

 

Albedo Texture / 모델링에 쓰이는 Texture는 프리퀀시가 높기 때문에 4x4를 많이 사용

파티클 / 이펙트 같은 경우는 프리퀀시가 높지 않기 때문에 12x12 사용

텍스쳐 종류별로 유연하게 설정 가능

 

 

 

PVRTC : 색 번짐

ETC : 채도/휘도로 나누다보니 뜻하지 않은 컬러가 나옴

 

 

ASTC 4x4 : 원본 이미지랑 거의 유사

 

메모리를 굉장히 많이 아낄 수 있다

 

 

노말맵에서 체감 많이 됨 ASTC가 더 퀄리티도 좋고 메모리도 적게 먹음

 

 

지원비율도 높은 편이다!

 

ASTC 동작 방식

 

 

대표 컬러를 뽑고, 블렌딩하는 방식

 

 

대표 컬러 최대 4개까지 가능

 

Partition Index

어떤 색의 영역인지 

 

Texel Weights

경계값, 블렌드값

 

이렇게 하면 뭔가 무거워질 것 같지만 그렇지 않다

특정 알고리즘에 의해 미리 패턴을 잔뜩 만들어놓고 그 중에 돌려쓰기를 함

 

 

얘네 둘은 다른 블럭처럼 보이지만 결국 같은 블럭이다

왼쪽에서 픽셀을 한칸씩 옆으로 밀고, 180도 돌리면 같아지기 때문

 

BC7

 

 

이거는 아까 혼자 다르다고한 BC7!

ASTC랑 유사함 하지만 ASTC는 블럭 크기가 가변적/BC7은 여전히 4x4 고정

ASTC - 주로 모바일

BC7 - PC, 콘솔에서 사용

 

 

이거는 유니티 그래픽스 엔지니어분이 품질뷰를 해서 올려준 이미지

BC7 / ASTC4x4는 거의 비슷함 동급이라고 봐도됨

 

 

PNG / JPG / PSD 뭐를 써야 하나요??

아무 상관이 없다 텍스처뿐만 아니라 뭐가 됐든 어차피 유니티가 사용하는 방식으로 변환됨

하지만 PSD는 PNG/JPG와 같은 이미지여도 용량이 확 커지기 때문에 문제가 발생할 수 있다 잘 찾아보고 사용하는걸 추천

 

원본 영상

https://youtu.be/BeEjoTa9sSo?si=O1IQ1hsH20FD1n-i