-
-
Notifications
You must be signed in to change notification settings - Fork 108
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add ColliderBackendPlugin
and support generic colliders
#311
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
2 tasks
brianreavis
pushed a commit
to naturalatlas/bevy_xpbd
that referenced
this pull request
Feb 17, 2024
An improved version of Jondolf#302. Currently, collider logic is split across several plugins. The `PreparePlugin` initializes them and manages mass properties and collider parents, the `SyncPlugin` handles collider scale and transform propagation, the `BroadPhasePlugin` updates their AABBs and collects potential collision pairs, and the `NarrowPhasePlugin` uses them for actually computing contacts. Using `Collider` in so many places isn't ideal since it couples collision logic with other plugins, and it also makes it very challenging to implement custom collision backends nicely. It would be useful to handle collider-specific background work in a single plugin and to support custom colliders through generics. - Add a `ColliderBackendPlugin`. It handles collider initialization, transform propagation, scaling, parents, mass property updates, AABB updates, and more. - Add the `AnyCollider` and `ScalableCollider` traits. Implementing these for a component makes it possible to use a completely custom collider component by passing the type to `ColliderBackendPlugin` and `NarrowPhasePlugin` through generics. There is a new `custom_collider` example that demonstrates this. To avoid leaking too many implementation details related to system ordering, I also added more system sets like the `BroadPhaseSet`, `NarrowPhaseSet` and `SyncSet` enums. Creating a custom collision backend is now straightforward. After implementing `AnyCollider` and `ScalableCollider` for a component, simply add the `CollisionBackendPlugin` and `NarrowPhasePlugin` with that type: ```rust .add_plugins(( DefaultPlugins, PhysicsPlugins::default(), ColliderBackendPlugin::<CircleCollider>::default(), NarrowPhasePlugin::<CircleCollider>::default(), )) ``` --- - `CollisionBackendPlugin` - `AnyCollider` trait - `ScalableCollider` trait - `scale_by` method for colliders - `Collider::swept_aabb` - `ColliderAabb::new` - `ColliderAabb::merged` - `BroadPhaseSet` system sets - `NarrowPhaseSet` system sets - `SyncSet` system sets - `custom_collider` example - Moved `collider` module from `components` to `collision` module - `NarrowPhasePlugin` takes a generic type implementing `AnyCollider` - Moved collider systems from `PreparePlugin`, `SyncPlugin` and `SleepingPlugin` to `ColliderBackendPlugin` - Collider logic from `upate_mass_properties` is in a new `update_collider_mass_properties` system - Replace `NarrowPhasePlugin` with `NarrowPhasePlugin::<Collider>` if you add it manually - Replace `Collider::compute_aabb` with `Collider::aabb`
Jondolf
added a commit
that referenced
this pull request
Feb 18, 2024
) # Objective #311 added support for custom collider backends. However, the default `Collider` still remains, which requires the Parry and Nalgebra dependencies which are unnecessary if your collision backend doesn't use them. `Collider` and Parry should be optional. ## Solution Add three feature flags: `default-collider`, `parry-f32`, and `parry-f64`. `parry-f32` is a default feature that also enables `default-collider`. The Parry features are unfortunately necessary, because Parry is split into separate crates for f32 and f64, and we can't reuse the `f32` and `f64` feature flags, because then the dependencies wouldn't be optional. Not having the `default-collider` feature disables `Collider`, the default collision backend using it, the `SpatialQueryPipeline`, the `SpatialQuery` system parameter, and `ShapeCaster`. The `RayCaster` is still available for now, but it doesn't actually raycast unless users implement the functionality themselves. --- ## Changelog - Add three feature flags: `default-collider`, `parry-f32`, and `parry-f64` - `ColliderAabb` no longer uses Parry's AABB, and it has new methods ## Migration Guide - If using bevy_xpbd without default features, add either the `parry-f32` or `parry-f64` feature, unless you have a custom collision backend
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
A-Collision
Relates to the broad phase, narrow phase, colliders, or other collision functionality
C-Enhancement
New feature or request
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Objective
An improved version of #302.
Currently, collider logic is split across several plugins. The
PreparePlugin
initializes them and manages mass properties and collider parents, theSyncPlugin
handles collider scale and transform propagation, theBroadPhasePlugin
updates their AABBs and collects potential collision pairs, and theNarrowPhasePlugin
uses them for actually computing contacts.Using
Collider
in so many places isn't ideal since it couples collision logic with other plugins, and it also makes it very challenging to implement custom collision backends nicely. It would be useful to handle collider-specific background work in a single plugin and to support custom colliders through generics.Solution
ColliderBackendPlugin
. It handles collider initialization, transform propagation, scaling, parents, mass property updates, AABB updates, and more.AnyCollider
andScalableCollider
traits. Implementing these for a component makes it possible to use a completely custom collider component by passing the type toColliderBackendPlugin
andNarrowPhasePlugin
through generics. There is a newcustom_collider
example that demonstrates this.To avoid leaking too many implementation details related to system ordering, I also added more system sets like the
BroadPhaseSet
,NarrowPhaseSet
andSyncSet
enums.Creating a custom collision backend is now straightforward. After implementing
AnyCollider
andScalableCollider
for a component, simply add theCollisionBackendPlugin
andNarrowPhasePlugin
with that type:Changelog
Added
CollisionBackendPlugin
AnyCollider
traitScalableCollider
traitscale_by
method for collidersCollider::swept_aabb
ColliderAabb::new
ColliderAabb::merged
BroadPhaseSet
system setsNarrowPhaseSet
system setsSyncSet
system setscustom_collider
exampleChanged
collider
module fromcomponents
tocollision
moduleNarrowPhasePlugin
takes a generic type implementingAnyCollider
PreparePlugin
,SyncPlugin
andSleepingPlugin
toColliderBackendPlugin
upate_mass_properties
is in a newupdate_collider_mass_properties
systemMigration Guide
NarrowPhasePlugin
withNarrowPhasePlugin::<Collider>
if you add it manuallyCollider::compute_aabb
withCollider::aabb