Rust में लिखा गया 2D·3D physics engine Rapier

• Rapier Rust आधारित physics engines का एक set है, जो games, animation और robotics जैसे real-time physics की जरूरत वाले applications के लिए लक्षित है
• इसका लक्ष्य तेज execution और stability है, और जरूरत पड़ने पर cross-platform determinism को वैकल्पिक रूप से support करता है
• यह physics simulation के लिए जरूरी features देता है, जैसे rigid-body collisions और forces, joint constraints, contact events·sensors, snapshots आदि
• JavaScript bindings उपलब्ध कराता है, जिससे Rust के बाहर के environments में भी Rapier का उपयोग किया जा सकता है
• यह Apache 2.0 license के तहत मुफ्त open source है, Dimforge इसे develop करता है और GitHub Sponsor के जरिए sponsorship लेता है

---

Rapier किन उपयोगों को लक्षित करता है

• Rapier Rust में लिखा गया 2D और 3D physics engines का set है
• इसका मुख्य target वे applications हैं जिन्हें real-time physics processing की जरूरत होती है
  • Video games
  • Animation
  • Robotics
• Design goal तेज और stable operation है, और यह वैकल्पिक रूप से cross-platform determinism को support करता है

उपलब्ध features और distribution तरीका

• Physics simulation के लिए मुख्य features शामिल हैं
  • Rigid-body collisions और forces
  • Joint constraints
  • Contact events और sensors
  • Snapshots
  • वैकल्पिक cross-platform determinism
  • JavaScript bindings
• Rapier मुफ्त open source है और Apache 2.0 license के तहत distributed है
• इसे Dimforge open source company develop करती है
• Sponsorship GitHub Sponsor के जरिए की जा सकती है

[GN⁺]

Hacker News की राय

• Rapier deterministic mode से एक ऑनलाइन multiplayer game बनाया
  इसमें खिलाड़ी बारी-बारी से कीड़ों को विरोधी टीम की तरफ टकराते हैं और पहाड़ी पर कब्ज़ा करते हैं
  अभी single-player mode नहीं है, और AI लिखना पहले बनाए गए chess-जैसे game की तुलना में ज़्यादा मुश्किल है
  game https://evrimzone.itch.io/crittershowdown पर देखा जा सकता है, और physics/game logic का source https://github.com/evrimoztamur/crittershowdown/blob/e4d9a19... पर है
  बाद में यह लिखने की योजना है कि इसे कैसे जोड़ा और क्या सीखा, लेकिन कुल मिलाकर यह बहुत मजबूत library है और Rust-जैसे API design की वजह से जो चाहिए था वह सब implement कर पाया

  • मज़ेदार लग रहा है। जानना चाहूंगा कि website पर deploy करना आसान था या नहीं
    क्या इसे WebAssembly में compile किया गया था, या पूरी logic को local server पर host करने का तरीका अपनाया गया था?
  • server-side multiplayer game बनाने के लिए Rapier2D इस्तेमाल करना शुरू किया है, इसलिए उम्मीद है कि इससे जुड़ा लेख जल्दी आएगा

• कुछ महीने पहले Geometric Algebra में डूब गया था, और 2D, 3D, 4D से आगे, non-Euclidean वगैरह जैसी बहुत तरह की geometries को संभालने का यह हैरानीजनक रूप से concise और intuitive तरीका लगा
  इसलिए सोच रहा था कि क्या Geometric Algebra physics engine के लिए अच्छा आधार बन सकता है
  कुछ दिलचस्प Rust libraries दिखती हैं [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 ने Geometric Algebra इस्तेमाल किया था और अभी भी कुछ interactions उसी से चलती हैं: https://github.com/excalidraw/excalidraw/blob/master/package...
  • physics engine में सबसे कम दिलचस्प हिस्सा vector representation है
    Geometric Algebra “classical” Heaviside-style vector algebra के isomorphic है, और मुश्किल समस्याएं collision handling, energy conservation, stability जैसी चीज़ों में हैं
  • मैं भी उसी Geometric Algebra rabbit hole में गया था, और Clojure में भी, जो एक और “हैरानीजनक रूप से concise और intuitive तरीका” है
    इसलिए ऐसी library बनाई जो arbitrary geometric algebra generate कर सकती है और कई मज़ेदार operations कर सकती है; इसे physics engine के आधार के तौर पर भी इस्तेमाल किया जा सकता है
    रुचि हो तो यह रही: https://cljdoc.org/d/net.clojars.jordibc/geometric-algebra/
  • संबंधित tutorial: https://www.youtube.com/watch?v=5R2sv9GCwz0
  • ज़्यादा ध्यान खींचने वाली library यह है: https://github.com/fu5ha/ultraviolet

• Rust के लिए Bevy Rapier plugin guide लिखी है: https://taintedcoders.com/bevy/rapier/
  Bevy side पर एक दिलचस्प alternative Bevy XPBD भी है, और उसके बारे में भी लिखा है: https://taintedcoders.com/bevy/xpbd/

  • धीमे चलने वाली वस्तुओं को न चलने वाली मानने वाली system देखकर चिंता होती है
    “Sleeping” एक technique है जो न चलने वाली objects की simulation cost घटाकर performance बढ़ाती है, और इसे SleepingThreshold resource से adjust किया जा सकता है
    default value के उदाहरण में linear: 0.1, angular: 0.2 हैं
  • अभी xpbd से physics-based 2D fighting game बना रहा हूं, और अब तक यह काफी पसंद आ रहा है
    अब तक एक समस्या आई है कि कुछ collisions एक frame के लिए गायब हो जाते हैं, लेकिन ऐसी चीज़ों को आसानी से workaround किया जा सकता है, या बेहतर यह कि report करके fix कराया जा सकता है
  • XPBD काफी दिलचस्प है, इसलिए कुछ बार trial implementations किए, और हाल की game jam entry में AABB-only XPBD डाला
    अभी सिर्फ rotation ठीक से नहीं कर पाया, बाकी में complexity जैसे पिघलती हुई लगती है
    linear algebra? ज़रूरत नहीं। बस Vec3 है। matrices? solver? जैसे 1998 में लौट आए हों, सभी constraints को बार-बार satisfy करा दो
    collision margin? skill issue है। broad phase? GJK? ज़्यादा मत सोचो, modern CPU पर छोड़ दो
    collect_pairs optimization करने के बाद जब समझ आया कि असली bottleneck malloc था और उसे ठीक कर दिया, तो करीब 100 objects आराम से संभल जाते हैं। Bullet की ज़रूरत नहीं
    velocity correction step भी शुरुआत में confusing था, लेकिन AABB से prototype करने के बाद लगता है कि इसे general shapes पर भी वापस ले जा सकता हूं
    पहले इस step को skip किया था, तो सभी collisions हल्के elastic जैसे behave कर रहे थे

• Dimforge सचमुच कमाल का काम कर रहा है
  रोबोटिक्स में localization और mapping जैसे क्षेत्रों में अगर nalgebra + Rust, Eigen + C++ की जगह ले सके, तो यह वाकई रोमांचक होगा

  • हाल के ज़्यादातर robotics projects मैं Rust में कर रहा हूँ, और industry C++ की खास idioms पर जितना समय बर्बाद करती है, वह बेतुका है
    Rust में बहुत-सी चीज़ें बस अपने-आप हो जाती हैं। बस अफसोस है कि पुरानी पीढ़ी के कुछ लोग हैं जो पीछे हटने को तैयार नहीं और Rust में निवेश से इनकार करते हैं
    ईमानदारी से कहूँ तो C++ robotics code के इर्द-गिर्द एक बहुत बड़ा industry ecosystem है, इसलिए वजह समझ आती है
  • मैं इसे वास्तविकता बनाना चाहता हूँ
    जानना चाहता हूँ कि अभी Rust में इस्तेमाल करने लायक कोई robotics framework है या नहीं
    सुना है कि ROS2 धीरे-धीरे Rust को शामिल कर रहा है [1], लेकिन यह कितना आगे बढ़ा है, ठीक से नहीं पता
    hardware integration/abstraction पहले से C++ में है, इसलिए ROS sensor fusion, mapping और localization में प्रवेश का अच्छा रास्ता हो सकता है
    यह भी जानना चाहता हूँ कि क्या कंपनियाँ इसका इस्तेमाल कर रही हैं
    [1] https://github.com/ros2-rust/ros2_rust

• दशकों पहले जब मैंने rigid body physics engine बनाया था, मेरी याद में stacking बहुत कठिन समस्या थी
  उस समय objects को floor में धँसने से बचाने का सबसे अच्छा उपाय था floor से शुरू करके objects को बाहर धकेलने वाला एक directed acyclic graph बनाना
  converge करने के लिए कई iterations करने पड़ते थे और यह काफी hacky लगता था
  जानना चाहता हूँ कि आजकल यह समस्या हल हो गई है या नहीं। इस project में stacking का कोई उल्लेख नहीं मिला

  • Box2D के लेखक ने इसी विषय पर एक बेहतरीन पोस्ट लिखी है: https://box2d.org/posts/2024/02/solver2d/
    पोस्ट के नीचे link किया गया लेखक का video दिखाता है कि अलग-अलग solvers कई कठिन stacking problems को कैसे handle करते हैं: https://youtu.be/sKHf_o_UCzI
  • आजकल stacking अच्छी तरह काम करती है
    acyclic graph की ज़रूरत नहीं होती, और solver iteration count पर्याप्त बढ़ाने पर convergence हो जाता है
    contact और friction constraints की संख्या देखते हुए कई बार iterate करना स्वाभाविक है, और maximum residual track करें तो लगभग 0 तक पहुँचने तक चला सकते हैं
    थोड़ी टूटी हुई बात यह है कि collision और solver सीमित update rate पर ही चलते हैं
    अगर शुरुआत से ही penetration state में हों तो इसे हल करना पड़ता है, लेकिन वास्तविक objects ऐसे penetrate नहीं करते, इसलिए यह कुछ हद तक “fake” handling है और अतिरिक्त motion पैदा हो सकता है, जिससे stack stability घट सकती है
    फिर भी इसे bypass करने के कई तरीके हैं, और लोकप्रिय physics engines के पास अपने-अपने ढंग से कोई न कोई समाधान है

• Rust लगातार stereotype को साबित करता लगता है
  वह joke याद आता है कि Rust में बने game engines 50 हैं, लेकिन Rust में बने games सिर्फ 5 हैं

  • काश 50 physics engines ही होते
    Rapier मेरी exact जरूरत पूरी नहीं करता, और कोई अच्छा alternative नहीं है
  • हाल में मज़े से खेला गया एक game मुझे याद है कि Rust में लिखा था: (the) Gnorp Apologue (https://gnorp.dev/)
    इसलिए छोटे 2D games में, जहाँ ज्यादा engine code लिखने की ज़रूरत नहीं होती, यह संभव लगता है
    यह game ज्यादातर काम SDL से कर रहा था

• Rapier से एक छोटा web demo भी बनाया था: https://github.com/iErcann/NotRoblox
  Rust इस्तेमाल नहीं किया
  जो बात अच्छी लगी वह यह कि documentation AmmoJS से बेहतर है। AmmoJS के लिए pybullet पढ़ना पड़ा था
  यह अपेक्षाकृत नया है, और server (Node) तथा client (browser) दोनों तरफ चल सकता है
  यहाँ इसे server side पर चलाया गया है, लेकिन दोनों तरफ चलाकर client prediction और correction implement करना भी संभव है
  bundle भी छोटा है। AmmoJS शायद करीब 2MB था

  • Rust side पर मुझे लगता है कि Rapier documentation up to date नहीं है
    शुक्र है कि यह पुराने version से बंधा है, इसलिए बहुत बुरा नहीं है

• JavaScript interoperability भी वाकई अच्छी है: https://www.rapier.rs/docs/user_guides/javascript/getting_st...

  • Threlte (Svelte में इस्तेमाल होने वाला ThreeJS) का भी Rapier integration बेहतरीन है
    https://threlte.xyz/docs/reference/rapier/getting-started

• Dimforge के पास पहले nphysics नाम का physics engine था, जो soft bodies और multibodies को support करता था
  अब उसे Rapier के लिए deprecate कर दिया गया है, लेकिन Rapier उन चीज़ों या nphysics के दूसरे features के आधे को भी support नहीं करता
  नतीजतन nphysics इतना पुराना हो गया है कि modern ecosystem में इस्तेमाल करना मुश्किल है, और Rapier इतना नया है कि features बहुत कम हैं
  पहले भी ऐसा ही हुआ था। Salva नाम की fluid simulation library nphysics के साथ bidirectional coupling support करती थी और सभी GPU/CPU पर चलती थी, लेकिन अब उसे Sparkl के लिए deprecate कर दिया गया है
  मगर Sparkl में वे features नहीं हैं और वह केवल CUDA support करता है। इसलिए Salva, nphysics जितना outdated हो गया है, और Sparkl बहुत नया है, features काफी कम हैं और cross-platform support भी नहीं है
  यहाँ तक कि यह जानबूझकर किया गया लगता है। मानो “इस code को कम cross-platform बनाने के लिए फिर से लिखा” गया हो
  उम्मीद है कि कभी न कभी लगातार rewrites रुकेंगे और वे किसी ऐसी चीज़ पर टिकेंगे जो सचमुच ज़रूरी सभी features support करती हो
  लेकिन अगर हर rewrite में features खोते हैं, तो मुझे नहीं पता कि Dimforge ecosystem मेरे लिए सही है या नहीं
  कैसे पता चले कि Rapier भी किसी दिन किसी और नई चीज़ के लिए deprecate नहीं होगा, और वह नया engine Rapier के आधे features भी support नहीं करेगा
  यह समझ आता है कि नया project होने के कारण यह mature nphysics के सभी features support नहीं कर सकता
  लेकिन समस्या यह है कि वही mature nphysics पूरी तरह deprecate हो चुका है और maintain नहीं किया जा रहा
  अगर Dimforge का पहले से ऐसा precedent न होता तो यह चिंता अवास्तविक होती, लेकिन record मौजूद है
  शायद किसी दिन Rapier उन features के स्तर तक पहुँच जाए जो nphysics के पास 5 साल पहले ही थे, लेकिन जो developer अभी missing features के ऊपर कुछ बनाना चाहता है, उसके लिए यह मनमाना 5 साल पीछे जाना लगता है