3D Ürünü Web'e Taşırken En Çok Yapılan Hatalar

Web tarafını en son düşünmek

Bence 3D'yi web'e taşırken yapılan en büyük hata, web tarafını en son düşünmek.

Modelleme, texture ve render bitiyor. Sonra "Bunu web'e de koyalım." Aslında problem burada başlıyor.

Çünkü render için hazırlanmış bir model ile web için hazırlanmış bir model aynı şey değil. Render sırasında bir görsel üretmek için dakikalar harcayabilirsiniz; web'de ise aynı sahnenin kullanıcının cihazında saniyenin çok küçük bir diliminde çizilmesi gerekiyor. Render'da milyonlarca polygon, birkaç yüksek çözünürlüklü doku ve karmaşık bir ışık kurulumu sorun değilken, aynısı bir telefon tarayıcısında ya hiç açılmıyor ya da takılarak açılıyor.

Bu farkı çalışmanın sonunda fark edenler genellikle iki seçenekle karşılaşıyor: ya modeli zorla hafifletip kaliteden ödün veriyorlar ya da ağır modeli olduğu gibi koyup kullanıcının beklemesini kabul ediyorlar. İkisi de keyifli bir yer değil.

Baştan farklı hazırlamak

Çünkü web modeli baştan farklı hazırlanabilir.

• Daha az polygon kullanılabilir.
• Texture'lar optimize edilebilir.
• Materyaller sadeleştirilebilir.
• Dosya boyutu kontrol edilebilir.

Ben bu yüzden kullanım alanını en başta belirlemeyi daha doğru buluyorum.

Pratikte bu, projenin ilk görüşmesinde sorulması gereken birkaç soruya dönüşüyor: Model nerede gösterilecek, ürün sayfasında mı, ana sayfada mı, bir AR deneyiminde mi? Kullanıcı ürünü ne kadar yakından inceleyecek? Renk ya da parça seçeneği olacak mı? Hedef cihazlar neler? Bu sorular netleşince polygon bütçesi, doku boyutları ve materyal sayısı için bir çerçeve çıkıyor. Soruların girdi hazırlığı tarafı ayrı bir yazının konusu, ama web hedefi o listenin en başında olmalı.

Aynı kaynaktan iki çıktı üretmek de mümkün: render için yüksek kaliteli sürüm, web için hafifletilmiş sürüm. Önemli olan bu ayrımın baştan planlanmış olması. Konuya modelleme ve görselleştirme farkı yazımda da değindim.

Tek cihazda test etmek

Bir başka hata da sadece güçlü bir bilgisayarda test etmek. Masaüstünde hızlı çalışan bir model mobilde aynı sonucu vermeyebilir. Bu yüzden web 3D'de hedef cihazı düşünmek gerekiyor; mümkünse orta seviye bir telefonda, mobil veriyle de denemek gerçek deneyimi gösteriyor.

Bu hatanın sinsi tarafı, geliştirme ortamının gerçek kullanıcı ortamından çok daha iyi olması. Yerel sunucudan yüklenen bir dosya anında geliyor; gerçek sitede ise aynı dosya bir CDN üzerinden, yavaş bir ağdan, bir telefon tarayıcısına iniyor. Güçlü bir ekran kartı pek çok kusuru gizliyor; telefondaki entegre grafik birimi ise aynı kusurları ortaya çıkarıyor.

Test ederken şu üç şeyi ayrı ayrı gözlemlemek faydalı:

• Yükleme süresi: Dosya indirilirken ne kadar beklendi? Ağ hızını tarayıcının geliştirici araçlarındaki ağ kısıtlama (throttling) seçenekleri ile simüle edebilirsiniz, ama gerçek bir telefonda denemek daha öğretici.
• Akıcılık: Modeli döndürürken görüntü takılıyor mu? Takılma varsa sorun polygon sayısı, doku boyutu, gölge ya da ışık maliyetinden biri olabilir.
• Bellek: Birden fazla model ya da sayfa art arda açıldığında tarayıcı yavaşlıyor ya da sayfa yeniden yükleniyor mu? Mobil tarayıcılar belleği sert sınırlıyor.

Gerçek cihaz yoksa bile en azından tarayıcının mobil emülasyon modunu ve CPU/ağ kısıtlamasını kullanmak, hiç test etmemekten iyi. Ama bu bir yaklaşım; gerçek donanımın yerini tutmuyor.

Dokuları gereğinden büyük tutmak

Web'de 3D modelin dosya boyutunu çoğu zaman geometri değil, dokular belirliyor. Her materyal için temel renk, pürüzlülük, metalik, normal gibi ayrı haritalar kullanılabiliyor ve her biri yüksek çözünürlükte ise dosya hızla büyüyor.

Burada önemli bir ayrım var: dosya boyutu ile bellek kullanımı aynı şey değil. Sıkıştırılmış bir PNG ya da JPEG dosya olarak küçük olabilir, ama GPU'ya yüklenirken açılır ve çözünürlüğüne göre bellek tüketir. Yani küçük görünen bir dosya, ekran kartı belleğinde beklenenden çok yer tutabilir. Doku çözünürlüğünü seçerken ekranda o dokunun kaç piksel kaplayacağını hesaba katmak gerekiyor. Küçük bir parça için büyük doku, görsel olarak hiçbir kazanç sağlamadan maliyet getirir.

Pratik adımlar:

• Doku boyutunu parçanın ekrandaki boyutuna göre seçmek.
• Birden fazla küçük parçanın dokusunu bir araya getirmek (atlas) ve malzeme sayısını azaltmak.
• Gerekmeyen haritaları kaldırmak. Düz bir plastik yüzey için ayrı bir normal haritası şart olmayabilir.
• Mümkün olan yerlerde yoğun sıkıştırma ve uygun dosya formatı kullanmak. GLB tarafında sıkıştırma seçeneklerini dosya formatları yazımda bulabilirsiniz.

Diğer sık hatalar

• Modeli sayfa açılır açılmaz, ihtiyaç olmadan yüklemek.
• Yükleme sırasında kullanıcıya hiçbir görsel geri bildirim vermemek.
• Sayfa kaydırma ile model döndürme hareketini karıştırmak.
• Her materyal için gereğinden büyük texture kullanmak.

Bunların çoğu optimizasyon sürecinde önceden önlenebiliyor.

Üstteki dört madde üzerinde biraz daha durayım, çünkü her biri kullanıcı deneyimini doğrudan bozuyor.

Gereksiz erken yükleme. Model sayfanın ilk ekranında değilse, kullanıcı oraya gelmeden indirmek mobil veri ve sayfa hızı açısından israf. Çözüm tembel yükleme: model görüntüleyici alanına yaklaşıldığında ya da kullanıcı bir etkileşim yaptığında yüklemek. Örneğin model-viewer bileşeni, yükleme zamanını yönetmek için "loading" özelliği ve poster görseli gibi seçenekler sunuyor; ayrıntı için model-viewer yazısına bakabilirsiniz.

Geri bildirimsiz yükleme. Dosya inerken boş bir kutu görmek, kullanıcıya sayfanın bozuk olduğunu düşündürüyor. Bir poster görseli, ilerleme göstergesi ya da en azından yer tutucu bir ürün fotoğrafı bu belirsizliği ortadan kaldırıyor. Bu görsel, modelin yüklenmesi bittiğinde yerini bırakıyor.

Scroll ve döndürme çakışması. Mobilde parmak hem sayfayı kaydırmak hem modeli döndürmek için kullanılıyor. Model ekranın tamamını kaplıyorsa kullanıcı sayfada mahsur kalıyor. Dönüş alanını sınırlamak, ilk dokunuşta etkileşimi etkinleştirmek ya da belirgin bir "kaydırarak devam et" alanı bırakmak sorunu azaltır. Bu konuyu kontrollerin tasarımı yazısında ayrıntılı ele aldım.

Büyük doku israfı. Yukarıdaki bölümde anlattım; hatayı gizleyen şey, masaüstünde hissedilmemesi.

Render ile aynı görüntüyü beklemek

Bir diğer sık yanılgı, web görüntüleyicide render'daki kalitenin birebir yakalanacağını beklemek. Render motoru ışığı fiziksel olarak hesaplar; web görüntüleyici ise gerçek zamanlı çalıştığı için yaklaşık yöntemler kullanır. Yansımalar, yumuşak gölgeler ve ışık sıçramaları aynı şekilde çıkmaz. Müşteri ile beklenti baştan netleşmezse, teslimde "render'daki gibi değil" şikâyeti kaçınılmaz oluyor.

Bunun sağlıklı yolu, web için ayrı bir görsel hedef koymak. Işığı ortam haritasıyla (HDRI tabanlı aydınlatma) kurmak, gölgeyi basit bir zemin gölgesiyle vermek ve malzemeleri PBR mantığında sade tutmak, gerçek zamanlı ortamda tutarlı sonuç veriyor. Ortam gölgesi gibi pahalı efektleri doku içine pişirmek (bake) de bazı durumlarda iş görüyor. Aydınlatma tarafında HDRI yazım işe yarayabilir. Gerçekçilik meselesine daha geniş açıdan web'de gerçekçi göstermek yazısında baktım.

Ayrıca aynı model farklı görüntüleyicilerde (bir web bileşeni, bir AR görüntüleyici, bir masaüstü uygulaması) biraz farklı görünebilir. Bu normal. Hedef ortamı seçip orada onaylamak, "her yerde aynı" hedefinden daha gerçekçi.

Ölçek, yön ve kamera çerçevesini ihmal etmek

Teknik olarak küçük ama kullanıcıyı hemen etkileyen birkaç hata daha var:

• Yanlış ölçek. Model Blender'da bir birim ölçeğiyle hazırlanıp farklı birimde dışarı aktarılırsa web'de ya minicik ya devasa görünür. glTF'de birim metredir; ölçüyü export öncesi kontrol etmek, özellikle AR kullanılacaksa önemli. Gerçek boyutlu gösterim AR yazısında anlattığım gibi doğru ölçekle anlam kazanıyor.
• Yanlış yön ve merkez noktası. Model eksende yan duruyor ya da dönüş merkezi nesnenin dışında kalıyorsa kullanıcı onu döndürürken ürün çerçeveden çıkıyor. Modelin orijinini nesnenin merkezine ya da zemin tabanına almak, ilk kamera açısını belirlemek gerekir.
• Kamera çerçevesi. Başlangıç kamera mesafesi çok yakın ya da çok uzaksa ürün kırpılıyor veya küçük kalıyor. Yakınlaşma ve uzaklaşma sınırları da belirlenmeli; yoksa kullanıcı modelin içine girebiliyor.
• Dönme sınırı olmaması. Ürünün altına bakmanın anlamsız olduğu durumlarda dikey dönüşü sınırlamak daha derli toplu bir deneyim veriyor.

Bu ayarlar tek başına pahalı değil; hepsi birkaç satırlık yapılandırma. Ama hiçbiri düşünülmezse deneyim amatör görünür.

Materyalleri web için sadeleştirmemek

Blender'da kurulan karmaşık materyal ağları web'de aynen taşınmıyor. glTF, sınırlı bir PBR modelini (temel renk, metalik, pürüzlülük, normal, doku tabanlı gölgeleme gibi) destekliyor; prosedürel dokular, karmaşık düğüm ağları ve render motoruna özgü efektler dışarı aktarılırken kaybolabiliyor ya da bozuluyor. Bunun yolu, bu tür materyalleri önce dokuya pişirmek (bake), sonra standart PBR bağlantılarıyla yeniden kurmak.

Materyal sayısı da önemli. Her materyal genellikle ayrı bir çizim çağrısı demek; çok sayıda küçük materyal render yükünü artırır. Aynı yüzey karakterine sahip parçaları tek materyal altında toplamak, performans için basit bir kazanım. Ama renk seçici gibi etkileşimlerde ayrı değiştirilebilir parçalar lazımsa, bu birleştirme bilinçli yapılmalı. Böyle bir ihtiyaç için Aura Reformer örneğine bakabilirsiniz: 6 ürün ve 57 renk gibi çok seçenekli bir yapıda malzeme düzenini baştan planlamak şart. Malzeme temelleri için PBR yazısı iyi bir ön okuma.

Fallback ve erişilebilirlik unutulduğunda

Tüm kullanıcıların cihazı 3D'yi taşıyamıyor. Eski bir telefon, veri tasarrufu modu, kısıtlı kurumsal bir tarayıcı ya da WebGL'nin devre dışı olduğu durumlar olabilir. Bu durumda 3D bileşenin yerine ne gösterileceği önceden düşünülmediyse sayfada boş bir alan kalıyor.

Bir düzenli yedek planı şunları kapsıyor:

• Model yüklenemezse görünen bir ürün fotoğrafı ya da render.
• Anlamlı bir alternatif metin; ekran okuyucu kullananlar için ürünün ne olduğunu anlatan bir açıklama.
• Hareket azaltma tercihini (prefers-reduced-motion) kullananlar için otomatik dönme gibi animasyonları kapatmak.
• Klavye ile erişilebilir kontroller; yalnızca fare ya da dokunmatikle çalışan bir arayüz herkese hitap etmiyor.

Bu önlemler çoğu zaman ek maliyet değil, bir yedek planı. 3D yoksa bile sayfa ürünü anlatmaya devam etmeli.

SEO ve içerik kaybı

Bir başka hata, ürünü yalnızca 3D görüntüleyici içinde göstermek. Arama motorları ve sosyal medya önizlemeleri 3D sahneyi yorumlayamaz; ürünün adı, açıklaması, özellikleri ve görselleri sayfa metninde ve statik görsellerde bulunmalı. 3D, ürün sayfasının yerini almamalı; sayfanın bir parçası olmalı.

Aynı şekilde sayfanın ilk açılışta kaydırma konumunu, yükleme sırasında yerleşim kaymasını (layout shift) da düşünmek gerekiyor. Model yüklenince sayfa içeriği aşağı kayıyorsa kullanıcı yanlış yere tıklayabilir. Görüntüleyici alanına baştan sabit bir en/boy oranı vermek bunu önler.

Hata yapmamak için kontrol listesi

Projeye başlamadan önce ve teslimden önce bakılabilecek kısa bir liste:

• Hedef kullanım (ürün sayfası, AR, ana sayfa) ve hedef cihazlar yazılı mı?
• Model web için ayrıca hazırlandı mı, polygon ve doku bütçesi belirlendi mi?
• Dosya boyutu ve doku çözünürlükleri ekrandaki gerçek boyuta göre mi seçildi?
• Model gerektiğinde, tembel olarak mı yükleniyor?
• Yükleme sırasında poster, ilerleme göstergesi ya da yer tutucu var mı?
• Mobilde kaydırma ile döndürme çakışması test edildi mi?
• Orta seviye bir telefonda, mobil veriyle denendi mi?
• Fallback görsel ve alternatif metin var mı?
• Ürün bilgisi 3D'nin dışında da sayfada metin olarak duruyor mu?

Bu listenin çoğunun cevabı, projenin başında verilirse ucuz; sonunda verilirse pahalı. Web tarafını en baştan düşünmenin temel gerekçesi de bu. Bir projeyi baştan web için kurmak istiyorsanız web için 3D ürün modeli hizmetinde süreç tam olarak bu sırayla ilerliyor. Hazırlık mantığı için ayrıca web sitesi için model hazırlama yazısına bakabilirsiniz.

Sık sorulan sorular

Sonuç

Web'de 3D'nin sorunlarının büyük kısmı sonradan değil, sürecin başında çözülebilen sorunlar: hedefi belirlemek, modeli buna göre hazırlamak, gerçek cihazda denemek ve yükleme deneyimini tasarlamak. Teknik olarak güçlü bir model, kullanıcıya ulaşana kadar yolda kaybolabiliyor; o yolu da tasarlamak gerekiyor. Projeniz için nereden başlanacağını konuşmak isterseniz teklif sayfasından yazabilirsiniz.

Bana göre iyi teknik süreç, işi yaptıktan sonra problemi çözmeye çalışmak değil. Problemi daha en başından tasarımın içine dahil etmek.

İlgili çalışmaAura ReformerÜrün Modelleme · Müşteri Çalışması · Blender · EEVEE · 6 ürün

İlgili çalışmaGemiSinematik kamera yolu · Blender · EEVEE · 1.500 kare · 24 fps