Collider not despawning correctly during PostUpdate stage

[ottermata]

I've just started playing around with bevy and wanted to add physics to my test project. As I was changing things over I encountered a weird bug, where some physics objects were not being removed properly. I tried changing the hit detection over to the collision event listener, but that had the same issues. After moving the system around a bit the bug went away, but then there was no knock back effect when the projectiles hit the enemy.

I have created a short example showcasing the different behaviors here: https://github.com/ottermata/heron-collision-test
These systems both suffer from the same issues:

• projectile_collision_event: check projectile hits with collision events
• projectile_collide_check: check projectile hits with transform collide check

When in the Update stage, the physics seem to be mostly ignored. Every now and then they slightly push or rotate the enemy.
When in the PostUpdate stage, they push the enemy away and don't correctly despawn.

While I was creating that test I saw the Collisions component which seems to not have these issues, so I will probably just use that. (projectile_collision_check system)

It would be nice to know why the collision is being registered, without resulting in physics changes. Since it looks like a bug to me, I have opened this issue.

Maybe an example of how something like this is supposed to be implemented would be helpful for newcomers, feel free to use my code as a base for that.

[jcornaz]

I see you use kinematic bodies. A kinematic body is not affected by other rigid bodies.

[ottermata]

While the projectile is indeed a KinematicVelocityBased ridig body, the enemy is a dynamic one. This should be fine, considering the knock back the enemy receives in the (currently active) add_system_to_stage(CoreStage::PostUpdate, projectile_collision_event) case. The only problem with that system is the collider of the already despawned projectile still affecting the enemy (at least until the next projectile hits).

The player being KinematicPositionBased is irrelevant for this, as he is just there to create the projectiles.

Just to try it out, I changed the projectile to also be dynamic. Now there is no knock back to the enemy at all, for all 3 ways to check for collision.

Since you brought it up though, what is the intended use case for KinematicVelocityBased & KinematicPositionBased rigid bodies? I used the velocity based one on the projectile, because it should only move based on the given velocity and despawn once it hits something (& knock the enemy back).
The player also shouldn't be moved by enemies, so KinematicPositionBased made sense to me.

If I'm completely on the wrong track here and both the projectile & enemy should really be dynamic, how would a knock back style effect be implemented? I'm not sure about the enemy movement being implemented by just setting the velocity directly. Do I need to change the enemy movement to account for the incoming hits?

[jcornaz]

Ah ok. Indeed the dynamic body should be affected by the collision with a kinematic body.

Kinematic means it is controlled programmatically, not by physics. The best use-case would be moving platforms, but bullets sound fine too.

For a player, it might be tricky, because the physics engine won't prevent a kinematic body to penetrate a static body (like floor, wall, etc.)

I'll try to look at your example, see if I can understand why it doesn't behave as expected.

[jcornaz]

Make sure to add a PhysicMaterial with a restitution that is greater than 0. zero restitution (which is the default) means all energy is lost in collision, so the objects don't "bounce". Restitution of 1 means all energy is kept and the objects "bounce" back.

I am open to feedback on how to improve the clarity/intuitiveness of that aspect though. Maybe through better/more discoverable documentation? And/Or maybe a better default restitution value? Or any other suggestion?

On another topic, that comment: https://github.com/ottermata/heron-collision-test/blob/master/src/main.rs#L120 which says "crash sometimes". Do you have a stack trace? It should definitely not crash (IMO), though it is not yet clear if it is a problem of bevy or heron,

[ottermata]

It actually crashes fairly reliably after a few shots for me if I use that system in the PostUpdate stage (with entity(...).despawn() rather than using the Despawn command).

Here's the complete output with full stacktrace:
log.txt

You can see that entity 3v3 starts colliding twice, but it was already deleted after the first time. My guess is that this system ran before the physics calculation. (As far as I understand, the entity only gets deleted after the stage, so it would still be going through a round of physics after being marked for deletion which would then create a new collision event)

Were you able to figure out why the enemy gets stuck on the already despawned projectile in my example? I feel like there is some kind of bug there. But maybe it's enough to just advise against doing anything physics related (including despawning) in the PostUpdate stage.

Re: restitution, I just checked the current docs. I think mentioning that it means how much energy is retained in the object or how much it is impacted by colliding with something would make it clearer for me. Thanks for pointing that out though.

[jcornaz]

Thanks, for the details. I have to look more closely at this.

[Cassumbra]

Workaround solution until there is a fix:
Put the system where the despawn occurs in a custom stage that runs after Update, or just move your system to Update.