Three.js · Varlık · Draco
Karar verme noktası: Draco ne zaman kullanılmalı?
Draco kullanıp kullanmama kararı, aslında bir «bütçe yönetimi»dir. Elinizde iki bütçe vardır: kullanıcının internet kotası (bant genişliği) ve cihazının işlem gücü (CPU).
Önce genel tabloyu netleştirmek için Draco vs. standart glTF sayfasını okuyun; bu metin doğrudan ürün kararı ve sahne tipine indirger. İsteğe bağlı üst düzey tamamlayıcılar için bölüm 6 sona bırakıldı.
Büyük sahneler ve karmaşık geometriler
Projeniz tek bir objeden değil, yüzlerce parçadan oluşan bir sahneden (örneğin fabrika simülasyonu, mimari yapı veya detaylı şehir taraması) oluşuyorsa Draco çoğu zaman kaçınılmaz bir seçenek hâline gelir.
Veri yığını
Sahne büyüdükçe her bir glTF dosyasındaki vertex listesi ve ilişkili öznitelikler katlanarak büyür; toplam tel boyutu, kullanıcı için «sayfa açılmıyor» eşiğini hızla geçer.
Hattın (pipeline) verimliliği
Büyük sahnelerde Draco, toplam indirme boyutunu örneğin kabaca 100 MB → 10 MB bandına çekebilir (içerik ve ayarlara bağlıdır). Bu, sayfanın «hiç açılmaması» ile «birkaç saniyede yüklenmesi» arasındaki çizgiyi belirleyebilir.
Instancing ile kombinasyon
Sahnede aynı ağacın yüzlerce kopyası varsa (instancing), Draco o temel ağaç modelini bir kez sıkıştırarak ağ tarafında büyük kazanç sağlar; örnekleyici sayıları boyut bölümü ile birlikte düşünün.
Static mesh vs. dynamic mesh
Burada net bir teknik ayrım gerekir: Draco’nun en rahat kazandığı yer durağan ağ (static mesh) yapılarıdır.
Static mesh (ideal senaryo)
Nedir? Mimari yapılar, heykeller, dekoratif objeler gibi sahneye yerleştikten sonra geometrisi değişmeyen içerik.
Neden Draco? Bu objeler genelde bir kez decode edilir ve bellekte kalır; işlemci maliyeti yüklemenin ilk anında tek seferlik (one-time cost) ödenir. Sonuç: yüksek sıkıştırma, düşük ağ yükü.
Dynamic mesh ve animasyon (dikkat)
Nedir? Skinned mesh (karakterler), morph targets (yüz ifadeleri) veya çalışma anında sürekli değişen geometriler; Skinning hattıyla birlikte okuyun.
Riskler:
- Titreme (jittering): Düşük niceleme (quantization) değerleri, rig’e bağlı noktaların animasyon sırasında hafifçe titremesine yol açabilir — ayrıntı için Vertex quantization.
- Decode süresi: Çok sayıda morph target içeren bir modeli çözmek, durağan bir modele göre işlemciyi daha fazla yorar.
Karar: Dinamik modellerde bit bütçesini (Draco tarafında özellikle position) bir kademe yüksek tutun veya Draco’yu yalnızca gerçekten ağır karakterlerde tercih edin — Sıkıştırma parametreleri.
Kullanıcı cihaz profili (target device)
Kararı kilitleyen filtre çoğu zaman hedef cihazdır: aynı dosya farklı donanımda tamamen farklı hissedilir.
Profil → öneri
| Kullanıcı profili | Öneri | Neden? |
|---|---|---|
| High-end desktop | Draco (yüksek sıkıştırma) | CPU güçlüdür; internet hızı değişse bile çözüm genelde tolere edilir. |
| Bütçe dostu Android | Orta seviye Draco veya standart glTF | CPU zayıf olabilir; 2 MB’lık bir dosyayı çözmek 5 saniye sürerse kullanıcı sayfadan çıkar. |
| VR / AR gözlükleri | Kritik ölçüm şart | VR’da frame drop mide bulantısına yol açar; decode anında FPS düşmemeli — ölçüm zorunlu. |
Ölçüm ve işçi limitleri için Performans ve Web Worker ile kritik eksikler (bölüm 5) birlikte ele alınmalıdır.
Draco’yu pas geçmeniz gereken «red flag» durumlar
Aşağıdaki durumlarda standart glTF veya başka sıkıştırma / teslim stratejileri (Meshopt vb., araç ve hedefe göre) daha mantıklı olabilir:
- Küçük dosyalar: Toplam model boyutu kabaca 1 MB’ın altındaysa, Draco çözücü yükü (WASM + JS, kabaca ~150 KB ek) kazanç / kayıp dengesini bozabilir.
- CPU darboğazı: Sahnede ağır JavaScript hesapları veya güçlü bir fizik motoru (Cannon.js, Ammo.js vb.) varken bir de Draco decode yükü eklemek ana iş parçacığını veya bellek baskısını zorlayabilir.
- Hızlı prototipleme: Tek model deniyorsanız ve build pipeline (CLI / Blender) ile uğraşmak istemiyorsanız ham glTF ile başlamak makul olabilir.
Profesyonel özet
Holodepth yaklaşımı
«Veriyi sadece taşıyabiliyorsan sıkıştır.» Veri miktarınız bir kamyonu dolduruyorsa Draco o yükü pratikte bir çantaya indirebilir. Elinizde yalnızca bir poşet veri varsa, onu çantaya sığdırmak için harcadığınız efor, poşeti doğrudan taşımaktan daha maliyetli olabilir.
Gerçekten mini (opsiyonel polish)
Aşağıdaki başlıklar ana kararı değiştirmek için değil; yukarıdaki bölümleri üst düzeyde tamamlayan kısa notlardır. Ayrıntı tekrarından kaçınmak için mümkün olduğunda karşı sayfaya bağlanır.
GPU upload notu (dynamic mesh)
Bölüm 2’deki dynamic mesh tarafında, decode bittikten sonra vertex / indeks tamponlarının GPU’ya yüklenmesi (upload cost) ayrı bir maliyet kalemidir; animasyon kare başına bu yük değişiyorsa bütçe daha da sıkışır. Aynı ekseni tamamlamak için Draco vs. standart · GPU upload.
Decode kuyruğu (çok model)
Çok sayıda Draco dosyası aynı anda yüklenirken çözüm genelde sınırlı işçi üzerinden sıraya girer; pratikte bir decode queue oluşur. Önceliklendirme ve lazy load kararını bölüm 1 ile birlikte düşünün — çok varlıklı sahne notu.
Progressive loading sınırı
«Parça parça geometri gösterimi» beklentiniz varsa, tipik Draco mesh yükü tek başına kademeli akış vaat etmez; kısıt ve tasarım seçenekleri için Streaming başlığı.
Meshopt (kısa teaser)
Bölüm 4’te adı geçen Meshopt, farklı bir tel + çözüm felsefesidir; hedefiniz yalnızca boyut değil, belirli motorlarda decode hızı veya önbellek dostu düzen ise pipeline’da karşılaştırmalı değerlendirme yapılmalıdır. Holodepth’te ayrı sayfa henüz yok; resmi dokümantasyon ve dışarıdaki örnek projelerden doğrulayın.
Kare zamanı bütçesi (ileri seviye)
60 FPS hedefinde kabaca ~16,7 ms / kare üst sınırı düşünülür; VR / AR satırındaki «ölçüm şart» uyarısı bu yüzdendir: decode ve ardından gelen upload, o karenin içinde veya bitişiğinde yer kaplıyorsa frame time hemen şişer. Profil çıkarmada GPU ve CPU izlerini ayrı kanallardan okuyun.