Material Slots glTF'de Primitive ↔ Material Bağı

«Material slot» ifadesi DCC ve oyun motorlarında genelde UI dilidir: mesh üzerinde Materyal 0, Materyal 1…. glTF dosyasında karşılığı bir dizi UI etiketi değil, primitive kaydındaki isteğe bağlı tamsayıdır. Bu tamsayı materials dizisine indeks dilidir; tıpkı accessor'ın bufferView'e bakması gibi.

Material Slots şunların hiçbiri değildir:

• Materyal içeriği değil metallic/roughness PBR Yapısı'nda
• Doku dosyası değil Texture Referansları'nda
• Scene graph düğümü değil node hiyerarşisinde
• Runtime Mesh.material API'si değil Three.js mapping sayfasında

Kart «nasıl görünecek?» sorusunu yanıtlar. Slot «kim giyecek?» sorusunu yanıtlar. İkisi olmadan model ya renksiz kalır ya da yanlış parçaya yanlış yüzey basılır.

glTF'de meshes kaydı bir veya daha fazla primitives içerir. Her primitive kendi attribute setini (POSITION, NORMAL, TEXCOORD_0…), isteğe bağlı indices, mode (triangles vb.) ve isteğe bağlı material taşır. Geometri hattı attribute'ları anlattı; burada odak yalnızca materyal bağlantısıdır.

"meshes": [{
  "name": "Character",
  "primitives": [
    {
      "attributes": { "POSITION": 0, "NORMAL": 1, "TEXCOORD_0": 2 },
      "indices": 3,
      "material": 0
    },
    {
      "attributes": { "POSITION": 4, "NORMAL": 5, "TEXCOORD_0": 6 },
      "indices": 7,
      "material": 1
    }
  ]
}]

Bu örnekte tek mesh, iki çizim birimi: ilki materials[0] (ör. deri), ikincisi materials[1] (ör. kumaş). Export araçları «multi-material mesh» dediğinde çoğu zaman birden fazla primitive üretir; her biri ayrı indeks aralığı ve ayrı material taşır.

Neden material mesh kökünde değil?

Mesh köküne tek material yazmak, çoklu yüzeyli modelleri zorlar. Primitive başına material, «aynı iskelet geometri organizasyonu, farklı yüzeyler» deseni için doğal birimdir. Holodepth: çizim birimi = primitive; materyal slotu bu birime takılır.

Primitive material: n der → materials[n]. Material kaydı «hangi primitive'ler beni kullanıyor?» listesi taşımaz. Bu, buffer → bufferView → accessor zincirindeki gibi aşağı iner, yukarı çıkmaz modelidir.

nodes[a].mesh → meshes[j]
  → primitives[k].material → materials[n]
       → pbrMetallicRoughness / textureInfo…
            → textures / images  (önceki sayfalar)

Node üzerinde material yoktur; node yalnızca mesh (veya camera, skin…) indeksi taşır. «Bu node'un materyali» demek format dilinde yanlıştır; doğru cümle: «Bu node'un mesh'inin şu primitive'inin materyali.» Node Hiyerarşisi sahne ağacını anlatır; slot o ağaçta değil, mesh tablosundadır.

Pratikte dört desen sık görülür. Hepsi geçerli glTF'dir; seçim export ve içerik ihtiyacına bağlıdır.

Paylaşım neden önemli?

Aynı materials[2]'yi yirmi primitive'in işaret etmesi, yirmi kopya PBR kartı yazmaktan daha küçüktür ve tutarlıdır. Kartı bir yerde güncellersiniz; tüm tüketiciler aynı indeksi okur. Holodepth'in bufferView paylaşım mantığı burada materyal ölçeğinde tekrarlanır: tek kaynak, çok görünüm.

Çoklu primitive maliyeti (format yüzü)

Her ek primitive genelde ayrı indeks aralığı ve ayrı draw anlamına gelir (runtime). Format dosyasında bu, daha uzun primitives dizisi ve çoğu zaman daha fazla accessor referansıdır. «Her vida için ayrı material» export'u dosyayı şişirir; «her vida aynı material indeksi» paylaşımı korur. Optimizasyon motoru Materyal Optimizasyonu sayfasındadır; burada yalnızca export kararının JSON'a yansıması işaretlenir.

material alanı isteğe bağlıdır. Yoksa spec, loader'ın varsayılan bir materyal uygulamasını bekler (tipik: mat, açık gri/beyaz, metallic 0, roughness yüksek civarı — kesin görünüm uygulamaya bağlıdır). Dosyada «materials dizisi boş, primitive material yok» tamamen geçerli bir minimal mesh olabilir.

• Kasıtlı eksik: placeholder, debug geometri, henüz boyanmamış parça
• Kazara eksik: export'ta material atanmamış; «neden gri?» semptomu
• Geçersiz indeks: material: 5 iken materials.length === 3 → kırık dosya

Holodepth debug sırası: primitive'de material var mı → indeks sınır içinde mi → materials[n] PBR/texture zinciri sağlam mı? Gri yüzey çoğu zaman «shader bozuk» değil, slot boş veya varsayılandır.

Aynı meshes[j] birden fazla node tarafından referanslanabilir (örnekleme). Her instance aynı primitive → material haritasını miras alır; materyal node başına değişmez (core). Farklı materyal istiyorsanız ya ayrı mesh/primitive seti ya da variants extension gerekir.

Transform node'dadır ( Transform Verileri); yüzey sözleşmesi mesh primitive'indedir. «Bu instance'ı kırmızıya boya» core glTF'de node alanıyla yapılamaz; kartı veya indeksi değiştirmek gerekir.

Skin / morph ile karıştırmayın

Skinning ve morph targets mesh/primitive üzerinde başka alanlardır (targets, node'da skin). Material slotundan bağımsızdırlar. Animasyon dalı bu konuları genişletir; burada yalnızca «slot ≠ deformasyon» sınırı yeterlidir.

Blender / Maya / Max'te «material slot» listesi glTF'e genelde şöyle yansır:

1. Yüzler materyal ID'sine göre gruplanır
2. Her grup bir primitive (veya birleşik mesh içinde ayrı indeks aralığı) olur
3. Her grup için materials kaydı yazılır veya mevcut kart paylaşılır
4. primitives[k].material = n bağlanır

Slot sırası (UI'daki 0, 1, 2) dosyadaki material indeksiyle birebir olmak zorunda değildir; export yeniden numaralandırabilir. Holodepth: DCC slot adını değil, JSON indeksini kaynak gerçek kabul edin. İsimler materials[n].name ile taşınabilir; bağlayıcı alan yine tamsayıdır.

«Apply modifiers / merge by material» gibi seçenekler primitive sayısını değiştirir. Tek material'e indirgemek slot sayısını azaltır; çoklu yüzeyi kaybedersiniz. Bu bir sanat/pipeline kararıdır; format her iki sonucu da taşır.

Dosya raporu yazarken üç sayı karıştırılmamalıdır:

materials.length === 10 ama yalnızca 3 indeks kullanılıyorsa 7 kart yetimdir (Texture Referansları'ndaki yetim image ile aynı sınıf sorun). Validator her zaman uyarmayabilir.

Standart anlatım «primitive.material bir indekstir» ile biter. Aşağıdakiler üretim ve debug'da sık, az yerde derin işlenir.

«Tek mesh» yanılsaması

DCC viewport'ta tek obje görürsünüz; glTF'de beş primitive olabilir. «Neden beş draw?» sorusunun cevabı çoğu zaman beş material slotudur. Format dosyasını açmadan motoru suçlamak yanlış katmandır.

Aynı kart, farklı UV

İki primitive aynı material: 0'ı paylaşır; attribute'ları farklı TEXCOORD_0 tablolarına bakabilir. Kart ortaktır; adres değildir. «Aynı materyal neden farklı duruyor?» → önce UV, sonra PBR. Slot paylaşımı görünüm özdeşliği garantilemez.

İndeks yeniden numaralama

Optimizasyon / gltf-pipeline araçları kullanılmayan material'leri silip indeksleri kaydırabilir. Harici script'iniz «hep materials[4] cam» diye sabit kodladıysa kırılır. Kararlı bağ için name veya içerik hash'i kullanın; saf indeks kırılgandır.

Alpha ve primitive sırası

alphaMode: BLEND materyalli primitive'ler çizim sırasına duyarlıdır. glTF core, şeffaf primitive'lerin global sıralamasını tanımlamaz. Slot doğru olsa bile «yanlış önde / arkada» runtime sıralama sorunudur; format yalnızca kartı ve bağı sağlar.

Variants teaser

KHR_materials_variants aynı primitive için alternatif material eşlemeleri sunar (renk seçenekleri). Core slot tek indekstir; variants onu genişletir. Bu sayfa core'u sabitler; alternatif harita KHR_materials_variants sayfasındadır.

Debug: yanlış parça, doğru kart

Cam materyali gövdeye basılmışsa PBR kartı «doğru» olabilir; material indeksi yanlış primitive'dedir. Holodepth: semptom «yanlış yüzey» ise önce slot haritasını, sonra kart içeriğini kontrol edin.

Core Materyal Sistemi omurgası üç soruyla tamamlanır: kart (PBR) → görüntü zinciri (Texture Referansları) → bağ (Slots). Sıradaki genişleme:

1. Extension Sistemi clearcoat, sheen, specular, transmission, variants (Extension Sistemi)
2. Uzantılar grubu (Draco, Basis, GPU instancing) ayrı dal
3. Runtime Material mapping

Format okuyucusu özeti: materials kartı → textures/images → primitives[].material. Slot, kartı çizim birimine takan son core halkadır.