Texture Referansları glTF'de images / textures / samplers

Tek tabloda «doku = dosya yolu» birleştirmek cazip görünür. glTF bunu ayırır çünkü aynı görüntü birden fazla texture kaydıyla, aynı sampler birden fazla texture ile paylaşılabilir. Bellek ve export tutarlılığı için kaynak bir kez yazılır; üst katmanlar indeksle işaret eder.

Texture Referansları şunların hiçbiri değildir:

• PBR formülü değil metal/rough anlamı PBR Yapısı'nda
• GPU Texture nesnesi değil WebGL/Three.js runtime API ayrı
• UV adresi değil örnekleme koordinatı geometride
• Atlas sanatı değil packing UV Mapping / Texture Atlas dalında

Materyal «ne için kullanılacak?» der. Texture tabloları «hangi baytlar, hangi örnekleme sözleşmesi?» der. İkisi birleşince yüzey boyanır; biri diğerinin yerini tutmaz.

Okuma yönü tek yönlüdür. Materyal textureInfo.index ile textures dizisine iner; texture source ile images'a, isteğe bağlı sampler ile samplers'a bakar. Image kaydı materyali bilmez.

materials[i].pbrMetallicRoughness.baseColorTexture.index
  → textures[k]
       .source   → images[j]   // URI veya bufferView
       .sampler  → samplers[m] // isteğe bağlı
  → GPU'ya yüklenen görüntü + örnekleme durumu

"images": [
  { "uri": "albedo.png" },
  { "mimeType": "image/png", "bufferView": 4 }
],
"samplers": [
  { "magFilter": 9729, "minFilter": 9987, "wrapS": 10497, "wrapT": 10497 }
],
"textures": [
  { "source": 0, "sampler": 0 },
  { "source": 1 }
]

İkinci texture kaydında sampler yok: loader varsayılan sampler uygular (tipik olarak repeat + linear/mipmap; kesin varsayılan spec ve uygulama ile doğrulanır). Holodepth notu: «sampler yazılmadı» ≠ «filtre yok»; sessiz varsayılan vardır.

Her image kaydı görüntünün fiziksel kaynağını tanımlar. İki ana yol:

• uri harici dosya veya data URI (tipik .gltf + yanındaki PNG/JPEG)
• bufferView gömülü binary (tipik GLB veya .bin içi görüntü bloğu); genelde mimeType zorunlu/beklenen

bufferView yolu binary buffer dilim mimarisinin görüntü yüzüdür: ofset/uzunluk BufferView ile gelir; image kaydı «bu dilim bir PNG'dir» der. Geometri attribute dilimleriyle aynı tabloda durabilirler; semantic farklıdır.

mimeType

Core'da yaygın değerler image/png ve image/jpeg'dir. Yanlış mimeType veya bozulmuş baytlar loader'da decode hatasına düşer; materyal slotu «dolu» görünür, GPU'ya texture çıkmaz. Extension ile KTX2 / Basis gibi formatlar eklenebilir; core image tablosu o sözleşmeyi bilmez.

textures[k] tek başına piksel taşımaz. Zorunlu alan source (image indeksi); isteğe bağlı sampler, name. Materyalin işaret ettiği indeks budur. Aynı images[j] iki texture kaydında paylaşılabilir; farklı sampler ile (ör. biri clamp, biri repeat) iki «görünüm» üretilir, görüntü bir kez saklanır.

Holodepth ayrımı: «kaç PNG var?» sorusu images.length; «kaç materyal slotu texture kullanıyor?» sorusu materyal alanlarıdır; «kaç texture kaydı var?» textures.length. Üç sayı farklıdır; karıştırmak «dosyada 4 doku var» raporunu bozar.

Sampler kaydı WebGL tarzı sabitlerle örnekleme davranışını yazar. Bu sayfa enum format alanlarını listeler; Three.js'de wrapS / minFilter atama detayı Wrapping & Repeat ve Texture binding sayfalarındadır.

Lightmap UV'si 0..1'de unique iken REPEAT wrap, kenarda sızıntı üretebilir; albedo tiling için REPEAT bilinçli seçilir. Format dosyası niyeti yazar; runtime aynı enum'u GPU'ya iletir. «Doku kayıyor» semptomunda önce UV'yi, sonra sampler wrap'ı kontrol edin; ikisi farklı katmandır.

Export araçları aynı albedo PNG'sini hem gövde hem aksesuar materyalinde baseColorTexture.index ile aynı texture kaydına bağlayabilir. İyi durum: tek image, tek texture, çok materyal. Kötü durum: aynı dosyanın üç kopyası üç image kaydı (paket şişer).

• Paylaşılan image, farklı sampler: iki texture kaydı, bir kaynak
• Paylaşılan texture, farklı materyal: PBR slotları aynı indeksi gösterir
• Çoğaltılmış image: URI aynı metin, iki kayıt; validator uyarı vermeyebilir

Holodepth: dosya boyutu analizinde önce images benzersizliğine bakın; «kaç materyal texture kullanıyor» sayımı yanıltıcıdır.

Sıra: materyal index → texture kaydı → source image → URI/bufferView erişilebilir mi → sampler varsayılanı kabul edilebilir mi. Bu sıra Texture binding API'sinden önce biter.

Standart anlatım «textures → images» ile biter. Aşağıdakiler üretimde sık, az yerde derin işlenir.

index karışıklığı

Materyal index'i image indeksi sanmak klasik hatadır. Doğru hedef textures'tır. İki dizi boyutu farklıysa «index 3» image'da taşar, texture'da geçerli kalır (veya tersi).

Göreli URI ve taşıma

.gltf + textures/albedo.png paketi klasör yapısına bağlıdır. Tek dosyayı başka dizine kopyalamak zinciri kırar; GLB bu yüzden web dağıtımında sık tercih edilir. Format sorunu «PNG bozuk» değil, «yol çözülemedi»dir.

Renk uzayı dosyada yazılmaz (core)

Core glTF image kaydı «sRGB mi linear mı?» demez; loader / engine albedo için sRGB, data map (MR, normal) için linear varsayar. Yanlış renk uzayı «soluk metal» üretir; JSON'da alan aramayın. Runtime sözleşmesi Texture binding / material mapping'dedir.

Yetim kayıtlar

Hiçbir texture'un işaret etmediği image, veya hiçbir materyalin işaret etmediği texture «ölü ağırlık»tır. Dosya geçerli kalabilir; paket boyutu şişer. Validator her zaman uyarmayabilir; Holodepth envanterinde referans sayımı yapın.

Bir image, iki rol

Aynı PNG hem occlusion R hem başka slotta kullanılıyorsa (nadir / kötü bake) kanal anlamı materyalde ayrılır; image tablosu tek kayıttır. «Dosyada iki AO var» sanısı yanlıştır; iki textureInfo aynı source'a bakıyor olabilir.

Extension kaynağı

Basis/KTX2 extension'ları image veya texture kaydına ek alan bağlar; core uri/bufferView yolu değişebilir. Bu sayfa core zinciri sabitler; sıkıştırılmış doku sözleşmesi Extension Sistemi / KTX2 dalındadır.

Görüntü kaynağı ve sampler sözleşmesi oturunca sıradaki soru: hangi mesh parçası bu materyali kullanır?

1. Material Slots primitive.material indeks dili (Material Slots)
2. Extension Sistemi variants, Basis, ekstra materyal modelleri (Extension Sistemi)
3. Runtime Texture binding

Format okuyucusu özeti: PBR kartı → textures/images/samplers → primitive material indeksi. Texture Referansları, karttaki «index»in çözüldüğü kattır.