Tekstur: Penyerap VRAM Terbesar yang Kerap Terabaikan

Pada artikel sebelumnya, kita telah memangkas jumlah vertex dan memperkecil ukuran geometri model. Namun beban terbesar file 3D masih tersisa: tekstur gambar. Pada model PBR standar, tekstur menyumbang lebih dari 80% ukuran file dan menjadi komponen yang paling rakus memori ketika dimuat ke dalam VRAM GPU.

Artikel ini membahas tuntas solusi atas pembengkakan VRAM tersebut: mengapa format PNG/JPG memiliki kelemahan mendasar bagi GPU, bagaimana format tekstur asli GPU bekerja, dan bagaimana integrasi Basis Universal + KTX2 menjadi jembatan solusi modern di web.

Mengapa File JPG Menyebabkan VRAM Membengkak?

Mari kita ingat kembali formula perhitungan memori VRAM:

Konsumsi VRAM = Lebar × Tinggi × 4 byte (RGBA) × 1.333 (dengan mipmaps)

Tekstur berukuran 4096×4096 piksel (baik berupa JPG 1.5MB maupun PNG 8MB di disk) akan memakan sekitar 87MB begitu dimuat ke dalam VRAM. Alasannya sangat sederhana: GPU tidak mengenali algoritma kompresi JPG atau PNG.

Unit sampler tekstur pada GPU dirancang untuk membaca data warna dari blok piksel berukuran tetap. GPU mengharuskan tekstur berada dalam VRAM sebagai "piksel mentah tanpa kompresi". Oleh karena itu, sebelum browser mengirim JPG ke GPU, CPU harus mengekstrak gambar tersebut secara penuh menjadi larik piksel RGBA, lalu mengunggah seluruh data mentah itu ke VRAM.

Proses ini menimbulkan 3 hambatan besar:

1. Lonjakan VRAM: Piksel mentah memakan ruang memori yang sangat masif (87MB per tekstur 4K).
2. Stall Pengunggahan: Memindahkan data piksel raksasa dari memori CPU ke VRAM GPU memakan waktu dan menunda kemunculan frame pertama.
3. Beban Komputasi CPU: Dekompresi gambar beresolusi tinggi menguras daya prosesor, terutama pada ponsel pintar.

Ibarat spons kering yang ditekan: PNG dan JPG sangat praktis saat dikirim melalui jaringan, namun langsung menyerap air dan mengembang maksimal begitu tiba di GPU, tanpa memberikan penghematan VRAM sedikit pun.

Format Tekstur Asli GPU (GPU-Native Formats)

Karena GPU menolak kompresi PNG di VRAM, solusinya adalah mempertahankan tekstur dalam kondisi tetap terkompresi di dalam VRAM, di mana hardware GPU mendekode blok piksel secara instan hanya saat proses sampling berlangsung.

Inilah prinsip kerja format tekstur asli GPU:

Keluarga Format	Nama Lengkap	Platform Utama	Karakteristik Teknis
BC1-7	Block Compression	Komputer Desktop (Windows & Mac)	Standar industri desktop dengan kompresi blok 4×4
ETC1/2	Ericsson Texture Compression	Perangkat Mobile (Android & iOS lama)	Standar klasik perangkat seluler
ASTC	Adaptive Scalable Texture Compression	Mobile & VR modern	Fleksibilitas tinggi dengan ukuran blok yang dapat disesuaikan
PVRTC	PowerVR	Perangkat iOS lawas	Mulai digantikan sepenuhnya oleh ASTC

Semua format di atas memiliki kesamaan: tekstur dikompresi dalam blok kecil 4×4 piksel, dan hardware GPU hanya mengekstrak blok yang sedang dibaca. Hasilnya, konsumsi VRAM menyusut secara konsisten terlepas dari variasi visual gambar.

Perbandingan format tradisional dan format asli GPU:

Aspek	Format Tradisional (PNG/JPG)	Format Asli GPU
Ukuran File di Disk	Sangat Kecil (khususnya JPG)	Sedang (kompresi blok dengan bitrate tetap)
Konsumsi VRAM	Sangat Besar (piksel mentah)	Sangat Ringan (tetap terkompresi di VRAM)
Kecepatan Upload ke GPU	Lambat (dekompresi CPU + transfer besar)	Sangat Cepat (transfer langsung tanpa ekstraksi)
Kecepatan Sampling	Cepat	Cepat (didekode langsung oleh chip GPU)

Kendala Fragmentasi Antar Perangkat

Mengapa kita tidak bisa langsung menggunakan format GPU tersebut di web? Masalah utamanya adalah fragmentasi hardware:

• Komputer Desktop mendukung format BC1-7, tetapi umumnya tidak mendukung ASTC.
• Ponsel Android mendukung format ETC2 dan ASTC, tetapi tidak mendukung BC.
• Perangkat iOS modern mendukung ASTC.

Untuk mendukung semua perangkat secara native, Anda harus membuat paket tekstur terpisah untuk masing-masing platform, melipatgandakan ukuran distribusi dan beban kerja. Di web, kita tidak dapat mengetahui jenis perangkat pengguna sebelum halaman dimuat.

Basis Universal: Enkoding Sekali, Transkoding di Mana Saja

Basis Universal diciptakan untuk memecahkan masalah fragmentasi tersebut dengan pendekatan satu langkah cerdas:

Kompres tekstur ke dalam satu format perantara universal saat proses build, lalu saat runtime di browser, transkodekan data tersebut ke format GPU asli yang didukung oleh perangkat pengguna secara instan.

Alur kerja transkoding Basis Universal:

Tekstur Sumber (PNG/JPG)
      │  Enkoding offline satu kali (saat build)
      ▼
Format Perantara Basis (ETC1S atau UASTC)
      │  Dikemas dalam kontainer KTX2
      ▼
Distribusi Web ──┬── Desktop GPU ──→ Transkoding runtime instan → BC1/3/7
                 ├── Android ─────→ Transkoding runtime instan → ETC2
                 └── iOS / VR ────→ Transkoding runtime instan → ASTC

Poin penting:

• Enkoding hanya dilakukan satu kali saat tahap persiapan aset.
• Transkoding saat runtime sangat cepat (hanya membutuhkan beberapa milidetik per tekstur).
• Data yang tersimpan di VRAM adalah format GPU terkompresi asli, menghasilkan penghematan memori VRAM yang identik dengan format native.

KTX2: Kontainer Standar Industri untuk Tekstur GPU

Untuk mengemas data Basis dan menghubungkannya dengan model glTF, digunakan kontainer standar KTX2.

KTX2 bukan sekadar file gambar biasa, melainkan format kontainer resmi dari Khronos Group yang membungkus data tekstur GPU beserta metadata penting (seperti ruang warna, level mipmaps, dan informasi enkoding).

Dalam ekosistem glTF, integrasi KTX2 dilakukan melalui ekstensi standar KHR_texture_basisu.

Perbedaan antara ketiga istilah:

Nama	Peran Teknis	Analogi Sederhana
Basis Universal	Skema algoritma enkoding ke format perantara	Metode kompresi
KTX2	Format kontainer pembungkus data	Kotak kemasan
KHR_texture_basisu	Ekstensi glTF untuk mengenali data Basis	Label penanda

Uji Nyata Konsumsi VRAM: Perbandingan Tekstur 4096

Berikut perbandingan riil konsumsi VRAM pada tekstur RGBA 4096×4096:

Metode	Ukuran di Disk	Konsumsi VRAM (dengan Mipmaps)	Kecepatan Upload	Kompatibilitas
PNG	~8MB	~87MB	Lambat	Mendukung
JPG	~1.5MB	~87MB	Lambat	Mendukung
WebP	~2MB	~87MB	Lambat	Mendukung
KTX2 (ETC1S)	~2-3MB	~11-14MB	Sangat Cepat	Mendukung via transkoding
KTX2 (UASTC)	~6-8MB	~22MB	Sangat Cepat	Mendukung via transkoding

Dua kesimpulan penting:

1. Format gambar konvensional (PNG/JPG/WebP) memakan jumlah VRAM yang sama persis (~87MB); ukuran file kecil di disk tidak menghemat memori GPU sama sekali.
2. KTX2 memangkas konsumsi VRAM hingga 1/4 atau 1/8 ukuran aslinya, mencegah browser ponsel dan headset VR mengalami crash akibat kekurangan memori.

Matriks Dukungan Platform untuk Format Grafis

Platform / Lingkungan	BC1-7	ETC2	ASTC	PVRTC
Komputer Desktop (DirectX / Vulkan / WebGPU)	Mendukung	Tidak	Parsial (GPU baru)	Tidak
macOS (Metal)	Mendukung (perangkat baru)	Tidak	Mendukung	Tidak
Android	Tidak	Mendukung	Mendukung	Tidak
iOS (A8 ke atas)	Tidak	Mendukung	Mendukung	Mendukung di seri lama
WebGL 2	Bergantung ekstensi	Mendukung	Parsial	Tidak
WebGPU	Mendukung (Desktop)	Mendukung	Mendukung sesuai device	Tidak

Perbandingan Alur Pengunggahan Tekstur

Alur Tradisional PNG/JPG:

Unduh file PNG → Memori CPU → Dekompresi lambat oleh CPU → Larik piksel mentah RGBA → Upload masif ke GPU → Konsumsi 87MB VRAM

Alur Modern KTX2 + Basis:

Unduh file KTX2 → Memori CPU → Transkoding cepat runtime → Blok terkompresi GPU → Upload ringan dan cepat → Konsumsi 11MB VRAM

Alur modern meniadakan proses ekstraksi berat pada CPU dan memangkas volume data yang diunggah hingga sepuluh kali lipat, mempercepat waktu render frame pertama secara dramatis.

Langkah Selanjutnya

Setelah memahami teori arsitekturnya, artikel berikutnya akan membahas praktik langsung di lapangan: menggunakan toktx dan gltf-transform untuk mengompresi tekstur ke KTX2, memuatnya di Three.js dan Babylon.js, serta memilih antara ETC1S dan UASTC.