Texture atlas: Malzeme ve çizim birleştirme sanatı

GPU ile konuşmak demek, her karede sınırlı bant genişliğiyle komut ve durum güncellemesi göndermektir. Aynı sahnede çok sayıda küçük nesne, her biri farklı doku bağlaması, farklı üniform / anahtar veya farklı gölgelendirici varyantı gerektirdiğinde, sürücü ve motor «her seferinde defteri baştan düzenlemek» zorunda kalır; bu da CPU tarafında ölçülebilir bir overhead üretir.

Atlas — bu metinde çözünürlük alanı paylaşımı anlamında — küçük dokuları tek büyük örnekte topladığı için, aynı materyal altında binlerce üçgeni gezseniz bile texture bind sayısını aşağı çekme şansı verir. Kritik nokta şudur: kazanç «dosyayı birleştirmekten» değil, çizim sürecinin aynı doku ve aynı malzeme sözleşmesini tekrar tekrar kurmaktan kurtulmaktan gelir.

Neden state change bu kadar ses çıkarır?

Pratikte maliyet sadece «doku dosyası sayısı» değildir: sarıcı (wrap modu), filtre, mipmap zinciri, anisotropy, karşılaştırma (compare mode) ve kanal maskeleri gibi ayarlar, bir malzemenin kimliğini oluşturur. Bu kimlik sahnede sürekli değişiyorsa, Three.js bile çizilebilir nesneleri sıralasa (sort) bile arka planda yine sık sık bağlama ödeme çıkar. Atlas, aynı materyal tanımını uzun süre geçerli tutmanızı kolaylaştırır.

Öğretim amaçlı kıyas (bilinçli sadeleştirme)

Aşağıdaki tablo tanıtım amaçlıdır; gerçek projede bağlam değişir:

• Texture atlas olmadan: on küçük obje, on ayrı doku veya on farklı malzeme kimliği → kamera dönse bile aynı karede yüzlerce küçük geçiş birikir; profil ekranında GPU timeline’da «ince tırtıl» gibi çok sayıda dar çubuk görürsünüz.
• Texture atlas ile: aynı on obje, aynı atlası paylaşan bir veya birkaç materyal → bağlama ve sözleşme yenileme sıklığı düşer; animasyonlu veya parçacıklı sahnelerde CPU süresi ölçülebilir şekilde nefes alır.

Bu arada «her zaman tek draw call» vaadi gerçek dünyada nadiren böyledir: şeffaflık sıralaması, derinlik öncesi geçişler, çok geçişli (multi-pass) malzemeler ve özel shader dalları hâlâ sizi bölebilir. Atlas, üst sınırı indirmek için bir araçtır; sihirli sayı üretmez.

Aşağıdaki panel gerçek zamanlı Three.js sayacı değildir; aynı sahne düzeninde atlas kapalı / açık ve (atlas kapalıyken) instancing seçeneklerinin çizim ve durum yükünü sayıyla hissettirmek için yuvarlatılmış bir modeldir. Kaydırıcıyı oynatıp kıyaslayın.

Her şeyi tek bir dev atlasa tıkıştırmak nadiren sürdürülebilir olur: bir ekip üyesi tek satır rengi değiştirdiğinde tüm levhanın yeniden üretilmesi, diff’lerin şişmesi ve sürüm çakışmaları başlar. Bu yüzden soru «atlas mı, değil mi?» değil; hangi ölçekte ve hangi yaşam döngüsüyle böleceğinizdir.

Yüksek getiri senaryoları

• Çok sayıda küçük obje (prop yoğunluğu): Bir masanın üzerindeki kalemler, kitaplar, bardaklar ve anahtarlar gibi parçalar genelde aynı kamera mesafesinde, aynı ışık ailesinde kalır. Her biri için ayrı doku ve malzeme açmak, draw sırasını sürekli kırar. Bu tür «tıka basa» sahnelerde atlas, görsel bütünlüğü korurken bağlam sayısını düşürmenin en eski ve en güvenilir yollarından biridir.
• UI ve HUD: İkonlar, buton durumları, çerçeve köşeleri ve ince çizgiler 2D arayüzde onlarca küçük parçaya bölünür. Bunları tek bir sprite sheet altında toplamak yalnızca WebGL için değil, tasarım–geliştirici işbirliği için de standarttır: tasarımcı tek levha üzerinde revize eder, geliştirici tek materyalden beslenir.
• Tekrar eden varlıklar (kitlesel tekrar): Bir şehirdeki çöp kutuları, banklar ve sokak tabelaları aynı sanatsal dilde olduğu sürece tek «sokak detay atlası» altında toplanabilir. Burada kazanç, bellekte tek örnekle yüzlerce örneklem yapmaktır; instancing ile birleştiğinde etki katlanır.

Atlasın zayıf kaldığı yerler

Aşağıdaki durumlarda atlas yerine akışı bölmek veya akıllı yükleme düşünün:

• İçerik akışı farklı: Oyuncu bölge bölge ilerliyorsa, her bölgeye ait dev atlası baştan sona bellekte tutmak, streaming stratejinizle çelişir. Bu durumda küçük paketler veya bölgeye özel alt atlaslar daha mantıklıdır.
• Çok farklı shader dalları: Aynı dosyayı paylaşsanız bile biri clearcoat isteyip diğeri istemiyorsa, motor yine farklı malzeme yollarına ayırır; atlas tek başına yetmez.
• Çözünürlük ihtiyacı uçurumdadır: Aynı levha içinde hem 4K yakın plan hem 256 uzak doku barındırmak, ya boşa çıkan pikseller ya da gereksiz büyük blok demektir. Bu noktada doku optimizasyonu sayfasındaki «ölçek ve mesafe» tartışması ile birlikte okuyun.

Atlas kullanmanın bir mühendislik bedeli vardır; bu bedel yalnızca sanatçıya değil, CI, sürümleme ve QA süreçlerine de yayılır. Aşağıdaki üç başlık, HoloDepth projelerinde en sık «sahada patlayan» konulardır.

UV ve paketleme disiplini

Her alt doku, atlas levhasında bir ada gibi düşünülmelidir. Koordinatları büyük görselin doğru köşelerine (ör. 0.25–0.50 aralığı) kilitlemek, elle yapıldığında hata toleransı düşüktür. Bu yüzden ekipler genelde Blender, Maya veya özel paketleyicilerde UV packing adımını ihracattan önce sabitler; aksi halde animasyonlu morph veya ikinci bir UV kanalı gerektiğinde atlas yeniden üretmek zorunda kalırsınız.

Örtüşme (overlap) ve ada sınırları için model tarafındaki ayrıntılı çerçeveyi UV mapping · örtüşme ve atlas ile tamamlayın; burada yalnızca «atlas yapınca zorlaşır» mesajını taşıyoruz.

VRAM ve çözünürlük: tek blok tuzakları

Atlas çok büyüdüğünde (ör. 8192×8192), bellek tarafında tek dev örnek gibi davranır. Sahnede yalnızca bir anahtarlık görünür olsa bile, sürücü çoğu akışta tüm levhanın bağlanmasını gerektirir; bu da mobil ve düşük bellekli cihazlarda ani düşüşlere yol açar. Çözüm, «daha sıkıştır»dan önce mantıksal bölmedir: mutfak, ofis ve dış mekân gibi yaşam döngüsü farklı setleri ayrı dosyalarda tutun. Disk / VRAM dengesinin sayısal sezgisi için doku formatları · disk vs VRAM bölümündeki modeli hatırlayın.

Mipmap sızıntısı ve padding

Mipmap zinciri, her seviyede texelleri ortaladığı için komşu ada renkleri içeri taşınabilir; bu «bleeding» etkisidir. Uzak kamera veya düşük çözünürlükte, ince çizgili UI öğelerinde ilk fark edilen artefakt genelde budur.

• Padding: Ada çevresine birkaç texel genişliğinde boşluk bırakın; gerektiğinde yarı saydam kenarları atlas dışına taşıyın.
• Kenar klonlama: Bazı DCC araçları dış kenarlara komşu rengi kopyalayarak süzülmeyi yumuşatır; otomasyona güvenmeden önce uzak LOD’da gözle kontrol şart.
• Atlas dışı tekrar: Dünya uzayı boyunca sonsuz tekrar gerekiyorsa, atlas içi UV yerine tiling doku kullanmak hâlâ daha ucuz olabilir — iki tekniği birbirinin yerine koymayın.

Aşağıdaki liste, HoloDepth tarzı projelerde atlası «tek seferlik sanat eseri» olmaktan çıkarıp ölçülebilir üretim hattı haline getirmek içindir. Uygulama ayrıntıları (KTX2 kodlama, transcode, cihaz profili) için KTX2 nedir? omurgasını ayrı tutuyoruz; burada yalnızca atlas düzeninin o hattaki yeri vardır.

Mantıksal gruplama ve dosya sözleşmesi

• Sahne önceliği: Aynı kamera mesafesi ve aydınlatma ailesinde kalan objeleri tek atlasa toplayın; örnek ad: Mutfak_esyalari_Atlas.ktx2. İsim, hem sanatçıya hem otomasyona «bu paket hangi bölümün belleği?» sorusunun cevabıdır.
• Sürüm çizgisi: Atlası tek dosyada tuttuğunuz sürece, küçük bir rota değişikliği bile tüm levhanın yeniden yayınlanmasını gerektirir. Bu yüzden HoloDepth ekipleri genelde alt atlas + manifest yaklaşımını benimser: manifest, hangi bölgelerin hangi material kimliğine bağlandığını makine okunur biçimde taşır.

Kanal paketleme (tek örnek, çok anlam)

Metalik ve pürüzlülük (roughness) gibi düşük renk hassasiyetli haritalar, tek atlasın R / G / B kanallarına gömülebilir; böylece örnek sayısı ve yüklenen dosya sayısı birlikte düşer. Dikkat: kanal birleştirme, linear / sRGB ayrımını göz ardı ederseniz parlaklık ve pürüzlülük birbirine bulaşır — dışa aktarım şablonunuzda renk uzayı etiketlerini sabitleyin.

2n çözünürlük ve kontrol listesi

Atlas toplam boyutunu 1024×1024, 2048×2048 gibi WebGL dostu kenarlara yakın tutmak, mipmap ve donanım hizalaması açısından hâlâ en az sürtünmeli yoldur; gerekçe için doku formatları · çözünürlük disiplini ile hizalanın.

• Üst sınır rozeti: Her atlas için hedeflenen maksimum kenar uzunluğunu (ör. masaüstü 4096, mobil 2048) depo README’sinde yazın; CI betiği aşanları reddetsin.
• Uzak kamera testi: Yayına çıkmadan önce sahneyi düşük çözünürlükte bir kez daha açın; mip bleeding ve alpha saçılması burada yakalanır.
• Ölçüm: Atlas öncesi / sonrası aynı kamera yolunda kare süresini kaydedin; yalnızca hisle değil, kısa bir tabloyla karar verin.

Texture atlas kullandığınızda Three.js tarafında tipik olarak tek bir MeshStandardMaterial (veya seçtiğiniz tek materyal sınıfı) oluşturur, yüzlerce Mesh’e aynı materyali atarsınız; motor bunları aynı «malzeme ailesi» altında gruplamaya daha yakın görür. Bu modelleri ileride geometri birleştirme (merge / batching) ile birleştirirseniz performans kazancı üst üste binebilir — detay için Buffer birleştirme dizisine bakın.