Skip to content
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

Child colliders added by a system seem not to be linked as children in Rapier #252

Open
ian-h-chamberlain opened this issue Aug 28, 2022 · 2 comments
Labels
A-Integration very bevy specific C-Bug Something isn't working D-Medium P-Medium S-not-started Work has not started

Comments

@ian-h-chamberlain
Copy link

Example gist (based on the existing player_movement2 example)

In this example, pressing Space spawns new (unparented) colliders somewhere relative to the player transform, and pressing Return adds all unparented colliders as children of the player. Here is a brief recording of the example:

bevy_rapier_example.mov

The main player collider does interact with the parentless colliders, (similar to if they were a Fixed Rigidbody, I think?), but once reparented, the colliders don't seem to interact with anything. Also, they are still colored as "parentless" by the debug renderer, which explains why their collisions are not impacting the parent's. This can be verified fairly easily with RapierContext::collider_parent() (none will be found even though there is a Rigidbody on the parent).

Is this expected behavior, or am I doing something wrong in my example? Maybe this is just a gap in the system change detection, and a system is needed that watches for HierarchyEvents on the relevant components, or something like that?

@ian-h-chamberlain
Copy link
Author

ian-h-chamberlain commented Aug 28, 2022

Interesting, I found a possible workaround by forcing the "initialization" code to run again on the collider after adding it as a child. In the spawning system:

commands.entity(player_entity).add_child(child);
commands.entity(child).remove::<RapierColliderHandle>();

And I ensure the system runs before the collider initialization:

.add_plugin(RapierPhysicsPlugin::<NoUserData>::pixels_per_meter(100.0))
.add_plugin(RapierDebugRenderPlugin::default())
.add_system_to_stage(
    PhysicsStages::SyncBackend,
    player_spawn_control.before(bevy_rapier2d::plugin::systems::init_colliders),
)
.run();

I'm not sure what the consequences might be of running in a different stage like that, (e.g. how it relates to transform propagation or other Bevy default systems), but at least this way I can get the colliders to affect the parent! Presumably this would be a similar mechanism for how this could be done by default (basically, re-evaluate the Collider parent-child relationship whenever the bevy Entity parent-child relationship changes).


Edit: there are definitely some issues with this approach re: transform calculation. I'm having a tough time figuring out how to properly set the collider position vs its transform and in what order, particularly when trying to simultaneously remove an existing rigidbody on the collider entity. This is most obvious if the parent Transform is non-default, especially if it's scaled.

@Vrixyz
Copy link
Contributor

Vrixyz commented May 24, 2024

thanks for the details ! Seems related to #486, not entirely sure it's a duplicate though.

@Vrixyz Vrixyz added C-Bug Something isn't working D-Medium P-Medium S-not-started Work has not started A-Integration very bevy specific labels May 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Integration very bevy specific C-Bug Something isn't working D-Medium P-Medium S-not-started Work has not started
Projects
None yet
Development

No branches or pull requests

2 participants