holodepth

Babylon.js · Fizik

Raycast ve collision: ışınla sorgulama

Holodepth Three.js tarafında Raycaster ile üçgen kesişimi ve sahne grafiği seçimi sık işlenir — doğru temeldir. Babylon.js üretiminde ise iki soru ayırımı yapmak gerekir: ekrandaki tıklanan görünür yüzey hangisi? ile fizik dünyasında bu doğrultuda ilk temas nerede? aynı matematiksel çizgiyi paylaşabilir ama farklı motor katmanlarından yanıtlanır.

Bu sayfa satır satır kesişim algoritması tablosu vermez ( WebGL / Three köprü sayfalarına havale); odak, Babylon bağlamında ışının sözleşmesi, sonuç kaydının okunması ve sıklık/filtre özel yapılarıdır.

Özet: ışın sorgusunun bileşenleri

Bileşen Ne sabittir? Yanlışta ne olur?
Başlangıç Işının çıktığı nokta ( origin). «Başka yerden ateş» edilmiş seçim.
Yön Çoğu yapıda normalize yön vektörü. Yanlış uzaklık ölçeği, kayan isabet.
Uzunluk Maksimum mesafe veya sonsuzluk politikası. Uzak nesneye «temas» veya hiç isabet yok.
Filtre Hangi gövdeler / katmanlar adaydır? Görünmez duvara çarpma veya seçilemeyen nesne.

Işın tanımı: doğru üzerinde parametre

Klasik biçimde ışın, başlangıç O ve yön D için doğru üzerinde P = O + t · D olarak düşünülür; burada t mesafe parametresidir. Özel yapı: çoğu motor pozitif ve küçük olan t değerini «önce gelen temas» olarak seçer — üçgen raytracing öğretilerindeki «en yakın pozitif kesişim» ile aynı ailedendir ( Holodepth Three.js kesişim anlatımına köprü).

Yön vektörünün uzunluğu 1 olmayabilir; bazı API'ler yönü içsel olarak normalize eder. Üretimde birimleri sahne ölçeği ile karıştırmamak için takım içinde «yön her zaman birim mi?» sorusunu sabitleyin.

Fizik ışını ile sahne seçimi (pick)

Sahne seçimi çoğu zaman görünür yüzey ve grafik düğümünü bulmak içindir — örneğin kullanıcı tıkladı mı? Fizik ışını ise çarpışma dünyasındaki gövdelerle temas sorar — örneğin görüş hattı engelleniyor mu? İkisi aynı geometride örtüşür gibi dursa da, şeffaf materyaller, görünürlük katmanları ve fizik filtreleri farklı sonuç üretebilir.

Özel yapı: «pick doğru, fizik yanlış» durumunda ilk şüphe hangi katmanın sorulduğu ve gövdenin gerçekten fizik dünyasında kayıtlı olup olmadığıdır ( Physics impostor).

Pratik teşhis sırası

Önce ışın başlangıcını ve yönünü görselleştirin (kısa çizgi veya hata ayıklama gösterimi — sonraki sayfa), sonra filtreyi daraltın, en son matematik şüphesine düşünün.

Temas kaydı: nokta, normal, mesafe

Başarılı bir sorgu genelde en az şunları taşır: temas noktası, yüzey normali (sekme veya sürtünme için), mesafe ve hangi nesne/ gövdeye ait olduğu. Özel yapı: çoklu isabet listesi gerekiyorsa «en yakın» yerine sıralı liste veya belirli materyal filtresi istenir — API tasarımına bağlıdır. Normal vektörün hangi uzayda (dünya, yüzey yerel) döndüğü motor başına değişir; ışın cevabındaki yön ile aydınlatma için beklediğiniz «dışarı» hissi her zaman örtüşmeyebilir — çünkü burada soru görünüş değil, ışın–yüzey geometrisi imzasıdır.

Kendi kendine isabet (self-hit) veya ince yüzeylerde titreme için başlangıç noktasını doğruya çok kısa kaydırmak (bias) üretimde sık kullanılır; bu, hile değil, sayısal stabilite meselesidir. Hangi yüzey kimliğinin ( face index, gövde kimliği) döndüğü, oyun mantığınızın «hangi düğümle konuşacağı» kararını belirler — Physics impostor köprüsüyle aynı kimlik dilinde kalmak hata ayıklamayı kısaltır.

  • En yakın: nişangâh, kapı tetiği — tek t yeterli.
  • Sıralı liste: sıçrayan mermi, çoklu engel — maliyet ve bellek üst sınırı tanımlayın.
  • Filtre: aynı geometride farklı "katman" anlamı; fizik maskesi ile kolizyon filtreleri aynı kelimeyi paylaşabilir, farklı boru hatlarıdır.

Çoklu isabet politikasını seçmeden önce

«Hepsini getir» çağrısı, geniş fazda çok aday ürettiğinizde ( Broad / narrow sezgisi) pahalılaşır. Gerçekten sıralı liste mi lazım, yoksa tek isabet + dar filtre mü — soruyu cevaplamadan API'yi açmayın.

Filtre, katman ve maliyet disiplini

Her karede yüzlerce ışın atmak pahalıdır; özellikle mobil web'de imleç takibi veya sürekli görüş testinde kare başına bütçe belirlenmelidir. Kolizyon filtreleri hem doğruluğu hem geniş faz yükünü iyileştirir — az sayıda aday üzerinde dar faz çalıştırmak ucuzdur ( geniş / dar faz ile aynı sezgi ailesi).

Özel yapı: aynı filtreyi hem fizik hem görünürlük için kullanmak caziptir; çoğu zaman yanlıştır — «ray hangi soruya yanıt veriyor?» sorusuna göre maskeleri ayırın. Grafik tarafında görünürlük Sahne · görünürlük katmanları ile yönetilir; fizik maskesi çarpışma dünyası içindir. İkisi aynı bit deseniyle çalışıyor gibi dursa da, farklı motor alt sistemlerine sorulur.

Sürekli sorgularda kare bütçesi Render loop · kare zamanı ile birlikte düşünülür: ağır fizik adımı + ağır ışın demeti aynı karede buluşursa mobilde önce ışın sıklığını düşürmek sık daha güvenlidir — bu sayfa döngü kodu yazdırmaz.

  • Tek seferlik: tıklama, kapı etkileşimi — tam kare bütçesi ayırmanız gerekmez ama yine de filtre kullanın.
  • Sürekli: nişangâh / görüş — her kare yerine N karede bir, veya sonuç önbelleği; imleç hareketi için kare başına üst sınır.
  • Çoklu isabet: gereksizse kapatın; liste maliyeti ve sıralama belleği artar.

«Katman» kelimesi

Takım içinde tek sözcük iki anlama geliyorsa hata raporları yanlış dosyaya gider. Kod incelemesinde «bu maske pick için mi, physics ray için mi?» diye sorulabiliyor olmalıdır.

Çarpışma olayı ile anlık sorgu

Fizik motoru sürekli zaman adımlarında çarpışmaları üretir ve iletir ( temas başladı / sürdü / bitti). Işın ise tek anda «şu anda bu doğrultuda ne var?» sorusunun anlık fotoğrafıdır. İkisini karıştırmak hata ayıklamayı zorlaştırır: olay gelmedi sanılıp motor bozuk sanılırken aslında anlık sorgu gerekiyordur veya tersi. Olaylar çoğu zaman abonelik veya geri çağırım kuyruğuna bağlanır; ışın ise çağırdığınız anda dönen fonksiyon çağrısıdır — aynı karede ikisini birbirinin yerine koymak, «neden bir kare gecikti?» hissini üretir.

Zaman adımı ile render karesi arasındaki fark Senkron ve zaman adımı ile aynı ailedendir: fizik olayı iki fizik adımı arasında kaçırılmış olabilirken, ışın sorgusu o anki dünya anlık görüntüsünü verir. Bu sayfa motor olay API sözlüğü vermez; yalnız soru türünü ayırır.

  • Olay: sürekli temas, itiş sürtünmesi, uyku–uyanma — simülasyon zamanına bağlıdır.
  • Işın: tıklama, görüş çizgisi, yetenek menzili — sorgu anına bağlıdır.
  • Hibrit: olay «yaklaştı» dediğinde ışın ile kesin doğrulama — iki aşamada farklı filtre kullanmak yaygındır.

Three.js ile üst üste okuma

«Üst üste okuma» burada Raycaster ile aynı fonksiyon adını aramak değildir. Three.js hattında grafik kesişimi çoğu zaman Mesh koleksiyonu üzerinde öğretilir; fizik ışını ayrı paket ve ayrı dünya ile gelir. Babylon.js tarafında da soru ikiye ayrılır; fakat Impostor · Three kutusu ve sahne köprüsü ile aynı cümlede düşünme eğilimi güçlüdür — yine de pick ile fizik ışını ayrımı geçerlidir.

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

Three.js'te Raycaster ile grafik seçimi öğretilir; fizik kütüphanesi ayrı kurulursa ikinci bir sorgu yolu doğar. Babylon.js tarafında sorular yine ikiye ayrılır fakat motor sahne ve fizik köprüsünü yakın tutmayı hedefler. Matematiksel ışın aynıdır; hangi dünyayı sorduğunuz değişir.

Sürekli çarpışma ve gövde kaydı düzlemi Kolizyon mantığı · Three kutusu içindedir; bu sayfa anlık sorgu ve temas kaydı düzlemini sabitler — ikisini tek «çarpışma kodu» sanmayın.

  • Three: iki yol bilinçli seçilmeli — aynı maskeyi kopyalamak cazip ama riskli.
  • Babylon: motor yardımı fazla olsa da «hangi API ışını attı?» sorusu aynı kalır.
  • Ortak: yön, başlangıç, filtre, sonuç kaydı — fark çoğu zaman ne zaman ve kime sorulduğundadır.

Sıradaki başlık

Işın ve temas sorguları netleştikten sonra XR girdi hattına Controller input ile devam edebilirsiniz. Önceki adım: Physics impostor.