KTX2 encode süreci: Doku hazırlama rehberi

Bir görseli KTX2'ye dönüştürürken tipik süreç şu sırayı izler. Buradaki sıra, araçların çoğunda «gizli varsayılanlar» olsa bile zihinsel modelinizin aynı kalmasını sağlar: önce ne sıkıştırıyorsunuz, sonra nasıl bloklanıyor, ardından hangi Basis yolu ve en sonda hangi ölçek seviyeleri pakete giriyor.

1. Analiz: Görselin türü belirlenir. Renk bilgisi mi (diffuse / albedo) yoksa matematiksel veri mi (normal, roughness, metallic vb.) içeriyor? Bu ayrım, sıradaki mod ve kalite seçimini doğrudan etkiler. Pratikte aynı «görsel dosyası» etiketi altında sRGB renk haritası ile doğrusal (linear) veri kanalları birbirine karıştığında en pahalı hatalar çıkar; üretim hattında kanal başına etiketlemek (veya glTF'teki renk uzayı metadata'sına güvenmek) encode öncesi zorunluluk sayılmalıdır.
2. Bloklama: Görsel, GPU'nun verimli okuyabileceği 4×4 piksellik bloklara ayrılır; hedef formatlar bu blok düzenine göre tanımlıdır. Bu adım sizin için çoğu zaman soyuttur, fakat «neden kenarlar titriyor?» sorusunun cevabı çoğu kez blok sınırları ve sıkıştırma artefaktlarıyla ilişkilidir — özellikle ince çizgi ve yüksek frekanslı normal haritalarında.
3. Basis Universal seçimi: Önceki derslerde işlenen ETC1S (maksimum sıkıştırma) veya UASTC (maksimum kalite) modlarından biri seçilir. Kural pratikte şuna yaklaşır: gözün «hatayı affetmediği» kanallar (normal, ORM paketli yüzey verisi) için UASTC; geniş alanlı renk için ETC1S — yine de sahneye göre doğrulama şart. Ayrımın özeti için ETC1S / UASTC bölümüne bakın.
4. Mipmap üretimi: KTX2 dosyası içine «mipmap» adı verilen, görselin daha düşük çözünürlüklü kopyaları gömülür. Model uzaktayken GPU, daha küçük bir doku seviyesi kullanarak hem bellek bant genişliği baskısını azaltır hem de örnekleme hatalarını yumuşatır. Bu adımı atlamak, aşağıdaki HoloDepth notunda ayrıntılandığı gibi, yalnızca «bulanık görüntü» değil — gereksiz yüksek çözünürlük örneklemesi ve aliasing riski demektir.

Bu dörtlü, tek bir doku dosyası için yeterlidir. glTF materyalinde onlarca kanal varsa iş, aynı dörtlünün kanal listesine uygulanması ve çıktıların isimlendirme / sürümleme kurallarıyla paketlenmesine döner — otomasyon (ör. CI betiği veya dışa aktarma şablonu) burada değer kazanır.

Bu sayfa için harici GLB model şart değildir; metin akışı tek başına yeterlidir. Aşağıdaki sahnede yalnızca dokulu bir düzlem vardır — amaç, uzaklaştıkça gözlemlenen mipmap etkisini ve iki Basis modunun öğretici ayrımını parmak basmadan hissettirmektir; düzlem ayrıca çok hafif salınır ki mipmap farkı çoğu zaman dokunmadan da seçilebilsin. Gerçek .ktx2 encoder / Basis WASM kullanılmaz; tam pipeline simülasyonu
transcoding labnda anlatılır. İşletim sistemi «hareketi azalt» tercihini açtıysanız salın ve yavaş dönüş kapanır; farkı yine fare ile uzaklaştırarak görebilirsiniz.

Dönüştürme için sektörde yaygınlaşmış birkaç temel araç bulunur; hepsi aynı fikri paylaşır: üretimde tekrarlanabilir komutlar ve kontrol edilebilen parametreler. Seçim genelde «tek doku mu, tüm glTF paketi mi?» ve «bu makinede hangi sürüm kurulu?» sorularına göre yapılır — aşağıdaki başlıklar rol ayrımı içindir, birbirini dışlamaz.

toktx (Khronos Group)

Khronos Group'un resmi CLI aracıdır; en düşük seviyede tam kontrol sağlar. Avantajı: kalite, mipmap seviyesi ve hedef tür gibi parametreleri elle yönetebilirsiniz. Tek dokuyu veya toplu işlem betiğini aynı arayüzle beslemek, CI için uygundur. Tam bayrak seti kurulumunuza ve KTX-Software sürümünüze göre değişebilir; üretim öncesi toktx --help çıktısı ile proje dokümantasyonunuzu eşleştirmeniz iyi pratik sayılır.

toktx --genmipmap --target_type etc1s output.ktx2 input.png

Örnek, ETC1S hedefi ve mipmap üretimini vurgular; farklı giriş biçimleri veya şeffaflık kanalı için ek bayraklar gerekebilir.

KTX-Software (GUI & CLI)

Khronos'un sağladığı geniş kapsamlı yazılım paketidir; hem görsel arayüz hem terminal araçlarını içerir. toktx gibi bileşenler genelde bu paketin parçasıdır. «Tek seferlik deneme» ile «her build'de aynı komut» arasında köprü kurmak isteyen ekipler için iyi bir başlangıç noktasıdır: önce GUI ile parametreleri keşfedip, sonra aynı ayarları betiğe taşırsınız.

glTF-Transform (geliştirici dostu)

Özellikle glTF modelleriyle çalışanlar için güçlü bir seçenektir; modeli ve içindeki dokuları tek komutla KTX2'ye gömebilirsiniz. Ağaç düzeyinde optimizasyon (resize, gereksiz dokuları düşürme, dedup) ile birlikte kullanıldığında encode adımı, sahne genelinde öngörülebilir kazanımlar verir. Yerelde genelde npx @gltf-transform/cli ön eki ile çağrıldığını göreceksiniz; aşağıdaki satır, fikir vermesi için sadeleştirilmiştir.

gltf-transform uastc input.glb output.glb --level 4

Bu örnek, modeldeki dokuları UASTC formatında KTX2 ile paketlemeye yöneliktir; proje politikasına göre ETC1S veya kanal bazlı komutlar da tercih edilebilir. Tüm kanalları aynı moda zorlamak yerine, yukarıdaki analiz adımıyla eşleştirmek genelde daha sağlıklıdır.

PlayCanvas / Gestaltor

Web tabanlı veya görsel arayüzlü araçları tercih edenler için, sürükle-bırak ile KTX2 dönüşümü yapılabilen editörlerdir; hızlı iterasyon ve ekip içi görsel geri bildirim için uygundurlar. Üretim hattının «nihai» adımı olarak değil, tasarım ve onay aşamasında hız kazanmak için düşünün; sürüm ve bayrakların tekrarlanabilir olduğu ortamda CLI hâlâ altın standarttır.

Sağlıklı bir 3D geliştirme hattında KTX2 dönüşümü çoğu zaman dışa aktarma (export) aşamasında otomatize edilir. Amaç, tasarımcının ürettiği «yüksek doğruluklu kaynak» ile oyuncunun indirdiği «küçük teslimat» arasındaki boşluğu, her build'de aynı kurallarla kapatmaktır. İdeal akış kabaca şöyledir:

1. Design: Doku, Photoshop veya Substance Painter gibi araçlarda 2K / 4K PNG (veya ekip standardınız ne ise) olarak hazırlanır. Bu aşamada çözünürlük ve dosya adlandırma kurallarını netleştirmek, sonraki otomasyonun ön koşuludur.
2. Sıkıştırma kararı: Renk dokuları (albedo) için çoğu senaryoda ETC1S (boyutu küçültmek için); yüzey dokuları (normal / metallic vb.) için veri kaybını sınırlamak adına UASTC düşünülür. Karar tek satırlık bir tabloya dökülebilir; önemli olan, kararın kodda veya betikte tekrarlanabilir olmasıdır.
3. Encoding: Seçilen araç (örneğin toktx) ile KTX2 dosyası üretilir; mipmap zinciri bu adımda dosyaya gömülür. Çıktıların sürüm kontrolünde izlenebilir olması (hash veya yapılandırma dosyası) regresyonları erken yakalar.
4. Entegrasyon: Oluşan .ktx2 veya dokuları gömülü .glb dosyası Three.js / Babylon.js projelerine dahil edilir. Buradan sonra sahne tarafında doku boyutu, filtreleme ve bellek profili devreye girer; özet için GPU doku optimizasyonu sayfasına geçmek doğal devamdır.

Bu hattı «sadece sanatçı çıktısı» olarak bırakmak yerine, mühendislik tarafında küçük bir doğrulama adımı eklemek (ör. referans sahne yükleme süresi, paket boyutu üst sınırı) encode kalitesini sübjektif yorumlardan çıkarır.