3D dünyasının hafiflik sanatı: Mesh compression (temel)

Web tabanlı 3D projelerde en büyük düşman gecikme (latency)dır. Bir kullanıcının tarayıcısında 50 MB’lık ham bir 3D modelin yüklenmesini beklemesi, modern kullanıcı deneyimi ölçütlerinde zorlanır. Mesh compression şu üç temel sorunu hedefler:

• Bant genişliği tasarrufu: Mobil veri veya düşük hızlı bağlantılarda erişilebilirliği artırır.
• Hızlı sahne açılışı: GPU’ya gidecek veri küçüldükçe ilk kareye ulaşmak kolaylaşır.
• Depolama ve önbellek: Sunucu ve CDN maliyetini düşürür; tarayıcı önbelleğini verimli kullanmayı destekler.

Sıkıştırılabilen «şey» soyut bir «mesh» kelimesi değil; GPU’nun okuyacağı arabellek akışlarıdır. Three.js / glTF tarafında bunlar çoğu zaman geometri öznitelikleri ve bağlantı listesi olarak gelir; dokular ayrı kanaldır — doku boyutu için texture binding sayfasına bakın.

Köşe başına üç bileşenli uzay konumu (float vektörler). Sıkıştırma burada en çok kazanım sağlar çünkü tepe sayısı arttıkça bayt doğrusal değil, çoğu zaman daha hızlı büyür.

Yüzey yönü; aydınlatma ve shading için gereklidir. Draco aynı semantik ile bu kanalı da kodlayıp açar; ham dosyada ayrı dizi olarak duran her şey, sıkı pakette aynı rolü korur.

Doku adresleri. Sıkıştırılmış teslimatta doku dosyası küçülmez; küçülen çoğu zaman geometri telidir. İkinci UV seti (uv2) varsa o da aynı mantıkla ayrı bir öznitelik akışıdır.

Hangi köşelerin bir üçgen oluşturduğunu söyleyen dizinler. Bağlantılı (indexed) ağlarda tekrar eden köşe paylaşımı bu tabloyla gelir; sıkıştırıcı genelde tekrarları ve komşuluk yapısını topoloji + tahmin tarafında da ucuz temsil etmeye çalışır.

Bu kavramların bellek ve buffer düzenini bilmek, ham boyutu neden gördüğünüzü açıklar: Attributes & buffers.

Google tarafından geliştirilen Draco, 3D geometrik ağları ve nokta bulutlarını sıkıştırmak / açmak için açık kaynaklı bir koddur. «JPEG benzeri» söylemi yalnızca statik dosya boyutu düşüncesi içindir; işleyiş olarak görüntü sıkıştırmasından farklıdır — aşağıdaki üç adım, jenerik «bit düzeyi» cümlesinden daha somut tutar.

Sürekli float koordinatları, daha az bitle temsil edilen sınırlı bir ızgaraya yuvarlar. Bu adım kayıplı olabilir; ayar ne kadar agresifse oyun alanı o kadar küçülür, dosya o kadar ince kalır. Dışa aktarımda bu eşiği modelin mesafesine göre seçmek kritiktir.

Üçgen mesh’lerde bir köşenin konumu, komşu köşelerden tahmin edilebilir olunca aradaki fark küçük kalır. Kodlayıcı bu residual’ları saklar; böylece tekrar eden geometri «aynı sayıyı tekrar yazmak» yerine daha kısa farklarla taşınır.

Tahmin + niceleme sonrası kalan sembol dizisi, tekrar eden desenleri arithmetic coding / entropy coding ailesi ile tekrar sıkıştırılır. Yani önce geometriyi matematiksel olarak sadeleştirip, kalan bitleri de olasılık dağılımına göre inceltmek; saf «metin dosyasını ziple» benzetmesinin ötesine geçer.

Küçük dosya ✔️ mutlaka ucuz kare demek değildir: açma işi ana iş parçacığında veya WebAssembly işçisinde CPU harcar. Çok büyük tek mesh + agresif ayar, indirme süresini kısaltıp ilk çizilebilir kareye giden yolu uzatabilir.

Parça parça gelen baytlar hızlı bir «indiriliyor» hissi verse de, buffer’ı doldurmak için decode zinciri yetişmeyebilir. Özellikle mobilde ağ hızlı ama CPU sınırlıysa, oynatma döngüsü ile decode sırasını planlamamak takılma üretir.

Tel üzerinde taşınan paket küçülür; fakat açılan geometri yine aynı üçgen sayısına yakınsa VRAM’e yazılacak vertex/index hacmi kabaca aynıdır. Kazanç çoğu zaman transfer + önbellek tarafındadır, «aynı anda daha az çokgen sığdırma» anlamına gelmez.

Web’de Draco pratiği çoğu zaman glTF ile kesişir: geometri öznitelikleri KHR_draco_mesh_compression uzantısı altında kodlanır; dosyanın geri kalanında ise accessor / bufferView düzenine uygun meta veri taşınır. Yükleyici uzantıyı tanımazsa model ya düşer ya da yedek ham tampona döner — bu yüzden hem dosya hem çalışma zamanı sözleşmesini birlikte düşünmek gerekir.

Hayır. Örnekler: korektif CAD ölçümü, tıbbi mikroskobik ölçek, yoğun morph hedefleri olan sahne, çok sık dinamik güncellenen geometri — küçük farka bile tahammül yoksa ham veya daha hafif niceleme yolu tercih edilebilir. Mobil vitrin, AR hızlı açılış ve uzak plan ürün görüntüleyici gibi senaryolarda ise sıkıştırma çoğu zaman net kazançtır.

Ham ağ ile Draco / glTF tabanlı sıkıştırılmış teslimat arasındaki farkı tek bakışta görmek için aşağıdaki tabloyu kullanabilirsiniz; takas ve glTF uzantısı bölümleriyle birlikte okuyun.

Aşağıdaki sahne harici .glb / CDN modeli yüklemez; yüksek segmentli prosedürel küre üzerinde hafif displasman ile yoğun bir mesh üretir (tek parça, UV + normal dahil). Raw ve Draco düğmeleri gerçek encoder yerine aynı geometri üzerinde ölçülen temsil indirme / decode sürelerini ve sabit oranlı tel boyutu etiketlerini gösterir; üretimdeki rakamlar dışa aktarım ayarınıza göre değişir. Üçgen sayısı her iki modda aynıdır — GPU tarafında topoloji yükü eşdeğer kalır; fark tel hacmi ve CPU decode aşamasındadır.

Özetle: Holodepth gibi performans odaklı içeriklerde ham dev ağı tek başına taşımak, kamyon dolusu tuğlayı tek tek taşımaya benzer. Draco ve mesh compression ise paketlenmiş bir inşaat kiti gibi adrese daha hızlı ulaştırır; kullanıcı detayda kaybolmaz, hızın konforunu yaşar — tabii decode bütçesini animasyon döngüsü ile birlikte ölçtüğünüz sürece.