Game crash when despawning collision entities ?

[ethereumdegen]

I get this panic when i am walking around my level and my collision doodads auto despawn and spawn. Happens randomly and infrequently

thread '<unnamed>' panicked at /home/andy/.cargo/registry/src/index.crates.io-6f17d22bba15001f/parry3d-0.15.1/src/query/epa/epa3.rs:129:13:
assertion `left == right` failed
  left: 92
 right: 80
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Encountered a panic in system `bevy_tnua_avian3d::update_proximity_sensors_system`!
Encountered a panic in system `bevy_app::main_schedule::Main::run_main`!

[idanarye]

How are you spawning and despawning?

Can you share the code or create a minimal example? If not - can you run with RUST_BACKTRACE=1 as it suggests and copy-paste the fully stack trace?

The little that gets printed points at a parry3d assertion. I assume it gets triggered from update_proximity_sensors_system querying the SpatialQueryPipeline, but I can't really determine if I'm doing anything wrong or if it's an Avian/Parry bug.

[ethereumdegen]

Here i was able to make it happen again

thread '<unnamed>' panicked at /home/andy/.cargo/registry/src/index.crates.io-6f17d22bba15001f/parry3d-0.15.1/src/query/epa/epa3.rs:313:50:
called `Option::unwrap()` on a `None` value
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Encountered a panic in system `bevy_tnua_avian3d::update_proximity_sensors_system`!
Encountered a panic in system `bevy_app::main_schedule::Main::run_main`!

I am auto despawning all children of doodad entities (this includes their colliders) as i walk away from them so MAYBE this is causing it but it really dont know. It happens about every 5 minutes of gameplay randomly. splendid.

[idanarye]

Looks like a different assertion this time. But again - unless you run it with RUST_BACKTRACE=1 I won't be able to determine how it got there.

First one happened here: https://docs.rs/parry3d/0.15.1/src/parry3d/query/epa/epa3.rs.html#129. Frankly - I don't really know what's going on there. It seems like low-level math check for penetration?

Second one happened here: https://docs.rs/parry3d/0.15.1/src/parry3d/query/epa/epa3.rs.html#313. This one looks like the heap is not being managed correctly?

Note that both happen in the same file of Parry. And I see you've already opened a ticket there. But it could also be an Avian issue.

I doubt it's really a Tnua issue, because Tnua just calls shape_hits_callback/ray_hits_callback (without RUST_BACKTRACE=1 I can't determine which one) and there isn't much room for Tnua to mess that call up. Then again - it's possible that it could be solved in Tnua by changing the scheduling, but since I have neither the knowledge of what the actual problem is nor a minimal reproducible example for trial-and-error on my machine, I can't even attempt to try fixing it that way.

Finally - it is always possible that this is a Bevy ECS quirk. But at this point we kind of have to live with these Bevy ECS quirks and work around them.

My money is on Avian though. Parry is not aware of Bevy, and it is Avian's job to mediate between the two and operate the low-level Parry constructs according to the Bevy ECS' status.