JSON Yapısı: Sahnenin Organizasyon Haritası

glTF (Graphics Language Transmission Format), bir 3B sahne dosyasıdır. Sahnenin parçaları hangi mesh hangi materyali kullanacak, hangi düğüm hangi çocuğa bağlı, hangi animasyon hangi kanalları hedefleyecek JSON belgesinde tanımlanır. JSON burada «veri deposu» değil, organizasyon dilidir: okunabilir, platform bağımsız ve araçlar tarafından kolayca işlenebilir bir üst katman.

Kritik ayrım şudur: JSON, gerçek vertex verilerini içermez. Köşe konumları, normal vektörleri, UV koordinatları ve indeks listeleri çoğunlukla binary buffer içinde sıkıştırılmış ham bayt blokları olarak durur; JSON tarafı bu bloklara «şu aralıktaki veriyi oku» diye işaret eder. Bu yüzden glTF’yi anlamak, önce «JSON neyi tarif eder?» sorusuyla başlar «JSON neyi taşır?» ile değil.

Pratik sonuç: bir .gltf dosyasını metin editöründe açtığınızda sahne anatomisini okuyabilirsiniz; fakat üçgen sayısını veya vertex listesini görmek için binary buffer, bufferView ve accessor zincirine inmeniz gerekir; bunların her biri ayrı sayfada detaylandırılır.

1. bölüm JSON’un organizasyon katmanı olduğunu metinle sabitledi. Aşağıdaki laboratuvar aynı fikri elle gezilebilir hale getirir: sadeleştirilmiş bir glTF belgesinde (ebeveyn küp + çocuk küre) indekslerin nasıl tablo tablo ilerlediğini üç panelde aynı anda görürsünüz.

Üç panel, tek senkron cevap

Bu interaktif laboratuvar alanı, GLTF mimarisini öğrenirken zihnimize kazımamız gereken o en temel felsefeyi, yani «JSON sahnenin kendisi değil, sahnenin inşa edileceği mimari haritasıdır» cümlesini görsel olarak parçalara ayırır. Karmaşık ve iç içe geçmiş veri yapılarında kaybolmanızı önlemek amacıyla tasarlanan bu araçta, her bir panel bu devasa haritanın farklı bir yapısal yüzünü temsil eder ve aralarındaki kusursuz senkronizasyon sayesinde 3D verinin yolculuğunu gözler önüne serer:

• Sol Panel · JSON Organizasyonu (Veri Hiyerarşisi): GLTF dosyasının omurgasını oluşturan nodes, meshes, materials ve textures gibi temel tabloların bilişsel yükü azaltılmış, sadeleştirilmiş bir görünümünü sunar. Bu panelde karşınıza çıkan mesh: 0 veya material: 1 gibi değerlerin fiziksel birer geometri, renk veya görsel dosyası olmadığını; aksine bilgisayarın belleğinde doğru veriyi bulmasını sağlayan, birer indeks referans noktası (pointer) olduğunu net bir şekilde görebilirsiniz.
• Orta Panel · Referans Zinciri (Bağlantı Mimarisi): Sol tarafta seçtiğiniz herhangi bir temel kayıttan yola çıkarak, 3D motorunun (örneğin Three.js) bu veriyi nasıl okuduğunu simüle eder ve Node → Mesh → Material → Texture hattındaki o görünmez bağı adım adım gözler önüne serer. Ortada yer alan dinamik açıklama satırları, o anki adımda JSON diziliminin tam olarak neye işaret ettiğini kavramsal olarak açıklar. Render motorunu yoran accessor, bufferView veya binary buffer gibi karmaşık düşük seviye okuma detayları, ana hiyerarşik mantığın anlaşılabilmesi için bu aşamada kasıtlı olarak gizlenmiştir.
• Sağ Panel · Three.js Sahnesi (Görsel Çıktı): Okunan bu mimari haritanın render motoru tarafından yorumlanıp nihai olarak çözülmüş, canlı bir mini örneğidir. Örneğin, sol paneldeki hiyerarşide yer alan küp verisi nodes[0] ile, küre verisi ise nodes[1] ile doğrudan eşleşerek ekranda var olur. Buradaki temel amaç, megabaytlarca büyüklüğünde gerçek ve ağır bir 3D asset yüklemek değil; soyut JSON indeks planının, WebGL dünyasındaki somut nesnelere, materyallere ve sahne grafiğine (scene graph) nasıl bağlandığını sezgisel olarak hissettirmektir.

Bu üçlü laboratuvar tasarımının en can alıcı noktası eşzamanlı çalışmasıdır. Sol panelde kod tabanlı bir satıra veya ortadaki soyut bir zincir halkasına tıkladığınız anda, her üç panel de birbiriyle konuşarak anında güncellenir. Bu kusursuz iletişim sayesinde zihninizde; «JSON dosyasında düz bir sayı gördüm → motor bu sayıyı alıp başka bir tablodaki özelliğe (örneğin materyale) gidiyor → ve en nihayetinde sahne tarafında tam olarak şu 3D nesnenin görünümü etkileniyor» şeklindeki o büyük aydınlanma döngüsü tek bir fare hareketiyle, akıcı bir şekilde kurulmuş olur.

Zincir Adımı = Sahne Modu

Orta panelde yer alan referans zincirinde hangi veri halkasını seçtiğiniz, yalnızca metinsel bir odaklanma yaratmaz; aynı zamanda sağ paneldeki canlı WebGL tuvalinde (canvas) anında görsel bir geri bildirim tetikler. Bu etkileşimli yapı, GLTF mimarisindeki her bir katmanın ve JSON özelliğinin üç boyutlu sahnede fiziksel olarak nasıl bir rol üstlendiğini kavramanız için özel olarak izole edilmiş "sahne modları" sunar. Seçtiğiniz her adım, render döngüsünde (render loop) farklı bir bileşeni aydınlatır:

• Node (Düğüm): Sahne grafiğindeki (scene graph) yapısal temeli ve uzaysal hiyerarşiyi temsil eder. Bu katmanı seçtiğinizde, nesnenin üç boyutlu uzaydaki konumunu belirleyen pivot noktası, transformasyon matrisleri ve ebeveyn-çocuk (parent-child) bağları görselleştirilerek mimari iskelet ön plana çıkarılır.
• Mesh (Ağ Yapısı): Bu katman seçildiğinde nesne, yapısal topolojisini ortaya çıkaran bir tel kafes (wireframe) modunda vurgulanır. Unutulmamalıdır ki asıl geometri verisi (vertex dizilimleri) JSON dosyasının içinde değil, harici binary (ikili) dosyalarda yaşar; sağ paneldeki bu mod yalnızca «gözlemlediğim bu mesh kaydı, sahnede fiziksel olarak hangi hacme ve gövdeye karşılık geliyor?» sorusuna görsel bir sınır çizerek yanıt verir.
• Material (Materyal): Seçim bu halkaya kaydığında, sahnedeki nesnenin ışık fotonlarıyla olan fiziksel etkileşimi ön plana çıkar. Modern PBR (Physically Based Rendering) kurallarına göre hesaplanan pürüzlülük (roughness) ve metaliklik (metalness) gibi gölgelendirici (shader) parametrelerinin anlık görsel geri bildirimi, doğrudan modelin yüzeyine yansıtılır.
• Texture (Doku): JSON içerisindeki texture referansının, ham image (görüntü kaynağı) verisine nasıl bağlandığını somutlaştıran adımdır. Modelin yüzeyine uygulanan örnek bir dama deseni (checkerboard) kullanılarak, 2D piksel verisinin UV koordinatları aracılığıyla 3D geometriye nasıl sarıldığı ve bu referans bağının görsel karşılığı test edilir.

Kullanıcı deneyimini her cihazda pürüzsüz ve premium kılmak adına etkileşim dinamikleri özel olarak ayrıştırılmıştır. Mobil cihazlarda, dokunmatik ekranın doğal dikey sayfa kaydırma (scroll) hareketi ile 3D kameranın serbest dönüş hareketinin (OrbitControls) birbiriyle çakışmasını önlemek için, sağ panelde «Sahneyi döndür» adında özel bir geçiş düğmesi bulunur. Masaüstü cihazlarda ise geniş ekranın ve imleç hassasiyetinin avantajıyla, ekstra bir onaya ihtiyaç duymadan doğrudan farenizle modeli döndürebilir ve detayları inceleyebilirsiniz.

Demo’nun kapsamı ve sınırı

Bu laboratuvar node transform kurallarını, scene graph runtime davranışını, skinning’i veya tam PBR eşlemesini öğretmez; yalnızca bu kavramların JSON içinde indekslerle nasıl referanslandığını görselleştirir. Vertex verisi, accessor çözümlemesi ve binary buffer bu demoda yoktur; binary buffer sayfasında tamamlanır.

Demo sonrası metin akışı 2. bölüm ile devam eder: glTF JSON’undaki tüm ana tablolar anatomi haritası olarak listelenir. Laboratuvar o haritanın canlı bir kesitidir; küp + küre örneği üzerinden.

Standart bir glTF JSON belgesi, sahneyi kurmak için gereken tablo koleksiyonlarından oluşur. Her tablo bir dizi (array) tutar; öğeler arası ilişki indeks numarası ile kurulur. Aşağıdaki harita, dosyanın genel anatomisini gösterir; bu bölümde her bloğun iç mekaniğine girilmez; amaç «hangi parça nerede duruyor?» sorusuna cevap vermektir.

{ } glTF JSON

1. asset format sürümü, üretici bilgisi
2. scenes hangi kök sahne aktif?
3. nodes dönüşüm, çocuklar, mesh / skin / camera bağlantıları
4. meshes primitive listesi (geometri + materyal referansı)
5. materials PBR parametreleri, texture referansları
6. textures image + sampler bağlantısı
7. images doku kaynağı (URI veya buffer içi)
8. animations kanal ve sampler referansları
9. accessors bufferView üzerinden tip / offset / stride tanımı
10. bufferViews buffer içindeki bayt aralığı
11. buffers ham binary veri (URI veya GLB chunk)

Bu tablolar birbirinden bağımsız «dosya parçaları» gibi düşünülmemelidir. Örneğin bir mesh kaydı, primitives altında attributes ve indices için accessor indeksleri taşır; material için ayrı bir indeks verir. nodes tablosu ise sahne ağacını kurar ve mesh, skin veya camera gibi kaynaklara referans verir. Yani JSON, ilişki haritasıdır; her satır bir «şuraya bak» işaretidir.

asset bloğu küçük görünse de önemlidir: version alanı loader’ın hangi glTF sürümünü beklediğini belirler; generator hangi aracın dosyayı ürettiğini kaydeder. Extension kullanımı da çoğu zaman extensionsUsed / extensionsRequired ile burada veya ilgili nesnede bildirilir; extension mekaniğinin detayı ayrı konularda kalır.

Modern 3D grafik formatlarının en büyük darboğazlarından biri, sahnede tekrar eden devasa verilerin nasıl yönetileceğidir. glTF, bu sorunu kökünden çözmek için geleneksel "isim bazlı" (string-based) arama yöntemlerini terk eder. Bunun yerine, çok daha performanslı ve doğrudan donanıma hitap eden bir mimari benimser: nesneler uzun metin dizileriyle değil, dizilerdeki (array) kesin kimlik numaralarıyla (indekslerle) birbirine zincirlenir. Bir sahne düğümünün (node), uzayda kaplayacağı fiziksel hacmi belirleyen bir mesh’e nasıl pratik bir şekilde referans verdiğini aşağıdaki kod bloğunda görebilirsiniz:

{
  "name": "Body",
  "mesh": 2,
  "children": [5, 6]
}

Burada yer alan "mesh": 2 ifadesi, meshes dizisinin 2. öğesini (bilgisayar bilimlerindeki standart sıfır tabanlı indeksleme mantığıyla) işaret eden sanal bir bellek okudur. Bu indeks tabanlı mimarinin en büyük gücü, aynı mesh verisinin sahnedeki onlarca, hatta yüzlerce farklı düğüm (node) tarafından aynı anda paylaşılabilmesidir. Benzer şekilde materyaller, dokular (texture) ve karmaşık animasyon kanalları da kopyalanmak yerine sadece indeksleriyle tekrar tekrar kullanılır. Bu stratejik tasarım kararı sayesinde şu devasa avantajlar elde edilir:

• Veri tekrarı (Redundancy) ortadan kalkar: Aynı geometri parçası, yüksek çözünürlüklü bir doku veya ahşap materyali dosya içerisinde yalnızca bir kez tanımlanır. Sahnede binlerce kez kullanılsa bile hepsi tek bir ana kaydı referans alır (Örneğin, devasa bir ormandaki tüm ağaçların tek bir yaprak modelinden türetilmesi instancing mantığı).
• Dosya boyutu dramatik şekilde küçülür: Özellikle endüstriyel tasarımlarda veya tekrarlayan mimari modüllere sahip (tekerlekler, vidalar, modüler paneller) projelerde gereksiz veri yığınları engellenir. Bu, dosyanın web üzerinden saniyeler içinde aktarılabilmesini sağlayan en kritik faktördür.
• Yükleme (Parsing) süresi hızlanır: Tarayıcı motoru veya 3D yazılım (loader), tabloları okurken yorucu metin eşleştirmeleri yapmak zorunda kalmaz. İndeks numaraları doğrudan bellek işaretçileri (pointers) gibi çalıştığı için, referanslar çözülürken hiçbir ekstra veri kopyalama işlemi yapılmaz ve dizilimler doğrudan GPU'ya akıtılır.

Aşağıdaki görselleştirme, tipik bir render zincirinin JSON mimarisinde nasıl okunduğunu adım adım göstermektedir. Dikkatinizi vermeniz gereken nokta, hiçbir adımın ham veriyi kendi içinde barındırmamasıdır; her katman bir sonrakinin adresini tutan bir harita görevi görür. Bu akış, organizasyon düzeyinde şu şekilde yapılandırılır:

Node indeks 4

mesh: 1

primitives[0]

attributes.POSITION → accessor 0

attributes.NORMAL → accessor 1

indices → accessor 2

material: 0

textures → image → buffer / URI

Bu kavramsal zincirde yer alan POSITION (nokta koordinatları) veya PBR (Fiziksel Tabanlı Render) materyal parametrelerinin tam olarak ne anlama geldiği veya piksellere nasıl dönüştüğü bu sayfanın kapsamı dışındadır. Burada odaklanmamız ve kavramamız gereken en temel kural şudur: Her bir veri halkası kendisinden bir üst tablodaki kesin bir indekse kopmaz bir bağla bağlıdır. Çalışma zamanında (Runtime), Three.js veya Babylon.js gibi bir loader devreye girdiğinde, bu soyut indeks numaralarını alır ve onları bilgisayarın belleğinde yaşayan, piksellerle etkileşime giren gerçek nesnelere (BufferGeometry, Material, Texture sınıflarına) çevirir. JSON'un o salt metin dünyasından WebGL'in canlı ve somut dünyasına geçişi sağlayan bu hayati dönüşüm süreci, 7. bölümde tüm mimari adımlarıyla özetlenmektedir.

glTF’yi anlamanın çoğu geliştirici için «aha» anı, JSON ile binary’nin rol ayrımını gördükleri yerdir. 3. bölümde indeks referanslarını, demoda aynı fikri üç panelde gezdiniz; bu bölüm o parçaları tek cümlede birleştirir: glTF dosyası iki farklı işi iki farklı katmanda yapar; biri «sahneyi tarif et», diğeri «sayıları taşı».

Karışıklık genelde şuradan gelir: JSON’da meshes, nodes gibi «gerçek sahne parçalarına» benzeyen tablolar görürsünüz; bu yüzden dosyanın tamamının metin olduğu sanılır. Oysa tabloların çoğu başka kayıtlara işaret eden indeksler taşır; asıl yoğun sayısal yük binary taraftadır. İki katmanı yan yana düşünmek, hem dosyayı okurken hem loader yazarken zihinsel modeli netleştirir.

JSON tarafı organizasyon

JSON’un sorduğu sorular «kim kime bağlı?» ve «hangi kayıt hangi kaynağı kullanıyor?» türündedir. Cevaplar tablo ve indeks diliyle verilir; vertex koordinatı veya üçgen listesi beklemeyin:

• Bu mesh hangi accessor’ları kullanıyor? → attributes ve indices alanlarındaki sayılar
• Bu primitive hangi materyali bağlıyor? → material indeksi
• Bu node hangi çocuklara ve hangi mesh’e sahip? → children, mesh referansları
• Bu animasyon hangi node özelliklerini hedefliyor? → channels ve targets bağlantıları

Ortak özellik: JSON burada grafik ve bağlantı planı üretir. Bir primitive satırı «şu köşeler şu koordinatlarda» demez; «position verisi için şu accessor kaydına git» der. Materyal satırı metalness değerlerini taşıyabilir, fakat doku piksellerini değil; görsel ham veri yine binary veya harici URI kanalındadır. Bu yüzden JSON’u okumak, sahneyi inşa talimatı okumak gibidir; talimatın kendisi inşa malzemesi değildir.

Binary tarafı ham veri

Binary katmanın sorduğu soru tek ve doğrudandır: «sayılar nerede, hangi baytlar?» Cevap, etiketsiz veya üst katmanlarca yorumlanan ham bloklar halinde gelir:

• Vertex konumları (float dizileri)
• Normal, tangent, UV kanalları
• İndeks buffer’ı (üçgen listesi)
• Animasyon anahtar kareleri (time / value dizileri)
• İsteğe bağlı: sıkıştırılmış geometri (Draco vb.) extension detayı ayrı konularda

Binary taraf «hangi mesh hangi materyali kullanıyor?» sorusunu yanıtlamaz; yalnızca «bu aralıktaki baytlar position verisidir» gibi sayısal içerik sunar. Havuz metaforu ve segment mantığı binary buffer · veri havuzu sayfasında açılır; burada yalnızca JSON sayfası perspektifinden sabitlenir: organizasyon metinde, yük binary’de.

İki katman, iki sorumluluk

Kısa formül: JSON = organizasyon, binary buffer = ham veri. Ayrımı günlük dilde şöyle özetleyebilirsiniz:

• JSON «Bu modelde neler var ve nasıl bağlanmış?»
• Binary «Bağlanan parçaların sayısal içeriği nedir?»

İkisini tek katmanda birleştirmek ya JSON’u devasa ve yavaş hale getirir ya da organizasyonu okunamaz kılar; glTF bu yüzden hibrit kalır. Performans ve boyut gerekçeleri binary buffer tanımında sayısal örnekle desteklenir; bu bölümde önemli olan rol ayrımının kendisi.

JSON’da vertex listesi görmeyebilirsiniz; bunun yerine şuna benzer bir yapı görürsünüz; sayılar accessor tablosuna gider, gerçek koordinatlar değil:

"primitives": [{
  "attributes": {
    "POSITION": 0,
    "NORMAL": 1
  },
  "indices": 2,
  "material": 0
}]

Bu örnekte POSITION: 0 «ilk vertex» demek değildir; accessors[0] kaydına işaret eder. NORMAL: 1 ve indices: 2 aynı şekilde ayrı accessor girişleridir. material: 0 ise tamamen organizasyon katmanında kalır; materyal tablosuna gider, binary vertex verisiyle karışmaz. Yani aynı primitive bloğu içinde bile farklı indeks türleri farklı tablolara açılır; hepsi tek bir vertex dizisi değildir.

Accessor’dan buffer’a giden zincir (accessor → bufferView → buffer) bu sayfada çözümlenmez; her halka accessor, bufferView ve binary buffer sayfalarında ayrıntılandırılır. JSON yapısı sayfasının görevi şudur: indekslerin geometri değil, organizasyon dili olduğunu göstermek.

Loader tarafında önce JSON’daki plan okunur, ardından binary’den sayılar çekilir; sıra 7. bölümde özetlenir. Burada kapanış cümlesi net kalsın: glTF’yi okurken elinizde iki belge varmış gibi düşünün; bir plan (JSON), bir malzeme deposu (binary). Plan olmadan depo anlamsız; depo olmadan plan boş bir şemadır.

Sonraki bölüm (5 · Neden JSON?) organizasyon katmanında neden özellikle JSON seçildiğini mühendislik gerekçeleriyle açar; binary tarafının «neden var?» sorusu ise binary buffer · katman ayrımı sayfasında derinleşir; çakışma yok, tamamlayıcı iki perspektif.

Modern 3D web dünyasının "JPEG'i" olarak anılan glTF mimarisinde, tüm hiyerarşiyi, sahneleri ve materyalleri yöneten üst kontrol katmanı olarak JSON (JavaScript Object Notation) dilinin seçilmesi sıradan veya rastgele bir tercih kesinlikle değildir. Aksine bu karar, performans odaklı 3D motorları ile modern web ekosisteminin kesişim noktasında yer alan çok katı mühendislik gereksinimlerinin mükemmel bir çözümüdür:

• İnsan Tarafından Okunabilir (Human-Readable): Geliştiriciler, teknik sanatçılar (technical artists) veya QA uzmanları, binlerce satırlık karmaşık bir 3D modelin içyapısını incelemek istediklerinde dosyayı basit bir metin editöründe açabilirler. JSON sayesinde "Hangi gölgelendirici (shader) materyali, sahnedeki hangi spesifik mesh bloğuna bağlı?" veya "Bu kamera düğümünün rotasyon katsayısı nedir?" gibi kritik sorular, herhangi bir 3D yazılıma ihtiyaç duyulmadan, salt metin düzeyinde okunabilir, hata ayıklanabilir (debug) ve Git diff süreçlerinden geçirilebilir.
• Araçlar Tarafından İşlenebilir (Tooling Ecosystem): Blender'dan fırlayan bir dışa aktarma (export) eklentisi, komut satırında çalışan bir optimizasyon pipeline'ı (örneğin gltf-pack) veya bir kalite kontrol validasyon aracı... Tüm bu ekosistem parçaları, JSON verilerini parse edip (ayrıştırıp) dönüştürmek için zaten onlarca yıldır standartlaşmış ve son derece optimize edilmiş evrensel kütüphaneleri kullanır.
• Platform Bağımsız Gezinme (Cross-Platform): İşletim sistemleri veya işlemci mimarileri (endianness farklılıkları, 32-bit vs 64-bit float düzeni vb.) donanımsal düzeyde farklı çalışsa da, JSON bu alt seviye karmaşadan tamamen izole bir metaveri (metadata) katmanı sunar. Motor, neyi nerede bulacağını bu evrensel dil sayesinde çözer.
• Web Dostu Doğası (Native Web Support): Tarayıcı motorları (V8, SpiderMonkey), JSON'u kendi anadilleri gibi konuşurlar. Bir web uygulaması, sunucudan fetch ile dosyayı çektikten sonra, mikrosaniyeler içinde çalışan yerleşik JSON.parse() fonksiyonu ile tüm sahnenin organizasyon iskeletini bellekte ayağa kaldırır. Sahnenin asıl ağır yükü olan milyonlarca piksellik veriler ise tarayıcıyı dondurmamak için, asenkron olarak ayrı isteklerle veya GLB paketinin binary (ikili) yığınında (chunk) daha sonradan, gizlice gelir.
• Kolay Genişletilebilir Esneklik (Extensibility): Standart bir formatın en büyük sorunu yeniliklere kapalı olmasıdır. Ancak JSON tabanlı glTF, içerisindeki extensions (resmi eklentiler) ve extras (özel geliştirici verileri) blokları sayesinde, çekirdek (core) şemayı kırmadan ekosisteme yeni yetenekler kazandırır. Örneğin; KHR_draco_mesh_compression ile ağ geometrilerini sıkıştırma veya KHR_texture_basisu ile ekran kartı dostu devasa dokular yükleme gibi özellikler, ana JSON haritasına kolayca birer eklenti düğümü olarak aşılanır.

Peki her şey bu kadar mükemmelse neden sahnedeki her veriyi JSON olarak tutmuyoruz? Çünkü JSON’un çok bariz bir dezavantajı da vardır: Milyonlarca noktalı (vertex) ham geometri verilerini veya 4K çözünürlüğündeki resim piksellerini düz metin olarak kodlamak inanılmaz derecede hantal, şişkin ve verimsizdir. İşte bu yüzden glTF akıllı bir "hibrit" (melez) model kullanır; kural şudur: "Metaveri JSON'dadır, asıl ağır yük (Payload) JSON'da değildir." Bu kritik mimari felsefe ve asset pipeline tarafında hangi dosya formatı stratejilerinin izlenmesi gerektiği, Asset Optimizasyonu · Dosya Formatları başlıklı konumuzla yapısal olarak doğrudan örtüşmektedir; bu sayfa ise yalnızca glTF’nin bu "beyin" rolünü üstlenen iç organizasyon mantığını zihinlerimize sabitlemektedir.

Sık sorulan soru: «glTF ile GLB aynı şey mi?» Kısa cevap: aynı veri modeli, farklı paketleme. Organizasyon katmanı her iki durumda da JSON’dur; fark, dosyanın diskte nasıl sunulduğundadır.

.gltf ayrık paket

• model.gltf JSON organizasyon
• model.bin binary buffer
• textures/ harici görseller

.glb tek dosya

• [JSON chunk] aynı organizasyon belgesi
• [BIN chunk] aynı binary veri
• gömülü görseller isteğe bağlı

GLB, glTF 2.0 spesifikasyonunun binary konteyner formatıdır. İçindeki JSON chunk, ayrık .gltf dosyasındaki belgeyle aynı şemayı taşır; yalnızca dışarıdan metin dosyası olarak değil, tek bir .glb dosyasının ilk bölümü olarak paketlenir. Buffer URI’leri GLB’de çoğu zaman buffer chunk’ına göreli offset ile çözülür; yine organizasyon JSON’da, ham veri chunk’ta kalır.

GLB ile glTF arasındaki performans, boyut ve dağıtım karşılaştırması bu sayfanın kapsamı dışındadır; o konu «GLB vs glTF» başlığında ele alınacaktır. Burada sabitlenen tek gerçek: GLB, JSON organizasyon katmanını ortadan kaldırmaz; saklar.

Tarayıcıda bir glTF yüklenirken JSON doğrudan ekrana çizilmez. Organizasyon belgesi, motorun sahne inşa hattının giriş planıdır. Tipik sıra:

1. 1

   JSON okunur (parse)

2. 2

   Tablolar belleğe alınır (nodes, meshes, materials, …)

3. 3

   İndeks referansları çözülür

4. 4

   buffer → bufferView → accessor zinciri ile ham veri okunur

5. 5

   Mesh + BufferGeometry oluşturulur

6. 6

   Material + Texture bağlanır

7. 7

   Node hiyerarşisi sahne ağacına yerleştirilir

8. 8

   GPU kaynakları (VAO, texture upload) hazırlanır

Three.js tarafında GLTFLoader bu planı okuyup Scene, Mesh, SkinnedMesh ve AnimationClip nesneleri üretir. Loader’ın düğüm davranışı, skinning kurulumu veya materyal eşlemesi ayrı pipeline sayfalarında anlatılır; bu bölüm yalnızca JSON’un pipeline’daki yerini gösterir: parse edilir, referanslar çözülür, sonra unutulmaz; sahne artık motor nesneleriyle yaşar.

Bu ayrımı net tutmak önemlidir: JSON dosyası render edilmez; JSON render için talimat setidir. Hata ayıklarken «sahne boş» sorununu ayırmak için önce JSON’da scenes / nodes referanslarının tutarlı olup olmadığına bakılır; geometri görünmüyorsa sorun çoğu zaman accessor–buffer zincirindedir; organizasyon doğru, ham veri yanlış veya eksik olabilir.

glTF içindeki JSON bölümü sahnenin kendisi değildir. Sahnenin nasıl kurulacağını tarif eden bir plan, bir organizasyon katmanı ve bir bağlantı haritasıdır. Mesh’ler, materyaller, animasyonlar ve dokular JSON içinde doğrudan depolanmak yerine birbirlerine referanslarla bağlanır; render sürecinde motor bu haritayı okuyarak gerçek sahneyi oluşturur.

Bu çerçeveyi koruduğunuzda sonraki adımlar doğal olarak açılır: binary tarafta veri nerede duruyor (binary bufferlar), o veriye nasıl erişiliyor (bufferView, accessor), sahne düğümleri JSON’da nasıl konumlanıyor (ileride: Sahne Verileri grubu). Her biri ayrı sayfa; çakışma yok, derinlik var.