Three.js · Varlık · Draco
Draco vs. standart glTF: gerçek dünya karşılaştırması
Bir 3B sahne oluştururken karşımıza çıkan temel soru şudur: «Hızlı bir indirme mi, yoksa hızlı bir görüntüleme mi?» Standart glTF (sıkıştırılmamış) veriyi olduğu gibi sunarken, Draco bu veriyi matematiksel bir bulmacaya dönüştürür.
Kavramsal çerçeve için Mesh compression · takaslar ve Ham · sıkıştırılmış tablo sayfalarına bakın; bu metin aynı fikirleri ürün ve ağ gerçekliği dilinde özetler. Tablonun ötesinde kalan boyutlar için bölüm 5 · kritik eksikler başlığına geçin.
Size (boyut) vs. load time (yükleme süresi)
Dosya boyutu, kullanıcı deneyiminin kapı eşiğidir. Draco burada mutlak bir üstünlüğe sahiptir.
Standart glTF
Veriyi raw (ham) ikili biçimde saklar. Dosya boyutu, vertex ve poligon sayısıyla kabaca doğrusal artar. Büyük modellerde yükleme süresi, internet hızına doğrudan bağlıdır.
Draco glTF
Geometriyi algoritmik olarak paketler. Özellikle yoğun mesh yapısına sahip modellerde %70–%90 aralığında bir küçülme sık görülür (içerik ve ayarlara bağlıdır).
Gerçek dünya örneği
Yaklaşık 1 milyon poligonluk bir heykel modeli düşünün:
- Standart glTF: örnek 40 MB — 4G bağlantıda indirme kabaca ~10–15 saniye.
- Draco glTF: örnek 4 MB — aynı koşullarda indirme kabaca ~1 saniye.
Rakamlar yuvarlak örnektir; ölçüm her sahne için zorunludur — fakat sıra büyüklüğü çoğu vitrinde tekrarlanır.
Zaman çizelgesi: aynı sahne, iki tel hattı
Bu sayfa geometri farkını değil, ağ + decode + ilk çizim takasını anlatır. Aşağıdaki laboratuvar harici .glb veya Draco WASM yüklemez; iki pipeline için kasıtlı bir zaman çizelgesi kullanır — üretimdeki süreler içerik ve cihaza göre değişir. Sol standart glTF (büyük ağ yükü, kısa decode); sağ Draco temsili (küçük indirme, uzun CPU decode). Aşama çubuklarını sürükleyerek veya Oynat ile izleyin; sonunda iki yarı da aynı prosedürel sahneyi gösterir.
Amaç: «Draco daha küçük ama daha geç görünür» cümlesini zaman ekseni üzerinde hissettirmek. Sol tarafta uzun ağ çubuğu, sağda kısa ağ + uzun decode; ortada bir pencerede sol sahne zaten ilk çizime gelmişken sağ hâlâ çözümde kalabilir (kurgu). Sağda decode çubuğu dolmadan mesh çizilmez; bittiği anda kısa bir pop-in ile vurgulanır. Üstteki İlk çizim süreleri temsil etiketidir. Son durumda iki yarı aynı küre + küpü çizer — fark tel hattındadır, şekil değil. Split oranı sabit %50; gerçek ölçüm için ağ ve Performance paneli şarttır.
CPU vs. bant genişliği: gizli takas
Bu karşılaştırmanın en can alıcı noktası, harcanan kaynağın türüdür.
Bant genişliği odaklı yaklaşım
Draco, bant genişliğini korur. Kullanıcı kitlesi mobildeyse veya zayıf altyapı bölgelerindeyse Draco bir lüks değil zorunluluk olabilir. Bu tasarruf bedava değildir; maliyeti CPU üstlenir.
CPU odaklı yaklaşım
Standart glTF, işlemciyi yormaz: veri indiği anda GPU-ready (ekran kartına gönderilmeye hazır) hâldedir. Draco ise indiğinde «anlamsız» bir veri paketidir; CPU (WASM üzerinden) bu paketi çözmek için yoğun mesai harcar.
Özet tablo
| Kriter | Standart glTF | Draco glTF |
|---|---|---|
| Ağ yükü | Çok yüksek | Çok düşük |
| İşlemci yükü | Minimum | Yüksek (decompression sırasında) |
| Görüntüleme hızı | Veri indiği an başlar | Çözme işlemi bittiğinde başlar |
| Batarya tüketimi | Düşük | Daha yüksek |
Hangisini, ne zaman seçmeli?
Her senaryo Draco için uygun olmayabilir. İşte Holodepth profesyonelleri için karar matrisi:
Standart glTF seçilmeli, eğer
- Modeliniz zaten küçükse (birkaç bin poligon): Draco’nun dosya boyutundaki kazancı, kütüphane yükleme maliyetinden (Draco decoder JS/WASM dosyaları kabaca ~100–200 KB) daha az olacaktır.
- Hedef cihazlar çok eski / düşük işlemci gücüne sahipse.
- Hızlı prototipleme yapıyorsanız ve ekstra loader karmaşası istemiyorsanız.
Draco glTF seçilmeli, eğer
- Modeliniz karmaşıksa (yüksek poligon, detaylı CAD verileri).
- Sayfanızda aynı anda onlarca farklı 3B varlık yükleniyorsa.
- Kullanıcılarınız mobil öncelikli ise ve First Contentful Paint (ilk anlamlı görüntüleme) süresini düşürmek istiyorsanız.
Teknik özet ve Holodepth notu
Teknik özet: denge sanatı
Draco vs. normal glTF tartışması bir network latency (ağ gecikmesi) ile compute latency (hesaplama gecikmesi) savaşıdır. Modern webde internet hızları artsa bile veri boyutları daha hızlı büyüdüğü için Draco genellikle galip gelir. Yine de unutulmamalı: en iyi sıkıştırma, gereksiz poligonları henüz Blender aşamasındayken silmektir.
Holodepth notu
Performans ölçümlerinizde (Lighthouse vb.) Total Blocking Time artıyorsa, Draco’nun CPU üzerindeki yükünü azaltmak
için setWorkerLimit ayarlarını gözden geçirmelisiniz — ayrıntı için
Performans ve Web Worker
sayfasına dönün.
Neden «final elite» değil?
Yukarıdaki tablo doğru yönde özetler; fakat üretimde karar verirken sık atlanan ek boyutlar vardır. Aşağıda, karşılaştırmayı tamamlayan kritik eksikler madde madde açılıyor.
GPU yükleme (upload) farkı
Önceki metinde «GPU-ready» ifadesi, çözülmüş tamponların anlamına gelir; GPU’ya aktarımın kendisi ayrı bir adımdır.
- Draco: ağdan gelen paket → decode → ortaya çıkan vertex / indeks tamponları → ardından GPU upload (bufferSubData vb.). İlk kare için kritik yol: indir + çöz + yükle.
- Standart glTF: ayrıştırma (parse) sonrası tamponlar zaten hedef biçimdedir; pratikte daha erken ve daha doğrusal bir upload hattı kurulabilir — yine de dosya büyükse ağ süresi bu avantajı gölgede bırakabilir.
Decode latency ve ilk çizim
«İlk piksel» veya ilk anlamlı mesh çizimi açısından ayrım netleşir:
- Draco: geometri ekranda görünmeden önce çözme gecikmesi mutlaka ödenir → gecikmeli ilk render (dosya küçük olsa bile).
- Standart glTF: tamponlar hazır olduğunda draw yolu açılabilir; ağ ve ayrıştırma bittiği ölçüde daha «anında» ilk çizime yaklaşırsınız — tabii ana iş parçacığı ve I/O düzeni ölçümle doğrulanmalıdır.
Bellek kullanımı: geçici sıçrama
Draco sıkıştırılmış tel, diskte küçüktür; fakat çözüm sırasında istemci genelde ara geometri temsilleri (decode çıktısı) için ek bellek ayırır. Sonuç: indirme bittikten sonra kısa süreli bir temporary memory spike (geçici bellek sıçraması) görülebilir. Standart glTF’de de ayrıştırma maliyeti vardır; fakat Draco’ya özgü çözüm + tampon katmanı mobil cihazlarda ölçüm gerektirir.
Streaming ve kademeli yükleme
Büyük sahnelerde «kullanıcı beklerken ne kadarını gösterebiliriz?» sorusu önem kazanır:
- Draco: tipik Draco ile kodlanmış mesh yükü, pratikte progressive (kademeli) bir geometri akışı sunmaz; çoğu akışta önce paket tamamlanır, sonra çözülür — parça parça «yarı çözülmüş çizim» modeli yaygın değildir.
- Standart glTF: tek başına sihirli değildir; yine de tamponlar ve chunk düzenine bağlı olarak kısmen kademeli (progressive) davranış kurgulanabilir (sunucu, loader ve dosya düzenine bağlı).
Önbellek (cache) davranışı
Varlık HTTP önbelleğinden gelse bile, Draco yükü çoğu uygulamada her oturumda yeniden çözülür — ağ tasarrufu kalır, fakat CPU / WASM maliyeti tekrarlanır. Çözülmüş geometriyi kendiniz bellekte veya IndexedDB gibi bir katmanda önbelleğe almadığınız sürece «diskte var = bedava» denklemi kurulamaz.
Worker bağımlılığı
Üretimde Three.js + GLTFLoader + DRACOLoader hattında çözüm çoğu kurulumda Web Worker ile yürütülür: bu, sadece «ek dosya» değil; worker havuzu, mesajlaşma ve ana iş parçacığı ile senkronizasyon demektir. Worker devre dışı veya kısıtlı ortamlarda (eski cihaz, katı CSP, gömülü WebView) Draco yolu risk taşır — ayrıntılar için Performans ve Web Worker.
Çok küçük model (edge case)
Kabaca < 100 KB altı, düşük poligonlu varlıklarda Draco bazen zararlı olabilir: decoder yükü + çözüm süresi, kazanılan birkaç kilobaytı geçer; ilk etkileşim süresi kötüleşebilir. Bu aralıkta önce ham glTF / GLB ölçün, sonra sıkıştırmayı karşılaştırın.
Çok varlıklı sahne: decode queue
Aynı sayfada çok sayıda Draco dosyası varsa, indirmeler paralel olsa bile çözüm genelde sınırlı worker veya tek kanala yakınsar → pratikte bir decode queue (çözüm kuyruğu) oluşur. Ana iş parçacığında kuyruk yönetimi zayıfsa, kare süresi dalgalanır. Çoklu varlıkta setWorkerLimit, önceliklendirme ve gecikmeli yükleme (lazy load) birlikte düşünülmelidir.