holodepth

3D Model Formatları · FBX · FBX Temelleri

Binary Yapı: İç İçe Kayıt Ağacı Olarak FBX

«Hex'te KaydaraFBX… gördüm, gerisi gürültü» gürültü değil; iç içe node record ağacıdır. Autodesk Kökeni kimliği sabitledi; bu sayfa: binary FBX'in bayt düzenine nasıl oturduğunu anlatır.

Holodepth'te binary yapı, glTF'deki JSON+chunk veya OBJ'deki satır listesi değildir. FBX binary, isimli kayıtların (record) özellik listesi ve çocuk kayıtlarıyla büyüyen bir ağaçtır. Scene Verisi «ağaçta hangi anlamlar var?» sorusunu; bu sayfa «ağaç diskte nasıl kodlanır?» sorusunu yanıtlar. SDK olmadan elle yazmak önerilmez; okumak için düzeni bilmek teşhis gücüdür.

Sayfayı bitirdiğinizde şu cümleyi kurabilmelisiniz: «Binary FBX header ile kimliklenir; gövde end-offset'li kayıt kayıtlarından oluşur. Her kayıt ad, özellik dizisi ve iç içe çocuklar taşır; null kayıt dalı kapatır. ASCII twin debug projeksiyonudur. glTF bufferView modeli değildir. Anlam Scene Verisi'nde; bayt düzeni burada.»

Bu sayfanın sınırı · komşu konularla ayrım

Bu sayfa FBX binary (ve ASCII twin) paket düzenini anlatır:

  • Header / kimlik baytları
  • Node record anatomisi
  • Özellik tipleri (kavramsal)
  • ASCII ↔ binary ilişki
  • Holodepth teşhis açıları

Bilinçli olarak dışarıda bırakılan konular:

  • Stüdyo / Autodesk kimliği → Autodesk Kökeni
  • Model, Geometry, Material anlamları → Scene Verisi
  • Skin / animasyon semantiği → Animasyon Sistemi
  • glTF buffer / accessor → Binary Buffers (glTF)
  • SDK API çağrıları → Autodesk dokümantasyonu

Kısa ayrım: Binary Yapı «bayt nasıl dizilir?» · Scene Verisi «kayıt adları ne anlama gelir?» · glTF Binary «chunk + bufferView»

İç içe klasör metaforu

Binary FBX'i düz byte dizisi gibi okumak yanıltır. Daha doğru imge: her «klasör» (kayıt) bir ad taşır, içinde etiketli kâğıtlar (özellikler) vardır, altında alt klasörler açılabilir. Dosya bitene kadar bu ağaç yürür. glTF'de JSON anahtarları + ayrı binary blob; burada anahtar ve veri aynı record diliminde iç içedir.

ZIP gibi tek sıkıştırma konteyneri değildir; isimli düğümlerin seriye dökülmüş hiyerarşisidir.

Header: kapıdaki tabela

Binary dosya tipik olarak sabit bir tanıtım dizisiyle açılır (pratikte «Kaydara FBX Binary» ailesi string'i). Ardından sürüm / uyumluluk için sayısal alanlar gelir. Header, loader'a «bu ASCII değil, binary FBX'im» der; yanlışlıkla metin parser'a sokulmasını engeller.

Holodepth teşhisi: hex başında beklenen tabela yoksa dosya bozulmuş, yanlış uzantılı veya ASCII FBX'tir. Tabela var diye sahne geçerli demek değildir; yalnızca kapı doğru türdedir.

Kayıt anatomisi: bitiş, özellik, ad, çocuklar

Her node record kabaca şu omurgayı taşır (sürümler alan genişliğini değiştirebilir; fikir sabittir):

  • End offset: bu kaydın (ve çocuklarının) dosyada nerede bittiği
  • Özellik sayısı / özellik listesi bayt uzunluğu
  • Kayıt adı: örneğin geometri veya bağlantı düğümü adı
  • Özellik dizisi: tip kodu + değer
  • Çocuk kayıtlar: aynı formatta iç içe
  • Null / sentinel kayıt: çocuk listesinin sonu

End offset, rastgele erişim ve atlama için kritiktir: bozuk uzunlukta tüm ağaç kayar. «Parse bozuk» ticket'ında sık suçlu, kaymış offset'tir.

Özellikler: tip kodu + yük

Kayıt adının yanındaki «kâğıtlar» tip kodlarıyla gelir: tamsayı, float, double, string, diziler (array) gibi aileler. Büyük geometri verisi çoğu zaman dizi özelliklerinde yığılır; küçük bayraklar skaler özelliktedir.

Bu sayfa SDK tip tablosunu satır satır kopyalamaz. Holodepth kuralı: her özellik önce tipini açıklar, sonra baytını yer. Tip'i yanlış okuyan parser sonraki tüm alanı çözer. Scene Verisi hangi adın hangi anlamda kullanıldığını; burada yalnızca taşıma zarfını sabitler.

Null kayıt: dalın noktası

Çocuk listesi sonsuz değildir. Biçim, «bu seviye bitti» diyen boş / sentinel bir kayıtla dalı kapatır. Eksik veya fazla null, ağacı erken keser veya sonraki kardeşe yapıştırır. Hex'te «anlamsız tekrar» sanılan bölgeler bazen bu sonlandırıcılardır.

ASCII twin: aynı ağaç, satır yüzü

ASCII FBX, aynı hiyerarşik modeli insan okunur sözdizimine döker: blok adları, süslü parantez veya girintili bölümler, özellik satırları. Binary'nin «debug projeksiyonu» gibidir; üretimde boyut ve parse hızı için binary tercih edilir.

Autodesk Kökeni'nde iki yüzden bahsedildi; burada ilişki netleşir: anlam ağacı ortak, kodlama farklı. Diff için ASCII, dağıtım için binary sık görülür. İkisini «farklı format» sanmak hata; aynı FBX kimliğinin iki yazımıdır.

glTF binary ile karıştırmayın

  • glTF: JSON tarif + (GLB'de) chunk'lı BIN blob; accessor/bufferView dilimler
  • FBX binary: isimli record ağacı; özellikler kayıt içinde
  • glTF: açık spesifikasyonla el ile izlenebilir
  • FBX: pratikte SDK ile güvenilir; elle yazım kırılgan

«İkisi de binary 3D» demek performans kıyasına yetmez; bellek modeli farklıdır. Dönüştürücü ağacı okur, glTF buffer'larına yeniden dizer.

Elle müdahale: neden yasak bölge?

End offset'ler birbirine bağlıdır. Bir string'i bir bayt uzatmak sonraki tüm ağacı kaydırabilir. OBJ'de satır silmek görece bağışlanır; FBX binary'de «küçük hex edit» çoğu zaman toplam göçmedir.

Holodepth: değişiklik DCC veya SDK üzerinden; hex yalnızca teşhis (header, sürüm ipucu, kayıt adı string'leri). Onarım iddiası yok.

Sürüm ve alan genişliği

Yıllar içinde kayıt başlığındaki tamsayı genişlikleri ve bazı kodlamalar evrilmiştir. Eski okuyucu yeni end offset boyutunu yanlış yorumlarsa ağaç çöker. Köken sayfasındaki versiyon ailesi burada layout uyumu olarak görünür.

Teşhis: «dosya açılmıyor» önce sürüm/export yılı, sonra bozukluk. Version Mismatch grubu pipeline tarafını; burada layout duyarlılığını sabitler.

Holodepth perspektifleri

String avı

Hex'te okunabilir kayıt adları (Geometry, Connections, …) haritada pusuladır. Anlamı Scene Verisi'nde; varlığı binary'nin ağaç olduğunu kanıtlar.

Boyut okuması

Büyük dizi özellikleri dosyayı şişirir; bu Runtime · Büyük Dosya konusuna köprüdür. Binary yapı «neden büyük?»in mekaniğidir; bütçe kararı orada.

SDK bir lüks değil

Öğrenme için düzeni bilmek; üretim için SDK şarttır. Kendi parser'ınızı yazmak eğitim projesidir, ürün omurgası değil (istisna: bilinçli dar okuyucu).

Teşhis maddeleri

  1. Header tabela doğru mu?
  2. ASCII mi binary mi (yanlış parser seçildi mi)?
  3. Sürüm / export yılı uyumlu mu?
  4. Dosya kesik mi (end offset dosya sonunu aşıyor mu)?
  5. Hex edit denendi mi (hemen vazgeçin)?
  6. Anlam sorunu mu, yoksa paket mi? (Scene'e yönlendir)

Holodepth içgörüsü

Binary FBX ticket'ında önce materyal panelini değil ağacın ayakta olup olmadığını sorun. Header ve offset çökmüşse scene semantiği konuşulmaz.

Bayt net; sırada anlam ağacı

Kayıt ağacının nasıl yazıldığı sabitlendi. Sonraki sayfa bu ağaçtaki isimli düğümlerin sahne dilini açar: Scene Verisi.

Format okuyucusu özeti: Binary FBX = end-offset'li iç içe kayıtlar + tip kodlu özellikler + null son. ASCII aynı ağacın satır yüzüdür. glTF chunk modeli değildir. Elle hex edit etmeyin; anlam Scene Verisi'nde.