Somehow prevent confusion caused by Assets being removed due to not having RenderAssetUsages::MAIN_WORLD

[laundmo]

What problem does this solve or what need does it fill?

One of the common causes of hard-to-diagnose issues i see people having is having the wrong RenderAssetUsages set. Most of the time the issue is silent, making it hard to figure out why things aren't working.

Examples:

• Emit warning when Pickable added to an entity whose mesh is unloaded from main world #19207 which is a more specific feature request that could be covered by this
• docs: picking requires RenderAssetUsages::MAIN_WORLD #19102
• Mesh picking does not work with manual mesh #17987
• Cannot get mesh that is rendered, am I doing something wrong? #15172
• https://discord.com/channels/691052431525675048/1380027984823455816
• https://discord.com/channels/691052431525675048/937158127491633152/1380049315887841310
• https://discord.com/channels/691052431525675048/1382751438110851212
• https://discord.com/channels/691052431525675048/1385132782514344038

What solution would you like?

#19207 is a good step, but it only covers one of many places where this issue could occur.

• only affects picking
• only affects Mesh

I think one solution could look like this:
Don't fully remove the handle from Assets in extract_render_asset. Either leave a marker in its place, or store the handle separately. This would likely require a method Assets::remove_with_reason or similar. Then, in the various methods for getting the asset data, log out a warning if one of those handles has been requested. Probably should be warn_once! or maybe a smarter thing based on track_caller where its logged once for each caller.

What alternative(s) have you considered?

And abundance of documentation and materials could also somewhat alleviate this, but thats far from ideal.
Another option could be to make Assets::get return a Result instead of a Option, allowing it to report a reason why it failed, though that assumes people don't just let-else the Err into oblivion.

Additional context

none so far

[alice-i-cecile]

Another option could be to make Assets::get return a Result instead of a Option

I like this! I'd prefer to start with something targeted like this, and then move to more intrusive designs if this continues.

[JMS55]

I'm happy having Assets::get() return a Result, but I caution that we should benchmark and ensure it doesn't affect performance too much.

Off the top of my head I think this should be ok, as the render world operates on RenderAssets<T> which we can keep as Option<T>.