Three.js · Etkileşim · Raycaster · Fizik
Raycaster vs. physics ray: iki dünya, iki mantık
Bir 3B uygulama aslında iç içe geçmiş iki farklı evrendir: gözümüzün gördüğü Görsel Evren (rendering) ve kuralların işlediği Fizik Evreni (simulation). Her iki evrenin de kendi «ışınları» vardır; görevleri ise tamamen farklıdır.
Bu sayfa, grafik kütüphanesinin sahne ışınını (Three.js Raycaster vb.) fizik motorunun ışını (Rapier, Ammo.js, Cannon.js vb.) ile yan yana koyar: 1 iki türün tanımı, 2 karşılaştırma tablosu, 3 senaryo rehberi, 4 hibrit kullanım ve 5 kısa özet. Pratik picking akışı için Mesh picking ve senaryo haritası için Kullanım senaryoları sayfalarına bağlanır.
İki tür ışın: görsel ve simülasyon
A. Görsel Raycaster (renderer-tabanlı)
Ana soru: «Kullanıcı neyi görüyor ve imleç / dokunuş neye denk geliyor?»
Bu katman, Three.js gibi kütüphanelerde çoğu zaman hazır bir modül olarak gelir: sahne grafiğindeki Mesh / Line / Points örnekleri üzerinde çalışır ve soruyu sunum dünyasına sorar — yani «şu an ekranda çizilen şekil ile kullanıcının girdiği kesişiyor mu?» Işın, kamera ve piksel konumundan üretilir; testler tipik olarak CPU’da, geometrinin üçgen düzeyindeki temsiline karşı yürütülür; bu temsil, GPU’ya gönderilen aynı mesh verisiyle uyumludur. Böylece seçim ile görüntü arasında «tek doğruluk kaynağı» hissi oluşur: tıkladığınız şey, çoğu zaman bire bir o yüzeydir.
- Temel amacı: Yukarıdaki soruya yanıt — oyun fiziğinden bağımsız, arayüz ve yönlendirilmiş etkileşim odaklıdır.
- Veri kaynağı: Render hattına bağlı objeler: dünya uzayında dönüştürülmüş köşeler (vertices), üçgen örgüsü (faces / indeks tamponları) ve isteğe bağlı yüzey ayrıntıları (morph, ölçek, instancing sınırları içinde anlamlı örnekleme).
- Kullanım yeri: Sahne içi UI, nesne seçimi (picking), gizmo tutamacı, sürükle-bırak, tooltip ve «tıklanabilir yüzey» sözleşmesi — kısacası kullanıcı niyetini geometriye çeviren her yer.
- Hassasiyet: Poligon sınırına kadar inebilir; ince çıkıntılar, ince paneller veya karmaşık LOD geçişlerinde bile, doğru filtre ve t kuralıyla görsel olarak beklenen vuruşu yakalarsınız. Karşı tarafı maliyettir: çok yoğun sahne ve sürekli hover’da optimizasyon (katman, BVH, erken çıkış) gerekebilir.
B. Physics ray (engine-tabanlı)
Ana soru: «Bu adımda kural dünyasında yol tıkanıyor mu, mesafe ve normal ne?»
Rapier, Ammo.js, Cannon.js vb. motorlarda ışın, simülasyon adımının parçasıdır: rigid body’ler, kısıtlar (joint) ve zaman integrasyonu ile aynı uzayda yaşar. Grafik sahnesindeki mesh ile bire bir örtüşmek zorunda değildir; motor, çarpışmayı collider adlı sade hacimler üzerinden çözer — kutu, küre, kapsül gibi «imza» şekiller yaygındır; bazı motorlarda konveks gövde veya (daha pahalı) üçgen örgü de seçilebilir. Işın burada «ekranda ne var?» değil, «kuvvet ve temas kurallarına göre yol tıkanıyor mu?» sorusuna yanıt verir.
- Temel amacı: «Bu zaman diliminde, ışın yönünde hangi çarpışma gövdesi var ve mesafe nedir?» — çarpışma, sürtünme, trigger alanı veya raycast tabanlı sorgu ile davranış kararı üretmek (hasar, engel, «yerde miyim?»).
- Veri kaynağı: Fizik dünyasındaki gövdeler: box, sphere, capsule, birleşik (compound) kabuklar; motorun iç uzamsal yapısı (broad phase / narrow phase) bu temsil üzerinden çalışır, görsel vertex sayısından kopuktur.
- Kullanım yeri: Grounded check (ayak altı kısa ışın), hitscan silah, merdiven / eğim normali, AI line-of-sight, sensör ve trigger bölgeleri — sürekli tekrarlanan, oyun döngüsüyle aynı ritimde ucuz kalmalıdır.
- Hassasiyet: Görseldeki ince çıkıntıyı her zaman yansıtmaz; «yaklaşık hacim» ile oynarsınız. Karşılığı hızdır: çok sayıda gövdede bile motor, ışını kendi indeksine göre ucuzlatır; doğru collider seçimi ve görsel–fizik hizası (debug draw) işin sırrıdır.
Karşılaştırmalı analiz: hangisi, ne zaman?
Aşağıdaki tablo iki dünyanın «iş sözleşmesini» tek bakışta toplar; mimaride hangi katmanın soru sorduğunu netleştirmek için kullanılabilir.
| Özellik | Görsel Raycaster (Three.js vb.) | Fizik ray (Rapier / Cannon vb.) |
|---|---|---|
| Bağımlılık | Sahne grafiği (scene graph) | Fizik dünyası (physics world) |
| Hesaplama birimi | CPU üzerinden mesh analizi | Fizik motorunun kendi optimize yapısı |
| Görsel detay | Milimetrik (poligon bazlı) | Yaklaşık (hacim bazlı) |
| Performans | Obje sayısı arttıkça hızla ağırlaşır | Binlerce objede bile çok hızlıdır |
Senaryolarla seçim rehberi
Aşağıdaki üç örnek, «hangi katman soruyu sahiplenir?» sorusunu somutlaştırır. Ortak ilke: kullanıcıya dokunan karar ile simülasyona bağlı kararı aynı araca yüklememek; gerektiğinde üst üste bindirmek (hibrit) ayrı bir başlıktadır (4).
Senaryo 1: 3B menüdeki butona tıklama
Tercih: Görsel Raycaster.
Neden: Butonun yerçekimiyle veya çarpışma çözücüsüyle işi yoktur; ekranda gördüğünüz dörtgen / yuvarlak köşeli panel, zaten render hattının parçasıdır. İhtiyaç, imleç konumundan çıkan ışının o poligonla kesişip kesişmediği ve varsa hangi yüzey önceliğinin kazandığıdır — tam da Raycaster’ın sözleşmesi. Fizik gövdesi uydurmak, çoğu zaman gereksiz eşleme maliyeti ve «görünmez duvar» riski getirir; menüyü UI layer / ayrı sahne dalında tutup sadece görsel ışınla seçmek sade kalır.
Senaryo 2: FPS oyununda duvarın arkasındaki düşmana ateş
Tercih: Fizik ray (hitscan veya motorun önerdiği eşdeğer sorgu).
Neden: Ateş kararı oyun kuralıdır: mermi, görünmeyen trigger hacimlerine, «ince ama aslında bloklayan» kolliyere veya zırhın altındaki isabet bölgelerine takılabilmelidir; bunlar sahne grafiğinde her zaman ayrı bir mesh olarak boyanmaz. Fizik dünyası, bu sorguyu zaten kare başına besleyeceği yapıda indeksler; binlerce gövde içinde bile ışın genelde Raycaster’a göre daha ucuzdur. Görsel tarafta LOD veya culling yüzünden çizilmeyen bir engel, simülasyonda hâlâ duruyor olabilir — hasarı fizik katmanına bağlamak tutarlılık sağlar.
Senaryo 3: Karakter havada mı, yerde mi? (Grounded check)
Tercih: Fizik ray (kısa mesafe, ayak/alt gövde kökenli).
Neden: Bu kontrol her karede veya çok sık tekrarlanır; görsel Raycaster ile zeminin tüm üçgenlerine bakmak, özellikle detaylı zemin örgüsünde gereksiz yük oluşturur. Fizik motoru zaten zemin için kutu / yükseklik alanı / konveks kabuk gibi bir temsil tutar; kısa bir ışın veya süpürme (shapecast / motorun eşdeğeri) ile «temas var mı, normal ne?» sorusu ucuz cevaplanır. Sonuç: hareket kodunuz simülasyonla aynı zemini referans alır; görseldeki dekoratif çıkıntı ile «gerçekten basılan» yüzeyin kayması da azalır.
Karma yaklaşım (hybrid)
Hybrid, iki dünyayı birbirinin yerine koymak değil; hangi kararın hangi katmanda üretileceğini netleştirmektir. Üretimde en sık yapılan hata, aynı soruyu iki kez sormak veya iki farklı cevabı «hangisi doğru?» diye birleştirmeye çalışmaktır. İyi hibritte bir pipeline vardır: önce niyet (görsel), sonra kural (fizik), gerektiğinde geri bildirim yine görselde.
Tıklama, seçim, imleç — görsel Raycaster ile «neye dokunuldu?»
Yerleşim, çarpışma, süpürme — fizik ışını / sorgu ile «olabilir mi, neye takıldı?»
Önizleme, renk, ses — yine sahne grafiğinde; karar mantığı yukarıdaki sıraya bağlı kalır.
Modern projelerde genellikle her ikisi de kullanılır. Örneğin:
- Kullanıcı bir objeye tıkladığında görsel Raycaster ile hedefi seçersiniz — ekranda gördüğü şekil ile eşleşen Object3D / örnek kimliği burada belirlenir.
- Seçilen nesne sürüklenirken veya bırakılırken, yerleşim veya engel için fizik ray / süpürme sorguları kullanılır; «buraya konabilir mi?», «hangi yüzeye yapışır?», «hangi gövdeye çarptı?» soruları simülasyon uzayında yanıtlanır.
Uygulama ipuçları: seçilen görsel nesne ile ona bağlı rigid body / collider arasında kararlı bir eşleme (kimlik, zayıf referans, tek kayıt defteri) tutun; aksi halde «tıkladım ama fizik başka şeyi duyuyor» sapması kaçınılmazdır. Önizleme çizgisi veya hayalet (ghost) yerleşimi için yine kısa fizik sorguları, imleç veya snap geri bildirimi için görsel ışın kullanılabilir — rolleri dokümante etmek, ekip içi anlaşmayı kurtarır (senaryolar ile aynı çizgide).
Holodepth teknik özet
Görsel Raycaster güzellik ve etkileşim içindir; fizik ray ise kural ve hız içindir. Yalnızca seçim yapacaksanız fizik motoruna ihtiyaç duymayabilirsiniz; gerçekçi dünya simülasyonunda raycast yükünün büyük kısmını fizik motoruna devretmek profesyonel yaklaşımdır.