Jondolf
Can this physics package be used outside of Bevy (e.g., with another ECS)?
First off, great work on this package! The quote "Made with Bevy, for Bevy. No wrappers around existing engines." is very clear, and I appreciate the dedication to the Bevy ecosystem.
However, I'm currently developing a game that uses both Bevy and a custom ECS-driven database called SpacetimeDB. I'm exploring options for a physics solution, and I'm particularly interested in your package due to its qualities (and personal preference over Rapier, honestly!).
My goal is to avoid a separate headless server for physics, and ideally, integrate the physics calculations directly within SpacetimeDB's ECS, similar to how it would work in Bevy.
Given that SpacetimeDB is also an ECS-driven system for game development, I was wondering if there's any possibility or approach to utilize this physics package's core logic or components outside of a direct Bevy application, specifically within another ECS framework like SpacetimeDB?
I understand the "for Bevy" philosophy, but I'm curious about the underlying architecture and if there's any degree of decoupling that might allow for such an integration. I'm trying to determine if I'd need to adapt a more generic physics engine like Rapier (which I'm considering as a fallback) or if there's a path to leverage your package's strengths in a more versatile manner across my game's different ECS environments.
First off, great work on this package!
Thanks 😄
Given that SpacetimeDB is also an ECS-driven system for game development, I was wondering if there's any possibility or approach to utilize this physics package's core logic or components outside of a direct Bevy application, specifically within another ECS framework like SpacetimeDB?
So, like you quoted, Avian is currently made with Bevy, for Bevy. In practice what this means is that physics data for rigid bodies and colliders is primarily stored in components on the entities themselves, the physics simulation loop is implemented with systems acting on these entities, and the systems are further organized into plugins. It's all tied to Bevy's types and conventions, which makes it kind of difficult to decouple from it, especially in terms of the API.
However...
I understand the "for Bevy" philosophy, but I'm curious about the underlying architecture and if there's any degree of decoupling that might allow for such an integration.
It's possible that we could extract a lot of the internal physics logic into a separate crate that is fully decoupled from the ECS. This would include most of the solver and collision detection stuff, so pretty much everything related to the actual rigid body dynamics. It would not contain a proper API for actually creating and using rigid bodies, or a data storage for them, but just the core functionality and utilities for simulating them.
We could then create crates on top of this to provide the actual API and data types. The Bevy integration would provide components like Avian currently does, and store physics data in the ECS, using the functionality in the "core crate" to act on that data. You could also create a more Rapier-like general library with larger RigidBody and Collider types and custom storage instead of using the ECS. Or in your case, there could also be a SpacetimeDB backend.
But to be clear, this is very hypothetical, and not something I'm prioritizing in the near future. There are still a lot of core architectural pieces and optimizations that need to be implemented, and I want to make sure that they're all sorted out and polished before attempting such a large restructuring. And even then, Bevy remains as my top priority for Avian, so I would only consider decoupling it as long as it doesn't hurt the Bevy integration. For now, I would recommend using Rapier for anything that needs to be decoupled from Bevy.
That being said, it would be great if Avian was more broadly useful to the Rust ecosystem even outside of Bevy, so this is definitely something worth experimenting with!
