Bir 3D Modeli Web İçin Optimize Etme Sürecim
Modeli küçültmeden önce sorunun geometride mi, texture'da mı, materyalde mi yoksa yüklemede mi olduğunu anlamaya çalışıyorum.

İçindekiler
Önce teşhisDosyanın içine bakmakTexture'lar sürpriz olabilirGeometri ne zaman asıl sorunMateryal ve mesh sayısıYükleme biçimiÖlçmeden optimize etmekÜç varsayımsal teşhisMobil cihazlar için ek notlarBenim sıramKaliteden vazgeçmedenSık sorulan sorularSonuçÖnce teşhis
Bir modeli optimize ederken ilk refleks bazen polygon azaltmak oluyor. Ben ise artık önce problemin nerede olduğunu anlamaya çalışıyorum.
- Dosya neden büyük?
- Geometri mi fazla?
- Texture mı büyük?
- Çok fazla materyal mi kullanılmış?
- Gereksiz meshler mi var?
- Yoksa modelin kendisi değil, web tarafındaki yükleme biçimi mi problem?
Bu soruların cevabı optimizasyon stratejisini değiştiriyor.
Hekimlikten bir benzetme yapmak gerekirse, ağrı kesiciyle başlamak yerine önce tanı koymak lazım. Polygon azaltmak, texture'ı küçültmek ve yüklemeyi ertelemek üç ayrı ilaçtır; yanlış olanı seçersen hem zaman kaybedersin hem de modelin kalitesinden boşuna ödün verirsin. Bu yazıda dosyanın nerede şiştiğini nasıl buluyorum, her bulguya nasıl yanıt veriyorum ve sonuçta hangi sırayla ilerliyorum, onu anlatıyorum.
Dosyanın içine bakmak
Teşhisin ilk adımı, GLB dosyasının neyden oluştuğunu görmek. Bir GLB'nin içinde geometri verisi, görseller (texture'lar), materyal tanımları ve varsa animasyon bilgisi bulunur. Bunların her birinin dosya boyutundaki payı farklıdır.
Bu dağılımı görmek için elimde birkaç yol var:
- glTF dosyalarını inceleyen çevrimiçi görüntüleyiciler ve komut satırı araçları, dosyanın içindeki görsellerin çözünürlüğünü, mesh ve materyal sayısını listeleyebiliyor. glTF-Transform gibi açık kaynak araçların inspect komutu bu amaçla kullanılabiliyor.
- Blender içinde, Image Editor ve Outliner'ın Blender File görünümü üzerinden hangi görsellerin ne kadar büyük olduğuna bakabilirsin.
- Tarayıcının geliştirici araçlarındaki Network sekmesi, dosyanın sayfada gerçekte ne kadar sürede ve hangi sırayla indiğini gösterir.
Bu incelemenin sonunda genellikle üç şeyden biri çıkıyor: Dosyanın büyük kısmı texture'lardan geliyor, geometri gereğinden ağır ya da dosya boyutu makul ama yükleme biçimi kötü.
Texture'lar sürpriz olabilir
Özellikle texture'lar bazen düşündüğümüzden daha büyük bir yük oluşturabiliyor. Bu nedenle sadece modeli küçültmek yerine dosyanın tamamını düşünüyorum. Çoğu zaman geometriyi hiç azaltmadan sadece texture boyutunu ve formatını düzenleyerek dosya ciddi biçimde hafifleyebiliyor.
Texture tarafında sırasıyla şunlara bakıyorum.
- Çözünürlük: Her görselin ekranda gerçekte ne kadar yer kapladığını düşünüp gereksiz yüksek çözünürlükleri düşürüyorum. Küçük bir parça için büyük bir doku taşımak israftır.
- Format: JPEG, PNG ve WebP arasındaki seçim boyutu değiştirir. Temel renk gibi fotoğrafik içerikte kayıplı sıkıştırma çoğu zaman iş görür; keskin kenarlı ya da saydam içerik için ise kayıpsız format gerekebilir.
- Gelişmiş GPU sıkıştırması: glTF ekosisteminde KTX2 / Basis Universal tabanlı texture sıkıştırması bulunuyor. Bu yaklaşım, görseller GPU belleğinde de daha az yer kaplasın diye tasarlanmıştır. Ancak görüntüleyicinin bunu destekleyen bir yükleme yolu kullanması gerekir; kullanmadan önce hedef ortamda test etmek şart.
- Kanal birleştirme: Occlusion, roughness ve metallic bilgilerini tek bir görselde birleştirmek dosya sayısını azaltır.
- Kullanılmayan haritalar: Gerçekte etki etmeyen ya da tamamen beyaz-siyah bir haritayı taşımak yerine, tek bir sayısal değerle ifade etmek mümkün.
GPU belleği konusunda şu not düşülmeli: Bir görselin dosya boyutu küçük olabilir, ama ekran kartı belleğinde açılmış hali çözünürlüğe göre büyür. Bu yüzden diskte hafif görünen ama çözünürlüğü yüksek bir texture, özellikle telefonlarda sorun çıkarabilir. Kullanılmayan dokuları temizleme konusunu texture temizliği yazısında ayrıca ele aldım.
Geometri ne zaman asıl sorun
Eğer inceleme geometrinin dosya boyutunu ve çizim yükünü gerçekten belirlediğini gösteriyorsa, o zaman polygon tarafına geçiyorum. Burada sırayı şöyle tutuyorum: önce görünmeyen parçaları ve iç yüzeyleri temizlemek, sonra düz alanlardaki gereksiz bölünmeleri azaltmak, kıvrımlı kenarlarda silueti koruyarak segment sayısını düşürmek, son olarak da kaybolan yüzey hissini normal map ile geri vermek. Bu mantığı ve alınabilecek önlemleri kaç polygon kullanılmalı yazısında ayrıntılı anlattım. Düşük polygonlu bir modelin nasıl iyi görünebileceği için düşük polygon model yazısı da konuya dahil.
Geometri verisi için dosya düzeyinde de seçenekler var. Mesh sıkıştırma yöntemleri (Draco ve Meshopt) geometri verisini küçültür. Ama bunlar yükleme tarafında ek bir çözme işlemi gerektirir; küçük modellerde kazanç az, çözme maliyeti göze çarpabilir. Bu yüzden önce sıkıştırmanın gerçekten fark yaratıp yaratmadığını ölçüyorum.
Materyal ve mesh sayısı
Dosya boyutu makul olsa bile model, çok sayıda materyal ve mesh nedeniyle yavaş çalışabilir. Her materyal ve her ayrı mesh, tarayıcıda ayrı bir çizim işlemi demek. Bu yüzden şunlara bakıyorum:
- Aynı özellikleri taşıyan materyaller birleştirilebilir mi?
- Birbirine bitişik ve aynı materyali kullanan küçük parçalar tek mesh olarak birleştirilebilir mi? Ama renk değiştirme ya da animasyon gibi nedenlerle ayrı kalması gerekenleri birleştirmemek gerekir.
- Kullanıcının hiç görmeyeceği iç parçalar dosyada duruyor mu?
- Aynı nesnenin kopyaları (örneğin dört ayak) tek bir mesh'in tekrar kullanımıyla mı kurulmuş, yoksa her biri ayrı veri olarak mı saklanıyor?
Tüm bunlar, görüntüyü hiç değiştirmeden performansı iyileştiren düzenlemelerdir. Export aşamasında yapılacak temizliği Blender'dan GLB export yazısında anlattım.
Yükleme biçimi
Model hafif olsa bile yanlış zamanda yüklenirse sayfa yavaş hissettirebilir. Modeli yalnızca gerektiğinde yüklemek, yüklenirken bir poster görseli göstermek ve ilk görüntüyü beklemeden sayfayı kullanılabilir tutmak, optimizasyonun model dışındaki yarısı. Polygon tarafı için kaç polygon kullanılmalı yazısına bakabilirsin.
Yükleme tarafında alabileceğin önlemler şunlar:
- Poster görseli: Model yüklenirken kullanıcıya ürünün statik bir görüntüsünü göstermek, boş bir alan yerine anında içerik sunar. model-viewer bileşeninde bunun için poster özelliği bulunuyor.
- Gecikmeli yükleme: Model sayfa açılır açılmaz değil, kullanıcı o bölüme geldiğinde ya da ürünle etkileşime girmek istediğinde yüklenebilir. model-viewer'da loading ve reveal özellikleri bu davranışı yönetmeye yarar; ayrıntılar için model-viewer ile web sitesine 3D model ekleme yazısına bakabilirsin.
- Sunucu tarafı: GLB dosyasının doğru önbellek başlıklarıyla sunulması ve bir içerik dağıtım ağı üzerinden verilmesi tekrar ziyaretlerde yüklemeyi hızlandırır. Sunucu sıkıştırması, zaten sıkıştırılmış texture'lar için çok az kazanç sağlar ama geometri verisine yardımcı olabilir.
- Aynı sayfada çok model: Birden fazla model aynı anda yüklenip çalışıyorsa, birini aktif tutup diğerlerini poster olarak göstermek bellek ve işlemci yükünü azaltır.
Bu önlemler modelin kendisine hiç dokunmaz ama kullanıcının hissettiği hızı doğrudan değiştirir. Web'de 3D kullanırken sık yapılan yük hatalarını 3D ürünü web'de kullanırken yapılan hatalar yazısında ayrıca topladım.
Ölçmeden optimize etmek
Optimizasyonun en önemli kuralı, her adımdan önce ve sonra ölçmek. Neyi ölçüyorum?
- Dosya boyutu: Toplam ve texture ağırlıklı dağılım.
- Yükleme süresi: Gerçek bir bağlantıda ve tarayıcının ağ kısıtlama özelliğiyle yavaş bağlantı koşullarında.
- Akıcılık: Modeli döndürürken ve yakınlaştırırken takılma var mı?
- Görsel fark: Önceki ve sonraki hali yan yana koyup siluet, yüzey ve renk farkına bakmak.
Görsel farkı kontrol etmeden agresif optimizasyona gitmek, ürünün fark edilir şekilde bozulmasına yol açabilir. Tersine, ölçmeden "yeterince hafif" varsaymak da sayfanın gizli bir yavaşlık kaynağına dönüşmesine neden olur. Tek bir optimizasyonun işe yarayıp yaramadığını anlamanın yolu, değişiklikleri birer birer yapıp sonucu kaydetmek.
Üç varsayımsal teşhis
Teşhisin neden önemli olduğunu göstermek için üç kurgusal senaryo düşünelim. Rakam yok; yalnızca mantık.
Birinci senaryoda model görsel olarak sade, geometrisi ölçülü ama dosya çok büyük. İncelemede dört tane yüksek çözünürlüklü, ayrı ayrı kaydedilmiş harita görülüyor: temel renk, normal, roughness ve occlusion. Çözüm geometride değil. Çözünürlükleri kullanım mesafesine göre düşürmek ve roughness ile occlusion'ı tek görselde birleştirmek yeterli olabilir.
İkinci senaryoda dosya boyutu makul ama model döndürülürken telefonda takılıyor. İncelemede onlarca ayrı materyal ve çok sayıda küçük mesh çıkıyor. Burada sorun ağırlıktan çok parçalanmışlık. Materyalleri birleştirmek ve aynı materyali kullanan küçük parçaları tek mesh yapmak, geometriye dokunmadan akıcılığı artırabilir.
Üçüncü senaryoda dosya hafif ve akıcı, ama sayfa açılışında ürün alanı uzun süre boş kalıyor. Model sayfa yüklenirken diğer her şeyle yarışarak indiriliyor. Çözüm modelin dışında: poster göstermek, modeli gerektiğinde yüklemek ve önbelleği doğru kurmak.
Üç senaryoda da ilk refleks "polygon azalt" olsaydı, birinde gereksiz kalite kaybı, diğerinde hiçbir kazanç, sonuncusunda ise sorunun kaçırılması söz konusu olurdu.
Mobil cihazlar için ek notlar
Web'deki kullanıcıların önemli bir kısmı telefondan geliyor ve telefonlar masaüstüne göre daha sınırlı bir bellek ve işlemci bütçesiyle çalışıyor. Bu yüzden optimizasyonu zayıf cihaza göre yapmak mantıklı.
- Texture çözünürlüğü, dosya boyutundan bağımsız olarak GPU belleğini etkiler. Telefonlarda çok büyük texture'lar sayfanın kapanmasına ya da modelin hiç görünmemesine yol açabilir.
- Aynı anda birden fazla model göstermek mobilde daha pahalıdır. Katalog sayfalarında listeleme sayfasında posterler, detay sayfasında canlı model kullanmak makul bir yaklaşım.
- Dokunmatik kontroller ve sayfa kaydırma çakışabilir. Model alanına dokunmanın sayfayı kaydırmayı engellemesi kullanıcıyı rahatsız eder. Bunu 3D ürün görüntüleyici kontrolleri yazısında ele aldım.
- Test sırasında yalnızca tarayıcının mobil emülasyonuna güvenmemek, mümkünse gerçek bir telefonda denemek gerekir. Emülasyon ekran boyutunu taklit eder ama gerçek cihazın GPU davranışını taklit etmez.
Benim sıram
Sonuç olarak teşhis sonrası izlediğim sıra genellikle şu:
- Dosyanın içeriğini incele: geometri, texture, materyal ve nesne dağılımına bak.
- Kullanılmayan ve görünmeyen her şeyi temizle.
- Texture çözünürlüklerini ve formatlarını kullanım mesafesine göre düzenle.
- Materyal ve mesh sayısını makul seviyeye getir.
- Gerekirse geometriyi siluet bozulmadan azalt.
- Mesh ve texture sıkıştırmasını hedef ortamda test ederek uygula.
- Yükleme biçimini düzenle: poster, gecikmeli yükleme, önbellek.
- Mobil ve masaüstünde son testi yap.
Bu sıra bir dogma değil; teşhis sonucuna göre bazı adımlar atlanabilir ya da öne alınabilir. Ama önce temizlik ve texture, sonra geometri, en sonda yükleme sıralaması çoğu zaman en yüksek fayda ile en düşük kalite kaybını veriyor.
Kaliteden vazgeçmeden
Benim için optimizasyon, modelin kalitesinden vazgeçmek değil. Aynı görüntüyü daha verimli elde etmek.
Bu bakış açısı 3D işlerinde bence giderek daha önemli hale geliyor. Çünkü artık modeller sadece render alınan dosyalar değil.
Tarayıcıda çalışan dijital varlıklara dönüşüyorlar.
Bu dönüşümün pratik sonucu şu: Bir model artık hem estetik hem de teknik bir ürün. Sayfanın hızını, kullanıcının deneyimini ve markanın ciddiyetini aynı anda etkiliyor. Ürünün dışarıda nasıl göründüğü kadar, nasıl yüklendiği de önemli. Web'de 3D'nin avantajlarını web'de 3D ürün modeli kullanmanın avantajları yazısında, tasarım ile performans arasındaki dengeyi ise 3D web sitesinde tasarım ve performans yazısında ele aldım.
Sık sorulan sorular
Web için ideal GLB dosya boyutu kaç MB olmalı?
Evrensel bir sınır yok; ürüne, hedef kitleye ve sayfadaki yerine bağlı. Kural olarak sayfanın geri kalanıyla birlikte düşünülmeli ve gerçek bir mobil bağlantıda test edilmelidir. Önemli olan kullanıcı ilk içeriği beklemeden sayfayı kullanabilsin.
Önce texture mı, yoksa geometri mi küçültmeliyim?
Önce dosyanın içine bakıp neyin büyük olduğunu görmek gerekir. Birçok üründe boyutun çoğunu texture'lar oluşturur ve geometriye dokunmadan büyük kazanç sağlanır. Geometri asıl yük ise o zaman polygon tarafına geçilir.
Draco ya da Meshopt kullanmak şart mı?
Şart değil. Büyük geometri verisi olan modellerde fayda sağlayabilir, küçük modellerde kazanç az olabilir. Kullanmadan önce görüntüleyicinin ve yükleme kodunun bu sıkıştırmayı desteklediğinden emin olmak gerekir.
Poster görseli gerçekten fark yaratır mı?
Dosya boyutunu değiştirmez ama algılanan hızı değiştirir. Kullanıcı boş bir alan yerine anında ürünün görüntüsünü görür ve model arka planda yüklenir. Bu, özellikle yavaş bağlantılarda deneyimi belirgin biçimde iyileştirir.
Optimizasyondan sonra modelin renkleri değişti, normal mi?
Texture formatı ya da sıkıştırması değiştiğinde renk farkı oluşabilir. Özellikle renk alanı ayarları (temel renk için sRGB, veri haritaları için doğrusal) yanlışsa fark belirgindir. Önce ve sonra halini yan yana karşılaştırıp ayarları gözden geçirmek gerekir.
Optimizasyonu kim yapmalı, modelleyici mi web geliştiricisi mi?
İdeal olan ikisinin iş birliğidir. Model tarafındaki kararlar (geometri, texture, materyal) modelleyicide, yükleme ve önbellek kararları geliştiricidedir. Bu yüzden iş başlarken web hedefinin baştan belirlenmesi önemlidir.
Sonuç
Web için optimizasyon, "küçült" komutundan çok bir teşhis işi. Önce dosyanın neyle büyüdüğünü görüyor, sonra en az kalite kaybıyla en çok kazanç sağlayacak adımdan başlıyor ve her adımı ölçerek ilerliyorum.
Web'de kullanılacak bir ürün modelinin hazırlanmasında destek arıyorsan web için 3D ürün modeli hizmetine göz atabilir ya da ürününü anlatarak teklif isteyebilirsin.


Aklınızda bir proje mi var?
Proje talebi gönder →