holodepth

Babylon.js · Mesh & materyal

Texture sistemi: örnekleme, mip ve adresleme

Holodepth'te WebGL ve Three.js tarafında doku genelde piksel verisi + örnekleme kuralları olarak öğretilir; doğrudur. Babylon.js perspektifinde ise aynı düşünce, çoğu zaman sahne ve materyal yaşamına bağlı bir GPU kaynağı olarak yönetilir: dosya yolu, güncelleme döngüsü, gamma yorumu ve adresleme — hepsi üretim kararıdır.

Bu sayfa bitmap ansiklopedisi değildir; her başlıkta bir "özel yapı" netleşir: UV uzayı, mip piramidi, sarma modları ve renk verisi vs ölçüm verisi ayrımı. Uzunluğu tablolar ve kısa listelerle dengeledik.

Özet: dokunun dört boyutu

Boyut Soru Tipik karşılık
Konum Koordinatta hangi renk okunur? UV ile örnekleme; filtre ve mip seçimi.
Sınır UV 0–1 dışına çıkınca ne olur? Tekrar / kes / ayna — adres modları (wrap).
Anlam Piksel değeri «renk mi, ölçüm mü?» sRGB vs lineer; kanal paketleri ( PBR · ORM).
Ömür Bellek ve güncelleme nasıl yönetilir? Doku nesnesi dispose; dinamik doku için güncelleme ritmi.

UV ve örnekleme: piksel değil, koordinat

Üç boyutlu yüzeyde her nokta, tipik olarak iki sayıyla (u, v) dokudaki bir konumu işaret eder; bu sayılar çoğu zaman 0 ile 1 arasında normalize edilir. Önemli özel yapı: doku çözünürlüğü ile UV aralığı farklı şeylerdir — aynı 0–1 aralığı hem 512² hem 4096² bir görüntüye bağlanabilir; kalite ve bellek sonucu değişir. Aynı şekilde UV ölçeği (döşemede 0–1'i kaç kez tekrarladığınız) da çözünürlükten bağımsızdır: sık döşenen düşük çözünürlüklü doku, seyrek döşenen yüksek çözünürlüklü dokudan farklı örüntü frekansı üretir.

Örnekleme (sampling), belirli bir UV noktasında komşu piksellerin ağırlıklı karışımıdır. Eğik yüzeylerde veya uzaktaki küçük dokuda tek piksel seçmek (en yakın komşu) çizgili titreme yapar; bu yüzden üretimde çoğu zaman düzgünleştirilmiş filtreleme kullanılır. Üçgen köşelerindeki UV değerleri interpolasyonla piksele taşınır; yani örnekleyici yalnız dosyaya değil, ekran üzerinde komşu piksel mesafesine de duyarlıdır — bu duyarlılık mip seçimi ( bir sonraki bölüm) ile birleşir.

Matematiksel ayrıntı Holodepth WebGL texture mapping maddesinde açılır; burada yalnızca şunu sabitleriz: görüntü «dosyadaki tek piksel» değil, koordinat + filtre + mip kararının birleşimidir.

  • Önce koordinat: kayma ve çatlak çoğu zaman çözünürlük değil, UV dikişi veya atlas yerleşimidir — örgü tarafı için VertexData · özel örgü disiplinine bakın.
  • Filtre seçimi: dünya uzayı ölçeği küçülen yüzeylerde en yakın komşu hızlı görünür ama titremeye yol açar; UI ikonları hariç üretimde dikkatli kullanın.
  • Tanı: titreme yalnız uzakta görünüyorsa önce mip; her mesafede görünüyorsa önce filtre ve UV sürekliliği.

Mip zinciri: önceden filtrelenmiş piramit

Mipmap, dokunun yarım ölçek, çeyrek ölçek… diye inen kopyalarından oluşur. GPU, yüzeyin ekrandaki küçük ayak izine göre uygun seviyeyi seçer; böylece uzak dokuda yüksek frekanslı detay tek tek piksel titremesi üretmez. Zincir yoksa veya zayıfsa görüntü «uğultulu» veya parıltılı görünür. Eğik yüzeylerde aynı doku farklı yönlerde farklı küçülme görebileceği için, donanım çoğu zaman seviye seçimini türevlere dayalı yaklaştırır; bu da neden döşeme ve hareket halinde titremenin birlikte ele alındığını açıklar.

Özel yapı: mip üretimi çoğu zaman kare boyutları ve üst sınır kurallarına bağlıdır; döşeme dokularında (tiling) her iki eksende tutarlı sarma modu seçmezseniz mip seviyelerinde dikiş kayması görebilirsiniz. NPOT (iki kuvveti olmayan) genişliklerde motor veya sıkıştırma aracı mip zincirini kısıtlayabilir; üretimde boyut sözleşmesi, görsel kaliteden önce öngörülebilir mip sağlar.

Anizotropik filtre, özellikle yere yakın perspektifte uzun ince ayak izlerinde mip'in faz agresifleşmesini yumuşatır; maliyeti vardır ve her platformda aynı üst sınırda çalışmaz — «her zaman aç» yerine hedef sahne ile doğrulayın.

  • Zincir eksik: uzakta parıltı / tarama; yakında aslında doğru görünüp uzakta çözülen sahte «doku bulanıklığı».
  • Döşeme + mip: u ve v için aynı sarma mantığı; ayrıntı Adres modları ile birlikte düşünülür.
  • Normal haritası: mip bazen yüksek frekanslı detayı erken eritir; üretimde normal için ayrı mip politikası gerekebilir — bu sayfa tek kanal reçetesi vermez, riski işaretler.

Atlas ve mip

Bir dosyada çok küçük alt bölgeler taşıyorsanız, mip düşerken komşu bölgeler birbirine bleed edebilir. Çözüm çoğu zaman atlas dolgusu veya ayrı dosyadır; tam atlas rehberi bu sayfanın kapsamını aşar — yalnız mip + komşuluk etkileşimini unutmayın.

Sarma ve adres modları: UV sınırını aşmak

Adres modu, UV 0–1 dışına taştığında donanımın davranışını belirler: tekrar (wrap), son piksele kenetlen (clamp), aynala ( mirror). Aynı doku hem döşeme zemini hem tek parça etiket için kullanılacaksa mod seçimi tasarım kararıdır — yanlış mod, görünmez «fay hatları» üretir. Clamp sırasında çoğu API, köşe piksel rengini sonsuza uzatır; kenar yumuşatması için kenar rengi ( border color) veya dolgulu atlas tercih edilir — motor başına isim değişir, fizik aynıdır.

Mirror simetrik örüntülerde dikişi gizlemek için caziptir; fakat tekrarlayan desende faz sıçraması veya yarım texel kaymasıyla «orta çizgi» artefaktı üretir. Sorun bazen mod değil, UV merkezlemesidir; mod değiştirmeden önce ölçeği kontrol edin.

  • Tekrar: tuğla, kumaş örüntüsü; UV ölçeği ile örüntü sıklığı.
  • Kenet: atlas veya tek kullanımlık alan; kenarda süzülme ( bleeding) riskine dikkat.
  • Ayna: zemin karoları, metal paneller; simetride kısa yol, döşemede faz hizasına duyarlıdır.

Aynı görsel, iki kullanım

Bir dosyayı zeminde wrap, UI plaketinde clamp ile kullanmak yaygındır; bunun için çoğu zaman aynı dosyayı iki doku örneği olarak açıp parametreleri ayırmak gerekir — tek örnekte mod çatışmasını beklemeyin. Bu sayfa Babylon API'sini anlatmaz; yalnız davranış farkını sabitler.

Renk uzayı: sRGB görsel vs lineer veri

İnsanın gördüğü «doğal» parlaklık ile shader'ın hesapladığı lineer uzay aynı değildir. Yüzey rengi (albedo) için görseller çoğu zaman sRGB olarak saklanır ve işlenirken doğru yola çevrilmesi beklenir. Oysa normal, metalik, pürüzlülük gibi kanallar «güzel görünen fotoğraf» değil ölçüm taşır; bunları renk fotoğrafı gibi gamma ile çözerseniz aydınlatma bozulur. HDR ortam veya fiziksel doğru karışımda hata, çoğu zaman «bir ton daha koyu» değil; speküler kenarların erimesi veya gölgelerin dolmaması gibi ikinci derece belirtilerle ortaya çıkar.

Bu ayrım Holodepth PBR materyal sayfasındaki kanal rolleriyle birleşir: tek dosyada birden fazla anlam taşıyan dokular ( ORM) için yanlış uzay, tek kanalı bile yanlış okutabilir. Aynı dosyada R kanalı bir anlamda gölgelenme, G kanalı başka anlamda pürüzlülük taşıyorsa, «dosyayı lineer aç» demek yeterli değildir; kanal bazında motor bayrağı ve ihracat ayarı eşleşmelidir.

Emissive gibi «ışık üreten» görünümler bazen ayrı gamma beklentisi taşır; motor ve içerik aracı çifti aynı varsayımda değilse parlaklık iki katına çıkar veya tüner gibi düşer — burada tek doğru tablo yok; ihracat şeması + motor örneği ile doğrulama şarttır.

  • Renk hissi: albedo, bazı emissive görselleri — çoğu zaman sRGB düşünün.
  • Ölçüm: normal yönü, metal–rough, yükseklik — lineer / veri yolu; görsel düzenleyicide «güzel» histogram aldatıcıdır.
  • Şüphe listesi: aynı materyalde bir kanal doğru iken diğeri yanlışsa önce paketleme ve uzay; sonra çözünürlük.

Pratik teşhis

Malzeme «soluk» veya kontrastı düşük görünüyorsa önce hangi dokunun renk, hangisinin veri olduğunu ve motorun o dokuya hangi renk uzayı varsayımıyla baktığını kontrol edin — çözünürlük artırmak çoğu zaman çözüm değildir. İki motor arasında yan yana kare açıyorsanız, önce ortam (IBL) ve ton eşlemesini eşitleyin; aksi halde «gamma hatası» sandığınız fark aslında ışık içeriği eksikliği olabilir.

Çözünürlük, sıkıştırma ve bant genişliği

Mobil web'de her ek megabit yükleme süresi ve her ek örnek çağrısı kare süresidir. Gözenekli sıkıştırma formatları (GPU'nun desteklediği yollar), mümkün olduğunda bellek ve bant avantajı sağlar; fakat renk kanalı düzeni ve şeffaflık bazen içerik hazırlama sürecini karmaşıklaştırır — teknik seçim ve tasarım süreci birlikte yürür. Aynı çözünürlükte bile sıkıştırma ailesi farkı, normal haritasında blok artefaktı üretebilir; «en küçük dosya» her zaman «en iyi normal» değildir.

Çözünürlük seçerken üç soru: (1) ekranda kaç piksel kaplıyor? (2) mip zinciri bu boyutta anlamlı mı? (3) materyalde kaç kez örnekleniyor? Üçüncü soru, Node vs PBR seçiminde grafik derinliği ile birleşir — bu sayfa materyal türünü tartışmaz, yalnız örnek başına maliyet uyarısı verir.

Transparanlık için öncelikli sıkıştırma yolu her cihazda aynı değildir; önceden çarpılmış renk + ayrı maske gibi üretim desenleri, motorun beklediği alfa modeliyle uyumlu olmalıdır. Aksi halde kenar parlaması veya düz renkte görünmez olan artefakt, HDR veya arka plan rengine bağlı olarak çıkar.

  • Önce doğruluk: kanal ve uzay doğru değilse 4K yüklemek hatayı keskinleştirir.
  • Sonra boyut: uzak varlıklarda düşük çözünürlük + tam mip zinciri, yakında tek yüksek çözünürlük setinden çoğu zaman iyidir.
  • Önbellek ve bellek: aynı doku on kez bağlıysa tek örnek paylaşımı kazanır; paylaşım yoksa bellek tabanı lineer büyür.

Çözünürlük tek başına çare değil

Bulanık veya gürültülü görünüm çoğu zaman dosya boyutu değil, filtre + mip + uzay seçimi kombinasyonudur. Çözünürlüğü ikiye katlamadan önce UV / örnekleme ve mip varsayımlarını kilitleyin; aksi halde üretim bütçesi yanlış yere gider.

Babylon.js tarafında: doku nesnesi ve parametreler

Sahneye bağlı bir Texture örneği genelde bir URL veya özel kaynaktan gelir; motor yükleme ve grafik bağlamını bilir. Sarma, filtre ve gamma ile ilgili ayarlar çoğu zaman doku üzerinde tutulur — böylece aynı görsel farklı materyallere bağlanırken tutarlı davranış için merkezi bir yer oluşur. Dinamik içerik (tuval veya piksel güncelleme) kullanıyorsanız güncelleme sıklığını render döngüsü ile uyumlu tutmak önemlidir ( Render loop · iş bölümü). 

// Örnek: dosya tabanlı doku; yol dağıtım yapınıza göre ayarlanır.

const albedoTex = new BABYLON.Texture("textures/albedo.png", scene);
// Sarma, örnekleme ve gamma ile ilgili ayarlar genelde bu nesne üzerinden yapılır.

Three.js ile üst üste okuma

Çakışmayı önleyen çerçeve

Three.js tarafında TextureLoader ve materyal slotları sık öğretilir; boru hatta «dosyayı al, materyale tak» düşüncesi öne çıkar. Babylon.js tarafında ise doku, çoğu zaman sahne motorunun kaynak yönetimiyle iç içe düşünülür — aynı fiziksel örnekleme kuralları, farklı üretim rahatlığı. İki Holodepth hattı birbirini dışlamaz; biri temeli, diğeri motor içindeki günlük pratiği anlatır.

Sıradaki başlık

Doku ve örnekleme netleştikten sonra çarpışma geometrisi ve fizik köprüsü için Kolizyon mantığı sayfasına geçebilirsiniz. Önceki adım: PBR materyal.