Open Architector4 opened 1 year ago
Can reproduce on my Windows 10 machine.
Running `target\debug\bevydebug.exe` 2023-06-25T09:53:21.838114Z INFO bevy_winit::system: Creating new window "Bevy App" (0v0) 2023-06-25T09:53:23.866498Z INFO bevy_render::renderer: AdapterInfo { name: "NVIDIA GeForce RTX 2060", vendor: 4318, device: 7817, device_type: DiscreteGpu, driver: "NVIDIA", driver_info: "527.56", backend: Vulkan } 2023-06-25T09:53:24.966677Z INFO bevy_rapier3d::render::lines: Loaded 3d debug lines plugin. 2023-06-25T09:53:25.374842Z INFO bevy_diagnostic::system_information_diagnostics_plugin::internal: SystemInfo { os: "Windows 10 Pro", kernel: "19045", cpu: "AMD Ryzen 5 1600 Six-Core Processor", core_count: "6", memory: "15.9 GiB" } thread 'Compute Task Pool (0)' panicked at 'internal error: entered unreachable code', C:\Users\frep\.cargo\registry\src\github.com-1ecc6299db9ec823\parry3d-0.13.4\src\query\nonlinear_time_of_impact\nonlinear_time_of_impact_support_map_support_map.rs:201:40 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace thread 'Compute Task Pool (0)' panicked at 'A system has panicked so the executor cannot continue.: RecvError', C:\Users\frep\.cargo\registry\src\github.com-1ecc6299db9ec823\bevy_ecs-0.10.1\src\schedule\executor\multi_threaded.rs:194:60 thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', C:\Users\frep\.cargo\registry\src\github.com-1ecc6299db9ec823\bevy_tasks-0.10.1\src\task_pool.rs:376:49 error: process didn't exit successfully: `target\debug\bevydebug.exe` (exit code: 101)
Seems to also happen on the current git versions of both Rapier and this plugin.
bevy_rapier.git#38e1b791
rapier.git#bf047ed4
The same 😢 on mac
Same for me too, using AsyncSceneCollider with TriMesh (no CCD enabled) and a capsule collider (CCD enabled).
Edit: Changing the computed collider type to ConvexHull fixes the issue.
The Parry issue is here: https://github.com/dimforge/parry/issues/176
I wrote up some potential reasons for the core problem there. We mainly just need someone to find where ClosestPoints::Disjoint
is returned (either GJK or one of the closest_points_*
implementations) and why. Then we either need to (ideally) fix that, or if that is not possible, remove the unreachable!
panic in favor of a warning or just doing nothing.
I converted @Architector4 's example to Bevy 0.13 and bevy_rapier 0.26 and it no longer panics but instead spams this error a bunch of times after clicking the mouse:
ERROR log: Closest points not found despite setting the max distance to infinity.
It does keep running with no apparent problems outside of the error logs. The boxes do fly off (from being inside each other?). It's unclear if there are any undesired side effects though.
I decided to try enabling CCD on some dynamic rigid bodies in a project, and immediately noticed crashes on unreachable code. The error seems to originate from Parry, but I'm unfamiliar with neither raw Parry nor Rapier, and can only provide example code as a Bevy project, so I feel like it's better if I post this issue here.
It seems to happen with the latest
bevy
andbevy_rapier3d
crates on latest versions as of now, with default features compiled from a fresh new crate (seeCargo.toml
below for exact versions).Trying this on Arch Linux on Intel i5-8250U CPU on rustc 1.70.0.
Here's an example project; click twice to immediately crash the application:
Cargo.toml
``` [package] name = "bevydebug" version = "0.1.0" edition = "2021" [dependencies] bevy = "0.10.1" bevy_rapier3d = "0.21.0" ```src/main.rs
``` use bevy::prelude::*; use bevy_rapier3d::prelude::*; fn spawn_dynamic(mut commands: Commands, input_mouse: Res>) { if input_mouse.pressed(MouseButton::Left) { commands.spawn(( RigidBody::Dynamic, Ccd { enabled: true }, Collider::cuboid(0.5, 0.5, 0.5), )); } } fn setup(mut commands: Commands) { let some_mesh: Mesh = shape::Box::default().into(); let collider = Collider::from_bevy_mesh(&some_mesh, &ComputedColliderShape::TriMesh).unwrap(); commands.spawn(Camera3dBundle { transform: Transform { translation: Vec3::new(0.0, 10.0, 10.0), rotation: Quat::from_rotation_x(-0.8), ..default() }, ..default() }); commands.spawn(( collider, SpatialBundle { transform: Transform { scale: Vec3 { x: 1.1, y: 1.0, z: 1.0, }, ..default() }, ..default() }, )); } pub fn main() { App::new() .add_plugins(DefaultPlugins) .add_plugin(RapierDebugRenderPlugin::default()) .add_plugin(RapierPhysicsPlugin::From experimentation, it appears that this specifically happens when there is a static rigid body with a computed collider from a mesh (using
Collider
type's presets likecuboid
don't seem to cause the crash, it has to be a trimesh) and 2 dynamic rigid bodies with any type of collider but with CCD on (even with default of 1 substep) that are smaller than the static one are found to be all intersecting with each other.I haven't tested them intersecting in any other configuration than all 3 bodies at once. Any collider shapes and types seem to work, as long as one of the bodies is a trimesh collider that is bigger than the rest (it can also be a dynamic rigid body, though then it can get a bit harder to reproduce the issue, with disabling gravity and more clicks needed).