Pengemasan Atlas Sprite: Padding, Pangkat Dua, dan Rembesan Warna

Mengapa atlas ada: draw call

Setiap kali GPU beralih menggambar dari satu tekstur ke tekstur lain, perpindahan itu memiliki biaya — secara konsep, "draw call" baru. Adegan dengan lima puluh sprite bertekstur masing-masing, jika digambar secara naif, dapat memerlukan lima puluh draw call terpisah meskipun setiap sprite kecil. Khusus pada perangkat seluler, overhead draw call terakumulasi cukup cepat untuk memengaruhi laju bingkai jauh sebelum GPU melakukan pekerjaan piksel yang berarti.

Atlas sprite mengatasi masalah ini dengan menempatkan banyak sprite pada satu tekstur bersama. Selama semua yang digambar dalam satu batch mengambil sampel dari tekstur yang sama, perender dapat menggabungkan penggambaran itu menjadi jauh lebih sedikit panggilan — dalam kasus terbaik, satu draw call untuk semua sprite yang berbagi atlas dan material yang sama. Inilah alasan atlas lebih penting untuk game dengan banyak sprite kecil yang sering digambar ulang (efek partikel, ikon UI, tileset) daripada beberapa gambar latar besar, ketika jumlah draw call tidak pernah menjadi hambatan.

Bin packing: menempatkan sprite dalam tekstur

Untuk sekumpulan sprite berukuran berbeda, menempatkannya dalam satu tekstur dengan sesedikit mungkin ruang terbuang merupakan versi masalah klasik masalah bin packing. Kebanyakan alat atlas menggunakan varian dari salah satu di antara dua pendekatan:

• Pengemasan baris: sprite ditempatkan dari kiri ke kanan sepanjang baris ("rak") hingga ada yang tidak muat, lalu rak baru dimulai di bawah. Sederhana dan cepat, tetapi membuang ruang ketika tinggi sprite dalam satu rak sangat beragam.
• Pengemasan maximal rectangles / guillotine: pengemas melacak area persegi panjang kosong yang tersisa setelah setiap penempatan dan memasukkan sprite baru ke ruang tersisa terbaik, sambil membagi persegi panjang. Pengepakan lebih padat, komputasi per sprite lebih banyak, dan merupakan pendekatan standar pada kebanyakan alat atlas modern (TexturePacker, Sprite Atlas Unity, pengekspor Godot) untuk jumlah sprite yang tidak sedikit.

Rotasi merupakan optimasi tambahan beberapa pengemas: memutar sprite 90 derajat dapat membuatnya muat pada sisa ruang sempit yang tidak muat tanpa rotasi. Kemasan lebih rapat tetapi menambah kompleksitas saat render (koordinat UV harus memperhitungkan rotasi), sehingga biasanya opsi yang diaktifkan sendiri, bukan bawaan.

Anda tidak perlu menerapkan sendiri semua ini — alat engine dan pengemas khusus menanganinya. Yang perlu dipahami adalah kepadatan kemasan dan ruang tambahan yang dibahas berikutnya saling bertentangan: kemasan rapat mengurangi ruang tekstur terbuang, tetapi ruang antarsprite mencegah perembesan berikut, sehingga pengemas terlalu agresif dapat mengembalikan bug visual demi menghemat beberapa persen area tekstur.

Perembesan tekstur: pengertian dan penyebab

Perembesan tekstur terjadi ketika tepi sprite yang dirender menampilkan sedikit warna dari sprite di sebelahnya dalam atlas — garis tipis berwarna pada satu atau lebih sisi yang tidak berkaitan dengan gambar sprite sendiri. Ini salah satu bug khusus atlas paling umum, dan memiliki dua penyebab terpisah yang sering tertukar.

Perembesan akibat filter. Ketika sprite digambar pada skala selain 1:1, atau kamera memindahkannya ke posisi yang tidak sejajar piksel, filter tekstur GPU mengambil sampel dari lingkungan kecil teksel di sekitar setiap titik sampel, bukan hanya satu yang terdekat — meskipun filter point/nearest ditetapkan pada tingkat tekstur, penyaringan dan mipmapping pada tahap sampling tetap dapat menjangkau sedikit di luar persegi panjang UV sprite. Jika area atlas yang bersebelahan berisi sprite berbeda, warna tetangganya merembes masuk.

Perembesan mipmap. Mipmap adalah versi tekstur penuh yang diperkecil sebelumnya, digunakan ketika sprite dirender kecil di layar. Pembuatan mipmap mencampur blok tekstur resolusi penuh, sehingga warna satu sprite dapat bercampur ke tingkat mip sprite tetangga bahkan sebelum sprite individual digambar. Itulah alasan perembesan terkadang hanya muncul dari jauh atau pada skala kecil, tetapi tampak baik saat diperbesar.

Kedua penyebab berasal dari kondisi dasar yang sama: dua sprite yang tidak terkait berada tepat berdampingan dalam atlas, tanpa apa pun di antaranya untuk menyerap kesalahan pengambilan sampel.

Mengatasi perembesan: ruang tambahan dan ekstrusi

Solusi standar adalah padding — menyisakan celah beberapa piksel transparan (atau piksel duplikat tepi) di antara setiap sprite dalam atlas, sehingga sampling yang meleset jatuh di celah, bukan konten sprite tetangga. Padding satu hingga dua piksel cukup untuk kebanyakan kasus pada resolusi asli; jika sprite diperbesar signifikan saat rendering atau mipmap aktif, padding lebih banyak memberi toleransi kesalahan lebih besar.

Ruang transparan biasa mengatasi kebocoran sprite tetangga tetapi menimbulkan masalah kecil sendiri: tepat pada tepi sprite, filter kini dapat mencampur warna tepi sprite dengan ruang transparan, menghasilkan penggelapan atau pinggiran samar tepat pada batas, bukan tepian sepenuhnya bersih. Ekstrusi (terkadang disebut edge extend) mengatasinya dengan mengisi ruang tambahan menggunakan salinan piksel tepi sprite itu sendiri, yang diperluas ke luar, bukan membiarkannya transparan. Masalah sprite tetangga diselesaikan dengan cara yang sama — tetap ada celah antarsprite yang berbeda — tetapi batas sprite menyatu dengan pikselnya sendiri, bukan dengan area transparan yang kosong.

Kebanyakan alat atlas (TexturePacker, pengemas Sprite Atlas Unity, ekspor atlas Godot) langsung menyediakan ukuran ruang tambahan dan tombol ekstrusi dalam pengaturan. Jarang ada alasan membiarkan ruang tambahan nol; biaya ruang tekstur satu atau dua piksel per tepi sprite kecil dibandingkan biaya menelusuri artefak sambungan sesekali yang hanya muncul pada tingkat zoom tertentu.

Apakah ukuran pangkat dua masih penting?

Dahulu GPU mengharuskan dimensi tekstur berupa pangkat dua (256, 512, 1024, 2048…) untuk mendukung mipmap dan mode wrapping tertentu secara efisien, dan tekstur bukan pangkat dua gagal sepenuhnya atau menggunakan jalur render lebih lambat. GPU dan API modern (OpenGL ES 3+, Metal, Vulkan, DirectX 11+) mendukung tekstur bukan pangkat dua secara native tanpa penalti kinerja berarti untuk render 2D dasar, sehingga persyaratan ketat itu sebagian besar hilang pada perangkat generasi sekarang.

Masih penting dalam situasi tertentu:

• Mipmap. Beberapa platform dan API lama masih memerlukan dimensi pangkat dua untuk membuat rantai mip lengkap dengan bersih. Jika atlas menggunakan mipmap, periksa batas sebenarnya platform target, bukan berasumsi.
• Perangkat keras lama atau terbatas. Perangkat seluler kelas rendah, konteks WebGL 1, dan beberapa perangkat tertanam masih diuntungkan atau memerlukan ukuran pangkat dua.
• Penyelarasan memori dan format kompresi. Format kompresi blok (banyak digunakan di perangkat seluler) memampatkan dalam blok berukuran tetap dan terkadang menambahkan ruang pada dimensi yang tidak sesuai hingga ukuran valid berikutnya, sehingga memilih ukuran pangkat dua sejak awal menghindari penambahan tersembunyi yang menghabiskan memori tanpa manfaat.

Secara praktis: jika menargetkan desktop terkini, konsol, atau perangkat seluler modern dengan alur 2D standar, dimensi atlas bukan pangkat dua baik-baik saja. Jika menargetkan WebGL 1, perangkat seluler lama, atau perangkat tertanam, pangkat dua masih bawaan lebih aman dan murah — kebanyakan pengemas otomatis membulatkan ukuran atlas ke pangkat dua berikutnya ketika pengaturan aktif.

Pemangkasan dan pivot

Pemangkasan berarti pengemas memangkas setiap sprite hingga konten opaknya sebelum ditempatkan dalam atlas, membuang margin transparan di sekeliling. Ini hampir selalu menguntungkan kepadatan pengepakan — sprite dengan banyak padding transparan di sekitar karakter kecil menggunakan jauh lebih sedikit ruang atlas setelah dipangkas.

Masalahnya, pemangkasan mengubah ukuran efektif dan offset sprite, penting jika logika game atau animasi mengandalkan setiap bingkai berdimensi sama dan pivot sama terhadap kanvas asli. Bingkai berjalan saat karakter condong kiri memiliki batas tidak transparan berbeda dari condong kanan; dipangkas terpisah, keduanya berbeda ukuran, dan beralih secara naif menggeser posisi terlihat karakter tiap bingkai.

Setiap alat atlas yang mendukung pemangkasan juga mencatat ukuran asli sebelum pangkas dan offset bersama data pangkasan khusus untuk mengatasi ini — engine merender sprite terpangkas kembali pada posisi benar dalam batas bingkai asli, sehingga pivot tetap konsisten secara visual meskipun lebih sedikit ruang tekstur digunakan untuk piksel transparan. Ini ditangani otomatis oleh Sprite Atlas Unity dan pengimpor Godot selama pemangkasan diaktifkan melalui alat, bukan dilakukan manual sebelum sprite mencapai pengemas; memangkas sendiri sebelum mengemas membuang metadata offset yang diperlukan engine untuk menempatkannya kembali dengan benar.

Satu atlas atau beberapa?

Memasukkan semuanya ke satu mega-atlas tidak otomatis lebih baik. Beberapa alasan praktis untuk membaginya menjadi beberapa atlas:

• Data yang menetap dalam memori. Jika level hanya menggunakan sebagian sprite, memuat satu atlas per level atau adegan menghindari menyimpan data sprite yang tidak digunakan dalam memori GPU untuk konten yang tidak sedang didekati pemain.
• Batas ukuran tekstur. Perangkat keras membatasi dimensi tekstur maksimum (umumnya 4096 atau 8192 pada perangkat modern, lebih rendah pada perangkat seluler lama). Set sprite yang cukup besar tidak akan muat dalam satu atlas, apa pun efisiensi pengemasannya.
• Frekuensi pembaruan. Sprite yang sering berubah (UI yang cepat diiterasi) lebih baik berada dalam atlas sendiri terpisah dari karya stabil yang jarang disentuh, agar perubahan kecil tidak memaksa build ulang dan unggahan ulang seluruh atlas.
• Perbedaan material. Sprite yang membutuhkan shader atau mode campuran berbeda tidak dapat dibatch bersama, apa pun atlasnya, sehingga menggabungkannya tidak memberi manfaat pengemasan.

Pilihan bawaan yang masuk akal adalah mengelompokkan berdasarkan konteks penggunaan — satu atlas untuk ubin lingkungan suatu level, satu untuk karakternya, satu untuk UI — dan hanya menggabungkannya lebih lanjut jika profiling menunjukkan bahwa draw call memang menjadi hambatan pada perangkat target Anda.

Pertanyaan yang sering diajukan