Rust ile yazılmış 2D·3D fizik motoru Rapier

 (rapier.rs)
3 puan yazan GN⁺ 2024-02-29 | 1 yorum | WhatsApp'ta paylaş
  • Rapier, oyunlar, animasyon ve robotik gibi gerçek zamanlı fizik gerektiren uygulamaları hedefleyen Rust tabanlı bir fizik motorları setidir
  • Hızlı çalışma ve kararlılığı amaçlar; gerektiğinde platformlar arası determinizmi isteğe bağlı olarak destekler
  • Katı cisim çarpışmaları ve kuvvetler, eklem kısıtları, temas olayları ve sensörler, snapshot’lar gibi fizik simülasyonu için gereken işlevleri sunar
  • JavaScript binding’leri sağlayarak Rust dışındaki ortamlarda da Rapier’in kullanılmasını mümkün kılar
  • Apache 2.0 lisanslı ücretsiz ve açık kaynaklıdır; Dimforge tarafından geliştirilir ve GitHub Sponsor üzerinden destek alır

Rapier’in hedeflediği kullanım alanları

  • Rapier, Rust ile yazılmış 2D ve 3D fizik motorları setidir
  • Ana hedefi, gerçek zamanlı fizik işlemesi gerektiren uygulamalardır
    • Video oyunları
    • Animasyon
    • Robotik
  • Tasarım hedefi hızlı ve kararlı çalışmadır; isteğe bağlı olarak platformlar arası determinizmi destekler

Sunulan özellikler ve dağıtım biçimi

  • Fizik simülasyonu için başlıca özellikleri içerir
    • Katı cisim çarpışmaları ve kuvvetler
    • Eklem kısıtları
    • Temas olayları ve sensörler
    • Snapshot’lar
    • İsteğe bağlı platformlar arası determinizm
    • JavaScript binding’leri
  • Rapier ücretsiz ve açık kaynaklıdır; Apache 2.0 lisansı ile dağıtılır
  • Geliştiricisi Dimforge adlı açık kaynak şirketidir
  • Destek GitHub Sponsor üzerinden verilebilir

İlgili okumalar

1 yorum

 
GN⁺ 2024-02-29
Hacker News yorumları

  • Rapier determinism moduyla çevrimiçi çok oyunculu bir oyun yaptım
    Oyuncular sırayla böcekleri rakip takımın tarafına doğru çarptırıp tepeyi ele geçirmeye çalışıyor
    Henüz tek oyunculu mod yok; yapay zeka yazmak, daha önce yaptığım satranç türü oyunlara göre daha zor
    Oyuna https://evrimzone.itch.io/crittershowdown adresinden bakabilirsiniz; fizik/oyun mantığı kaynak kodu da https://github.com/evrimoztamur/crittershowdown/blob/e4d9a19... konumunda
    İleride bunu nasıl bağladığımı ve neler öğrendiğimi yazmayı planlıyorum; genel olarak çok sağlam bir kütüphane ve Rust’a yakışan API tasarımı sayesinde ihtiyaç duyduğum her şeyi uygulayabildim

    • Eğlenceli görünüyor. Web sitesine dağıtımı kolay mıydı merak ettim
      WebAssembly’ye mi derlediniz, yoksa tüm mantığı yerel bir sunucuda barındırma yöntemi mi kullandınız merak ediyorum
    • Sunucu taraflı çok oyunculu bir oyun yapmak için Rapier2D kullanmaya başladım; ilgili yazının bir an önce yayımlanmasını umuyorum

  • Birkaç ay önce Geometric Algebra (Geometrik Cebir) konusuna sardım; 2D, 3D, 4D ve üzeri, Öklid dışı vb. çok çeşitli geometrileri ele almak için şaşırtıcı derecede özlü ve sezgisel bir yol gibi göründü
    Bu yüzden geometrik cebirin bir fizik motoru için iyi bir temel olup olamayacağını merak ettim
    İlginç görünen birkaç Rust kütüphanesi var [1][2], ama hiçbiri büyük ilgi görüyor gibi durmuyor
    Bu tarafa bakmış olan var mı merak ediyorum
    [1]: https://crates.io/keywords/geometric-algebra
    [2]: https://github.com/Lichtso/geometric_algebra
    Başlamak isterseniz Freya Holmér’in “Why can't you multiply vectors?” videosu iyi bir giriş olabilir: https://www.youtube.com/watch?v=htYh-Tq7ZBI ve https://bivector.net/index.html

  • Rust için Bevy Rapier eklentisi rehberi yazdım: https://taintedcoders.com/bevy/rapier/
    Bevy tarafında ilginç bir alternatif olarak Bevy XPBD de var; onu da yazıya döktüm: https://taintedcoders.com/bevy/xpbd/

    • Yavaş hareket eden nesneleri hareketsiz kabul eden sistemi görünce huzursuz oluyorum
      “Sleeping”, hareket etmeyen nesnelerin simülasyon maliyetini azaltarak performansı artıran bir teknik; SleepingThreshold kaynağıyla ayarlanabildiği belirtiliyor
      Varsayılan değer örneği olarak linear: 0.1, angular: 0.2 kullanılıyor
    • Şu anda xpbd ile fizik tabanlı bir 2D dövüş oyunu yapıyorum ve şimdiye kadar oldukça memnunum
      Şimdiye kadar bazı çarpışmaların bir kareliğine kaybolduğu tek bir sorun yaşadım; ama bunlar kolayca etrafından dolaşılabilecek şeyler, daha iyisi de bildirip düzeltilmesini sağlamak
    • XPBD oldukça ilginç geldiği için birkaç kez deneme uygulaması yaptım; son game jam çalışmama da yalnızca AABB’ye özel XPBD koydum
      Henüz yalnızca rotasyonu düzgün yapamadım; geri kalanında karmaşıklık sanki eriyip gidiyor
      Lineer cebir mi? Gerek yok. Sadece Vec3. Matris mi? Çözücü mü? 1998’e dönmüş gibi tüm kısıtları tekrar tekrar sağlayın yeter
      Çarpışma toleransı mı? Beceri meselesi. Broad phase? GJK? Fazla düşünmeyin, modern CPU’ya bırakın
      collect_pairs optimizasyonunu yaptıktan sonra asıl darboğazın malloc olduğunu fark edip düzeltince, 100 kadar nesneyi rahatça kaldırıyor. Bullet’a gerek yok
      Hız düzeltme aşaması da başta kafamı karıştırdı, ama AABB ile prototipleyince genel şekillere de geri taşıyabilecekmişim gibi görünüyor
      Başta bu aşamayı atlayınca tüm çarpışmalar hafifçe elastikmiş gibi davranmıştı

  • Dimforge gerçekten harika işler yapıyor
    Robotikte konum kestirimi ve haritalama gibi alanlarda nalgebra + Rust, Eigen + C++’ın yerini alabilirse gerçekten heyecan verici olur

    • Son dönemde robotik projelerimin çoğunu Rust ile yapıyorum; sektörün C++’a özgü deyimlere harcadığı zaman akıl almaz derecede fazla
      Rust’ta birçok şey kendiliğinden halloluyor. Yine de geri adım atmayan ve Rust’a yatırım yapmayı reddeden eski kuşak olduğu için üzücü
      Açıkçası C++ robotik kodunun etrafında devasa bir endüstri olduğu için nedenini anlıyorum
    • Bunu gerçeğe dönüştürmek istiyorum
      Şu anda Rust’ta kullanılabilir bir robotik framework olup olmadığını merak ediyorum
      ROS2’nin Rust’ı yavaş yavaş bünyesine kattığını duydum [1], ama bunun nasıl ilerlediğini pek bilmiyorum
      Donanım entegrasyonu/soyutlaması zaten C++ ile yapıldığı için ROS; sensör füzyonu, haritalama ve konum kestirimine girmek için iyi bir giriş kapısı olabilir
      Şirketlerin bunu kullanıp kullanmadığını da merak ediyorum
      [1] https://github.com/ros2-rust/ros2_rust

  • Onlarca yıl önce katı cisim fizik motoru geliştirirken hatırladığım kadarıyla istifleme (stacking) çok zor bir problemdi
    O dönemde nesnelerin zeminin içine gömülmesini önlemek için en iyi çözüm, zeminden başlayıp nesneleri dışarı itme yönünde yönlendirilmiş çevrimsiz bir grafik oluşturmaktı
    Yakınsaması için defalarca yinelemek gerekiyordu ve epey hacky hissettiriyordu
    Bugünlerde bu problemin çözülüp çözülmediğini merak ediyorum. Bu projede istiflemeye dair bir ifade bulamadım

    • Box2D yazarı tam da bu konuda harika bir yazı yayımlamış: https://box2d.org/posts/2024/02/solver2d/
      Yazının altındaki yazar videosu, farklı çözücülerin çeşitli zor istifleme problemlerini nasıl ele aldığını gösteriyor: https://youtu.be/sKHf_o_UCzI
    • Günümüzde istifleme iyi çalışıyor
      Çevrimsiz grafiğe gerek yok; çözücü yineleme sayısını yeterince artırırsanız yakınsıyor
      Temas ve sürtünme kısıtlarının sayısı düşünüldüğünde birden çok yineleme yapmak doğal; maksimum artığı izlerseniz neredeyse sıfıra ulaşana kadar çalıştırabilirsiniz
      Biraz bozuk olan taraf, çarpışma ve çözücünün yalnızca sınırlı bir güncelleme hızında çalışması
      Başlangıçtan itibaren iç içe geçme durumuyla başlarsanız bunu çözmeniz gerekir; gerçek nesneler böyle iç içe geçmediği için bu bir bakıma “sahte” bir işlem ve ekstra hareket yaratıp yığın kararlılığını düşürebilir
      Yine de bunu aşmanın çeşitli yolları var ve popüler fizik motorlarının her biri bir şekilde çözüm bulmuş durumda

  • Rust klişeleri sürekli doğruluyor gibi
    Rust ile yazılmış 50 oyun motoru var ama Rust ile yazılmış yalnızca 5 oyun var şakası akla geliyor

    • Keşke 50 tane fizik motoru olsaydı
      Rapier tam olarak ihtiyaç duyduğum gereksinimleri karşılamıyor, ama iyi bir alternatif yok
    • Son zamanlarda keyifle oynadığım bir oyunun Rust ile yazıldığını hatırlıyorum: (the) Gnorp Apologue (https://gnorp.dev/)
      Yani çok fazla engine kodu yazmayı gerektirmeyen küçük ölçekli 2D oyunlarda mümkün görünüyor
      Bu oyun çoğu işi SDL ile halletmişti

  • Rapier ile küçük bir web demosu da yaptım: https://github.com/iErcann/NotRoblox
    Rust kullanmadım
    Hoşuma giden nokta, belgelerinin AmmoJS’ten daha iyi olması. AmmoJS için pybullet okumam gerekmişti
    Nispeten güncel ve hem sunucuda (Node) hem istemcide (tarayıcı) çalışabiliyor
    Burada sunucu tarafında çalıştırıyorum, ama her iki tarafta da çalıştırıp istemci tahmini ve düzeltmesini uygulamak da mümkün
    Bundle da küçük. AmmoJS sanırım yaklaşık 2 MB’tı

    • Rust tarafında Rapier belgelerinin güncel olmadığını biliyorum
      Neyse ki önceki bir sürüme bağlı olduğum için çok kötü değil

  • JavaScript birlikte çalışabilirliği de gerçekten iyi: https://www.rapier.rs/docs/user_guides/javascript/getting_st...

  • Dimforge’un daha önce nphysics adlı bir fizik motoru vardı ve soft body ile multibody desteği sunuyordu
    Artık Rapier için rafa kaldırıldı; ama Rapier bunları ya da nphysics’in yaptığı diğer özelliklerin yarısını bile desteklemiyor
    Sonuç olarak nphysics modern ekosistemde kullanılamayacak kadar eski, Rapier ise çok yeni olduğu için özellik bakımından çok daha eksik
    Daha önce de benzer bir şey olmuştu. Salva adlı bir akışkan simülasyonu kütüphanesi nphysics ile çift yönlü coupling destekliyor ve tüm GPU/CPU’larda çalışıyordu; şimdi ise Sparkl için rafa kaldırıldı
    Ama Sparkl’da bu özellikler yok ve yalnızca CUDA destekliyor. Bu yüzden Salva da nphysics kadar eskidi; Sparkl ise çok yeni, çok daha az özellikli ve çapraz platform desteği de yok
    Hatta kasıtlı gibi görünüyor. “Bu kodu daha az çapraz platformlu yapmak için yeniden yazmak” gibi
    Umarım bir gün bu sürekli yeniden yazmalar durur ve gerçekten ihtiyaç duyulan tüm özellikleri destekleyen bir şeyde karar kılınır
    Ama her yeniden yazımda özellik kaybediliyorsa Dimforge ekosisteminin bana uygun olup olmadığından emin değilim
    Rapier’in de bir gün daha yeni bir şey uğruna rafa kaldırılmayacağını ve o yeni motorun Rapier’in özelliklerinin yarısını bile desteklemeyeceğini nereden bilebilirim?
    Yeni bir proje olduğu için olgun nphysics’in tüm özelliklerini destekleyememesini anlıyorum
    Ancak sorun, tam da o olgun nphysics’in tamamen rafa kaldırılmış ve bakımı yapılmıyor olması
    Dimforge’un geçmişinde böyle bir örnek olmasaydı bu gerçekçi olmayan bir endişe olurdu, ama sicil ortada
    Rapier belki bir gün nphysics’in 5 yıl önce zaten sahip olduğu özellik düzeyine ulaşabilir; ancak şu anda eksik olan özelliklerin üzerine bir şeyler inşa etmek isteyen geliştirici için bu keyfi bir 5 yıllık gerileme gibi hissettiriyor