specs-physics
specs-physics copied to clipboard
amethyst
0.4.0 Rewrite
Specs-physics 0.4 Rewrite
This rewrites the specs-physics API to remove unnecessary synchronization and copying by implementing the new BodySet and ColliderSet traits with Component Storages, indexing handles for each object type using Entity. This new API reduces maintenance burden, complexity, and better exposes the entirety of nphysics, all while likely improving performance.
Background
I originally planned to more directly integrate with the traits provided by nphysics (such as with concrete storages for different body types, that together implement the set traits, or even borrowing a custom rigidbody type and its associated position together to implement Body, eliminating the local position data and associated pose synchronization), reducing indirection and making access more simple, but this proved to be difficult, maybe impossible, to implement. And it didn't seem if such an approach was beneficial enough for its maintenance costs.
However, I came up with the idea of doing this the opposite direction with the join extension trait API, and found that it could be a very nice solution that would make the crate a lot easier to maintain. This led to me opening https://github.com/rustsim/nphysics/pull/237 when I discovered that given the BodySet parameters were removed from some types, I could very simply implement BodySet (albeit using Box<dyn Body>) and other associated Set types over Component Storages.
Changes
- Adds support for 2D from @jmeggitt's PR.
- Updates to latest nphysics/ncollide
- Replaces old Body API with
BodySetandColliderSetimplemented as Storages, with object handles implemented using the Entity type. - Removes parameter bits and their synchronization in lieu of simply exposing new nphysics resources.
- Removes collider bits since bodies and their colliders are now easily addressable by the Entity type.
To Do
While the API itself is ready for use and review, I still have some of all of the following stuff to do:
- [x] Update documentation
- [x] Update examples
- [x] Add Amethyst example from my crusty old Amethyst example branch
- [x] Provide a nice EntityBuilder extension API Bodies and Colliders
- [x] Refactor pose synchronization
However, the bulk of the work is done, especially the spooky (happy October) unsafe blocks in handle.rs.
One might say that the library definitely shouldn't be called nphysics-ecs-dumb any longer!
This latest commit is based on the work in https://github.com/rustsim/nphysics/pull/237 (I cannot reference that git branch from my manifest due to the crates themselves being in subdirectories of the repository). This fixes compilation errors in the library, and now what's remaining is to clean up the API and get the examples running.
The basic example is now fully updated and works with a nice EntityBuilder extension trait! Also, the fixed stepping bits from previous versions have returned, along with a new addition in the batch dispatcher inspired by @andreacatania (although I have yet to tango with it in full) While some specific pieces of the API are yet to be ironed out (BodyPartHandle component with pose sync, joins with automatic casting for builtin Body types like RigidBody, and implementing JointConstraintSet and ForceGeneratorSet as Storages), the core part of the API is done, and this PR is now ready for review! Just please mind the documentation and remaining examples which have not been updated. Also note that this PR uses a temporary Git submodule since this API is made possible by https://github.com/rustsim/nphysics/pull/237, which has not landed.
The nphysics PR has landed WOOT! Will remove the git submodules with the next nphysics release.
Have you built with commit 51ce6c8? I'm not able to build using that refpoint
Apologies... I posted incomplete work because I was rushing out the door. Ignore the amethyst dep stuff, that's just me writing an example with the amethyst nalgebra bump.
No worries, I was able to integrate the changes from this PR + my diff into my game project and it worked well! Overall, I was very happy with the cleaner API and the updated dependencies.
There were a couple surprises when I found that 1) I needed to manually sync the Transform::isometry() to all BodyComponents and 2) I needed to insert various Resources when I created my own PhysicsBundle. I am okay with these changes to behavior and don't think anything needs to be changed from your PR. Maybe add a note about the behavior changes to the release documentation?
-
You're very right I need to document this but I will also personally recommend against writing code like this in the migration docs. If you have a Body/Transform which are sync'd in the Pose system, you should simply just change the position of the Body directly! I'm adding Marker types to make joining over RigidBodies etc more ergonomic so this will be easier since you can't mutate a Body/BodyPart's position generically anyways.
-
PhysicsBundle should add everything necessary for you, could you post your code where you needed to manually insert a resource? That'd be a bug imo.
Thanks for testing stuff out and posting feedback! I super appreciate it 💜
I get an error when I try the build this branch
error[E0495]: cannot infer an appropriate lifetime for lifetime parameter `'a` due to conflicting requirements
--> C:\Users\paris\.cargo\git\checkouts\specs-physics-8734272910d5c1dd\30331dc\src\systems\physics_stepper.rs:18:24
|
18 | impl<'a, N: RealField> System<'a> for PhysicsStepperSystem<N> {
| ^^^^^^^^^^
|
note: first, the lifetime cannot outlive the lifetime `'a` as defined on the impl at 18:6...
--> C:\Users\paris\.cargo\git\checkouts\specs-physics-8734272910d5c1dd\30331dc\src\systems\physics_stepper.rs:18:6
|
18 | impl<'a, N: RealField> System<'a> for PhysicsStepperSystem<N> {
| ^^
note: ...so that the types are compatible
--> C:\Users\paris\.cargo\git\checkouts\specs-physics-8734272910d5c1dd\30331dc\src\systems\physics_stepper.rs:18:24
|
18 | impl<'a, N: RealField> System<'a> for PhysicsStepperSystem<N> {
| ^^^^^^^^^^
= note: expected `shred::system::System<'a>`
found `shred::system::System<'_>`
= note: but, the lifetime must be valid for the static lifetime...
note: ...so that the type `nphysics2d::world::mechanical_world::MechanicalWorld<N, world::BodySet<'_, N>, specs::world::entity::Entity>` will meet its required lifetime bounds
--> C:\Users\paris\.cargo\git\checkouts\specs-physics-8734272910d5c1dd\30331dc\src\systems\physics_stepper.rs:19:5
|
19 | / type SystemData = (
20 | | Entities<'a>,
21 | | WriteExpect<'a, MechanicalWorldRes<'a, N>>,
22 | | WriteExpect<'a, GeometricalWorldRes<N>>,
... |
28 | | Write<'a, ProximityEvents>,
29 | | );
| |______^
What am I doing wrong ? I'm using
specs-physics = {git = "https://github.com/amethyst/specs-physics/", branch = "v0.4.0", default-features = false, features=["dim2"]}
to import the crate. (Tested with stable and nightly)
Use the following instead:
- specs-physics = {git = "https://github.com/amethyst/specs-physics/", branch = "v0.4.0", default-features = false, features=["dim2"]}
+ specs-physics = {git = "https://github.com/distransient/specs-physics/", branch = "0.4.0", default-features = false, features=["dim2"]}
I can't possibly review this, its way too big.
What's the status on this? If its in working condition I'll port my project to it and see how that all works.
What's the status of this PR? By the looks of the description of the PR this seems almost finished? Would it make sense to start building towards your fork in the meantime @distransient?
