specialized_mesh_pipeline example panics when hovering over mesh

[rparrett]

Bevy version

main
bisected to #15800.

Relevant system information

SystemInfo { os: "MacOS 14.5 ", kernel: "23.5.0", cpu: "Apple M1 Max", core_count: "10", memory: "64.0 GiB" }
AdapterInfo { name: "Apple M1 Max", vendor: 0, device: 0, device_type: IntegratedGpu, driver: "", driver_info: "", backend: Metal }

What you did

• cargo run --example specialized_mesh_pipeline
• hover over over the triangles

What went wrong

thread 'Compute Task Pool (3)' panicked at crates/bevy_picking/src/mesh_picking/ray_cast/intersections.rs:145:29:
index out of bounds: the len is 3 but the index is 3
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Encountered a panic in system `bevy_picking::mesh_picking::update_hits`!
Encountered a panic in system `bevy_app::main_schedule::Main::run_main`!

[alice-i-cecile]

I'm pretty sure something is malformed in the mesh. This looks like the exact issue spotted by @tbillington and called out as not a problem in #15800 (comment) by @Jondolf.

[rparrett]

It looks like it is because the mesh doesn't have normals. Don't feel like we should be packing there, but it seems like there's a pretty nasty perf hit to write non-packing code based on the discussion linked above.

[Jondolf]

The line the panic is referring to is indexing the third vertex position for a triangle, not indexing a normal. The code does check if Mesh::ATTRIBUTE_NORMAL exists at all, and should work if it doesn't. I believe normals should only be an issue if there are less normals than there are vertices, which is considered malformed by Bevy anyway.

The panic happens because the example defines the mesh's indices as [0, 1, 2, 0, 2, 3]. Index 3 points to nothing since the mesh only has three vertices. Not sure why it's set up like that or how it's even meant to work.

[rparrett]

Cool, you're right, thanks. Opened a tiny PR to fix.