holodepth

Babylon.js · Motor & sahne

Sahne yönetimi: grafik, zaman ve öncelik

Holodepth'te Three.js tarafında sahne grafiği, Object3D hiyerarşisi ve traversal gibi konuları ayrı sayfalarda işledik. Babylon.js'te aynı kelime — sahne — benzer bir ağaç taşır; fakat bu sayfadaki odak, "nedir" tekrarından çok sahneyi bir üretim motoru içinde nasıl yönetirsiniz sorusudur: kare zamanına bağlı güncellemeler, gözlemlenebilir yaşam döngüleri, aktif kamera ve görünürlük katmanları.

Kısaca: Three.js'te sıkça elle kurduğunuz döngü ve sahne düzeni, Babylon.js'te sahnenin kendi olay modeli ve motorla sıkı bağlantısı ile desteklenir. Bu metin, sahne yönetimini alternatif API ezberi değil, motor deneyimi olarak okumanız için yazıldı.

Özet: sahne yönetiminin dört boyutu

Boyut Pratik soru Babylon.js'te tipik karşılık
Yapı Nesneleri kim kimin altında duruyor? Ebeveyn–çocuk düğümleri; TransformNode, mesh ve grup benzeri köprüler.
Zaman Kare başına ne güncellenir, ne geciktirilir? Observable tabanlı kanca ve sahne hazır olma olayları.
Görünürlük Hangi nesne hangi passta çizilir veya seçilir? Katman (layer) ve görünürlük bayrakları; aktif kamera seçimi.
Ömür Sahne değişince veya rota kapanınca ne olur? Ağaç üzerinden dispose, çoklu sahne örnekleri ve motorla simetrik temizlik.

Sahne (Scene) ve motor sözleşmesi

Babylon.js'te Scene, bir Engine örneğiyle doğar; bu yüzden sahne yönetimi soyut bir liste meselesi değil, grafik bağlamının içinde yaşayan bir dünya meselesidir. Motor tarafında çözünürlük ve bağlam yenilenirken sahne tarafında düğüm dönüşümleri, animasyon ve sistem güncellemeleri aynı zaman ekseninde buluşur.

Üç temel "sorumluluk" ayırımı işinizi kolaylaştırır: (a) sahne grafiğinde nesneleri örgütlemek, (b) her karede veya belirli olaylarda bu grafiği güvenle güncellemek, (c) görüntüleme kararını — örneğin hangi kameranın geçerli olduğu — tek yerden tutarlı kılmak. Kamera matrisleri ve projeksiyon ayrıntısı için bu klasördeki Kamera sistemi sayfasına bırakıyoruz; burada yalnızca sahne–kamera ilişkisinin yönetim yüzünü işaretliyoruz.

Graf, yerel–dünya dönüşümü ve içerik örgütü

Bir sahne ağacında ebeveyni hareket ettirdiğinizde çocukların dünya uzayındaki konumu güncellenir; bu kural Three.js ile aynı fiziksel gerçektir. Babylon.js tarafında sık kullanılan desen, boş bir kök için TransformNode benzeri bir düğüm oluşturup içerikleri onun altına toplamaktır — böylece "karakter", "prop" veya "UI kökü" gibi kavramlar sahne içinde net paketlenir.

Yönetim perspektifinden kritik olan: derin traversal ile her karede binlerce düğümü tek tek gezmek yerine, anlamlı kökler ve isim / meta veri disiplini ile sahneyi aranabilir tutmaktır. Tasarım araçlarından gelen büyük sahnelerde düğümlere tutarlı adlar ve sahne içi gruplama, hata ayıklama maliyetini doğrudan düşürür.

Kare zamanı: gözlemlenebilir kancalar ve sahne hazırlığı

Three.js öğrenirken oyun döngüsünü çoğu zaman kendiniz kurarsınız; Babylon.js'te sahne, render öncesi ve sonrası için olay benzeri bir model sunar. Örneğin her karede çalışması gereken mantığı, sahneye kayıtlı bir gözlemci ile toplayabilirsiniz; bu, uygulama kodunu "nerede güncelleniyor?" sorusuna tek yerden cevap vermeyi kolaylaştırır.

İkinci yaygın ihtiyaç: içerik veya ağ ilk kez hazır olduğunda tek seferlik kurulum (örneğin fizik gövdelerini bağlama veya harici sisteme abone olma). Bu aşamayı netleştirmek, özellikle asenkron model yüklemelerinde yarış durumlarını azaltır. 

// Kare başı mantık ve tek seferlik hazırlık (örnek iskelet)
// BABYLON içeri aktarımı proje yapınıza göre değişir.

scene.onBeforeRenderObservable.add(() => {
  // Her kare: basit animasyon, giriş özetleme vb.
});

scene.executeWhenReady(() => {
  // Sahne ve temel bağımlılıklar hazır: tek seferlik kurulum
});

Bu yaklaşımın getirdiği avantaj, yaşam döngüsü kancalarının sahne nesnesinde merkezlenmesidir; yani döngüyü yazdığınız dosya ile sahne davranışını yazdığınız dosya arasında köprü kurmak için ekstra çatı kod yazma ihtiyacı azalır. Motorun runRenderLoop çerçevesi ( Motor yaşam döngüsü) ile birlikte düşünüldüğünde tablo şöyle oturur: motor kareyi çağırır, sahne kanca ve düğüm güncellemeleriyle kendini hazırlar, ardından görüntü üretilir.

Aktif kamera, ortam ve sahne atmosferi

Babylon.js'te bir sahnenin "şu an nasıl göründüğü" büyük ölçüde hangi kameranın aktif olduğu ile belirlenir; sahne yönetimi burada bir geçiş problemidir — örneğin birinci şahıs ile kuş bakışı arasında kullanıcı akışına göre aktif kamerayı değiştirmek. Ortam rengi, sis veya çevre yansıması gibi görsel atmosfer kararları da çoğu zaman sahne düzeyinde toplanır; böylece aynı içerik farklı görsel modlarda tutarlı kalır.

Bu sayfada derin matematik yok; mesele, bu ayarların sahne yaşam ömrüyle birlikte düşünülmesi gerektiğidir: rota değişince yalnızca mesh'leri silmek yetmez, hangi kameranın ve hangi ortam ayarının geçerli olduğunu da yeniden kurmak gerekir.

Katmanlar ve seçici görünürlük

Büyük sahnelerde her şeyi her karede çizmek yerine, nesneleri mantıksal katmanlara ayırmak yaygın bir yönetim aracıdır: örneğin yardımcı mesh'ler, düzenleyici önizlemeler veya "sadece düşük kalite önizleme" katmanları. Babylon.js bu ihtiyaca yönelik katman kimlikleri ve kamera–katman eşlemesi gibi mekanizmalar sunar; doğru kullanıldığında hem seçim (picking) hem çizim maliyeti kontrol edilir.

Three.js'te benzer ihtiyaç için sıklıkla layer mask ve çoklu kamera kombinasyonları öğretilir; Babylon.js tarafında vurgu, bu ayrımın sahne ve kamera yönetimiyle iç içe gelmesidir — yani teknik ayrıntıları ezberlemekten çok, üretimde hangi öncelik sırasının işe yaradığını düşünmek.

Three.js ile çakışmadan düşünmek

Three.js dokümantasyonunda sahne genelde grafik ve traversal üzerinden anlatılır; burada ise sahne, kanca tabanlı zaman çizelgesi ve motorla uyumlu ortam kararları üzerinden anlatılır. İkisi çelişmez — biri veri yapısını, diğeri üretim akışını öne çıkarır. Babylon.js sayfalarında küçük karşılaştırma şunu hatırlatır: aynı GPU gerçeği, farklı motor rahatlığı ile sunulur.

Çoklu sahne, editör akışı ve ömür yönetimi

İleri düzey uygulamalarda tek bir Scene ömrü boyunca her şeyi taşımak yerine, bölüm bazlı sahneler veya yükleme ekranları arasında geçiş yapan ayrı sahne örnekleri kullanılabilir. Yönetim maliyeti burada patlar: hangi dinleyicinin hangi sahneye ait olduğu, hangi motor döngüsünün aktif olduğu ve dispose sırasının nasıl korunacağı net olmalıdır ( Dispose sırası ile birlikte okuyun).

Özet kural: sahne değiştirmek, sadece görünürlüğü kapatmaktan daha fazlasıdır — GPU ve olay kaynaklarının da planlı şekilde devreden çıkarılması gerekir.

Bu klasörde sıradaki başlıklar

Motor ve sahne hattı burada tamamlanır; kullanıcı arayüzü katmanına 3D GUI ile devam edebilirsiniz. Önceki adım: Render loop.