holodepth

3D Model Formatları · FBX vs glTF · Karşılaştırma

Karakter Pipeline: Çift Raylı Teslim

«Karakteri FBX'te mi yoksa glTF'te mi kilitleyelim?» orkestra sorusu değil; yazarlık rayı ile runtime teslim rayının hangi dilde konuşacağıdır. Version Uyumsuzlukları aile kapısını kapattı; bu sayfa: karakter hattında FBX ile glTF seçimini anlatır.

Holodepth FBX vs glTF grubunun ilk ekseni karakterdir: skin, shape, take ve rig sözleşmesinin hangi formatta üretildiği ile hangi formatta oyuncuya/motor'a gittiği sıkça ayrılır. DCC Pipeline'daki Character Pipeline sahiplik ve kapıları anlatır; burada format çatalı vardır. glTF Skinning / Morph sayfaları paket şemasını; FBX Animasyon Sistemi stüdyo dilini işler. Bu sayfa ikisini yan yana koyup ne zaman tek ray, ne zaman çift ray sorusunu cevaplar.

Sayfayı bitirdiğinizde şu cümleyi kurabilmelisiniz: «Karakter hattında FBX çoğu zaman yazarlık ve motor köprüsüdür; glTF web/runtime paketidir. Çift ray bilinçli politikadır. Skin/morph/take her iki dilde de taşınır ama sözlük farklıdır. Erken glTF kilidi web'i hızlandırır, stüdyo zenginliğini kesebilir. Ara dönüşüm kayıp bütçesi ister. Web/motor/verimlilik derinliği sonraki sayfalardadır.»

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

Bu sayfa karakter tesliminde FBX ↔ glTF format seçimini anlatır:

  • Çift ray (yazarlık / teslim) modeli
  • Skin, morph, take karar yüzeyi
  • Tek format vs bilinçli çatal
  • Ara dönüşüm kayıp bütçesi
  • Holodepth karar matrisi

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

Kısa ayrım: Bu sayfa «karakterde hangi format?» · DCC Character Pipeline «kim hangi kapı?» · Web Kullanımı «tarayıcıda nasıl yaşar?»

Çift ray: yazarlık ve teslim

Karakter üretimi çoğu stüdyoda FBX (veya DCC native) rayında akar: MoCap, retarget, polish, face kanalları. Oyuncu veya web runtime ise glTF/GLB veya motor native ister. İki rayı tek «Final.fbx» ile zorlamak web'i cezalandırır; her şeyi erken glTF kilitlemek stüdyo araçlarını zorlar. Holodepth: çift ray suç değil, yazılı politikadır.

Aynı karakter, iki teslim dili konuşabilir; karışıklık dilsizlikten değil, dil seçiminin yazılmamasındandır.

Yazarlık rayında FBX neden kalır?

Autodesk kökenli interchange, zengin take setleri, stüdyo araç zinciri ve motorların geleneksel FBX kapısı yazarlıkta FBX'i doğal kılar. Constraint bake, MoCap solved paketleri, çoklu AnimationStack bu rayda yaygındır. glTF bu aşamada zorunlu hedef değildir; erken kilitlemek «web paketini DCC yerine koymak» anlamına gelebilir.

Teslim rayında glTF ne zaman öne çıkar?

Tarayıcı, Three.js/Babylon hattı, açık runtime sözleşmesi ve öngörülebilir skin/morph paketi glTF'i teslim diline çeker. Karakter web'e gidiyorsa production Final çoğu zaman GLB'dir; FBX ara workfile kalır. Motor-only ürünlerde FBX teslim rayında da kalabilir; bu Oyun Motorları sayfasının derinliğidir. Burada kural: teslim consumer'ı formatı seçer, alışkanlık değil.

Skin ve morph: iki sözlük, bir yüz

Her iki format da iskelet derisi ve şekil kanallarını taşır. FBX stüdyo lehçesinde cluster/shape channel; glTF'de skin joints/weights ve morph targets. Karar yüzeyi: hedef runtime hangi sözlüğü native konuşuyor? Web'de glTF sözlüğü doğrudan; FBX ek çeviri (ve Dönüşüm sayfasındaki ara hop riski) demektir. Yüz kanal isimlerinin extras'a inmesi veya index'e düşmesi çift rayın bilinen vergiidir; manifesto'ya yazılır.

Take vs animation clip

FBX AnimationStack çokluğu stüdyo arşivinde rahattır. glTF animations dizisi runtime clip modeline daha yakındır; fazla take'i olduğu gibi gömmek web bütçesini şişirir. Çift ray politikası: yazarlıkta geniş take seti, teslimde seyreltilmiş / seçilmiş clip'ler. Bu, Dosya Verimliliği'nin önizlemesidir; karakter kararı olarak «hangi take'ler glTF'e iner?» diye sorulur.

Tek ray ne zaman yeter?

  • Yalnız motor, FBX native: glTF zorunlu değil
  • Yalnız web, DCC doğrudan glTF yazıyor: FBX ara adım opsiyonel
  • Küçük ekip, tek consumer: çift ray maliyeti yüksek

Tek ray sadeleştirir; yanlış consumer'a tek ray dayatmak (web'e şişman FBX) Runtime sayfalarındaki semptomları üretir.

Bilinçli çatal: nerede ayrılır?

Tipik çatal noktaları:

  1. Rig onayından sonra (kadrolar sabit)
  2. Anim polish kapısından sonra (take listesi kilitli)
  3. LOD çatalında (hero FBX workfile, crowd erken glTF)

Çatalı her gece rastgele export'ta yapmak sadakat ve version pin'ini bozar. DCC Character Pipeline kapısı, format çatalını yeşil ışığa bağlar.

Köprü vergisi: FBX → glTF

Çift rayın maliyeti ara dönüşümdür: isim, materyal tavanı, constraint yokluğu, shape index kayması. Dönüşüm Problemleri bu yüzeyi semptom olarak anlatır; burada bütçe diline çevrilir: köprü vergisi kabul mü, yoksa doğrudan glTF yazarlık mı? Web-first ekipler ikinciyi; film/oyun hibritleri birincisi + checklist'i seçer.

Karar matrisi (özet)

  • Stüdyo DCC + motor FBX: yazarlık FBX, teslim FBX
  • Stüdyo DCC + web: yazarlık FBX (veya native), teslim glTF
  • Web-only + Blender: doğrudan glTF güçlü aday
  • MoCap ağır + çok take: yazarlık FBX; teslimde clip diyeti
  • Yüz kanalı kritik web: glTF morph + isim sözleşmesi erken kilitle

Sık seçim kırılmaları

  • «Her yerde FBX» politikası web parse/boyut cezasını gizler
  • «Her yerde glTF» stüdyo MoCap/aracını koparır
  • Çatal noktası yok; her revizyon farklı lehçe
  • Köprü vergisi ölçülmeden «glTF bozuk» denir
  • DCC orkestrasyon ile format seçimi aynı ticket'ta karışır

Holodepth perspektifleri

Ray etiketi

Her karakter paketinde «authoring format» ve «delivery format» alanları. Aynı dosya adı ikisini gizlemesin.

Köprü bütçesi

FBX→glTF için kabul edilen kayıp listesi (constraint yok, isimler extras, …) yazılıdır; sürpriz ticket azalır.

Teşhis maddeleri

  1. Asıl consumer web mi, motor mu, ikisi mi?
  2. Yazarlık rayı hangi format?
  3. Teslim rayı hangi format?
  4. Çatal hangi kapıdan sonra?
  5. Köprü vergisi kabul edildi mi?
  6. Take/shape diyeti teslimde uygulandı mı?

Holodepth içgörüsü

«FBX mi glTF mi?» karakter ticket'ında önce format fanatikliğini değil consumer rayını sorun. Yanlış rayda mükemmel paket yine yanlış istasyona varır.

Raylar net; sırada web yaşamı

Karakter hattında format seçiminin omurgası sabitlendi. Sonraki sayfa tarayıcı ve web runtime'da iki formatın nasıl yaşadığını açar: Web Kullanımı.

Format okuyucusu özeti: Karakter pipeline'da FBX ve glTF sıkça çift raydır. Yazarlık ile teslim ayrılır. Skin/morph/take iki sözlükte taşınır. Çatal ve köprü vergisi yazılı politikadır.