안녕하세요. 만나서 반갑습니다!
알비언 앱의 모든 그래픽 관련 이슈들을 해결하며 생동감을 부여하는 Technical Artist Nate입니다.
게임 엔진에서 텍스쳐 파일이나 UI 이미지를 사용할 때 원본 파일 보다 용량이 늘어난 경험을 하셨던 적이 있으신가요?
그리고 예상보다 늘어난 빌드 파일 크기 때문에 고민하셨던 경험이 적어도 한번은 있으실 겁니다.
이번 최적화 이야기 #1 에서는 게임엔진에 사용하는 텍스쳐 사이즈에 대한 비밀을 풀어나가 보도록 할게요.
최적화 이야기 #1
: 텍스쳐를 2의 거듭제곱으로 해야 하는 이유
서론
일반적으로 게임 제작에 있어 빌드 패키지 용량을 많이 차지하는 파일 유형은 텍스쳐(3D 매쉬용, UI포함)로, 해당 포맷의 파일 개수 역시 다른 포맷에 비해 압도적입니다. 따라서 수많은 텍스쳐파일의 사용은 설치에 필요한 디스크의 공간 뿐 아니라, 필요한 메모리의 양 또한 많아지게 되는데요, 사양 및 스펙을 넘어서는 활동이 지속될 경우, 앱이 강제 종료되는 불상사가 생기기도 합니다.

[ 앱 크래쉬 - 대부분 이러한 경우는 허용램 사용을 초과하여 발생한다 ] 이러한 원인을 해결하고자 여러 실력있는 공학도들이 텍스쳐 품질은 유지하고, 용량을 줄일 수 있는 여러 방법을 고안했는데요, 최적화 기능을 사용하기 위해서는 지켜져야 할 ‘약속’이 있습니다. 바로 2의 거듭제곱(POT, Power Of Two) 단위로 이미지를 저장하는 것이죠. 본 콘텐츠에서는 게임 엔진에서 이미지를 POT 사이즈 규격으로 저장하는 이유에 대해 다뤄보겠습니다.
우선 POT에 대해 이야기하기 전에, 컴퓨터의 작동 방식에 대해 간단히 짚고 가려 합니다. 현대인은 적어도 하루에 몇 번 이상은 스마트 기기나 컴퓨터를 사용하죠. 이러한 기기를 통해 우리는 게임, 인터넷, 영상시청, 음악감상, 업무 등을 하게 되는데, 이 모든 처리가 0과 1로 이루어진 2진법(Binary)으로 이루어 진다는 점입니다.
위에 언급했던 스마트폰과 컴퓨터 모두 ‘디지털 기기’라고 통칭하는 이유가 따로 있지요. 디지털은 On(1) 과 Off(0) 기능만 있기 때문이지요. 2진법의 효율적인 사용 배경에 대한 이해를 돕기 위해, 지금으로부터 약 50년 전으로 되돌아가 보겠습니다.

[ 8비트 컴퓨터의 대표 기종들 - 좌 : 애플 2 우 : 닌텐도 패밀리 컴퓨터(일명 파미콤) ]
70년대 후기 본격적으로 8bit 컴퓨터와 게임기가 큰 호응을 얻었는데요, 당시 기기의 사양을 살펴보면 입이 떡 하니 벌어집니다! 요즘 시대 컴퓨터 사양과는 차이가 매우 크지요.
APPLE 2 사양 |
---|
운영체제 | integer BASIC / Apple DOS |
CPU | MOS Technology 6502 @ 1.023 MHz |
메모리 | 4, 8, 12, 16, 20, 24, 32, 36, 48 or 64 KiB |
저장소 | Audio cassette |
Disk II (5.25- inch, 140 KB, Apple) |
디스플레이 | NTSC vidio out (built-in RCA connector) |
그래픽 | Lo-res : 40 x 48, 16-color Hi-res : 280 x 192, 6-color |
사운드 | 1bit speaker (built-in) 1bit cassette input (built-in microphone jack) 1bit cassette output (built-in headphone jack) |
입력 | Upper-case keyboard, 52 keys |
컨트롤러 입력 | Paddles |
확장 연결 | Parallel port card (Apple and third party); Serial port card (Apple and third party); SCSI |
패밀리 컴퓨터 사양 |
---|
CPU | 리코 2A03 1.79 MHz |
음원칩 | CPU 내장 PAPU (Pseudo Audio Processing Unit) |
PPU | 리코 2C02 5.37 MHz |
RAM | 워킹 RAM | 2 KB SRAM |
VRAM | 2 KB SRAM |
색 표시 성능 | 52~56색 | 동시 발색 수 25색 |
스프라이트 오브젝트 | 사이즈 | 8x8 또는 8x16 |
표시 가능수 | 1화면 중 64매 |
캐릭터 패턴(그래픽) 65종류 정의 가능 |
수평/수직 반전 가능 |
표시 위치는 배경화면의 앞뒷면 선택 가능 |
백그라운드(BG) 화면 | 256x240 영역 2개 화면 |
BG 캐릭터 | 8x8 도트 256개 |
스프라이트 | 별도의 BG 캐릭터 3개 |
카트리지 | ROM 카트리지 |
규격 | 254mm x 203mm x 64mm / 1.25kg |
[ 표 : APPLE 2 사양 & 닌텐도 패밀리 컴퓨터 사양 ]
가격 또한 만만치 않았습니다.
APPLE 2 가 발매된 1977년 당시 가격이 약 1,200달러, 닌텐도 패밀리 컴퓨터의 1983년 출시 판매가는 14,800엔 이었습니다. 1970년대 말에서 80년대초 근로자 평균 임금을 생각한다면 두 제품 모두 쉽게 구매하기 어려운 제품이었죠. 그 중에서도 메모리는 엄청난 가격을 자랑했습니다.
PC, 즉 퍼스널컴퓨터와 게임기는 일반 소비자들을 위한 제품이기에 제조비용을 줄여야 했고 그 만큼의 부품 또한 줄여야 했고 한정적인 환경과 화면 상에 보여질 텍스트와 그래픽을 표현할 수 있도록 2진수의 조합을 만들어냈습니다. 그 중 하나가 2진수의 7자리 조합 (128가지)을 이용한 ASCII입니다.

[ ASCII 2진수 (바이너리) 챠트 ]
예를 들어 소문자 ‘a’의 코드는 11000001, 대문자 ‘A’의 코드는 10000001 이렇게 표기하기로 약속한 것입니다. 이처럼 컴퓨터 화면에 출력되는 가장 기본적인 요소인 텍스트를 표시하기 위해 정의된 ASCII 및 ANSI 가 2진법의 8승으로 만들어졌으니, 2진수의 8자리 사용은 곧 8Bit라는 단위를 만들게 됩니다.
대중들에게 가장 많이 보급된 8Bit 컴퓨터는 1Hz, 즉 한번에 2의 8승 크기의 정보(256가지 조합)를 처리할 수 있는 능력을 가지게 되었지요. 그에 따라 임시 저장되고 빠르게 데이터를 사용하기 위한 공간, 메모리의 용량 또한 2의 거듭 제곱에 맞춰 생산되었습니다.


[ 메모리의 용량과 그에 따른 바이너리 조합수 ]
이를 통해 시중에 판매되고 있는 메모리의 용량을 보시면 8, 16, 32, 64기가 규격으로 되어있다는 것을 알 수 있습니다.
본론
색상과 비트Bit에 대한 이해
2진법의 조합으로 문자를 저장 및 표현할 수 있으니, 색상 또한 같은 방법으로 표현할 수 있습니다. 단일 비트, 즉 1비트면 0과 1만 있게 됩니다. 0을 블랙, 1을 화이트로 지정해 흑백 표현이 가능하게 되는데, 이를 1비트 컬러라고 합니다.

숫자를 올려보죠.
2^2 (2비트 컬러 팔레트)는 4이므로 4개의 컬러를 사용합니다. 앞서 정의된 Black, White에 Cyan과 Magenta 컬러가 포함됩니다. 반드시 Cyan과 Magenta 컬러가 적용되는 건 아닙니다. 다른 색상을 팔레트에 저장하고 사용자가 필요할 때 색상 팔레트를 교체하는 방식으로 사용되었습니다.

2^3 (3비트 컬러 팔레트)는 8개의 색상 팔레트로, 앞서 정의된 4개 색상에 더해 Red, Green, Blue, 그리고 Yellow가 더해졌습니다. 3비트 컬러를 적용한 기기는 그리 많지 않았어요.
2^4 (4비트 컬러 팔레트)에 이르러 16개의 색상들이 포함돼 그제서야 이미지의 기본 색상을 표현하기 시작했습니다.

2^8 (8비트 컬러 팔레트), 즉 2의 8승이므로 256개의 색상입니다. 90년대부터 2000년대 초기까지 널리 적용된 컬러 범위였으며 우리에게 친숙한 게임 ‘스타 크래프트1’이 256가지 색상 만으로 품질 좋은 게임 화면을 그릴 수 있었지요.

현재는 어떨까요?
흔히 16만 컬러, 혹은 True Color라 불리는 색상 팔레트는 Red, Green, Blue 각 채널을 8비트 팔레트로 만든 뒤, 이들을 곱해 16만 색상을 표현할 수 있게 되었습니다. 8비트 채널이 3개가 있으니, 24비트 컬러라고 하지요.

일부 그래픽 카드의 경우 채널 당 10비트 컬러, R,G,B 모두 합하여 30비트 색상을 만들 수 있는 기능을 지원하는 경우도 있으며, 그 이상 컬러를 표현할 수도 있지만 이 경우 가격이 높아져 전문 분야에 사용되는 기기라고 할 수 있겠습니다.
그렇다면 투명 이미지는 어떨까요? 앞서 알아본 24비트 색상에 8비트 투명 채널 (256 단계)이 더해지므로, 32비트 컬러라고 불립니다.
이미지 용량 계산법 및 메모리에 저장되는 크기, 그리고 POT을 적용해야 하는 이유
비트의 수로 색상이 표현되는 과정을 알아봤으니, 이미지가 메모리에 저장되는 방법을 살펴봅시다. 이미지 파일의 용량 계산법은 그리 어렵지 않아요.

[ 일반적인 이미지 파일 용량 계산법 ]
- 이미지 파일의 용량 = 가로 pixel x 세로 pixel x 사용된 채널 수
* 위 계산법은 Jpeg이나 PNG와 같은 압축된 포맷이 아닌, 무압축 BMP파일에만 해당된다는 점 참고 바랍니다.
예를 들어, 투명도(Alpha)가 적용된 True 컬러 (Red, Green, Blue)의 32 x 32 픽셀 이미지의 경우, 32 x 32 x 4 (R, G, B, A) = 4,096 byte = 2^12와 같습니다.
예시에 사용된 이미지의 가로 / 세로의 픽셀 크기가 2의 거듭제곱 형식을 따르는 것을 볼 수 있습니다.
이를 메모리에 저장한다면, 2의 거듭제곱에 규격화된 비디오 메모리 크기에 딱 알맞게 저장됩니다. 이미지 프로그램에 따라 차이가 있으며, 특히 게임 엔진에서 사용 시 파일의 용량과 이에 따른 필요 메모리의 크기 또한 달라지게 됩니다. 참고만 해두세요.

실제 파일을 가지고 예를 들어보겠습니다.
가로, 세로 각 180픽셀 크기인 이미지를 유니티에 import 할 경우, 128픽셀로 자동 변경된 것을 확인할 수 있습니다. 이는 유니티의 이미지 설정 중 Non-Power of 2 설정이 ToNearest가 기본으로 되어 있기 때문입니다. 다시 말해 2의 거듭제곱 근처 값으로 자동 변경됩니다.

180픽셀은 128(2^7)픽셀과 256(2^8) 중 128픽셀에 더 가깝기 때문에 근처 값으로 자동 변경되었다고 이해하시면 됩니다. 그렇다면 200 x 200픽셀 이미지는 어떻게 될까요?

256 x 256 (2^8) 픽셀 이미지로 변경된 것을 볼 수 있습니다. 이때 2의 거듭제곱 자동 변경 기능을 쓰지 않고 원래의 해상도를 사용하면 어떻게 될까요?

확연히 드러나는 것은 파일 크기입니다. (저 수치는 빌드 시 적용됩니다)
그렇게 원래의 실제 파일과 크기를 비교를 하면 원본 파일에 비해 대략 4배 늘어났습니다.

256px로 자동변환 되었을(42K) 때 보다 확연히 높다는 것을 알 수 있지요. 이렇듯 게임 엔진 및 실시간 그래픽 라이브러리 사용 시 2의 거듭제곱 픽셀 크기를 가진 이미지들이 더 효율적임을 알 수 있습니다.
게임엔진에서 POT 텍스쳐를 권장하거나, 사용되어야 하는 이유는 여러가지가 있지만, 아래와 같이 몇 개의 사례를 통해 알아보겠습니다.

[ Unity 에서 제공하는 이미지 압축 옵션들 ]
1. 모바일의 경우 최적화 된 이미지 압축 기술은 크게 2가지가 사용되는데, 하나는 ASTC 이며, 나머지 하나는 ETC 포맷입니다. 이들 압축 포맷은 텍스쳐의 해상도가 반드시 POT 단위여야 제대로 지원됩니다.
2. 게임 카메라에서 멀어질 수록 텍스쳐의 해상도를 단계적으로 떨어뜨려 렌더링 최적화에 도움이 되는 ‘MIPMAP’은 텍스쳐가 POT 해상도를 따를 때 극도의 효율로 동작합니다.
3. 컴퓨터 그래픽스 라이브러리인 OpenGL에서 NPOT을 지원하는 버전은 2.0 (2004년) 이었으나, 그 당시 까지 몇몇 그래픽 카드는 POT이외 사이즈 이미지를 사용하면 밉맵을 사용할 수 없다거나, 심지어는 그래픽카드를 통해 렌더링되지 않고 오로지 소프트웨어 (CPU)를 통해 렌더링 되었습니다. 당연히 시각적인 오류와 성능 저하를 일으켰지요.
결론
" 텍스쳐 이미지의 적절한 압축 설정으로 빌드 용량 감소 및 메모리 사용률을 줄이자! "
POT 텍스쳐의 개념은 게임 또는 실시간 그래픽 구현을 위한 최적화의 산물 중 하나 입니다.성능이 한정된 기기에서 보다 현실적이고 아름다운 연출을 위해 수학과 물리학, 그리고 그 외 여러가지 분야가 합쳐진 결과이죠.
급속도로 상승한 하드웨어 사양 덕분에, 실시간 그래픽은 영상과 같은 프리(pre) 렌더링 그래픽과 견줄만한 수준이 되었습니다. 게임 플레이 중간 이벤트 씬을 영상으로 썼던 2000년대와는 달리, 지금은 모든 상황을 실시간 그래픽으로 보여주고 있죠.
게임 그래픽 에셋 제작 역시 예전에 비해 비용이 높아진 만큼, 영화 제작에 필적한 장비를 사용하는 사례가 높은데요, 그럼에도 불구하고 POT 텍스쳐의 사용은 변하지 않고 있습니다. 소프트웨어와 하드웨어 모두 POT 형식에 맞춰 개발되어 온 이래, 실시간 그래픽의 최적 구동에 있어 무시할 수 없는 ‘약속’이 된 셈이죠.
높아진 실시간 그래픽의 퀄리티를 요구하는 성능 또한 높아졌지만, 그 요구치가 ‘제한적이다’라는 것 또한 옛날이나 지금이나 다를 바가 없습니다. 많은 것들이 바뀌었음에도 불구하고, 원리적인 방법은 그대로 남아있는 것을 볼 수 있습니다.
POT의 적용은 크게 어렵지 않으며, 작업물의 최종 출력(export) 시에만 신경 쓰면 됩니다.
POT단위로 제작된 텍스쳐는 각종 게임엔진에서 최적화 옵션 적용 시 넓은 선택을 가능케 하며, 옵션 선택에 따라 최종 빌드의 용량이 작아지는 것은 물론, 실제 구동 시 기기의 부하를 주지 않기 때문에 앱 사용자에게 큰 메리트가 될 것 입니다.
Ref.
https://forum.unity.com/threads/npot-textures.54954/
https://forum.unity.com/threads/disadvantages-of-non-power-of-two-textures.814542/
이미지 출처.
1. Youtube Channel : about game play, 이미지 해상도를 2의 거듭제곱으로 해야하는 이유 中
2. 애플 2 컴퓨터 이미지 출처 : https://ko.wikipedia.org/wiki/%EC%95%A0%ED%94%8C_II
3. 닌텐도 NES 이미지 출처 : https://en.wikipedia.org/wiki/Nintendo_Entertainment_System
안녕하세요. 만나서 반갑습니다!
알비언 앱의 모든 그래픽 관련 이슈들을 해결하며 생동감을 부여하는 Technical Artist Nate입니다.
게임 엔진에서 텍스쳐 파일이나 UI 이미지를 사용할 때 원본 파일 보다 용량이 늘어난 경험을 하셨던 적이 있으신가요?
그리고 예상보다 늘어난 빌드 파일 크기 때문에 고민하셨던 경험이 적어도 한번은 있으실 겁니다.
이번 최적화 이야기 #1 에서는 게임엔진에 사용하는 텍스쳐 사이즈에 대한 비밀을 풀어나가 보도록 할게요.
최적화 이야기 #1
: 텍스쳐를 2의 거듭제곱으로 해야 하는 이유
서론
일반적으로 게임 제작에 있어 빌드 패키지 용량을 많이 차지하는 파일 유형은 텍스쳐(3D 매쉬용, UI포함)로, 해당 포맷의 파일 개수 역시 다른 포맷에 비해 압도적입니다. 따라서 수많은 텍스쳐파일의 사용은 설치에 필요한 디스크의 공간 뿐 아니라, 필요한 메모리의 양 또한 많아지게 되는데요, 사양 및 스펙을 넘어서는 활동이 지속될 경우, 앱이 강제 종료되는 불상사가 생기기도 합니다.
이러한 원인을 해결하고자 여러 실력있는 공학도들이 텍스쳐 품질은 유지하고, 용량을 줄일 수 있는 여러 방법을 고안했는데요, 최적화 기능을 사용하기 위해서는 지켜져야 할 ‘약속’이 있습니다. 바로 2의 거듭제곱(POT, Power Of Two) 단위로 이미지를 저장하는 것이죠. 본 콘텐츠에서는 게임 엔진에서 이미지를 POT 사이즈 규격으로 저장하는 이유에 대해 다뤄보겠습니다.
우선 POT에 대해 이야기하기 전에, 컴퓨터의 작동 방식에 대해 간단히 짚고 가려 합니다. 현대인은 적어도 하루에 몇 번 이상은 스마트 기기나 컴퓨터를 사용하죠. 이러한 기기를 통해 우리는 게임, 인터넷, 영상시청, 음악감상, 업무 등을 하게 되는데, 이 모든 처리가 0과 1로 이루어진 2진법(Binary)으로 이루어 진다는 점입니다.
위에 언급했던 스마트폰과 컴퓨터 모두 ‘디지털 기기’라고 통칭하는 이유가 따로 있지요. 디지털은 On(1) 과 Off(0) 기능만 있기 때문이지요. 2진법의 효율적인 사용 배경에 대한 이해를 돕기 위해, 지금으로부터 약 50년 전으로 되돌아가 보겠습니다.
[ 8비트 컴퓨터의 대표 기종들 - 좌 : 애플 2 우 : 닌텐도 패밀리 컴퓨터(일명 파미콤) ]
70년대 후기 본격적으로 8bit 컴퓨터와 게임기가 큰 호응을 얻었는데요, 당시 기기의 사양을 살펴보면 입이 떡 하니 벌어집니다! 요즘 시대 컴퓨터 사양과는 차이가 매우 크지요.
Hi-res : 280 x 192, 6-color
1bit cassette input (built-in microphone jack)
1bit cassette output (built-in headphone jack)
[ 표 : APPLE 2 사양 & 닌텐도 패밀리 컴퓨터 사양 ]
가격 또한 만만치 않았습니다.
APPLE 2 가 발매된 1977년 당시 가격이 약 1,200달러, 닌텐도 패밀리 컴퓨터의 1983년 출시 판매가는 14,800엔 이었습니다. 1970년대 말에서 80년대초 근로자 평균 임금을 생각한다면 두 제품 모두 쉽게 구매하기 어려운 제품이었죠. 그 중에서도 메모리는 엄청난 가격을 자랑했습니다.
PC, 즉 퍼스널컴퓨터와 게임기는 일반 소비자들을 위한 제품이기에 제조비용을 줄여야 했고 그 만큼의 부품 또한 줄여야 했고 한정적인 환경과 화면 상에 보여질 텍스트와 그래픽을 표현할 수 있도록 2진수의 조합을 만들어냈습니다. 그 중 하나가 2진수의 7자리 조합 (128가지)을 이용한 ASCII입니다.
[ ASCII 2진수 (바이너리) 챠트 ]
예를 들어 소문자 ‘a’의 코드는 11000001, 대문자 ‘A’의 코드는 10000001 이렇게 표기하기로 약속한 것입니다. 이처럼 컴퓨터 화면에 출력되는 가장 기본적인 요소인 텍스트를 표시하기 위해 정의된 ASCII 및 ANSI 가 2진법의 8승으로 만들어졌으니, 2진수의 8자리 사용은 곧 8Bit라는 단위를 만들게 됩니다.
대중들에게 가장 많이 보급된 8Bit 컴퓨터는 1Hz, 즉 한번에 2의 8승 크기의 정보(256가지 조합)를 처리할 수 있는 능력을 가지게 되었지요. 그에 따라 임시 저장되고 빠르게 데이터를 사용하기 위한 공간, 메모리의 용량 또한 2의 거듭 제곱에 맞춰 생산되었습니다.
[ 메모리의 용량과 그에 따른 바이너리 조합수 ]
이를 통해 시중에 판매되고 있는 메모리의 용량을 보시면 8, 16, 32, 64기가 규격으로 되어있다는 것을 알 수 있습니다.
본론
색상과 비트Bit에 대한 이해
2진법의 조합으로 문자를 저장 및 표현할 수 있으니, 색상 또한 같은 방법으로 표현할 수 있습니다. 단일 비트, 즉 1비트면 0과 1만 있게 됩니다. 0을 블랙, 1을 화이트로 지정해 흑백 표현이 가능하게 되는데, 이를 1비트 컬러라고 합니다.
숫자를 올려보죠.
2^2 (2비트 컬러 팔레트)는 4이므로 4개의 컬러를 사용합니다. 앞서 정의된 Black, White에 Cyan과 Magenta 컬러가 포함됩니다. 반드시 Cyan과 Magenta 컬러가 적용되는 건 아닙니다. 다른 색상을 팔레트에 저장하고 사용자가 필요할 때 색상 팔레트를 교체하는 방식으로 사용되었습니다.
2^3 (3비트 컬러 팔레트)는 8개의 색상 팔레트로, 앞서 정의된 4개 색상에 더해 Red, Green, Blue, 그리고 Yellow가 더해졌습니다. 3비트 컬러를 적용한 기기는 그리 많지 않았어요.
2^4 (4비트 컬러 팔레트)에 이르러 16개의 색상들이 포함돼 그제서야 이미지의 기본 색상을 표현하기 시작했습니다.
2^8 (8비트 컬러 팔레트), 즉 2의 8승이므로 256개의 색상입니다. 90년대부터 2000년대 초기까지 널리 적용된 컬러 범위였으며 우리에게 친숙한 게임 ‘스타 크래프트1’이 256가지 색상 만으로 품질 좋은 게임 화면을 그릴 수 있었지요.
현재는 어떨까요?
흔히 16만 컬러, 혹은 True Color라 불리는 색상 팔레트는 Red, Green, Blue 각 채널을 8비트 팔레트로 만든 뒤, 이들을 곱해 16만 색상을 표현할 수 있게 되었습니다. 8비트 채널이 3개가 있으니, 24비트 컬러라고 하지요.
일부 그래픽 카드의 경우 채널 당 10비트 컬러, R,G,B 모두 합하여 30비트 색상을 만들 수 있는 기능을 지원하는 경우도 있으며, 그 이상 컬러를 표현할 수도 있지만 이 경우 가격이 높아져 전문 분야에 사용되는 기기라고 할 수 있겠습니다.
그렇다면 투명 이미지는 어떨까요? 앞서 알아본 24비트 색상에 8비트 투명 채널 (256 단계)이 더해지므로, 32비트 컬러라고 불립니다.
이미지 용량 계산법 및 메모리에 저장되는 크기, 그리고 POT을 적용해야 하는 이유
비트의 수로 색상이 표현되는 과정을 알아봤으니, 이미지가 메모리에 저장되는 방법을 살펴봅시다. 이미지 파일의 용량 계산법은 그리 어렵지 않아요.
[ 일반적인 이미지 파일 용량 계산법 ]
* 위 계산법은 Jpeg이나 PNG와 같은 압축된 포맷이 아닌, 무압축 BMP파일에만 해당된다는 점 참고 바랍니다.
예를 들어, 투명도(Alpha)가 적용된 True 컬러 (Red, Green, Blue)의 32 x 32 픽셀 이미지의 경우, 32 x 32 x 4 (R, G, B, A) = 4,096 byte = 2^12와 같습니다.
예시에 사용된 이미지의 가로 / 세로의 픽셀 크기가 2의 거듭제곱 형식을 따르는 것을 볼 수 있습니다.
이를 메모리에 저장한다면, 2의 거듭제곱에 규격화된 비디오 메모리 크기에 딱 알맞게 저장됩니다. 이미지 프로그램에 따라 차이가 있으며, 특히 게임 엔진에서 사용 시 파일의 용량과 이에 따른 필요 메모리의 크기 또한 달라지게 됩니다. 참고만 해두세요.
실제 파일을 가지고 예를 들어보겠습니다.
가로, 세로 각 180픽셀 크기인 이미지를 유니티에 import 할 경우, 128픽셀로 자동 변경된 것을 확인할 수 있습니다. 이는 유니티의 이미지 설정 중 Non-Power of 2 설정이 ToNearest가 기본으로 되어 있기 때문입니다. 다시 말해 2의 거듭제곱 근처 값으로 자동 변경됩니다.
180픽셀은 128(2^7)픽셀과 256(2^8) 중 128픽셀에 더 가깝기 때문에 근처 값으로 자동 변경되었다고 이해하시면 됩니다. 그렇다면 200 x 200픽셀 이미지는 어떻게 될까요?
256 x 256 (2^8) 픽셀 이미지로 변경된 것을 볼 수 있습니다. 이때 2의 거듭제곱 자동 변경 기능을 쓰지 않고 원래의 해상도를 사용하면 어떻게 될까요?
확연히 드러나는 것은 파일 크기입니다. (저 수치는 빌드 시 적용됩니다)
그렇게 원래의 실제 파일과 크기를 비교를 하면 원본 파일에 비해 대략 4배 늘어났습니다.
256px로 자동변환 되었을(42K) 때 보다 확연히 높다는 것을 알 수 있지요. 이렇듯 게임 엔진 및 실시간 그래픽 라이브러리 사용 시 2의 거듭제곱 픽셀 크기를 가진 이미지들이 더 효율적임을 알 수 있습니다.
게임엔진에서 POT 텍스쳐를 권장하거나, 사용되어야 하는 이유는 여러가지가 있지만, 아래와 같이 몇 개의 사례를 통해 알아보겠습니다.
[ Unity 에서 제공하는 이미지 압축 옵션들 ]
1. 모바일의 경우 최적화 된 이미지 압축 기술은 크게 2가지가 사용되는데, 하나는 ASTC 이며, 나머지 하나는 ETC 포맷입니다. 이들 압축 포맷은 텍스쳐의 해상도가 반드시 POT 단위여야 제대로 지원됩니다.
2. 게임 카메라에서 멀어질 수록 텍스쳐의 해상도를 단계적으로 떨어뜨려 렌더링 최적화에 도움이 되는 ‘MIPMAP’은 텍스쳐가 POT 해상도를 따를 때 극도의 효율로 동작합니다.
3. 컴퓨터 그래픽스 라이브러리인 OpenGL에서 NPOT을 지원하는 버전은 2.0 (2004년) 이었으나, 그 당시 까지 몇몇 그래픽 카드는 POT이외 사이즈 이미지를 사용하면 밉맵을 사용할 수 없다거나, 심지어는 그래픽카드를 통해 렌더링되지 않고 오로지 소프트웨어 (CPU)를 통해 렌더링 되었습니다. 당연히 시각적인 오류와 성능 저하를 일으켰지요.
결론
" 텍스쳐 이미지의 적절한 압축 설정으로 빌드 용량 감소 및 메모리 사용률을 줄이자! "
POT 텍스쳐의 개념은 게임 또는 실시간 그래픽 구현을 위한 최적화의 산물 중 하나 입니다.성능이 한정된 기기에서 보다 현실적이고 아름다운 연출을 위해 수학과 물리학, 그리고 그 외 여러가지 분야가 합쳐진 결과이죠.
급속도로 상승한 하드웨어 사양 덕분에, 실시간 그래픽은 영상과 같은 프리(pre) 렌더링 그래픽과 견줄만한 수준이 되었습니다. 게임 플레이 중간 이벤트 씬을 영상으로 썼던 2000년대와는 달리, 지금은 모든 상황을 실시간 그래픽으로 보여주고 있죠.
게임 그래픽 에셋 제작 역시 예전에 비해 비용이 높아진 만큼, 영화 제작에 필적한 장비를 사용하는 사례가 높은데요, 그럼에도 불구하고 POT 텍스쳐의 사용은 변하지 않고 있습니다. 소프트웨어와 하드웨어 모두 POT 형식에 맞춰 개발되어 온 이래, 실시간 그래픽의 최적 구동에 있어 무시할 수 없는 ‘약속’이 된 셈이죠.
높아진 실시간 그래픽의 퀄리티를 요구하는 성능 또한 높아졌지만, 그 요구치가 ‘제한적이다’라는 것 또한 옛날이나 지금이나 다를 바가 없습니다. 많은 것들이 바뀌었음에도 불구하고, 원리적인 방법은 그대로 남아있는 것을 볼 수 있습니다.
POT의 적용은 크게 어렵지 않으며, 작업물의 최종 출력(export) 시에만 신경 쓰면 됩니다.
POT단위로 제작된 텍스쳐는 각종 게임엔진에서 최적화 옵션 적용 시 넓은 선택을 가능케 하며, 옵션 선택에 따라 최종 빌드의 용량이 작아지는 것은 물론, 실제 구동 시 기기의 부하를 주지 않기 때문에 앱 사용자에게 큰 메리트가 될 것 입니다.
Ref.
https://forum.unity.com/threads/npot-textures.54954/
https://forum.unity.com/threads/disadvantages-of-non-power-of-two-textures.814542/
이미지 출처.
1. Youtube Channel : about game play, 이미지 해상도를 2의 거듭제곱으로 해야하는 이유 中
2. 애플 2 컴퓨터 이미지 출처 : https://ko.wikipedia.org/wiki/%EC%95%A0%ED%94%8C_II
3. 닌텐도 NES 이미지 출처 : https://en.wikipedia.org/wiki/Nintendo_Entertainment_System