rapier
rapier copied to clipboard
Panic in ParallelInteractionGroups::group_interactions
thread '<unnamed>' panicked at 'index out of bounds: the len is 128 but the index is 128', /Users/matt/.cargo/git/checkouts/rapier-1eded0a3355a18db/77a4bbf/crates/rapier2d/../../src/dynamics/solver/interaction_groups.rs:120:21
stack backtrace:
0: _rust_begin_unwind
1: core::panicking::panic_fmt
2: core::panicking::panic_bounds_check
3: rapier2d::dynamics::solver::interaction_groups::ParallelInteractionGroups::group_interactions
at /Users/matt/.cargo/git/checkouts/rapier-1eded0a3355a18db/77a4bbf/crates/rapier2d/../../src/dynamics/solver/interaction_groups.rs:120:21
4: rapier2d::dynamics::solver::parallel_island_solver::ParallelIslandSolver::init_and_solve
at /Users/matt/.cargo/git/checkouts/rapier-1eded0a3355a18db/77a4bbf/crates/rapier2d/../../src/dynamics/solver/parallel_island_solver.rs:181:9
5: rapier2d::pipeline::physics_pipeline::PhysicsPipeline::build_islands_and_solve_velocity_constraints::{{closure}}::{{closure}}
at /Users/matt/.cargo/git/checkouts/rapier-1eded0a3355a18db/77a4bbf/crates/rapier2d/../../src/pipeline/physics_pipeline.rs:263:25
Hi! Could you please provide more details on the scene you are simulating? And, if you can, provide a piece of code to reproduce the panic?
I'm seeing the same issue (thread '<unnamed>' panicked at 'index out of bounds: the len is 128 but the index is 128', C:\Users\victor\.cargo\registry\src\index.crates.io-6f17d22bba15001f\rapier2d-0.17.2\src\dynamics\solver\interaction_groups.rs:120:21
) when doing 2D rigid bodies and listen for collisions. I'm using Rapier2D via the Bevy plugin.
I think this happens when there is one rigid body having a lot of collisions with others, rather than many one-to-one collisions, as far as I can tell. I don't have a smaller example that reproduces the issue right now though, sorry for that.
This happened to me with bevy_rapier3d-0.17.2
whilst working on an n-body simulation.
More than 128 collider actively in contact with a single, shared other body triggers it for me, as long as the "parallel"
feature is enabled.
Here is a minimal working example: https://gist.github.com/alexd3rsan/08cd1ce2e25e3045bee34d946bedd8c6
(It also occured just by spawning all the smaller spheres inside the larger sphere, but the snippet above allows one to see what is going on visually.)
u128::trailing_zeros()
can return 128 and the bit-mask code in this match block and related parts only work if the returned value stays below 128, creating this limit.
I'm not sure if the upper limit of 128 is intended as a performance trade-off or if it was supposed to be the size of bins that things get distributed/sorted into with the intention of supporting higher values.
If this limit is indeed intentional, then a condition with a panic message highlighting the limitation might be helpful for the future!
I've encountered this as well. For applications where accuracy is less important than keeping the app running (e.g. a game), having the option to avoid panicking would be best IMO.
This crash will no longer happen with the latest version of rapier. Please reopen if you can still reproduce it.