Rapier, mesin fisika 2D·3D yang ditulis dengan Rust

 (rapier.rs)
3 poin oleh GN⁺ 2024-02-29 | 1 komentar | Bagikan ke WhatsApp
  • Rapier adalah rangkaian mesin fisika berbasis Rust yang ditujukan untuk aplikasi yang memerlukan fisika real-time seperti game, animasi, dan robotika
  • Ditujukan untuk eksekusi cepat dan stabil, serta secara opsional mendukung determinisme lintas platform bila diperlukan
  • Menyediakan fitur yang dibutuhkan untuk simulasi fisika seperti tumbukan dan gaya benda tegar, batasan joint, event kontak·sensor, snapshot, dan lainnya
  • Menyediakan binding JavaScript sehingga Rapier dapat digunakan juga di lingkungan selain Rust
  • Merupakan open source gratis dengan lisensi Apache 2.0, dikembangkan oleh Dimforge dan didukung melalui GitHub Sponsor

Kasus penggunaan yang dituju Rapier

  • Rapier adalah rangkaian mesin fisika 2D dan 3D yang ditulis dengan Rust
  • Target utamanya adalah aplikasi yang memerlukan pemrosesan fisika real-time
    • video game
    • animasi
    • robotika
  • Tujuan desainnya adalah operasi yang cepat dan stabil, dengan dukungan determinisme lintas platform secara opsional

Fitur yang disediakan dan cara distribusinya

  • Mencakup fitur utama untuk simulasi fisika
    • tumbukan benda tegar dan gaya
    • batasan joint
    • event kontak dan sensor
    • snapshot
    • determinisme lintas platform opsional
    • binding JavaScript
  • Rapier adalah open source gratis dan didistribusikan dengan lisensi Apache 2.0
  • Pengembangnya adalah perusahaan open source Dimforge
  • Dukungan dapat diberikan melalui GitHub Sponsor

Bacaan terkait

1 komentar

 
GN⁺ 2024-02-29
Komentar Hacker News

  • Membuat game multipemain online dengan mode deterministik Rapier
    Pemain bergiliran menabrakkan serangga ke arah tim lawan dan merebut bukit
    Belum ada mode pemain tunggal, dan menulis AI-nya lebih sulit daripada game mirip catur yang pernah dibuat sebelumnya
    Gamenya bisa dilihat di https://evrimzone.itch.io/crittershowdown, dan sumber logika fisika/game ada di https://github.com/evrimoztamur/crittershowdown/blob/e4d9a19...
    Nanti saya berencana menulis bagaimana semuanya dirangkai dan apa yang dipelajari; secara keseluruhan ini pustaka yang sangat solid, dan berkat desain API yang terasa khas Rust saya bisa mengimplementasikan semua yang diperlukan

    • Kelihatannya menarik. Penasaran apakah mudah untuk men-deploy-nya ke situs web
      Penasaran apakah dikompilasi ke WebAssembly, atau seluruh logikanya di-host di server lokal
    • Saya mulai memakai Rapier2D untuk membuat game multipemain sisi server, jadi semoga tulisan terkaitnya segera terbit

  • Beberapa bulan lalu saya terpikat pada Aljabar Geometrik (Geometric Algebra), dan itu tampak seperti cara yang sangat ringkas dan intuitif untuk menangani beragam geometri: 2D, 3D, 4D ke atas, non-Euklides, dan lain-lain
    Jadi saya penasaran apakah aljabar geometrik bisa menjadi fondasi yang baik untuk engine fisika
    Ada beberapa pustaka Rust yang tampak menarik [1][2], tetapi sepertinya belum ada yang mendapat perhatian besar
    Penasaran apakah ada yang sudah menelusuri bidang ini
    [1]: https://crates.io/keywords/geometric-algebra
    [2]: https://github.com/Lichtso/geometric_algebra
    Jika ingin mulai, “Why can't you multiply vectors?” dari Freya Holmér bisa menjadi pintu masuk yang bagus: https://www.youtube.com/watch?v=htYh-Tq7ZBI dan https://bivector.net/index.html

  • Saya menulis panduan plugin Bevy Rapier untuk Rust: https://taintedcoders.com/bevy/rapier/
    Di sisi Bevy ada juga alternatif menarik, Bevy XPBD, dan itu juga sudah saya rangkum dalam tulisan: https://taintedcoders.com/bevy/xpbd/

    • Saya merasa khawatir saat melihat sistem yang memperlakukan objek yang bergerak lambat sebagai tidak bergerak
      Disebutkan bahwa “Sleeping” adalah teknik untuk meningkatkan performa dengan mengurangi biaya simulasi objek yang tidak bergerak, dan dapat disetel dengan resource SleepingThreshold
      Contoh nilai default-nya mencakup linear: 0.1, angular: 0.2
    • Saat ini saya sedang membuat game pertarungan 2D berbasis fisika dengan xpbd, dan sejauh ini cukup suka
      Sampai sekarang ada satu masalah ketika beberapa tumbukan menghilang selama satu frame, tetapi hal seperti ini mudah diakali, atau lebih baik lagi dilaporkan agar bisa diperbaiki
    • XPBD cukup menarik, jadi saya beberapa kali mencoba mengimplementasikannya, dan pada karya game jam terbaru saya memasukkan XPBD khusus AABB
      Sejauh ini hanya rotasi yang belum benar-benar beres, selebihnya kompleksitasnya terasa meleleh begitu saja
      Aljabar linear? Tidak perlu. Cukup Vec3. Matriks? Solver? Seperti kembali ke tahun 1998, cukup penuhi semua constraint secara iteratif
      Margin tumbukan? Masalah skill. Broad phase? GJK? Jangan terlalu dipikirkan, serahkan saja ke CPU modern
      Setelah mengoptimalkan collect_pairs lalu menyadari bahwa bottleneck sebenarnya adalah malloc dan memperbaikinya, sekitar 100 objek bisa ditangani dengan mudah. Tidak perlu Bullet
      Tahap koreksi kecepatan juga awalnya membingungkan, tetapi setelah membuat prototipe dengan AABB, rasanya bisa dipindahkan lagi ke bentuk umum
      Awalnya saya melewatkan tahap ini, dan semua tumbukan jadi sedikit berperilaku seperti elastis

  • Dimforge benar-benar melakukan pekerjaan yang luar biasa
    Akan sangat menarik jika nalgebra + Rust bisa menggantikan Eigen + C++ di bidang seperti lokalisasi dan pemetaan dalam robotika

    • Belakangan ini saya mengerjakan sebagian besar proyek robotika dengan Rust, dan waktu yang dihabiskan industri untuk idiom khas C++ itu benar-benar tidak masuk akal
      Banyak hal di Rust yang langsung berjalan begitu saja. Sayangnya masih ada generasi lama yang bersikeras menolak berinvestasi di Rust
      Jujur saja, karena ada industri besar di sekitar kode robotika C++, saya bisa memahami alasannya
    • Saya ingin membuat ini menjadi kenyataan
      Saya penasaran apakah saat ini ada framework robotika yang layak dipakai di Rust
      Saya dengar ROS2 perlahan mulai memasukkan Rust [1], tetapi tidak begitu tahu sejauh apa perkembangannya
      Karena integrasi/abstraksi hardware sudah tersedia dalam C++, ROS bisa menjadi pintu masuk yang baik ke sensor fusion, pemetaan, dan lokalisasi
      Saya juga penasaran apakah perusahaan-perusahaan sudah menggunakannya
      [1] https://github.com/ros2-rust/ros2_rust

  • Dari ingatan saya saat membuat engine fisika benda tegar puluhan tahun lalu, stacking adalah masalah yang sangat sulit
    Saat itu solusi terbaik untuk menghindari objek tenggelam ke lantai adalah membuat graf asiklik berarah yang dimulai dari lantai dan mendorong objek ke luar
    Agar konvergen, ini harus diulang berkali-kali dan terasa cukup hacky
    Saya penasaran apakah masalah ini sudah terpecahkan sekarang. Saya tidak menemukan penyebutan tentang stacking di proyek ini

    • Penulis Box2D pernah menulis artikel bagus tepat tentang topik itu: https://box2d.org/posts/2024/02/solver2d/
      Video penulis yang ditautkan di bagian bawah artikel menunjukkan bagaimana tiap solver menangani berbagai masalah stacking yang sulit: https://youtu.be/sKHf_o_UCzI
    • Saat ini stacking sudah bekerja dengan baik
      Tidak perlu graf asiklik, dan jika jumlah iterasi solver dinaikkan cukup banyak, ia akan konvergen
      Mengingat jumlah constraint kontak dan gesekan, melakukan banyak iterasi adalah hal yang wajar, dan jika melacak residual maksimum, Anda bisa menjalankannya sampai hampir mencapai 0
      Bagian yang agak bermasalah adalah collision dan solver hanya berjalan pada frekuensi update yang terbatas
      Jika dari awal sudah dimulai dalam keadaan saling menembus, itu harus diselesaikan, tetapi benda nyata tidak menembus seperti itu, jadi ini agak merupakan penanganan “palsu” dan dapat menimbulkan gerakan tambahan yang mengurangi stabilitas stack
      Meski begitu, ada berbagai cara untuk mengakalinya, dan engine fisika populer masing-masing punya solusi dengan caranya sendiri

  • Rust tampaknya terus membuktikan stereotipnya
    Saya teringat lelucon bahwa ada 50 game engine yang dibuat dengan Rust, tetapi hanya 5 game yang dibuat dengan Rust

    • Andai saja ada 50 engine fisika
      Rapier tidak benar-benar memenuhi kebutuhan yang saya perlukan, tetapi tidak ada alternatif yang bagus
    • Saya ingat salah satu game yang belakangan ini saya nikmati ditulis dengan Rust: (the) Gnorp Apologue (https://gnorp.dev/)
      Jadi sepertinya ini memungkinkan untuk game 2D kecil yang tidak perlu banyak menulis kode engine
      Game ini sebagian besar menangani semuanya dengan SDL

  • Saya juga pernah membuat demo web kecil dengan Rapier: https://github.com/iErcann/NotRoblox
    Saya tidak memakai Rust
    Hal yang saya suka adalah dokumentasinya lebih baik daripada AmmoJS. Untuk AmmoJS, saya harus membaca pybullet
    Rapier relatif modern, dan bisa dijalankan di sisi server (Node) maupun klien (browser)
    Di sini saya menjalankannya di sisi server, tetapi menjalankannya di kedua sisi lalu mengimplementasikan prediksi dan koreksi klien juga memungkinkan
    Bundle-nya juga kecil. Seingat saya AmmoJS sekitar 2MB

    • Setahu saya, di sisi Rust, dokumentasi Rapier tidak dalam keadaan terbaru
      Untungnya masih terikat ke versi sebelumnya, jadi tidak terlalu buruk

  • Interoperabilitas JavaScript-nya juga sangat bagus: https://www.rapier.rs/docs/user_guides/javascript/getting_st...

  • Dimforge dulu punya engine fisika bernama nphysics, yang mendukung soft body dan multibody
    Sekarang engine itu ditinggalkan demi Rapier, tetapi Rapier bahkan belum mendukung setengah dari fitur-fitur itu atau fitur lain yang dulu dimiliki nphysics
    Akibatnya, nphysics terlalu tua sehingga sulit dipakai di ekosistem modern, sementara Rapier terlalu baru sehingga fiturnya jauh lebih sedikit
    Hal serupa juga pernah terjadi sebelumnya. Ada library simulasi fluida bernama Salva yang mendukung coupling dua arah dengan nphysics dan berjalan di semua GPU/CPU, tetapi sekarang ditinggalkan demi Sparkl
    Namun Sparkl tidak memiliki fitur-fitur itu dan hanya mendukung CUDA. Jadi Salva sudah setua nphysics, sedangkan Sparkl terlalu baru, fiturnya jauh lebih sedikit, dan tidak punya dukungan lintas platform
    Bahkan ini terasa disengaja. Seolah-olah “menulis ulang kode ini agar menjadi kurang lintas platform”
    Saya berharap suatu hari rangkaian penulisan ulang ini berhenti, dan mereka menetap pada sesuatu yang benar-benar mendukung semua fitur yang diperlukan
    Namun jika setiap penulisan ulang kehilangan fitur, saya tidak yakin ekosistem Dimforge cocok untuk saya
    Bagaimana saya bisa tahu Rapier tidak akan suatu hari ditinggalkan demi sesuatu yang lebih baru, lalu engine baru itu bahkan tidak mendukung setengah dari fitur Rapier
    Saya paham bahwa sebagai proyek baru, ia belum bisa mendukung semua fitur nphysics yang sudah matang
    Tetapi masalahnya adalah justru nphysics yang matang itu sudah sepenuhnya ditinggalkan dan tidak dipelihara
    Kalau Dimforge tidak punya preseden seperti ini, kekhawatiran ini akan terasa tidak realistis, tetapi rekam jejaknya ada
    Mungkin suatu hari Rapier akan mencapai tingkat fitur yang sudah dimiliki nphysics 5 tahun lalu, tetapi bagi developer yang ingin membangun sesuatu di atas fitur-fitur yang saat ini hilang, ini terasa seperti kemunduran 5 tahun yang arbitrer