3D Web Sitesi Yaparken Tasarım mı Performans mı?

En zor denge

3D web projelerinde en zor dengelerden biri bu. Görüntüyü mümkün olduğunca etkileyici yapmak istiyorsun. Ama aynı zamanda sayfanın hızlı açılmasını da istiyorsun.

Bu gerilim iki yönden besleniyor. Tasarım tarafında her zaman daha fazlası mümkün görünüyor: bir yansıma daha, bir parçacık daha, daha yüksek çözünürlük, daha akıcı bir kamera hareketi. Performans tarafında ise sınır belli ama görünmez: kullanıcının cihazı, ağ bağlantısı ve tarayıcının bellek sınırı. Bu sınırı aştığınızda sayfa ya açılmıyor ya takılıyor ya da pil tüketiyor. Çoğu zaman da bunu sizin masanızda değil, kullanıcının elindeki orta seviye telefonda öğreniyorsunuz.

Dolayısıyla soru "ne kadar iyi görünsün" değil, "kimin cihazında, hangi koşulda, hangi bedelle" olmalı.

Doğru soru

Ben bunu "hangisinden vazgeçmeliyim?" diye düşünmek yerine "aynı etkiyi daha verimli nasıl oluşturabilirim?" diye düşünmeyi tercih ediyorum.

• Bazen ağır bir model yerine iyi bir kamera hareketi daha etkili olabilir.
• Bazen yüksek çözünürlüklü texture yerine doğru ışık daha iyi sonuç verebilir.
• Bazen de çok karmaşık bir animasyon yerine sade bir geçiş yeterlidir.

Bu üç madde aynı fikri farklı yerlerde söylüyor: kullanıcının algısı ile sistemin maliyeti her zaman orantılı değil. Bir sahnede izleyicinin gözünü tutan şey çoğunlukla ışığın yönü, kompozisyon ve hareketin ritmi. Polygon sayısı ya da doku çözünürlüğü bu algının küçük bir parçası. Maliyetin büyük kısmını harcadığınız şey, algıya katkısı en az olan şey olabilir.

Bütçe düşünmek

Performansı bir bütçe gibi düşünmek işe yarıyor: dosya boyutu, ekranda aynı anda çizilen nesne sayısı, ışık ve gölge maliyeti, mobil cihazın gücü. Bütçeyi bilince her görsel kararın bir maliyeti olduğunu görüyorsun ve en etkili yere harcıyorsun. Modeli hafifletme tarafı için optimizasyon, 3D'nin ne zaman gereksiz olduğu için bu yazıma bakabilirsin.

Bütçe fikri somut olunca daha kullanışlı. Bir proje başında şu kalemler için hedef belirlemek mantıklı (rakamları ben vermiyorum, çünkü hedef kitleye ve projeye göre değişir; önemli olan bir rakam koymanız):

• İndirme boyutu: Model, doku ve betiklerin toplam boyutu. Tek bir sayı belirleyin ve her eklemede kontrol edin.
• Çizim yükü: Ekranda aynı anda kaç nesne ve kaç materyal var. Her ayrı materyal ve nesne genellikle ayrı bir çizim çağrısı demek; çoğalınca işlemciyi yorar.
• Işık ve gölge: Gerçek zamanlı gölgeler ve çoklu ışık pahalıdır. Gölgesiz ama iyi hazırlanmış bir zemin gölgesi çoğu üründe yeterli olabilir.
• Kare hızı hedefi: Hangi cihazda akıcı sayılacağı. Orta seviye bir telefonda test edilebilecek bir hedef koymak gerekir.
• Bellek: Dokular açıldığında GPU belleğinde yer tutar; dosya boyutundan çok daha büyük olabilir.

Bütçe bir kural değil, karar aracı: yeni bir görsel öğe eklemek istediğinizde "bunun karşılığında neyi hafifletiyorum?" sorusunu sorduruyor.

Aynı etkiyi daha ucuza kurmanın yolları

Pratikte işe yarayan, görsel kaliteyi koruyup maliyeti düşüren yaklaşımları şöyle sıralıyorum.

Işığı önceden hesaplamak (bake). Gerçek zamanlı gölge ve global ışık yerine, gölge ve ortam gölgesini dokuya yazmak çok daha ucuz. Statik nesneler için bu genellikle iyi bir takas. Hareket eden parçalar için sınırlı kalır.

Ortam haritasıyla aydınlatma. Tek bir HDRI ortam haritası, yansımaları ve ışığı birçok ışık kaynağından daha az maliyetle verir. Ürün görünümünde malzemenin kalitesini en çok bu belirliyor. Konuyu HDRI yazısında işledim.

Geometriyi siluete harcamak. Polygon bütçesinin çoğunu görünür kenarlara ayırıp iç detayı normal map ve malzemeyle vermek. Düşük polygonla kaliteli görünmenin mantığını low poly yazımda anlattım.

Doku boyutunu ekran boyutuna göre seçmek. Ekranda küçük görünen parça için büyük doku, görsel kazanç olmadan bellek harcar. Doku sıkıştırma formatları da ciddi fark yaratabilir.

Geometri ve doku sıkıştırması. glTF için Draco ya da meshopt geometri sıkıştırması, KTX2 ise doku sıkıştırması sağlayabiliyor. Bunlar indirme boyutunu ve GPU belleğini düşürmek için bilinen araçlar; ancak her görüntüleyici veya kütüphane hepsini aynı biçimde desteklemez, hedef ortamda denemek gerekir. Format tarafı için dosya formatları yazısı bir başlangıç.

Gerektiğinde çizmek. Sahne sürekli değişmiyorsa, her karede yeniden çizmek yerine yalnızca bir şey değiştiğinde çizmek pil ve işlemci tasarrufu sağlar. Ürün görüntüleyici gibi durağan sahnelerde bu fark yaratır.

Piksel yoğunluğunu sınırlamak. Yüksek yoğunluklu ekranlarda tarayıcı çok fazla piksel çizmeyi gerektirebilir. Çizim çözünürlüğünün üst sınırını makul tutmak, görsel farkı çoğu zaman fark edilmeyecek şekilde performansı iyileştirir.

Varsayımsal bir karar örneği

Karar sürecini somutlaştırmak için varsayımsal bir senaryo düşünelim. Bir marka, ana sayfasında dönen bir ürün modeli, arkasında yumuşak bir ışık geçişi ve scroll ile yaklaşan bir kamera istiyor. Aynı zamanda sayfanın mobilde hızlı açılması da şart.

İlk bakışta üç ayrı istek var: model, ışık efekti ve kamera hareketi. Bütçe açısından her birinin maliyeti farklı. Model, indirme boyutunu belirliyor. Işık efekti, canlı hesaplanırsa işlemciyi yoruyor. Kamera hareketi ise neredeyse ücretsiz.

Bu durumda mantıklı bir dağılım şöyle olabilir: modeli web için sadeleştirip dokuları ekran boyutuna göre kısmak; ışık geçişini canlı hesaplamak yerine önceden hazırlanmış bir ortam haritası ve basit bir zemin gölgesiyle vermek; kamera hareketini ise cömert tutup etkiyi oradan almak. Böylece en pahalı kalemler küçülürken, kullanıcının gördüğü etki (yaklaşan, dönen, ışığı yakalayan bir ürün) büyük ölçüde korunuyor.

Mobil için ayrıca, scroll hareketini sadeleştirmek ya da modeli etkileşim sonrası yüklemek gibi bir ek karar gerekebilir. Bu noktada kuralı basitleştiriyorum: masaüstü deneyimi mobil deneyimin süslü hâli olmamalı, mobil deneyim masaüstünün kırpılmış hâli de olmamalı. İkisi aynı hedefe ayrı yoldan ulaşmalı.

Kademeli yükleme ve yedek planı

Performansı yalnızca "hızlı yüklensin" diye düşünmek yetmez; yükleme sırasında ne gördüğü de tasarımın parçası. Kademeli bir yaklaşım hem algılanan hızı hem gerçek hızı iyileştirir:

• Önce hafif bir poster görseli ya da statik render gösterilir; sayfa hemen anlamlı görünür.
• Model, görünür alana yaklaşıldığında ya da kullanıcı etkileşince yüklenir.
• Yükleme sırasında bir ilerleme göstergesi ya da hafif bir geçiş, kullanıcıya bir şeyin geldiğini hissettirir.
• Yükleme başarısız olursa ya da cihaz yetersizse poster görseli kalır ve sayfa yine ürünü anlatır.

Bu yapı, 3D'nin zorunlu değil, ek bir katman olduğu fikrine dayanıyor. 3D çalışsa da çalışmasa da sayfa işini yapıyor. Hazır bir bileşenle bu yapıyı kurmayı model-viewer yazısında örnek kodla anlattım.

Hareket, kamera ve animasyonda sadelik

Performans sorunlarının önemli bir kısmı animasyonlardan geliyor. Ama tasarım açısından da fazla hareket çoğu zaman gürültü yaratıyor. Şu sorular faydalı:

• Bu hareket kullanıcıya bir şey anlatıyor mu, yoksa sadece teknik gösteri mi?
• Aynı etkiyi basit bir geçiş ya da kamera kaymasıyla sağlayabilir miyim?
• Hareketi azaltmak isteyen kullanıcılar (işletim sistemi düzeyinde tercih bildirenler) için sayfa alternatif bir hâle geçiyor mu?

Hareket azaltma tercihine saygı hem erişilebilirlik hem de performans için olumlu. Scroll ile tetiklenen sahnelerde de aynı ilkeyi uyguluyorum: scroll tabanlı hareketin ne zaman anlamlı olduğunu ayrı yazıda ele aldım. Kısaca: scroll animasyonu bir hikâye anlatıyorsa değerli, sadece göz boyuyorsa maliyet.

Kamera hareketi ise çok ucuz bir araç. Aynı model, iyi planlanmış bir yaklaşma ve ışık değişimiyle sahnelenirse, geometriyi artırmadan sinematik bir etki verebilir. Bu yaklaşım, ürün animasyonlarında da geçerli; konuyu animasyon videosu yazısında ele aldım.

Ölçmeden karar vermemek

"Bence hızlı" ile "hızlı" aynı şey değil. Performansı hissiyatla değil, ölçerek değerlendirmek gerekiyor. Pratik araçlar:

• Tarayıcının geliştirici araçlarındaki performans ve ağ sekmeleri; indirme boyutu, yükleme sırası ve ana iş parçacığı yükünü gösterir.
• Ağ ve işlemci kısıtlama (throttling) seçenekleri; yavaş bağlantıda ve yavaş cihazda ne olacağını simüle eder.
• Sayfa hız denetim araçları; yükleme performansı ve yerleşim kaymaları gibi göstergeleri raporlar.
• Gerçek cihaz testi; orta seviye bir Android telefon ve eski bir iPhone gibi, tercihen mobil veriyle.

Burada kritik nokta, sonuçları sezgiyle yorumlamamak. Bir değişiklikten önce ve sonra aynı koşulda ölçüp karşılaştırmak, hangi karar işe yaradı sorusunu net cevaplıyor. Yaygın hataları web'e taşırken yapılan hatalar yazısında topladım.

Dengeyi bozan yaygın alışkanlıklar

Tasarım ile performans arasındaki dengeyi sessizce bozan birkaç alışkanlık var ve çoğu iyi niyetle yapılıyor:

• "Önce güzel yapalım, sonra hafifletiriz" demek. Hafifletme sonradan çoğu zaman görsel kayıp demek; baştan bütçeyle çalışmak daha az ödün gerektirir.
• Her şeyi en yüksek kalitede dışarı aktarmak. Küçük bir parça için bile en büyük doku seçilirse bütçe fark edilmeden şişer.
• Tek cihazda karar vermek. Güçlü bir bilgisayarda akıcı çalışan sahne, orta seviye telefonda takılabilir.
• Efekti amaç sanmak. Bulanıklık, parçacık ya da sonradan işleme efektleri, ürünü daha net göstermiyorsa dikkat dağıtır.
• Mobil için ayrı düşünmemek. Dokunmatik ekran, küçük alan ve sınırlı bellek ayrı bir tasarım gerektirir.
• Yedek planı atlamak. 3D yüklenemediğinde boş kalan bir alan, ürünü hiç anlatmayan bir sayfa demek.

Tasarım ve performans aynı masada olmalı

Bu dengeyi bozan en yaygın süreç hatası, tasarımın ve teknik uygulamanın ayrı aşamalar olması. Tasarımcı "bunu yapalım" diyor, geliştirici "bu ağır" diyor ve karşılıklı pazarlık sonuna kalıyor. Oysa kısıtlar baştan konuşulursa, tasarım o kısıtların içinde daha yaratıcı olabiliyor.

Pratik çerçeve şöyle: projenin başında bütçeyi ve hedef cihazı yazmak, tasarım fikirlerini bu bütçeyle sınamak, her büyük görsel öğe için kabaca maliyeti tahmin etmek ve prototipi erken aşamada gerçek cihazda denemek. Böylece son aşamada "bu çok ağır oldu" sürprizi çıkmıyor. Tekrar kullanılabilir bir temel kurmanın bu açıdan faydası büyük; bu yönelimi 3D web kitleri yazısında anlattım. Müşteri projelerinde ise web için 3D ürün modeli hizmetinin kapsamı, modelin görsel hedefi ile performans bütçesini birlikte belirlemeyi içeriyor.

Hepsini kullanmak zorunda değiliz

Teknoloji arttıkça her şeyi kullanmak zorunda olmadığımızı düşünüyorum.

Bugün tarayıcıda gerçek zamanlı yansıma, parçacık sistemi, sonradan işleme efektleri, fizik ve daha fazlası mümkün. Mümkün olması, ürün sayfasında ihtiyaç olduğu anlamına gelmiyor. Bir ürün sayfasının asıl işi ürünü net göstermek ve kullanıcının karar vermesine yardım etmek. Her ek efekt, bu işe katkı veriyorsa yerini hak eder.

Örnek olarak Aura Reformer gibi renk seçeneği yoğun bir çalışmada, görsel hedef ürünü ve renk seçimini net göstermek. Sahneyi gereksiz efektlerle yormak, bu hedefe hizmet etmiyor.

Sık sorulan sorular

Sonuç

Tasarım ile performans karşıt iki taraf değil; aynı bütçeyi paylaşan iki ihtiyaç. Bütçeyi baştan koymak, her görsel kararın maliyetini görmek ve gerçek cihazda ölçmek, "hangisinden vazgeçeyim" sorusunu "aynı etkiyi nasıl daha verimli kurarım" sorusuna çeviriyor. Projeniz için görsel hedef ve performans dengesini birlikte kurmak isterseniz teklif sayfasından yazabilirsiniz.

İyi tasarım bazen neyi kullanmayacağını bilmek.

İ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