Option::unwrap panic in `specialize_material2d_meshes`

[fatho]

Bevy version

0.16

[Optional] Relevant system information

Does not seem relevant, but happy to provide extra info if needed.

What you did

Code worked fine on 0.15, but starts crashing on 0.16. I don't have a small reproducer readily available unfortunately, but I can potentially look into that at a later time if needed.

What went wrong

My application crashes on a unwrap call in specialize_material2d_meshes deep in the bevy internals.

thread 'Compute Task Pool (23)' panicked at ~/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/bevy_sprite-0.16.0/src/mesh2d/material.rs:730:79:
called `Option::unwrap()` on a `None` value
stack backtrace:
   0: rust_begin_unwind
             at /rustc/4d91de4e48198da2e33413efdcd9cd2cc0c46688/library/std/src/panicking.rs:692:5
   1: core::panicking::panic_fmt
             at /rustc/4d91de4e48198da2e33413efdcd9cd2cc0c46688/library/core/src/panicking.rs:75:14
   2: core::panicking::panic
             at /rustc/4d91de4e48198da2e33413efdcd9cd2cc0c46688/library/core/src/panicking.rs:145:5
   3: core::option::unwrap_failed
             at /rustc/4d91de4e48198da2e33413efdcd9cd2cc0c46688/library/core/src/option.rs:2015:5
   4: core::option::Option<T>::unwrap
             at ~/.rustup/toolchains/1.85.0-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/option.rs:978:21
   5: bevy_sprite::mesh2d::material::specialize_material2d_meshes
             at ~/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/bevy_sprite-0.16.0/src/mesh2d/material.rs:730:79
   6: core::ops::function::FnMut::call_mut
             at ~/.rustup/toolchains/1.85.0-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:166:5
   7: core::ops::function::impls::<impl core::ops::function::FnMut<A> for &mut F>::call_mut
             at ~/.rustup/toolchains/1.85.0-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:294:13
   8: <Func as bevy_ecs::system::function_system::SystemParamFunction<fn(F0,F1,F2,F3,F4,F5,F6,F7,F8,F9,F10,F11,F12,F13,F14) .> Out>>::run::call_inner
             at ~/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/bevy_ecs-0.16.0/src/system/function_system.rs:945:21
   9: <Func as bevy_ecs::system::function_system::SystemParamFunction<fn(F0,F1,F2,F3,F4,F5,F6,F7,F8,F9,F10,F11,F12,F13,F14) .> Out>>::run
             at ~/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/bevy_ecs-0.16.0/src/system/function_system.rs:948:17
  10: <bevy_ecs::system::function_system::FunctionSystem<Marker,F> as bevy_ecs::system::system::System>::run_unsafe
             at ~/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/bevy_ecs-0.16.0/src/system/function_system.rs:735:19
  11: <bevy_ecs::system::schedule_system::InfallibleSystemWrapper<S> as bevy_ecs::system::system::System>::run_unsafe
             at ~/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/bevy_ecs-0.16.0/src/system/schedule_system.rs:64:9
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
Encountered a panic in system `bevy_sprite::mesh2d::material::specialize_material2d_meshes<MyMaterial>`!

Additional information

I've seen #18980 so far, which seems to have an unwrap crash in the 3D variant of mesh material specialization, perhaps that's related?

[grind086]

Definitely looks related

This issue: https://github.com/bevyengine/bevy/blob/main/crates/bevy_sprite/src/mesh2d/material.rs#L730
#18980: https://github.com/bevyengine/bevy/blob/main/crates/bevy_pbr/src/material.rs#L1023

Both are crashing on

let entity_tick = entity_specialization_ticks.get(visible_entity).unwrap();

So it looks like the core issue might be the assumption that every entity in a view's RenderVisibleEntities will always be present in EntitySpecializationTicks. I'm not sure if this assumption should be correct (seems like it should be), but at the moment it doesn't seem to be.

[fatho]

I've done some digging in the meantime and found that the EntitySpecializationTicks resource in the render world is ultimately populated (with some intermediate steps) from check_entities_needing_specialization in the PostUpdate of the main world.

The likely issue in my case is that I am adding a mesh material to entities in PostUpdate as well, so they are not seen by check_entities_needing_specialization, but they are eventually seen by the extraction, and therefore expected to be there in the render world.

I don't know enough about bevy internals to say what a proper solution here would be, but I managed to work around this issue for now by ensuring that the mesh components are visible to check_entities_needing_specialization like so

            .add_systems(
                PostUpdate,
                (
                    spawn_my_mesh_components,
                    // Workaround for bevyengine/bevy#19048, ensuring the mesh components are
                    // present before extraction-relevant systems.
                    ApplyDeferred,
                )
                    .chain()
                    .before(
                        check_entities_needing_specialization::<MyMaterial>,
                    ),
            )

---

What's unclear to me still is whether I'm wrong (and shouldn't add mesh materials in PostUpdate) or Bevy is wrong (and should rather do check_entities_needing_specialization later during extraction).

[grind086]

I think this is a bevy system ordering issue. If check_entities_needing_specialization is ordered before the CheckVisibility set I think that will fix it. I'll get a PR going.

EDIT: I'm not able to verify that changing this actually does anything. I tried a bunch of things, but can't reproduce the crash.

[fatho]

I can reliably trigger the crash with the following reproducer. The crucial part seems to be the prepare_custom_effects.after(TransformSystem::TransformPropagate) constraint (note that while it seems redundant in the example, I do need this in the real thing because I depend on GlobalTransforms for setting up some shader parameters) . So it's indeed likely a system ordering issue.

In case this doesn't trigger it for you, is there a way for me to get the concrete system order bevy decided on?

Reproducer

use bevy::prelude::*;

fn main() {
    App::new()
        .add_plugins(DefaultPlugins)
        .add_systems(
            PostUpdate,
            prepare_custom_effects.after(TransformSystem::TransformPropagate),
        )
        .add_systems(Startup, startup)
        .run();
}

fn startup(mut commands: Commands) {
    // 1. Setup cameras
    commands.spawn(Camera2d);

    commands.spawn(CustomEffect);
}

#[derive(Debug, Default, Clone, Component)]
#[require(Transform, Visibility)]
pub struct CustomEffect;

#[allow(clippy::type_complexity)]
pub fn prepare_custom_effects(
    mut commands: Commands,
    new_effects: Query<
        Entity,
        (
            With<CustomEffect>,
            Without<Mesh2d>,
            Without<MeshMaterial2d<ColorMaterial>>,
        ),
    >,
    mut meshes: ResMut<Assets<Mesh>>,
    mut effect_materials: ResMut<Assets<ColorMaterial>>,
) {
    for ent in new_effects.iter() {
        let mesh: Mesh2d = meshes.add(Circle::new(10.0)).into();

        let material = effect_materials.add(ColorMaterial::default());
        commands
            .entity(ent)
            .insert((mesh, MeshMaterial2d(material)));
    }
}

[grind086]

The reproduction works great, and it looks like the fix worked too! Gonna check the 3d material quick too.