MeshPlugin migration is a gigantic footgun #21253
Description
Bevy version and features
- 0.17.0-rc.2
What you did
There are reasons to use MeshPlugin explicitly outside of DefaultPlugins. The most important one is testing mesh-related functionality (e.g. when loading glTFs) without a renderer in CI or headless servers. In 0.16, the mesh plugin had to be imported with use bevy::render::mesh::MeshPlugin.
Because of the render crate split, this plugin should now be imported as use bevy::mesh::MeshPlugin, see https://github.com/bevyengine/bevy/blob/v0.17.0-rc.2/crates/bevy_mesh/src/lib.rs#L51.
BUT! The render crate still has its own little MeshPlugin see https://github.com/bevyengine/bevy/blob/release-0.17.0/crates/bevy_render/src/mesh/mod.rs#L25. This plugin does something different from the other MeshPlugin we all know and love. Coincidence would have it that this new MeshPlugin is at bevy::render::mesh::MeshPlugin... which is precisely the import path 0.16 users used for the actual MeshPlugin!
This means that CIs (like the ones in Avian and Rerecast) now fail with "Mesh asset not initialized" despite the MeshPlugin clearly having been added. I expect the exact same will hit everyone using meshes in headless servers.