holodepth

Babylon.js · Mesh & materyal

Mesh builder: örgüyü sahneye çıkarmak

Holodepth'te Three.js ve WebGL tarafında örgü genelde öznitelik tamponları (position, normal, uv) ve indeks listesi olarak anlatılır; doğrudur ve temeldir. Babylon.js sayfasında ise aynı matematik, çoğu zaman hazır fabrika fonksiyonları ve sahne bağlı üretim üzerinden gelir: küp, küre, zemin — tek satırda isim, parametre ve hedef sahne ile birlikte.

Bu metin, ham üçgen verisini sıfırdan yazma rehberi değildir; motorun mesh kurmayı nasıl kolaylaştırdığı ve özel ihtiyaçta VertexData ile nerede inşa edeceğiniz sorusudur. Three.js ile çakışmayı önlemek için mikro API listesi yerine üretim kararları öne çıkar.

Özet: mesh üretiminin üç yolu

Yol Ne zaman? Babylon.js tarafında tipik karşılık
Hazır primitif Prototip, blokout, basit kolizyon gövdesi. MeshBuilder.Create* ailesi (küp, küre, düzlem…).
Özel örgü Dışarıdan gelmeyen şekil; prosedürel yüzey. VertexData ile tamponları doldurup mesh'e uygulama.
Dosya içi örgü Tasarım aracından export. glTF vb. ile yükleme — bu klasörde Asset loading.

Mesh bu bağlamda neyi temsil eder?

Bir mesh, sahne grafiğinde görünür yüzey taşıyan düğümdür: geometri + materyal birlikte düşünülür (materyal ayrıntısı bu dizinin devam sayfalarında). Üretim dilinde mesh "model" ile özdeş sayılmaz — model dosyası içinde birden fazla mesh veya alt örgü olabilir; builder ise çoğu zaman tek bir örgü düğümü üretir.

Motor perspektifinden kritik fark: örgü oluşturmak GPU belleğine bağlanan bir adımdır; sahne ömrü boyunca güncellenmezse bile başlangıçta doğru segment ve ölçek seçimi, sonradan gölge ve fizik maliyetini belirler. Bu yüzden "küp koy" demek yalnız bir satır değil, kalite–maliyet düğmesi seçimidir.

MeshBuilder: hazır gövdeler

MeshBuilder.CreateBox, CreateSphere, CreateGround gibi metotlar aynı deseni izler: nesneye bir ad verir, isteğe bağlı parametre nesnesi ile boyut ve segment sayısını seçer, çıktıyı verilen scene'e ekler. Three.js'te karşılığı sıklıkla "önce BufferGeometry oluştur, sonra Mesh yap" zinciridir; Babylon.js tarafında zincirin çoğu fabrika içinde toparlanır.

  • Küp / kutu: blokout, basit tetik alanları, yer tutucu kolizyon.
  • Küre: test materyali, ışık probu, düşük poli iklim küresi.
  • Zemin / düzlem: sonsuz zemin hissi için segment artırımı bilinçli yapılmalıdır. 
// Örnek: birim küp; scene üretim akışınızdaki sahne örneğidir.

const box = BABYLON.MeshBuilder.CreateBox(
  "crate",
  { size: 1, updatable: false },
  scene
);

updatatable bayrağı, sonradan köşe konumlarını sık değiştirecekseniz bellek ve işlem modelini etkiler; statik level geometride genelde kapalı tutmak yaygındır. Parametre isimleri sürüme göre küçük farklar gösterebilir — resmi referansla doğrulamak üretim kodunda iyi alışkanlıktır.

VertexData ile özel örgü

Hazır primitif yetmediğinde — ızgara yüzeyi, yükseklik haritasından üretilmiş arazi veya basit prosedürel kapak — pozisyon, normal, UV ve gerekiyorsa indeks tamponlarını siz doldurursunuz. Babylon.js'te bu işin birleştirici yüzü VertexData: dizileri ayarlayıp applyToMesh ile bir Mesh'e bağlarsınız; böylece tek tek Float32Array düzenlemek ile sahne düğümünü aynı soyutlamada buluşturmuş olursunuz. Holodepth'teki WebGL "öznitelik" anlatımıyla kanal adları örtüşür; amaç tampon matematiğini burada yeniden yazmak değil, motorun tamponları tek nesnede toplayan birleştirici API tabakasını göstermektir.

Özel örgü "özel yapı" dediğimiz şeyleri sık sık bir araya getirir: indeksli üçgen listesi (köşe havuzu + indices), keskin kenar için aynı köşede birden fazla vertex ve bölünmüş normal, dokunun atlas üzerinde sürekli kalması için ise UV dikişinde bilinçli köşe çoğaltımı. Bunlar WebGL dersinin tekrarı değil; üretim kodunda VertexData tarafında netleştirmeniz gereken teknik seçimlerdir.

  • Yüzey yönü ve normal: üçgen sırası (winding) ile normal vektörünün işaretini birlikte düşünün; tek renk veya düşük kontrastlı önizlemede hata saklanır, yönlü ışık veya gölge açılınca yüzey "içeri dönmüş" görünür.
  • UV planı: atlas içinde kesintisiz kaplamak ile dikişte farklı UV kullanmak farklı işlerdir; kayma ve çatlak çoğu zaman "texcoord yanlış" değil, dikiş için köşe kopyalamayı ihmal etmektir ( Doku sistemi).
  • İndeks: üçgen başına üç bağımsız köşe yerine paylaşımlı havuz + indeks dizisi, bellek ve bant genişliği kazanır; güncellenebilir örgüde hangi tamponun sık değişeceğini ayırarak maliyeti kontrol edersiniz.

İlk kare aldatıcı olabilir

Düz renk veya basit emissive ile düzgün görünen örgü, PBR, çevresel gölge veya metalik kanal açılınca kopuk görünür — sorun çoğu zaman ilk tam ekranda değil, materyal gerçekçiliği devreye girdiğinde ortaya çıkar. Şüphede önce yüzey yönünü ve köşe çoğaltımını doğrulayın; sonra boru hattının beklediği kanalları ( Materyal boru hattı) kontrol edin.

Özet: özel örgü yazarken üç pratik şemsiye — normal tutarlılığı (ışık ve gölge için), UV disiplini (doku için), indeks ve güncelleme modeli (bellek ve dinamik kullanım için). Birini gevşetmek çoğu zaman ilk renderda değil, materyal veya gölgelendirme açıldığında hissedilir.

Segment sayısı: pürüzsüzlük ve örnek başına maliyet

Küre veya düzlem "daha yumuşak" olsun diye segmentleri agresif artırmak, üçgen sayısını — ve dolayısıyla vertex başına iş — çoğu primitifte iki yönde çarpılan alt bölümle hızla şişirir; maliyet "segment bir artırdım" hissiyle doğrusal değil, üretkenlikte sürpriz yapar. Özetle: her ek köşe, vertex shader'dan geçer; görünür örgü yoğunlaştıkça bu yük önce dolgu oranında, sonra da siluet ve gölgelikte hissedilir.

Blokout veya prototipte düşük segment yeterlidir; sunum veya yakın çekimde hedef çözünürlüğe göre artırım yapın. İki ayrı örgü tutmak — düşük poli proxy ile yüksek poli kahraman örgü — tam LOD sistemi değildir ama aynı prensibi pratikte uygular: önce taşıyıcı geometri, sonra maliyeti hak eden detay.

Yerel ölçek (model birimi = kaç dünya birimi) ile takım içi "metre mi birim mi?" sözleşmesi yoksa, mesh gözle "doğru" görünüp fizik ölçeği veya gölge kapsayıcısı ile çarpışır. Bu, MeshBuilder parametresinden çok organizasyon meselesidir; yine de örgü üretirken birimi sahne düzenine sabitleyin.

  • Küre / silindir: yatay ve dikey (veya eksenler arası) segmentler birlikte büyür; üçgen sayısı için iki boyutu aynı anda düşünmek gerekir.
  • Zemin / düzlem: genişlik ve derinlik için alt bölüm sayıları geniş alanı "döşeme" eder; sonsuz zemin illüzyonunda segment artışı sessizce overdraw ve fill-rate baskısı da ekleyebilir.
  • Sunum öncesi kontrol: hedef kamera mesafesinde siluet yeterliyse, ek segment çoğu zaman oyuna değmez; maliyeti materyal ve ışıkta harcayın.

Görsel doğru, davranış şaşırır

Render örgüsü ince, kolizyon kabuğu kaba kaldıysa veya birimler karıştıysa, gölge ve fizik ilk gerçek mahkemedir. Bu sayfa segment ekonomisini sabitler; görünür örgü ile çarpışma geometrisini ayıran kararlar için Görsel örgü ile çarpışma hattına bakın — burada tekrar etmiyoruz.

Özet: segment kalite–maliyet düğmesidir; birim ölçeği ise sahnede tutarlılık düğmesidir. İkisini ayrı düşünmezseniz mesh ilk bakışta düzgün, ikinci bakışta tutarsız olur.

Ömür: klon, yeniden kullanım ve dispose

Aynı görünür örgüyü çoğaltırken tipik spektrum şudur: aynı geometri, çoklu dünya dönüşümü (instancing veya motorda buna denk ince örnek desenleri), klon (yeni düğüm; geometri veya materyalin paylaşılıp paylaşılmadığı sürüme ve seçeneklere bağlıdır) ve her kullanımda sıfırdan tampon (en bağımsız, genelde en pahalı). Hangi uca yaklaştığınız bellek ile düzenleme maliyetini değiştirir; hedef gereksiz vertex tamponu üretmemek olmalıdır — özellikle prosedürel üretim veya spawn döngülerinde fark anında büyür.

Klon "kolay"dır; fakat her klon ayrı materyal veya doku tutuyorsa, ölçek büyüdükçe GPU belleği ve bağlama maliyeti ayrı bir sorun haline gelir. Bu sayfa mesh üretim çizgisindedir; materyal ömrü ve boru hattı ayrıntısı Materyal boru hattı ile tamamlanır — burada yalnızca şunu sabitleriz: örgü ömrü ile materyal / doku ömrünü aynı varsaymayın.

Sahneden kaldırmak (detach, ebeveyn altından çıkarma) ile dispose aynı iş değildir: düğüm görünmez olsa da WebGL tamponları yaşamaya devam edebilir. Dinamik oluştur–boz akışlarında dispose zincirini atlama, birikimli bellek baskısı ve bazen bağlam yeniden oluşturma ihtiyacı doğurur. Tam sıra, motor sürümüne göre ince farklar ve kontrol listesi Dispose sırası sayfasında; burada tekrar etmiyoruz.

  • Klon öncesi soru: gerçekten ayrı geometri mi lazım, yoksa aynı örgüyü farklı position / rotation ile çoğaltmak yeterli mi?
  • Paylaşım: statik level parçalarında tek geometri + çok düğüm sık kazandırır; her parça için MeshBuilder ile sıfırdan üretim genelde gereksiz kopyadır.
  • Ömür sonu: kaldırdığınız düğüm için dispose çağrılmadıysa, bir sonraki seviye yüklemesinde "sessiz" şişme görürsünüz — profil düz çizgi vermez, ani düşüş yapar.

Mesh sayfası, sahne grafiği değil

Ömür yönetiminin tamamı sahne ve motor kapanışına kadar uzanır ( Kapanış ve dispose). Bu bölümün sınırı şudur: örgü üretirken hangi çoğaltma modelini seçtiğinizi ve düğüm gittiğinde tamponun da gittiğini doğrulayın; aksi halde mesh "hafif" görünürken bellek ağırlaşır.

Özet: çoğaltma desenini erken seçin, paylaşımı bilinçli kullanın, kaldırma ile dispose arasındaki boşluğu dinamik sahnelerde kapatın — ayrıntılı disiplin Dispose sırası ile birlikte okunmalıdır.

Three.js ile üst üste okuma

"Üst üste okuma" burada API aynası kurmak anlamına gelmez; aynı GPU örgüsünü (köşe öznitelikleri, indeks üçgenleri) farklı soyutlama katmanlarından okuduğunuzu kabul edersiniz. Three.js tarafında zihninizde sıkça BufferGeometry + öznitelik atamaları + Mesh birleşimi durur; Babylon.js tarafında aynı sonuç çoğu zaman MeshBuilder veya VertexData ile daha kısa yoldan gelir. Karışıklık, "hangi satır Three'teki hangi satıra denk" aramakta değil; hangi tamponu kim sahipleniyor ve dispose sınırında neyin ayrıldığı sorusunda oluşur — bu sayfa §2–§5'te o sınırları işler.

Holodepth'te Three omurgası ayrı bir çizgidir; yalnızca isim düzeyinde hizalanmak istiyorsanız Three.js nedir? köprüsüne dönebilirsiniz. Bu bölüm Babylon mesh üretimini sabitler; Three geometri dersinin tamamını burada yeniden yazmıyoruz.

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

Three.js öğrenirken örgüyü adım adım kurmak — öznitelik dizilerini doldurup geometriyi Mesh'e bağlamak — bilinçli bir pedagoji seçimidir; temel tampon gerçeğini elle hissettirir. Babylon.js tarafında ise üretim hızı için motor, sık kalıpları fabrika fonksiyonlarına alır; özel ihtiyaçta yine aynı tampon gerçeğine (VertexData) inersiniz.

İki Holodepth hattı birbirini silmez: biri "neden bu diziler var" sorusunu açar, diğeri "bu projede motor bunu neden kısaltıyor" sorusunu yanıtlar. Hangi sırayla okuduğunuz mühim değil; aynı anda iki farklı zihin modelini tek sahne gerçeğine çarptırmamak mühimdir. Diğer Babylon sayfalarındaki Three karşılaştırma kutuları (ör. kolizyon hattı) aynı prensibi farklı konuda işler — burada tekrar etmiyoruz.

  • İsim eşlemesi yapmayın: parametre adları, eksen/yön varsayılanları ve segment anlamı motorlar arasında bire bir gitmez; kopyala–yapıştır taşıma yerine hedef motorun dokümanına güvenin.
  • Fabrika ile yetinmeyin, körü körüne de bağlanmayın: prototipte MeshBuilder doğru; üretimde ölçek, ömür ve paylaşım (§4–§5) aynı geometrinin maliyetini belirler.
  • Tampon gerçeği ortaktır: normal / UV / indeks disiplini §3'te; dispose disiplini §5 ve Dispose sırası ile birlikte düşünülür — hangi motorda okursanız okuyun.

Özet: Three hattı şeffaflık, Babylon mesh sayfası üretkenlik kısayolu sunar; ikisini rakip değil, aynı Holodepth haritasının farklı derinlikleri olarak taşıyın.

Sıradaki başlık

Örgü hazır olduğunda sıradaki soru özel gölgelendirme yüzeyi ve düğüm grafiğidir: Node material ile derinleştirebilirsiniz. Önceki adım: Material pipeline.