Rustで書かれた2D・3D物理エンジン Rapier

 (rapier.rs)
3 ポイント 投稿者 GN⁺ 2024-02-29 | 1件のコメント | WhatsAppで共有
  • Rapierは、ゲーム・アニメーション・ロボティクスのようにリアルタイム物理が必要なアプリケーションを対象とした、Rustベースの物理エンジン群
  • 高速な実行と安定性を目標としており、必要に応じてクロスプラットフォーム決定性を選択的にサポート
  • 剛体の衝突と力、ジョイント制約、接触イベント・センサー、スナップショットなど、物理シミュレーションに必要な機能を提供
  • JavaScriptバインディングを提供しており、Rust以外の環境でもRapierを活用可能
  • Apache 2.0ライセンスの無料オープンソースで、Dimforgeが開発し、GitHub Sponsorで支援を受けている

Rapierが対象とする用途

  • RapierはRustで書かれた2Dおよび3D物理エンジン群
  • 主な対象は、リアルタイム物理処理が必要なアプリケーション
    • ビデオゲーム
    • アニメーション
    • ロボティクス
  • 設計目標は高速で安定した動作であり、選択的にクロスプラットフォーム決定性をサポート

提供機能と配布形態

  • 物理シミュレーションのための主要機能を含む
    • 剛体衝突と力
    • ジョイント制約
    • 接触イベントとセンサー
    • スナップショット
    • 選択的なクロスプラットフォーム決定性
    • JavaScriptバインディング
  • Rapierは無料のオープンソースで、Apache 2.0ライセンスで配布
  • 開発元はDimforgeというオープンソース企業
  • 支援はGitHub Sponsorを通じて可能

関連記事

1件のコメント

 
GN⁺ 2024-02-29
Hacker Newsの意見

  • Rapierの決定論モードでオンラインマルチプレイヤーゲームを作った。
    プレイヤーが交互に虫を相手チーム側へ体当たりさせ、丘を占領する方式。
    まだシングルプレイヤーモードはなく、AIを書くのは以前作ったチェス系ゲームより難しい。
    ゲームは https://evrimzone.itch.io/crittershowdown で見られ、物理／ゲームロジックのソースは https://github.com/evrimoztamur/crittershowdown/blob/e4d9a19... にある。
    いずれ、どう組み合わせたか、何を学んだかを記事にするつもりだが、全体として非常に堅牢なライブラリで、RustらしいAPI設計のおかげで必要なものはすべて実装できた。

    • 面白そう。Webサイトにデプロイするのは簡単だったのか気になる。
      WebAssemblyにコンパイルしたのか、それともロジック全体をローカルサーバーでホストする方式なのか知りたい。
    • サーバー側のマルチプレイヤーゲームを作ろうとしてRapier2Dを使い始めたので、関連する記事が早く出るとうれしい。

  • 数か月前に**幾何代数（Geometric Algebra）**にはまったのだが、2D、3D、4D以上、非ユークリッドなど非常に多様な幾何を扱ううえで、驚くほど簡潔で直感的な方法に見えた。
    なので、幾何代数が物理エンジンのよい基盤になり得るのか気になっていた。
    興味深そうなRustライブラリはいくつかあるが [1][2]、大きく注目されているものはなさそう。
    この方面を調べた人がいるのか知りたい。
    [1]: https://crates.io/keywords/geometric-algebra
    [2]: https://github.com/Lichtso/geometric_algebra
    始めてみたいなら、Freya Holmérの「Why can't you multiply vectors?」がよい入口になり得る: https://www.youtube.com/watch?v=htYh-Tq7ZBI それと https://bivector.net/index.html

    • 面白い事実として、Excalidrawでは幾何代数が使われており、今も一部のインタラクションを動かしている: https://github.com/excalidraw/excalidraw/blob/master/package...
    • 物理エンジンで最も面白くない部分はベクトル表現だ。
      幾何代数は「古典的な」Heaviside式ベクトル代数と同型で、難しい問題は衝突処理、エネルギー保存、安定性のような方面にある。
    • 同じ幾何代数の沼にはまり、もう一つの「驚くほど簡潔で直感的な方法」であるClojureにもはまった。
      そこで、任意の幾何代数を生成し、いろいろ面白い演算ができるライブラリを作った。物理エンジンの基盤としても使える。
      興味があればここにある: https://cljdoc.org/d/net.clojars.jordibc/geometric-algebra/
    • 関連チュートリアル: https://www.youtube.com/watch?v=5R2sv9GCwz0
    • より注目されているのはこちらのライブラリ: https://github.com/fu5ha/ultraviolet

  • Rust向けのBevy Rapierプラグインのガイドを書いた: https://taintedcoders.com/bevy/rapier/
    Bevy側の興味深い代替としてBevy XPBDもあり、これも記事にまとめた: https://taintedcoders.com/bevy/xpbd/

    • ゆっくり動く物体を動いていないものとして扱うシステムを見ると不安になる。
      「Sleeping」は動いていない物体のシミュレーションコストを減らして性能を高める手法で、SleepingThresholdリソースで調整できると書かれている。
      デフォルト値の例として linear: 0.1, angular: 0.2 が入る。
    • 今xpbdで物理ベースの2D格闘ゲームを作っているが、今のところかなり気に入っている。
      これまでに、いくつかの衝突が1フレーム消える問題が一つあったが、こういうものは簡単に回避できるし、よりよくは報告して修正してもらうこともできる。
    • XPBDがかなり興味深かったので何度か試し実装をしてみて、最近のゲームジャム作品にはAABB専用のXPBDを入れた。
      まだ回転だけはうまくできていないが、それ以外は複雑さが溶けていく感じだ。
      線形代数？ 必要ない。ただのVec3だ。行列？ ソルバー？ 1998年に戻ったように、すべての制約を反復して満たせばいい。
      衝突マージン？ 腕の問題だ。ブロードフェーズ？ GJK？ 考えすぎず、現代のCPUに任せればいい。
      collect_pairsの最適化をしたあと、実際のボトルネックがmallocだったと気づいて直せば、100個くらいのオブジェクトは楽に処理できる。Bulletは不要だ。
      速度補正ステップも最初は混乱したが、AABBでプロトタイプしてみると一般の図形にも再び移せそうだ。
      最初はこのステップを飛ばしていたので、すべての衝突が少し弾性的に振る舞っていた。

  • Dimforge は本当にすごい仕事をしている
    ロボティクスの位置推定や地図作成のような分野で nalgebra + Rust が Eigen + C++ を置き換えられるなら、とても期待できる

    • 最近のロボティクスプロジェクトのほとんどを Rust でやっているが、業界が C++ 特有のイディオムに浪費している時間はばかげているほど大きい
      Rust ではそのままうまくいくことが多い。ただ、頑として Rust への投資を拒む旧世代がいるのは残念
      正直、C++ のロボティクスコード周辺には巨大な産業があるので、理由は理解できる
    • これを現実にしたい
      現在 Rust で使えるまともな ロボティクスフレームワーク があるのか気になる
      ROS2 が Rust をゆっくり取り込みつつあるという話は聞いたが [1]、どう進んだのかはよく分からない
      ハードウェア統合/抽象化はすでに C++ で行われているので、ROS はセンサーフュージョン、地図作成、位置推定へ入っていく良い入口になり得る
      企業がこれを使っているのかも気になる
      [1] https://github.com/ros2-rust/ros2_rust

  • 数十年前に剛体物理エンジンを作っていたときの記憶では、積み重ね（stacking） は非常に難しい問題だった
    当時、物体が床に沈み込むのを避ける最善の解法は、床から始めて物体を外側へ押し出す方向性非循環グラフを作ることだった
    収束させるには何度も反復する必要があり、かなりハックっぽく感じた
    今ではこの問題が解決されているのか気になる。このプロジェクトでは積み重ねについての言及を見つけられなかった

    • Box2D の作者がまさにそのテーマで素晴らしい記事を書いている: https://box2d.org/posts/2024/02/solver2d/
      記事の下部にリンクされている作者の動画では、各ソルバーが複数の難しい積み重ね問題をどう処理するかを示している: https://youtu.be/sKHf_o_UCzI
    • 今では積み重ねはうまく動作する
      非循環グラフは不要で、ソルバーの反復回数を十分に増やせば収束する
      接触と摩擦制約の数を考えれば、何度も反復するのは自然なことで、最大残差を追跡すればほぼ 0 に到達するまで回せる
      少し壊れている部分は、衝突とソルバーが限られた更新速度でしか動かない点
      最初から貫通状態で始まるとそれを解消する必要があるが、現実の物体はそのように貫通しないので、やや「偽物」の処理であり、余分な動きが生じてスタックの安定性が落ちることがある
      それでもこれを回避する方法はいくつもあり、人気のある物理エンジンはそれぞれ何らかの形で解法を持っている

  • Rust は固定観念を証明し続けているように見える
    Rust 製ゲームエンジンは 50 個あるのに、Rust 製ゲームは 5 本しかない、というジョークを思い出す

    • 物理エンジンが 50 個でもあればいいのに
      Rapier はこちらがまさに必要としている要件を満たしてはいないが、良い代替もない
    • 最近楽しく遊んだゲームの1つは Rust で書かれていたと記憶している: (the) Gnorp Apologue (https://gnorp.dev/)
      だから、エンジンコードをあまり多く使わなくてよい小規模な 2D ゲームなら可能そうだ
      このゲームは大部分を SDL で処理していたケースだった

  • Rapier で小さな Web デモも作ってみた: https://github.com/iErcann/NotRoblox
    Rust は使っていない
    気に入った点は、AmmoJS よりドキュメントが良いこと。AmmoJS では pybullet を読む必要があった
    比較的新しく、サーバー（Node）とクライアント（ブラウザ）の両方で実行できる
    ここではサーバー側で動かしているが、両方で動かしてクライアント予測と補正を実装することも可能
    バンドルも小さい。AmmoJS は 2MB くらいだったと思う

    • Rust 側では Rapier のドキュメント が最新状態ではないと理解している
      幸い以前のバージョンに固定しているので、それほど悪くはない

  • JavaScript との相互運用性も本当に良い: https://www.rapier.rs/docs/user_guides/javascript/getting_st...

  • Dimforge には以前 nphysics という物理エンジンがあり、ソフトボディとマルチボディをサポートしていた
    今では Rapier のために廃止されたが、Rapier はそれらや nphysics が持っていた他の機能の半分もサポートしていない
    結果として、nphysics は古すぎて現代のエコシステムでは使いにくく、Rapier は新しすぎて機能がかなり不足している
    以前にも似たことがあった。Salva という流体シミュレーションライブラリは nphysics との双方向結合をサポートし、あらゆる GPU/CPU で動作していたが、今では Sparkl のために廃止された
    ところが Sparkl にはその機能がなく、CUDA だけをサポートしている。そのため Salva は nphysics と同じくらい古く、Sparkl は新しすぎて機能がずっと少なく、クロスプラットフォーム対応もない
    それどころか意図的に見える。「このコードをよりクロスプラットフォームでなくするために書き直した」ようなものだ
    いつか継続的な書き直しが止まり、実際に必要な機能をすべてサポートする何かに落ち着いてほしい
    だが書き直しのたびに機能を失うなら、Dimforge エコシステム が自分に合うかどうかは分からない
    Rapier もいつかさらに新しい何かのために廃止され、その新しいエンジンが Rapier の機能の半分もサポートしない、ということがないとどうして分かるだろう
    新しいプロジェクトなので、成熟した nphysics の全機能をサポートできないのは理解できる
    だが問題は、まさにその成熟した nphysics が完全に廃止され、メンテナンスされていない点だ
    Dimforge にすでにこうした前例がなければ非現実的な心配だっただろうが、実績がある
    いつか Rapier が 5 年前の nphysics がすでに備えていた機能レベルに到達するかもしれないが、今欠けている機能の上に何かを作りたい開発者にとっては、恣意的な 5 年の後退 のように感じられる