-
-
Notifications
You must be signed in to change notification settings - Fork 120
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
Async colliders #190
Merged
Merged
Async colliders #190
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
It now wakes up bodies and subtracts from their mass properties. Since we can't access components of despawned entities, I added a `ColliderStorageMap` for now. It might not be optimal, but it can be improved later. Ideally we'd use hooks/callbacks once they're implemented in Bevy.
Jondolf
added a commit
that referenced
this pull request
Oct 21, 2023
# Objective A very common and important physics engine feature is to be able to attach multiple colliders to a body and position them relative to that body. This is already possible via `Collider::compound`, but it's highly limiting, as you can not specify separate material properties, densities, collision layers or whether a collider is a sensor, or add other components like meshes to the separate colliders. It can also be useful to have separate collision events for the individual colliders instead of for just the shared rigid body entity. Users expect it to be possible to have colliders be child entities that move with the parent and act as separate colliders, while still affecting the body like a normal compound collider would. It should be possible to nest the colliders in arbitrarily deep hierarchies. ## Solution This PR makes it possible to attach colliders as child entities: ```rust fn setup(mut commands: Commands) { commands .spawn((RigidBody::Dynamic, Collider::ball(0.5))) .with_children(|commands| { commands.spawn(( Transform::from_xyz(3.0, 0.0, 0.0), Collider::ball(0.5), )); }); } ``` You should be able to nest colliders as much as you want, and they will all be positioned relative to each other using `Transform`. Each collider has its own AABB, collision events, collision layers, material properties and so on. For knowing which colliders affect which rigid bodies, we use a `ColliderParent` component that stores the `Entity` of the rigid body. The component is automatically updated based on entity hierarchies. For positioning the colliders correctly and computing contact positions and centers of mass relative to the rigid body, we can use an automatically updated `ColliderTransform` component that stores the local positional and rotational offset and scale relative to the rigid body (not necessarily the collider's direct parent!). To avoid precision issues and numerical drift, I try to avoid using `GlobalTransform` and instead use `Position` and `Rotation` wherever possible. The mass properties of bodies are also automatically updated whenever any of the colliders are transformed or removed. ## Todo - [x] Document child colliders in `Collider` - [x] Wake up bodies when child colliders are transformed - [x] Wake up bodies and update their mass properties when their colliders are removed - [x] Remove `ColliderParent` and reset `ColliderOffset` when the collider's rigid body is removed - [x] Verify that arbitrary nesting with translations and rotations works correctly ## Follow-up work - Collider scale based on transforms #189 - Async colliders #190 - Colliders and AABBs should be debug rendering the sleeping status of the rigid body even as children - Find a way to remove `ColliderStorageMap` - Fix remaining contact issues with child colliders - Child collider collisions can sometimes be jittery, maybe the position isn't exactly right? - The orbiting motion of offset child colliders should be taken into account better when expanding AABBs - The center of mass seems to affect collisions a bit weirdly; this appears to be a constraint issue rather than a child collider issue though
Merged
Jondolf
added a commit
that referenced
this pull request
Oct 22, 2023
# Objective Setting the density of a collider is currently unnecessarily verbose and limiting. It requires giving the collider and density to a method that creates the mass property component: ```rust ColliderMassProperties::new_computed(&Collider::ball(0.5), 2.5) ``` This makes it basically impossible to specify the density when the collider isn't known in advance, like for async colliders #190, and the API is just very inconvenient. ## Solution Add a `ColliderDensity` component. The above becomes just this: ```rust ColliderDensity(2.5) ``` Because `ColliderMassProperties` is always overwritten using this density, I also made its properties completely read-only with getter methods. --- ## Changelog - Added `ColliderDensity` - Added `Collider::mass_properties` - Renamed `ColliderMassProperties::new_computed` to `ColliderMassProperties::new` - Made the properties of `ColliderMassProperties` read-only - Updated the documentation ## Migration Guide ```rust // Before let collider = Collider::ball(0.5); commands.spawn(( RigidBody::Dynamic, ColliderMassProperties::new_computed(&collider, 2.5), collider, )); // After commands.spawn(( RigidBody::Dynamic, Collider::ball(0.5), ColliderDensity(2.5), )); ```
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
Fixes #104. Depends on #154 and #189.
Currently, there's no easy way to add colliders to meshes loaded from scenes (glTFs and so on). A very common request is to have a way to generate the colliders automatically.
Solution
Add
AsyncCollider
andAsyncSceneCollider
, which are essentially equivalents to bevy_rapier's components. Also add aComputedCollider
enum that determines if the colliders should be trimeshes or convex hulls. Because these rely on some Bevy features, there is a newasync-collider
feature that is enabled by default, but only in 3D because colliders can't be created from meshes in 2D currently.AsyncCollider
example:AsyncSceneCollider
example:Changes to methods
I also renamed and added some more methods to make things more consistent and simple. I removed
_bevy
from the names because this crate is already for Bevy so it's unnecessary to have the prefix.Renamed
trimesh_with_flags
→trimesh_with_config
convex_decomposition_with_params
→convex_decomposition_with_config
trimesh_from_bevy_mesh
→trimesh_from_mesh
trimesh_from_bevy_mesh_with_flags
→trimesh_from_mesh_with_config
convex_decomposition_from_bevy_mesh
→convex_decomposition_from_mesh
Added
convex_decomposition_from_mesh_with_config
convex_hull_from_mesh