Blender'da Texture Temizliği Neden Önemli?

Dosya büyüdükçe

Bir proje büyüdükçe Blender dosyasının içinde çok fazla materyal ve texture birikebiliyor. Bazıları artık kullanılmıyor ama dosyada görünmeye devam ediyor.

Bu küçük bir detay gibi geliyor ama proje düzenini ciddi şekilde etkiliyor. Bunun nedeni, bir ürün modelinin yaşam döngüsü: ilk denemede bir malzeme kuruluyor, beğenilmiyor, yenisi yapılıyor; bir doku yanlış çözünürlükte indiriliyor, doğrusu yükleniyor; aynı görsel iki farklı yoldan içeri alınıyor. Hiçbirini tek tek silmek aklınıza gelmiyor, çünkü o an önemli değil. Birkaç hafta sonra ise malzeme listesinde "Material.004", "Material.005" gibi adlar, aynı görselin üç kopyası ve hangisinin gerçekten kullanıldığı belirsiz bir yığın duruyor.

Bu birikim üç ayrı sorun yaratıyor: dosya boyutu büyüyor, doğru malzemeyi bulmak zorlaşıyor ve export sırasında istemediğiniz verinin dışarı sızma ihtimali artıyor.

Temiz proje ne demek?

Benim için temiz proje sadece güzel görünen proje değil. Nelerin kullanıldığını, nelerin artık gereksiz olduğunu bildiğim proje.

Kullanılmayan veri bloklarını temizlemek, materyalleri düzenlemek ve texture bağlantılarını kontrol etmek sonraki aşamaları daha kolay hale getiriyor. Temiz proje aynı zamanda başkasına devredilebilir proje. Altı ay sonra dosyayı yeniden açtığınızda ya da bir başkası açtığında, ne olup bittiğini anlamak için dosyayı baştan keşfetmek zorunda kalmamalısınız.

Blender veri bloklarını nasıl yönetir?

Temizliğin neden bazen "çalışmıyor" gibi göründüğünü anlamak için Blender'ın mantığını bilmek gerekiyor. Blender'da materyaller, görseller, mesh'ler gibi öğeler "veri bloğu" olarak tutuluyor ve her veri bloğunun bir kullanıcı sayısı var. Bir mesh bir materyali kullanıyorsa materyalin kullanıcı sayısı bir oluyor. Hiçbir şey kullanmıyorsa kullanıcı sayısı sıfırlanıyor ve bu veri bloğu "yetim" (orphan) sayılıyor.

Kullanıcı sayısı sıfır olan veri blokları dosyayı kaydedip kapatıp yeniden açtığınızda otomatik olarak silinir. Ancak bu yalnızca Blender'ı kapatıp açtığınızda olur; açık oturum boyunca listede görünmeye devam ederler. İstisna "Fake User" (sahte kullanıcı) ile işaretlenmiş olanlardır: bunlar kullanılmasa bile saklanır. Malzeme listesindeki kalkan simgesi bu işaretidir ve bilerek ya da yanlışlıkla açık kalmış olabilir.

Bu yüzden iki durumu ayırmak lazım:

• Gerçekten yetim olan, kullanıcısı olmayan veri blokları. Bunlar temizlik komutlarıyla silinir.
• Fake User ile korunan veri blokları. Bunlar kasıtlı olarak saklanmış olabilir; silmeden önce neden orada olduklarına bakmak gerekir.

Kullanılmayan veriyi bulmak ve silmek

Pratikte kullandığım yöntemler şöyle. Menü adlarının sürüme göre biraz farklılaşabileceğini baştan belirteyim; kendi sürümünüzde kontrol edin.

Outliner'da yetim veriyi görmek. Outliner'ın görüntüleme modunu değiştirince yetim veri blokları ayrı bir görünümde listelenir. Eski sürümlerde bu mod "Orphan Data" adıyla, yeni sürümlerde ise "Unused Data" adıyla geçiyor. Burada hangi materyallerin, görsellerin, mesh'lerin kullanıcısız kaldığını görebilirsiniz. Silmeden önce göz atmak, yanlışlıkla gerekli bir şeyi silme riskini azaltır.

Toplu temizlik. File menüsünde Clean Up altında "Purge Unused Data" seçeneği, kullanıcısı olmayan veri bloklarını tek seferde siler. Bu işlem bir dizi veri türünü etkiler; yeni sürümlerde açılan pencerede hangi türlerin silineceği seçilebiliyor. Kaydetmeden önce yapmanızı öneririm, çünkü işlem geri alınabilse bile büyük bir silmeden sonra emin olmak istersiniz.

Materyal slotlarını kontrol etmek. Bir nesnede boş ya da kullanılmayan materyal slotları kalabiliyor. Yüzeylere atanmamış slotlar export sırasında gereksiz materyal olarak çıkabiliyor. Nesne özelliklerinde materyal sekmesinden slotları gözden geçirmek ve kullanılmayanları kaldırmak iyi bir alışkanlık.

Fake User kontrolü. Orphan görünümünde kalkan simgesi açık olan öğeleri not edin. Gerçekten saklanması gerekmiyorsa Fake User'ı kapatıp ardından temizliği çalıştırmak gerekir.

Kopya texture'ları birleştirmek

Yetim veriden daha sinsi bir sorun, kopya veri. Aynı görsel dosyasını iki kez içeri aldığınızda Blender ikinci kopyaya ".001" gibi bir uzantı ekler ve bu iki bağımsız görsel veri bloğu olarak durur. Her ikisi de kullanılıyorsa, yetim olmadıkları için purge onları silmez. Sonuç: aynı doku iki kere bellek ve dosya boyutu tüketiyor.

Bunu temizlemek için önce hangi materyallerin hangi kopyayı kullandığını bulmak, sonra Image Texture düğümlerini tek bir görsele yönlendirmek gerekiyor. Ardından kullanılmayan kopya yetim kalır ve temizlenir. Aynı mantık materyaller için de geçerli: "Material.001" ve "Material" adlı iki neredeyse özdeş malzeme varsa, nesneleri tek malzemeye bağlayıp diğerini silmek düzeni sadeleştirir.

Dikkat edilecek bir nokta: iki görselin adı farklı olsa bile aynı dosyadan geliyor olabilir ve tersi de geçerli. Emin olmak için görselin dosya yolunu ve boyutunu Image Editor'de incelemek gerekiyor.

Eksik ve kırık dosya yolları

Texture'lar Blender dosyasına gömülü değilse dış dosya olarak bağlanır. Proje klasörünü taşıdığınızda ya da başka bir bilgisayara aktardığınızda bu yollar kırılabilir ve materyaller mor-pembe görünür. Bunun için File menüsündeki External Data altında şu işlevler işe yarar:

• Report Missing Files: Eksik dosyaları listeler.
• Find Missing Files: Seçtiğiniz bir klasörde eksik dosyaları arayarak yolları düzeltir.
• Make Paths Relative: Dosya yollarını .blend dosyasına göre bağıl hale getirir; klasörü taşıdığınızda yollar bozulmaz.
• Pack Resources: Dış dosyaları .blend içine gömer. Dosyayı tek parça olarak göndermek istediğinizde işe yarar ama boyutu artırır.

Hangi yöntemin doğru olduğu duruma bağlı. Üretim sırasında bağıl yollar ve düzenli bir klasör yapısı genelde en rahat çözüm. Dosyayı arşivlerken ya da başkasına gönderirken ise paketlemek daha güvenli.

Adlandırma düzeni

Temizliğin sessiz ama etkili parçası isimlendirme. "Material.012" ya da "Image.003" gibi adlar ne olduğunu anlatmıyor. Bunun yerine ürün parçasını ve yüzey türünü anlatan bir düzen kullanıyorum, örneğin gövde için "govde_boyali_metal", doku için "govde_basecolor", "govde_roughness", "govde_normal" gibi. Tam adlandırma kuralı kişiden kişiye değişir; önemli olan tutarlı olması.

Düzenli adlandırmanın somut bir faydası var: GLB'ye dışarı aktarırken materyal adları dosyaya taşınıyor. Web tarafında bir kod ile belirli bir materyalin rengini değiştirmek istediğinizde, "Material.005" yerine "govde_boyali_metal" adını bulmak çok daha kolay. Renk seçici gibi etkileşimler kuruyorsanız bu adlar doğrudan işin parçası oluyor; çok renkli ürünlerde, örneğin Aura Reformer çalışmasında, hangi materyalin hangi parçaya ait olduğunun anlaşılır olması düzeni büyük ölçüde kolaylaştırıyor.

Yaygın hatalar ve nasıl önlenir

Temizlik sırasında sık yapılan birkaç hata var ve çoğu, aceleyle işlem yapmaktan çıkıyor.

• Purge'ü kaydetmeden çalıştırmak. Bir şey yanlış giderse dönüş noktanız olmaz. Önce dosyayı kaydedin ya da sürümlü bir kopya alın.
• Yedeksiz çalışmak. Teslim dosyasını temizlerken kaynak dosyayı ayrı saklamak, ileride bir malzemeyi geri istediğinizde kurtarıcı olur.
• Fake User'lı öğeleri gözden geçirmeden silmek. Bilerek saklanmış bir malzeme varsa, onu silip sonra aramak zaman kaybıdır.
• Paketlenmiş (packed) dokuları unutmak. Dosyaya gömülmüş görseller, dış dosya gibi görünmez ama dosya boyutuna doğrudan yansır. Ne kadar yer kapladığını görmek için kaydedilmiş dosyanın boyutuna bakmak yeterli ipucu verir.
• Her şeyi tek hamlede düzeltmeye çalışmak. Önce bir kategori (örneğin materyaller), sonra diğeri; böylece hangi değişikliğin neyi etkilediğini görebilirsiniz.
• Kopya materyalleri silerken atamaları kontrol etmemek. Bir nesne silinen materyalin yerine boş slot bırakabilir ve render ya da export'ta beklenmedik bir varsayılan görünüm çıkar.

Küçük bir örnek akış

Varsayımsal bir senaryo ile akışı somutlaştırayım. Bir ürün dosyasında gövde için iki farklı metal materyali denendiğini ve ikisinin de listede durduğunu düşünelim. Ayrıca aynı normal map dosyası iki kere içeri alınmış, bu yüzden listede hem "govde_normal" hem "govde_normal.001" var.

İlk adım Outliner'da görünümü yetim veriye çevirip neyin kullanıcısız olduğuna bakmak. Reddedilen metal materyali burada görünüyorsa tamam, purge ile gidebilir. Ama kopya normal map, bir materyal tarafından kullanıldığı için yetim görünmeyecektir. İkinci adımda hangi materyalin hangi kopyayı kullandığını bulup düğümü tek görsele yönlendirmek gerekiyor. Üçüncü adımda artık kullanıcısız kalan kopya purge ile temizleniyor. Dördüncü adımda kalan materyal ve dokular anlamlı adlarla yeniden adlandırılıyor. Son adımda dosya kaydedilip deneme amaçlı bir GLB export yapılıyor ve çıktı bir görüntüleyicide açılıp bakılıyor.

Burada ilginç olan, purge'ün tek başına işin ancak bir bölümünü çözmesi. Gerisi gözle kontrol ve bilinçli düzenlemeden geliyor.

Dosya yapısı ve klasör düzeni

Blender içindeki temizlik, dosya sistemi düzeniyle birlikte düşünülürse daha kalıcı oluyor. Her proje için aşağıdakine benzer sade bir yapı işimi kolaylaştırıyor:

• Kaynak .blend dosyası, çalışma sürümü.
• Dokular için ayrı bir klasör; ham ve işlenmiş dokular karışmasın.
• Referans görselleri için ayrı bir klasör.
• Export edilen çıktılar (GLB, render görselleri) için ayrı bir klasör.

Bu yapının getirisi şu: Blender dosyası bağıl yollar kullandığında klasörü taşımak sorun çıkarmaz ve hangi doku dosyasının hangi projeye ait olduğu belli olur. Referans fotoğraflarının düzeni de modelleme kalitesini etkiliyor; konuya referans fotoğrafı yazımda değindim.

Temizlik rutini

• Kullanılmayan materyalleri ve texture'ları tespit etmek.
• Aynı görsele bağlı kopya texture'ları birleştirmek.
• Materyal ve texture isimlerini anlaşılır hale getirmek.
• Eksik ya da kırık dosya yollarını düzeltmek.

Bu rutin özellikle export öncesinde işe yarıyor; ayrıntılar için Blender'dan GLB export yazıma bakabilirsin. Rutinin sırası da önemli: önce kopyaları birleştirmek, sonra adlandırmak, en son yetimleri purge etmek. Çünkü kopyaları birleştirmeden purge yaparsanız hiçbir şey silinmez; purge'ü en başta yaparsanız da birleştirme sonrası oluşan yeni yetimleri kaçırırsınız.

Export öncesi temizlik

Çünkü bir dosyayı web'e, müşteriye veya başka bir programa gönderiyorsam gereksiz veriyi de taşımak istemiyorum.

Export öncesinde ek olarak şunlara bakıyorum:

• Texture çözünürlükleri ihtiyaca uygun mu? Küçük bir ayrıntı parçası için gereğinden büyük doku kullanıldıysa küçültmek dosya boyutunu belirgin biçimde etkiler. Web tarafı için ayrıntıları optimizasyon yazımda anlatıyorum.
• Kullanılmayan UV kanalları ya da vertex renk katmanları kaldı mı? Bunlar da export'a gidebiliyor.
• Görünmez ya da gizlenmiş nesneler seçili export kapsamında mı? Export ayarlarındaki "sadece seçili nesneler" ya da görünür nesneler seçeneklerini kontrol etmek gerekir.
• Doku bağlantıları gerçekten glTF'nin desteklediği yapıda mı? Karmaşık düğüm ağları glTF'ye aynen aktarılmaz; yalnızca standart Principled BSDF bağlantıları sağlıklı çıkar. Malzeme tarafı için PBR malzeme yazım faydalı olabilir.
• UV'ler temiz mi? Dokuların doğru oturması için UV açma aşamasını gözden geçirmek gerekir.

Düzenli proje dosyası aslında üretim hızını da artırıyor. Bir şeyi tekrar aramak zorunda kalmamak bile uzun vadede ciddi zaman kazandırıyor. Üretim sürecimde bu temizliği 3D ürün modelleme teslimlerinin standart parçası olarak görüyorum.

Sık sorulan sorular

Sonuç

Texture ve materyal temizliği gösterişli bir iş değil, ama dosyanın güvenilir kalmasını sağlıyor. Hangi verinin nerede kullanıldığını bildiğinizde hata ayıklamak, export etmek ve teslim etmek kolaylaşıyor. Önce kopyaları birleştirin, isimleri düzenleyin, yolları kontrol edin, en sonunda yetimleri temizleyin ve hedef formatta bir deneme export'u yapın.

Bir ürün modelini temiz bir dosya yapısıyla ve web'e hazır şekilde teslim almak istiyorsanız teklif sayfasından ihtiyacınızı iletebilirsiniz.

Düzen, hızın düşmanı değil; hızın zemini.

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