-
-
Notifications
You must be signed in to change notification settings - Fork 259
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
ColliderParent
component
#397
base: master
Are you sure you want to change the base?
Conversation
Is |
Thank you for this PR! What use-case does this new component serve? I’m not sure it should have any side-effect (when moved or removed) regarding the collider’s parent since this is based only on the entity hierarchy. I’m also worried of the performance implications of If the goal is only to easily find the entity of a collider’s parent rigid-body, we have the method |
I don't think we ever updated the collider parent if the entity was moved in the hierarchy though which was part of the point of this. At least I don't see any I also kind of think |
Some ways I think we could minimize the performance implications is by having a |
This fixes #337 as well. |
src/plugin/systems.rs
Outdated
let child_colliders = |entity: Entity| -> Vec<Entity> { | ||
let mut found = Vec::new(); | ||
let mut possibilities = vec![entity]; | ||
while let Some(entity) = possibilities.pop() { | ||
if rigid_bodies.contains(entity) { | ||
continue; | ||
} | ||
|
||
if colliders.contains(entity) { | ||
found.push(entity); | ||
} | ||
|
||
if let Ok(children) = childrens.get(entity) { | ||
possibilities.extend(children.iter()); | ||
} else { | ||
continue; | ||
}; | ||
} | ||
|
||
found | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This could be done better, ideally without allocations. I'm thinking of just refactoring this all so that any entity in the hierarchy between a RigidBody
and a Collider
has a ColliderLink
marker component.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suppose this is fine as long as the Vec is re-used in the system as a Local<Vec<Entity>>
This should be ready to merge now.
Entity hierarchy changes are not reflected in the
I'm a bit confused on this, we base the parent initially on the entity hierarchy so I'd assume we'd want to keep it updated to that standard.
Topology changes should be relatively infrequent so I'm not too worried here. There are some improvements we could make by mimicking transform propagation and only operating on
The method is super useful, but I think it lacks a bit of discoverability, I don't think I've seen any uses of rapier in the wild where it was correctly used instead of just assuming that the |
I was worried about the user adding or removing the Since it is not supposed to be modified by the user, I wonder if we should call this Otherwise that looks good! |
Just ColliderParent should be fine, Parent for bevy is similar in that you shouldn't modify it manually, but instead through commands. I'll improve the docs here a bit as well. I think it is worthwhile just for consistency over changes to the ECS world. We could also do it by directly setting the collider parent in the RapierContext, but this is more idiomatic for how bevy users see game entities, where the property is directly attached. Plus this has some benefits in the future when bevy finally gets relations added. |
7efa59b
to
70f2c16
Compare
Ease of access for finding the rigid body associated with the collider as well as updating the collider parent based on changes to the bevy hierarchy.
For an example of the issue with the current system: https://github.com/Aceeri/rapier_sync