Sahnenin dinamiği

Aynı mesh, iki dünya. Kinematic modda yalnızca position yazılır küre asılı kalır. Dynamic modda her karede v ← v − g·Δt, y ← y + v·Δt uygulanır; zeminde zıplama sönümü vardır. Bu bir fizik motoru değil; dinamiğin sahneye “nasıl eklendiğinin” pedagojik modeli.

Three.js bir render ve sahne grafiği kütüphanesidir: mesh’leri, kameraları, ışıkları ve materyalleri yönetir. Fizik ise ayrı bir problem sınıfıdır kısıtlar, çarpışma manifold’ları, uyku halleri, sabit zaman adımı. Bunları çekirdeğe gömmek hem paket boyutunu hem de “yanlış varsayılan” riskini artırır.

Sonuç: mesh.position.y = 2 yazdığında obje “oraya konur”; yerçekimi kendiliğinden işlemez. Matematik sayfasındaki transform hesabı tamamlanmıştır; dinamik henüz başlamamıştır. Bu ayrım bilinçli bir mimari karardır bug değil.

Klasik nokta kütle modeli: F = m · a → a = F / m. Yerçekiminde (yaklaşık) F = m · g olduğundan a = g (aşağı yönlü). Demo’daki g kaydırıcısı bu ivmenin büyüklüğüdür; kütleyi ayrıca taşımıyoruz çünkü serbest düşüşte kütle sadeleşir.

Hız ve konum

İvme hızı değiştirir; hız konumu değiştirir:

v(t+Δt) ≈ v(t) + a·Δt
x(t+Δt) ≈ x(t) + v·Δt

Bu, sürekli diferansiyel denklemin ayrık (discrete) yaklaşımıdır. Sahnede “fizik” dediğimiz şey çoğu zaman bu iki satırın (ve çarpışma düzeltmelerinin) her karede tekrarlanmasıdır ister sen yaz, ister motor.

• Kuvvet F: yönlü bir “itme” (vektör); birden fazla kuvvet toplanır.
• Kütle m: aynı kuvvete ne kadar ivme düşeceğini ölçekler.
• İvme a: hızın değişim oranı.

Bölüm 3’teki a → v → x zinciri sürekli zamanda yazılır. Ekran ise kare kare ilerler. Entegrasyon, o sürekliliği küçük Δt dilimlerine bölüp her dilimde hız ve konumu güncellemektir. Rest or Fall’un dinamik modu bunun en sade pedagojik örneğidir motor değil, “zaman adımında ne hesaplanır?” cevabı.

Her karede iki satır

Demo, yerçekiminde a = −g (Y aşağı) varsayar. Bir karede kabaca şu sıra işler:

1. Hızı güncelle: v ← v + a·Δt (demo’da v ← v − g·Δt).
2. Konumu yeni hızla ilerlet: y ← y + v·Δt.
3. Sonra (isteğe bağlı) zemin kontrolü: penetrasyon varsa konumu düzelt, hızı yansıt / söndür.

Önce v, sonra x bu sıra literatürde sıkça semi-implicit Euler (veya symplectic Euler) diye anılır. Önce konumu eski hızla yazıp sonra hızı güncellemek (explicit Euler) aynı aileden ama farklı kararlılık davranışına sahiptir. İkisinin de ortak fikri aynıdır: türevi sonlu farkla yaklaşmak.

Bu şema ne değildir?

Euler entegrasyonu anlaşılır ve ucuz; bu yüzden demoda var. Büyük Δt, sert yaylar veya yüksek restitution ile enerji şişebilir veya çözelti “patlar”. Oyun motorları bu yüzden Verlet, RK4, kısıt çözücüler veya sabit alt-adımlar kullanır. Fikir yine aynıdır sürekli hareketi dilimlere bölmek ama hata ve kararlılık bütçesi farklıdır.

Zaman adımının kendisi (değişken kare süresi vs fixed timestep) bir sonraki nabız bölümünde; burada yalnızca şunu tut: entegrasyon formülü ile Δt politikası ayrı kararlardır.

Entegrasyondan sonra: tepki ayrı katman

Zemin temasında demo hızı yansıtır ve söndürür (v ← −e·v benzeri). Bu satır Euler’in parçası değildir; entegrasyon bittikten sonra uygulanan bir tepki kuralıdır “impulse / restitution” fikrinin tek satırlık karikatürü.

Gerçek motor aynı anda contact manifold, sürtünme konisi ve çoğu zaman birden fazla kısıt çözer. O köprü Çarpışma ve tepki bölümünde; burada önemli ayrım: hareketi ilerletmek (entegrasyon) ile teması düzeltmek (tepki) aynı cümlede karışmamalıdır.

Motor jargonunda kinematic gövde: sen (veya animasyon) konumu dayatırsın; dünya ona tepki verir ama o “kütleli tepki” üretmez. Dynamic gövde: kuvvetler / çarpışmalar hızı yazar; konum entegrasyondan gelir. Three.js çekirdeğinde her mesh varsayılan olarak “kinematic gibi”dir çünkü hiç kimse hız tutmaz.

İki dünya

Demo’daki Δt kare süresidir (rAF aralığı). FPS düşerse aynı g ile daha büyük adımlar atılır; zıplama “daha çılgın” görünür. Oyunlarda bu yüzden fixed timestep tercih edilir: fizik 1/60 s (veya benzeri) dilimlerde ilerler; render ayrı hızda interpolasyon yapabilir.

Clock ve rAF ne sağlar?

Three.js Clock / requestAnimationFrame yalnızca zamanı ölçer. Entegrasyon politikası değişken Δt, sabit adım, max alt-adım sayısı sana (veya motora) aittir. “Fizik bozuldu” şikâyetinin önemli bir kısmı yanlış kuvvet değil, kontrolsüz zaman adımıdır.

İleri okuma: Delta time, requestAnimationFrame.

Serbest düşüş (entegrasyon) tek başına yetmez. Cisim zeminle veya başka bir gövdeyle örtüşünce iki ayrı iş çıkar: tespit (“değdiler mi?”) ve tepki (“şimdi ne yapalım?”). Rest or Fall zemini bu ikisini tek satırda karikatürize eder; gerçek boru hattı daha katmanlıdır.

Tespit ≠ tepki

Tespit, geometrik bir sorudur: iki şekil kesişiyor mu, ne kadar penetrasyon var, temas noktası / normal nedir? Tepki ise dinamik bir sorudur: hızı nasıl değiştiririm, konumu nasıl düzelteyim, enerji / sürtünme nasıl işlesin? Euler bölümündeki v ← −e·v ikinci gruba aittir önce “zeminin altındayım” bilgisi gelir, sonra yansıtma.

Geniş faz → dar faz → impulse

Ölçek büyüyünce motorlar işi üçe böler:

1. Geniş faz (broad phase): ucuz kaba filtre AABB, sweep, spatial hash. “Kesinlikle değmez” çiftleri erken eleyerek maliyeti düşürür.
2. Dar faz (narrow phase): kalan çiftlerde gerçek şekil testi (küre–küre, kutu–üçgen, convex…). Penetrasyon derinliği ve contact normal burada çıkar.
3. Impulse / kısıt çözümü: hızları (ve gerekirse konumları) fiziksel tepkiye göre düzeltir. Restitution, sürtünme, uyku hali burada devreye girer.

Bu sayfa o boru hattını kodlamaz; sözleşmeyi kurar. Derinlik: Çarpışma mantığı, AABB.

Raycaster ≠ fizik ışını

Three.js Raycaster çoğunlukla seçim / picking içindir: “bu piksel hangi meshe değiyor?” Fizik motorundaki ray cast ise sıklıkla aynı geometri fikrini sorgu olarak kullanır: yer testi, görüş hattı, projectile. Ortak dil “ışın × şekil”; amaç farklıdır biri etkileşim UI’si, diğeri dünya sorgusu.

Ayrıntılı ayrım: Raycaster vs fizik ışını. Görünen mesh ile collider şeklinin aynı olmak zorunda olmadığı ise Sahnenin şekli köprüsünün işidir.

Entegrasyon hızı üretir; çarpışma tepkisi hızı anlık değiştirebilir. Sürtünme ve damping ise hızı zamanla yer “neden bir süre sonra duruyor / kayma hissi azalıyor?” sorusunun cevabıdır.

Sürtünme sezgisi

Klasik sürtünme, temasta hıza (veya kayma eğilimine) karşı kuvvet üretir; mekanik enerjiyi ısıya (veya sayısal sönüme) çevirir. Statik sürtünme “henüz kaymıyorsa tut”; kinetik sürtünme “kayarken yavaşlat” ayrımı oyunlarda sıkça basitleştirilir veya tek bir parametreye indirgenir.

Rest or Fall demosunda yatay sürtünme yoktur yalnızca düşey restitution karikatürü. Gerçek zeminde kayma, yuvarlanma ve açısal hız (ω) ayrı kanallardır; motor bunları contact manifold üzerinde çözer.

Dijital damping: kontrol edilebilir sönüm

Oyunlarda sıkça görülen yol: v ← v · (1 − d) (veya v ← v · e^−λ·Δt benzeri üstel sönüm). Bu, Newton sürtünme yasası değildir; tasarım parametresidir “ne kadar çabuk dursun?” sorusuna doğrudan cevap verir.

OrbitControls ve motor damping

Three.js OrbitControls damping’i aynı aileden gelir: kamera “hızını” her karede biraz azaltır; bırakınca yumuşak durur. Fizik motorlarındaki linear / angular damping de gövde hızlarını benzer şekilde söndürür. Akrabalık sayısal sönüm fikrindedir bu, çekirdek Three.js’in yerçekimi veya sürtünme simüle ettiği anlamına gelmez.

Uygulama yüzeyi: Damping. Motor tarafında sürtünme / restitution parametreleri ise çarpışma ve entegrasyon sayfalarına aittir; bu köprü yalnızca “hız neden zamanla ölür?” sezgisini kurar.

• “Three.js fizik yapmalı.” Hayır. Render + sahne grafiği; dinamik opt-in katmandır.
• “Transform = fizik.” Hayır. Transform yerleşim yazar; fizik hız/ivme entegre eder Sahnenin hesabı.
• “Mesh şekli = dinamik gövde.” Hayır. Görünen geometri ile çarpışma şekli (collider) ayrı sözleşmelerdir Sahnenin şekli.
• “Δt’yi umursama.” Hayır. Değişken kare süresi, aynı g ile farklı yörüngeler üretir; sabit adım düşün.