holodepth

Babylon.js · GUI & UI

Fullscreen UI: arayüzü sahne ile aynı düzlemde tutmama

Fullscreen UI, Babylon.js GUI modülünde arayüzünüzü genellikle tam ekran bir dokuya çizip bunu kameranın önüne yerleştirme yaklaşımıdır — düğmeler ve metinler 3B örgü üzerinde dolaşmaz; pencere koordinatlarında kalır. Bu, ürün menüleri, HUD, ayar panelleri için doğal seçimdir.

Holodepth Three.js tarafında benzer ihtiyaç çoğu zaman HTML/CSS katmanı veya CSS2D / CSS3D ile anlatılır; burada motorun kendi doku tabanlı arayüz hattını ve ona özgü ölçekleme–girdi kurallarını netleştiriyoruz — tekrarlayan «el ile div yerleştir» öğretisine çakışmadan.

Özet: dört karar noktası

Konu Soru Risk
Katman Arayüz dünya uzayında mı, ekranda mı? Yanlış katmanda pick ve ölçek hayalet hataları.
İdeal çözünürlük Tasarım piksel genişliği / yüksekliği ne? Metin bulanık veya kontroller sıkışık.
Girdi Tıklama GUI'de mi tüketiliyor? «Tıklanıyor ama sahne tepki vermiyor» veya tersi.
Yerleşim Kök konteyner ve hizalama ağacı net mi? Bileşenler üst üste binir veya taşar.

Tam ekran dokusu: sahne grafiğinden ayrı katman

Özel yapı: fullscreen modda oluşturulan Advanced Dynamic Texture, arayüzü sahne örgülerinden bağımsız tutar; çizim genelde tek bir geniş dokuya gider ve görüntü kamera önünde ekran boyutuna oturtulur. Bu, dünya koordinatında dönen bir düzlem üzerinde metin basmaktan ( 3D GUI ile karıştırılmamalıdır) farklıdır.

Sonuç: kamera hareketi arayüzü «kaydırmaz» — kullanıcı bakışı değişse bile HUD çerçevesi sabittir; sahne içi etiket istiyorsanız bir sonraki konuya geçmek gerekir.

İdeal genişlik ve ölçek: bulanıklığı tasarımdan yönetme

Özel yapı: çoğu kurulumda bir ideal genişlik / yükseklik seçilir — örneğin tasarımın hazırlandığı piksel tuvali. Gerçek pencere boyutu bundan farklı olduğunda motor, kontrolleri bu ideale göre konumlandırıp tek bir ölçek faktörüyle ekrana yayar. Böylece margin ve yazı boyutları tasarım biriminde kalır; ekstra kod ile her kontrolü elle yeniden boyutlamanız gerekmez.

Pratik kural: ideal çözünürlüğü «gerçek kullanıcı masaüstü» ile «minimum mobil genişlik» arasında seçin; uç değerlerde yazı ya fazla küçük ya fazla büyük görünür — prototipte birkaç pencere boyutunda deneyin.

Yüksek DPI ve netlik

Dokunun iç çözünürlüğü düşük seçilirse vektör hissi yerine piksel kırpması görürsünüz; ideal ölçü ve ölçek ilişkisini metin ağırlıklı ekranlarda özellikle doğrulayın.

Konteynerler ve hizalama ağacı

Özel yapı: tam ekran dokuda bile içerik düz HTML değildir; kutular, ızgaralar ve yığılı yerleşim ( stack) ile hiyerarşi kurarsınız. Üst konteyner genelde ekranı kaplar; alt öğeler üst–alt, sol–sağ veya köşe sabitleme ile yerleşir. Özel yapı: üst üste bindirme sırası ( z-order) yanlış ayarlanırsa tıklanabilir alan görünmez kalır veya alt katmandaki düğme üstteki şeffaf panelin altında kalır — etkileşim sırasını tasarımla birlikte düşünün.

  • Kök: tam tuvali kaplayan konteyner; kenar boşlukları burada sabitlenir.
  • Çocuklar: panel, başlık çubuğu, kaydırma alanı — her biri kendi iç ölçüsüyle.
  • Kısayol: karmaşık HUD için önce blok diyagram, sonra ağaç.

İşaretçi: GUI ile sahne yarışı

Özel yapı: tam ekran katmanı aktifken işaretçi olayı önce arayüz ağacına düşer. Bir düğme veya kaydırıcı «tüketirse», aynı konumdaki sahne pick'i ( Raycast) çalışmayabilir — bu çakışma değil doğru öncelikdir; hangi katmanın aktör olduğunu bilerek tasarlayın. Şeffaf tam ekran bölgeleri bazen tüm tıklamayı yutar; gereksiz dolgu kullanmayın veya etkileşimsiz alanlarda işaretçiyi geçirme ( pass-through) davranışını araştırın.

Sahne tarafında ışın başlangıcı genelde kamera veya imleçten dünya uzayına taşınır; tam ekran GUI ise ekran koordinatında isabet arar. «Hiç vurmuyor» hissi bazen öncelikten, bazen de ışının yanlış uzayda tanımlanmasından gelir — ayrıntılı ayrım için Raycast sayfasındaki uzay ve filtre bölümlerine bakın; dokudaki isabet mantığı için UI doku mantığı · UV ve tıklama bölümüne yönelmeniz yeterlidir.

Kısa kural

Aynı ekranda hem menü hem dünya seçimi gerekiyorsa modları ayırın: örneğin inşa / düzenleme modunda GUI öncelikli, oyun modunda sahne öncelikli — yarı yarıya davranış kullanıcıya «rastgele» görünür. Görünmez veya tam şeffaf üst katmanlar ( yerleşim ve üst üste sıra) tıklamayı sessizce tüketebilir; prototipte katmanları renkle geçici olarak işaretlemek teşhisi hızlandırır.

  • Öncelik: tam ekran katmanı açıkken sahne pick'inin «kaybolması» çoğu zaman hata değil, tasarım sonucudur.
  • Şeffaflık: tüm ekranı kaplayan etkileşimli olmayan alanları daraltın veya geçirgen yapın; boş alanları GUI ağacından çıkarmayı düşünün.
  • Teşhis: sorun GUI mi sahne mi — önce katmanı kapatıp aynı tıklamayı tekrarlayın; sonra tek tek geri açın.

Performans ve güncelleme maliyeti

Özel yapı: doku tabanlı GUI, içerik değiştikçe dokuyu yeniden örnekleyebilir. Metin veya çok sayıda küçük kontrol sürekli güncelleniyorsa kare bütçesine pay ayırın; mümkünse statik panelleri ayırın, canlı sayaçları tek bir alt dokuya veya sınırlı bölgeye indirin. Üretimde gereksiz animasyonlu şeffaflık ve gölgeleri sadeleştirmek genelde kazançlıdır.

Yüksek frekanslı sayaç veya ağ durumu gibi alanlarda her karede tüm tuvali yeniden çizmek yerine güncellemeyi kısıtlayın (saniyede birkaç kez, yalnız değişimde veya alt bölge «kirli» iken). Kare bütçesini Render döngüsü · güncelleme ve çizim yükü ile birlikte düşünün; doku yenileme stratejisinin ayrıntısı UI doku mantığı · güncelleme maliyeti sayfasında — burada yalnız tam ekran HUD için pratik sonuç özetlenir.

  • Statik / dinamik ayrımı: menü çerçevesi ve ikonlar seyrek değişir; canlı metni ayrı küçük dokuda veya sınırlı dikdörtgende tutun.
  • Şeffaflık ve gölge: her kareden blend ve büyük gölgeler pahalıdır; sade tasarım hem GPU hem okunabilirlik için genelde iyidir ( şeffaflık ve sahne karışımı).
  • Ölçüm: şüphede GPU zamanlayıcı veya motorun sahnedeki GUI maliyet göstergeleriyle tek seferlik profil alın; optimizasyonu tahmine bırakmayın.

Three.js ile üst üste okuma

Bu sayfa Babylon.js tam ekran dokusunu anlatır; Three.js tarafında aynı ihtiyaç çoğu zaman HTML / CSS üst katmanı veya CSS2D ile çözülür — pencere yeniden boyutu ve güvenli alan gibi konular doğrudan tarayıcı düzenine bağlıdır ( Duyarlı UI · yeniden boyut zinciri ile paralel okuyabilirsiniz). Motor içi doku yaklaşımında ise bu zincir sahne döngüsü ve doku boyutlarıyla birleşir.

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

Three.js ekosisteminde ekran üstü arayüz sıkça gerçek DOM ile çözülür; Babylon.js burada motor içi doku ve kontrol ağacı ile gider — erişilebilirlik ve stillendirme alışkanlıkları farklıdır. Matematik olarak ikisi de «2B düzlem + projeksiyon» üzerinden okunur; asıl fark iş akışı ve araç zincirisidir; birini öğrenince diğeri otomatik taşınmaz, ama kavramlar eşlenir.

DOM tabanlı arayüzde ekran okuyucu ve klavye odağı tarayıcıya aittir; doku tabanlı GUI'de bu sözleşmeyi siz kurmalısınız — üretimde erişilebilirlik gereksinimi varsa hibrit (motor + gerçek HTML) veya özel kısayol katmanları planlayın. Giriş önceliği ve şeffaf katman davranışı bu sayfada ( 4); kavramsal doku ayrımı UI doku mantığı · iki projeksiyon bölümünde pekiştirilir.

  • Projeksiyon: ikisinde de hedef «ekrana oturan 2B yüzey»; fark çoğunlukla veri yolunda.
  • Araç: CSS yerine kontrol ağacı ve doku çizimi — tasarım sistemini buna göre kurun.
  • Taşıma: düzen mantığını taşırsınız; bileşen kodunu satır satır kopyalamayı beklemeyin.

GUI dizisi: sıradaki adım

Ekran katmanını netleştirdikten sonra farklı pencere boyutlarında yerleşim için Responsive UI sayfasına geçebilirsiniz. Önceki adım: Control system.