3D Model Formatları · glTF / GLB · Web İçin Kullanım
Neden glTF? Web'de 3D Dağıtım Formatı Olarak Stratejik Seçim
«Blender'da mükemmel, tarayıcıda çöp» çoğu zaman motor hatası değil; web'e yanlış formatla çıkmaktır. Uzantılar grubu Variants ile dosya sözleşmesi omurgası kapandı; bu sayfa Web İçin Kullanım dalının ilk sorusuna geçer: 3D varlığı neden özellikle glTF ile dağıtmalıyız?
Holodepth'te «neden glTF» sorusu loader API'si veya tek bir uzantının iç yapısı değildir. Bu sayfa ürün ve mühendislik stratejisi katmanıdır: açık spesifikasyon, tarayıcıya yakın veri modeli, PBR + animasyon + geometrinin tek interchange paketinde buluşması ve geniş motor ekosistemi. JSON chunk, accessor byte offset veya Draco decode detayı burada değil; onlar File Structure ve Uzantılar dallarında kalır.
Sayfayı bitirdiğinizde şu cümleyi kurabilmelisiniz: «glTF, web için tasarlanmış açık bir 3D interchange formatıdır. Üretim formatı değil, dağıtım sözleşmesidir. Sahne, materyal, animasyon ve sıkıştırma uzantıları tek pakette taşınabilir; motorlar aynı dosyayı farklı runtime'a çevirir. GLB mi modüler glTF mi, boyut ve performans sonraki üç sayfada ölçülür; bu sayfa «neden bu format ailesi?» sorusunu kilitler.»
Bu sayfanın sınırı · komşu konularla ayrım
Bu sayfa glTF'nin web dağıtımı için stratejik gerekçelerini anlatır:
- Interchange vs üretim formatı ayrımı
- Web kısıtları (ağ, parse, bellek, GPU yolu)
- Açık spesifikasyon ve ekosistem uyumu
- Tek pakette sahne + PBR + animasyon hikayesi (üst seviye)
- Uzantılarla kademeli zenginleştirme (strateji, mekanizma değil)
- Ne zaman glTF, ne zaman alternatif format
- Holodepth teşhis ve karar açıları
Bilinçli olarak dışarıda bırakılan konular:
- GLB konteyner vs .gltf + harici URI → GLB vs glTF
- Byte / draw call / LCP boyut analizi → Dosya Boyutu Analizi
- Frame time, decode süresi, GPU upload → Runtime Performansı
- JSON / buffer / accessor omurgası → JSON Yapısı
- PBR alanları, textureInfo, material slots → Materyal Sistemi
- Keyframe, channel, skinning, morph → Animasyon Sistemi
- Extension mekanizması, Draco/BasisU decode → Uzantılar grubu
- GLTFLoader, scene graph kurulumu → glTF Pipeline (Three.js)
- FBX iç yapısı, OBJ face sözdizimi → FBX / OBJ dalları
Kısa ayrım: Neden glTF (Strateji) «format ailesini neden seçiyoruz?» · GLB vs glTF (Dağıtım) «hangi konteyner?» · File Structure (Sözleşme) «dosya içi alanlar nedir?» · glTF Pipeline (Runtime) «loader sahneyi nasıl kurar?»
Web İçin Kullanım hattı birinci soru
| Katman | Odak | Soru | Sayfa |
|---|---|---|---|
| 1 · Strateji | Format seçimi | Web'de neden glTF ailesi? | Neden glTF (bu sayfa) |
| 2 · Konteyner | GLB / .gltf | Tek dosya mı modüler paket mi? | GLB vs glTF |
| 3 · Boyut | Byte bütçesi | Ne kadar veri indiriliyor? | Dosya Boyutu Analizi |
| 4 · Performans | Runtime maliyeti | Parse ve GPU yolu ne kadar? | Runtime Performansı |
«Neden glTF?» sorusunun gerçek kapsamı
Zihin modeli: üretim atölyesi vs dağıtım kutusu
- Üretim formatı (FBX, .blend, USD stage): sanatçı, rig, shot düzenleme.
- Interchange / dağıtım formatı (glTF): son kullanıcıya gidecek paket.
- Runtime (Three.js sahnesi): paketi ekrana çeviren motor.
- Bu sayfa ortadaki kutunun neden glTF olduğunu savunur.
«Neden glTF?» sorusu üç farklı cevaba kayabilir; Holodepth'te bunları ayırmak çakışmayı önler. Birincisi teknik uyum: tarayıcıda JSON/binary okunabilir, GPU'ya yakın attribute düzeni, PBR alanları standart. İkincisi ekosistem: Khronos spesifikasyonu, validator araçları, Blender / Maya / Substance export yolları, Three.js / Babylon / Unity import. Üçüncüsü ürün maliyeti: tek dosya CDN'e koy, versiyonla, A/B test et; motor değişse bile varlık aynı kalır.
Bu sayfa «glTF nasıl parse edilir?» demez; «glTF ailesini seçmek hangi riskleri kapatır, hangi maliyeti kabul ettirir?» der. Parse ve sahne kurulumu glTF Pipeline'da; byte düzeni JSON Yapısı'nda kalır.
Üretim dosyasını doğrudan web'e koymak, PDF yerine Word'ün ham XML'ini ziyaretçiye vermek gibidir: çalışabilir ama kırılgandır. glTF «yayına hazır PDF» rolünü üstlenir; düzenleme hâlâ DCC'de kalır.
Web dağıtımının zorunlu kısıtları
Masaüstü oyun motoru ile tarayıcı vitrininin bütçesi aynı değildir. glTF'nin web argümanı bu kısıtlara bilinçli cevap vermesinden gelir; sihirli «her şeyi küçültür» iddiasından değil.
| Kısıt | Ne demek? | glTF yaklaşımı (üst seviye) |
|---|---|---|
| Ağ | Her byte indirme ve TLS maliyeti | Binary buffer, uzantılı sıkıştırma (Draco, BasisU); detay Dosya Boyutu'nda |
| Parse | Main thread'de JSON/binary okuma | GLB tek istek; modüler .gltf paralel fetch (konteyner seçimi GLB vs glTF'da) |
| Bellek | Mobil cihazda sıkı RAM tavanı | İndeks tabanlı paylaşım, tek bufferView paylaşımı (File Structure) |
| GPU yolu | Buffer → attribute → draw | Accessor semantiği WebGL/WebGPU ile hizalı geometri ( Vertex Verileri) |
| Güvenilirlik | Her ziyaretçide aynı görünüm | PBR core + yaygın KHR uzantıları; validator ile CI kapısı |
Holodepth vurgusu: glTF «sıfır maliyet» formatı değildir. Draco decode CPU yer, BasisU GPU decode ister, ağır morph hedefleri bellek yer. Stratejik «neden» şudur: bu maliyetler ölçülebilir ve standarttır; FBX'teki kapalı ikili veya özel eklenti bağımlılığı kadar öngörülemez değildir. Runtime maliyet tabloları Runtime Performansı sayfasına bırakılır.
LCP ve 3D (kısa köprü)
E-ticaret ve vitrin sayfalarında 3D model LCP'yi bozabilir. glTF seçimi tek başına LCP'yi kurtarmaz; konteyner, sıkıştırma ve lazy load birlikte tasarlanmalıdır. Bu sayfa «glTF ailesi LCP dostu olabilir» der; sayısal hedefler Dosya Boyutu ve Runtime Performans'ta ölçülür.
glTF 2.0 tasarım hedefleri: minimal core, genişleşen kenar
glTF 2.0, Khronos'un «JPEG of 3D» metaforuyla anılan açık interchange standardıdır. Çekirdek (core) kasıtlı olarak küçüktür: sahneler, node'lar, mesh primitive'leri, PBR metallic-roughness materyaller, skin, animasyon, görüntüler. Her şey indeks tabanlı dizilerde tutulur; bu da JSON organizasyon katmanının web dostu olmasını sağlar.
Core'da olmayan zenginlik extensions / extras ile gelir.
Holodepth'te uzantı mekanizması
Extension Sistemi'nde; Draco, BasisU, variants gibi
tek uzantı derinlikleri Uzantılar grubundadır. Stratejik «neden» açısından
önemli olan: core dosya her viewer'da açılır; uzantı desteklenmiyorsa graceful
fallback veya açık hata üretilebilir (
extensionsRequired sözleşmesi Extension Sistemi'nde).
- Minimal core = düşük uyumluluk riski, hızlı «ilk piksel»
- Extensions = üretim kalitesi ile web bütçesi arasında köprü
- extras = vendor metadata; ürün koduna güvenmeyin, taşıyıcıdır
Çoğu sitede atlanan açı: glTF «her özelliği core'a sıkıştırmaz»; bu bilinçli mimaridir. Film pipeline'ındaki USD'nin layer/composition gücü ile glTF'nin «ince, taşınabilir paket» hedefi farklıdır; web vitrininde ikinci hedef kazanır.
Tek pakette sahne: geometri, materyal, animasyon
Web'de 3D deneyiminin kırılganlığı çoğu zaman parçalı varlıkten gelir: OBJ + MTL + doku klasörü + ayrı animasyon; biri eksik kalınca model beyaz veya T-pose olur. glTF'nin stratejik gücü, bu parçaları tek sözleşme altında toplamasıdır.
| Katman | glTF'de (özet) | Holodepth derin sayfa |
|---|---|---|
| Geometri | mesh · primitive · accessor | Vertex Verileri |
| Materyal / PBR | materials · textures · images | PBR Yapısı |
| Hareket | animations · skins · morph targets | Keyframe Mantığı |
| Varyant / sıkıştırma | KHR uzantıları | Draco, BasisU |
Bu birleşim «monolitik oyun paketi» değildir; referans grafi hâlâ modülerdir (aynı bufferView birden çok accessor'da). Ancak dağıtım sınırında tek GLB veya tek .gltf kökü + URI seti ile versiyonlama basitleşir. Ürün ekibi «model v2.3» der; sanatçı ayrı MTL revizyonu takip etmez.
DCC → glTF → runtime el değişimi
Export anında kayıp olabilir (custom shader, legacy Phong). glTF seçimi bu kaybı sıfırlamaz; görünür ve test edilebilir kılar: validator raporu, referans viewer, Holodepth format sayfaları ile «dosyada ne var?» sorusu yanıtlanır. Runtime tarafında «sahneye ne kuruldu?» Material mapping ve Animation clips ile ayrılır.
Açık spesifikasyon: öngörülebilirlik ve QA kapısı
Kapalı veya «de facto» formatlarda «Blender'da iyi, web'de kötü» ayrımının kökü sıklıkla belirsiz export bayraklarıdır. glTF spesifikasyonu herkese açıktır; alan adları, zorunluluklar ve uzantı sözleşmeleri yazılıdır. Holodepth için bu, format okuryazarlığı ile CI validator aynı dilde konuşur demektir.
- glTF-Validator (veya eşdeğeri) build pipeline'a konabilir
- Regression: aynı asset'in v1 ve v2 diff'i JSON seviyesinde mümkün
- Vendor lock-in düşük: motor değişse dosya aynı kalır
- Hukuk / lisans: açık spec, telifsiz implementasyon hedefler
Çoğu eğitim içeriği «GLTFLoader kullanın»da durur. İleri seviye ekip «export + validate + golden screenshot» üçlüsünü glTF seçiminin gerçek ROI'si sayar. Bu sayfa o üçlüyü stratejik gerekçe olarak bağlar; validator komut satırı detayı araç dokümantasyonunda kalır.
Spec uyumu vs motor davranışı
Dosya spec'e uygun olsa bile viewer farklı ışık veya tone mapping uygulayabilir. glTF «görsel pixel-perfect garanti» vermez; veri anlamında garanti verir. PBR alanlarının ne taşındığı PBR Yapısı'nda; viewer farkları Three.js materyal sayfalarında. Stratejik sonuç: tartışmayı «hangi gizemli FBX flag'i?» yerine «hangi baseColorTexture eksik?» seviyesine indirgersiniz.
Uzantılarla kademeli zenginleştirme
Web'de «tek boyutlu asset» nadiren yeterlidir: mobilden gelen kullanıcı düşük polygon ister, masaüstü clearcoat ve 4K doku ister. glTF bunu aynı dosya ailesi içinde uzantı profilleriyle yönetmeye izin verir; ayrı FBX/OBJ kopyaları demek zorunda değilsiniz (variants ile materyal SKU'su da tek dosyada kalabilir: KHR_materials_variants).
Holodepth'te üç sık «web bütçesi» uzantısı:
- Draco geometri byte'ını düşürür; decode maliyeti vardır ( Draco Mesh Compression)
- BasisU / KTX2 texture GPU upload'unu hızlandırır ( KHR_texture_basisu)
- Variants çoğaltılmış mesh yerine materyal eşlemesi taşır
Stratejik karar: hangi uzantılar extensionsRequired olacak? Required
= desteklemeyen viewer dosyayı reddeder; Used = sessiz fallback. Web vitrininde
Required listesini kısa tutmak geniş uyumluluk sağlar; iç configurator'da Required
genişletilebilir. Mekanizma
Extension Sistemi'nde anlatılır; bu sayfa yalnızca
«uzantı profili = dağıtım stratejisi» bağını kurar.
glTF vs üretim formatları (web merceği)
FBX, OBJ, COLLADA, USD ve .blend dosyaları web'e «yanlışlıkla» da servis edilir. Holodepth format dalında her birinin kendi omurgası vardır; burada yalnızca web dağıtım merceğinden özet karşılaştırma yapılır, iç yapı tekrarlanmaz.
| Format | Web'de tipik sorun | glTF'ye göre |
|---|---|---|
| FBX | Kapalı ikili, ağır SDK, tutarsız PBR export | glTF açık, hafif parser, standart PBR |
| OBJ + MTL | Animasyon yok, doku yolu kırılgan, materyal sınırlı | glTF animasyon + gömülü URI / GLB |
| USD (film) | Tarayıcı stack'i ağır, composition karmaşık | glTF ince paket, doğrudan viewer hedefi |
| .blend | Kaynak dosya sızıntısı, büyük boyut, güvenlik | glTF yalnızca runtime gerekeni taşır |
«FBX her zaman kötü» demek doğru değildir: iç araçlar, Maya pipeline'ı, legacy oyun portu için FBX hâlâ üretim köprüsüdür. Holodepth kuralı: FBX (veya USD) üretimde kalır, glTF CDN'de kalır. Dönüşüm maliyeti (interchange tax) kabul edilir; kullanıcıya FBX indirtmek edilmez.
Interchange tax: dönüşüm maliyetinin ROI'si
Her export işçilik ve otomasyon ister: rig doğrulama, texture path düzeltme, Draco profili seçimi. Bu maliyet, web'de FBX parser bakımı + tutarsız materyal debug süresinden çoğu ekipte daha düşüktür. ROI ölçümü: «son üç ayda web'de format kaynaklı bug ticket sayısı» ile «export pipeline süresi» karşılaştırması. glTF seçimi teknik moda değil, operasyonel sadeleştirmedir.
Ne zaman glTF doğru seçim değildir?
Dürüst «neden glTF» yazısı, glTF'nin her sorunu çözmediğini de söyler. Aşağıdaki senaryolarda başka yol düşünün veya glTF'yi yalnızca ara katman olarak kullanın.
- Tamamen prosedürel sahne (shader ile üretilen geometri): dosya formatı minimal kalabilir; glTF «paket» gereksiz olabilir
- Nokta bulutu / Gaussian splat gibi glTF core dışı veri: uzantı veya özel binary; ekosistem henüz olgunlaşmadıkça riskli
- Film kalitesi shot pipeline (USD layer, variant set): web vitrinine export dalı ayrı tutulmalı
- Çok yüksek polygon + offline path trace: web'de yine glTF olabilir ama Draco/Lod stratejisi şart; «ham scan» doğrudan servis etmeyin
- Gerçek zamanlı collaborative edit: glTF snapshot; canlı state için CRDT / özel protokol gerekir
Holodepth içgörüsü: «glTF kullanmıyoruz çünkü özel formatımız var» cümlesi çoğu zaman özel formatın bakım maliyetini gizler. Özel binary yalnızca çok dar performans kazancı ve kapalı ekosistem varsa mantıklıdır; aksi halde glTF + seçilmiş uzantılar daha sürdürülebilir.
Holodepth perspektifleri: çoğu dokümanda olmayan açılar
«glTF açık formattır, PBR vardır» listesi yeterli değildir. Aşağıdaki açılar üretim ve ürün ekiplerinde sık tartışılır, az yazılı kaynakta bir arada bulunur.
CDN semantiği ve immutable asset
glTF/GLB dosyasını içerik hash'i ile adlandırıp (`chair-v3-a8f2.glb`) sonsuz cache süresi vermek, web stratejisinin parçasıdır. Modüler .gltf + harici bin/doku ile parça parça cache mümkün; yanlış URI güncellemesi «eski doku» bug'ı üretir. Konteyner seçimi GLB vs glTF'da; burada önemli olan glTF ailesinin statik varlık olarak CDN düşüncesiyle uyumlu tasarlanmasıdır.
Motor piyangası vs spec sabiti
Three.js, Babylon.js, PlayCanvas, Unity WebGL build hepsi glTF import eder; ancak uzantı desteği ve ışık varsayılanları farklıdır. glTF seçimi «tek motor kilidi» anlamına gelmez; spec sabiti motor değişiminde varlığı korur. Runtime farkları glTF Pipeline ve motor dallarında kalır.
Configurator ürününde glTF
E-ticaret 3D'de variants uzantısı tek GLB içinde renk/trim SKU'su taşır; ayrı model indirmek yerine runtime seçim yapılır. Bu, «neden glTF»nin iş modeli cevabıdır: depolama ve CDN maliyeti SKU sayısıyla lineer büyümez. Seçim API'si runtime'dadır; format yalnızca eşleme tablosunu taşır.
Erişilebilirlik ve SEO (3D vitrin)
glTF dosyası SEO metni değildir; ancak statik sayfada `
glTF 2.x omurgası ve gelecek uzantıları
Core 2.0 yıllardır stabildir; yenilik uzantı hattından gelir (meshopt, transmission, iridescence vb.). Web stratejisi «core'a güven, uzantıyı profille» şeklinde güncellenir; tüm spec'i yeniden öğrenmek gerekmez. Extension Sistemi kataloğu genişledikçe dağıtım profiliniz versiyonlanır (v1: yalnızca core, v2: +Draco, v3: +BasisU).
Yedi soruluk «neden glTF» teşhisi
| Soru | Evet ise glTF güçlü aday | Hayır ise düşün |
|---|---|---|
| Hedef platform tarayıcı mı? | Interchange hedefi hizalı | Native oyun paketi (glb yine olabilir) |
| PBR + doku + animasyon birlikte mi? | Tek paket avantajı | Prosedürel / statik mesh only |
| CDN'den statik servis mi? | Cache + versiyonlama kolay | Canlı DB blob (yine glTF olabilir) |
| Motor değişimi olası mı? | Açık spec sigortası | Kapalı özel format |
| CI'da validator koşacak mı? | QA kapısı mümkün | Manuel «gözle kontrol» |
| SKU / varyant sayısı yüksek mi? | Variants + tek dosya | Mesh başına kopya (pahalı) |
| Ekip format spec okuyabiliyor mu? | Holodepth omurgası + debug | Önce eğitim yatırımı planla |
Holodepth içgörüsü
«Neden glTF» tartışmasını loader benchmark'ında bitirmeyin. Üç cümlede kapanış: (1) Dağıtım formatı üretim formatından ayrıdır. (2) glTF web kısıtlarına açık spec ile cevap verir. (3) Boyut ve frame time sonraki sayfalarda ölçülür; strateji doğruysa ölçüm optimize eder, yanlışsa format değiştirmeyi gösterir.
Strateji kilitlendi; sıradaki dağıtım soruları
«Neden glTF ailesi?» sorusu yanıtlandı. Web İçin Kullanım hattının kalan üç adımı operasyonel detaya iner:
- Konteyner seçimi GLB vs glTF: tek istek mi, modüler fetch mi?
- Byte bütçesi Dosya Boyutu Analizi: mesh, doku, animasyon payları
- Runtime maliyeti Runtime Performansı: parse, decode, draw
Format omurgası (File Structure, Materyal, Animasyon, Uzantılar) bu stratejinin altında kalır; runtime uygulama glTF Pipeline (Three.js) ile tamamlanır.
Format okuyucusu özeti: glTF web için açık interchange standardıdır; üretim yerine dağıtım kutusudur. Core + uzantı profili ile tek pakette sahne taşınır; GLB/modüler seçim, boyut ve performans bu dalın devam sayfalarındadır.