Asset can only be retrieved once

[mixolydianmel]

Howdy y'all,

I've been working on a project using apriltag-rust and nokhwa to find AprilTags in webcam frames and track shapes to them, but I'm currently running into a troubling issue.

The issue is thus:

1. Add asset
2. Put asset handle into a resource
3. Access the asset through its handle stored in the resource, returns Some(<asset>)
4. Attempt to do so again, but get_mut() returns None

I'm using get_mut() in one of my systems to retrieve an asset by its handle, which is stored in a resource.

#[derive(Resource, Default)]
pub struct DebugImage(Handle<Image>);

The resource is added with app.insert_resource() in a plugin the relevant systems are in, and then set through a ResMut<> in a setup system.

pub fn setup_image(
  /*...*/
  images: ResMut<Assets<Image>>,
  debug_img: ResMut<DebugImage>,
  /*...*/
) {
  // <snip>
  let mut img = Image::new_fill(
      bevy::render::render_resource::Extent3d {
          width: WIDTH,
          height: HEIGHT,
          depth_or_array_layers: 1,
      },
      TextureDimension::D2,
      &[255, 255, 255, 255],
      bevy::render::render_resource::TextureFormat::Rgba8Unorm,
      RenderAssetUsages::RENDER_WORLD,
  );
  img.texture_descriptor.usage = TextureUsages::COPY_DST | TextureUsages::TEXTURE_BINDING;
  
  debug_img.0 = images.add(img);
  // </snip>
}

Then, later on, I try to retrieve the asset, which only seems to work once (based on debug printing).

pub fn update_image(
  /* ... */
  mut images: ResMut<Assets<Image>>,
  debug_image: Res<DebugImage>,
  /* ... */
) {
  let image = images
    .get_mut(&debug_image.0.clone())
    .unwrap_or_else(|| panic!("Unable to locate resource"));
}

Here's a gist of the file the code resides in, though I modified some of the variable names for readability in the code examples here.

Let me know if there's anything else I can provide, I'm really desperate to fix this issue, I truly have no idea what is causing it (this is my first bevy project :P). Thanks :)

[mixolydianmel]

Quick update: I've confirmed the handle stored in the resource is still always a strong handle, whether the get_mut() works or not. I've also tried removing the modification and changing get_mut() to get(), but the issue persists in the exact same fashion (probably not something with the asset being modified). It appears as though the Option::as_mut() call is returning None the second time around.

[mixolydianmel]

Update part 2: The asset with the handle does not have a load state (i.e. asset_server.get_load_state(...) returns None). This is curious, I'm not sure what could be causing this, maybe the asset never gets loaded in the first place? Though if that's the case, I'm not sure what the images.add() method is even doing... Anyway, hopefully somebody sees this and knows what's going on :/

[k9]

Hi @mixolydianmel since your asset has RenderAssetUsages::RENDER_WORLD, during Extract https://bevy-cheatbook.github.io/gpu/stages.html it will be removed from the main world after its extracted into the render world. I ran into this same issue last week and it caused me a lot of confusion. I solved it by setting the usage to RenderAssetUsages::RENDER_WORLD | RenderAssetUsages::MAIN_WORLD. I'm not a bevy expert though so there may be details I'm missing.

[mixolydianmel]

Heyo! Thanks for the advice, to clarify you're talking about when the Image gets instantiated right? I tried changing the RenderAssetUsages::RENDER_WORLD in Image::new_fill(...) to RenderAssetUsages::RENDER_WORLD | RenderAssetUsages::MAIN_WORLD and nothing changed, which is a shame since this seemed like a really likely candidate for why this was happening. I'll keep massaging it a bit, but it looks like this probably isn't the fix...

[mixolydianmel]

This turned out to be the fix, just had to order them the other way around (i.e. MAIN_WORLD | RENDER_WORLD)! Thanks again for your help.

[k9]

Glad to hear it's working! If you still want to find the root cause though, I would double check that the key is the order of main_world and render_world though, since that's a bitwise OR operator, and order shouldn't matter.