Struggling to understand asset management under bevy

[formal thunder]

Note, I'm on bevy 17, so librairies for assets are still mostly on bevy 16

I've never experimented with asset management, so I'm struggling.
The examples are great but to me it's a bazaar of useful things, What am I even supposed to start with.
This one has the most comments and seems to be the one I should be focusing first but what do I know?
https://github.com/bevyengine/bevy/blob/latest/examples/asset/asset_loading.rs

My first question is should I handle loading - unloading like expensive sprites manually to not clog the memories, or the engines does that lifting for me?

My second question is what is the most data driven way to register all assets, below is a prototype I have done

pub enum SoundEffects {
    ImpactCinematicBoom
}

impl SoundEffects{
    fn value(&self) -> &'static str{
        match *self {
            SoundEffects::ImpactCinematicBoom => "impact-cinematic-boom",
        }
    }
}
// Then I'll handle the loading down the line in a system

I could then add more methods for more, but would there be a pitfall with that approach?

Third question is how can I get the handle of anything I loaded with the minimum amount of code (in logic)?
Is that when loaded, I can reclaim the handle whenever I want by querying it from the ECS?
Or do I need to make a "registry struct" of handles and then query that handle?

Fourth question is a bit less about that and more about how can I, with the least amount of code (in logic), call a system that handles assets?
For example:
I have a logical situation where I have to play a ring sound sfx.
I ideally just want to limit the code of that by just calling one function, well actually I want to order the ECS runtime to call a system that will generate (or not) the sound effect.
What tool with bevy should be used for that? State? Events?

Thanks for reading

[river ivy]

Assets stay loaded as long as (strong, the default) handles still exist somewhere in memory. That means to keep assets loaded, you'll have to keep around the handles somewhere.

AssetServer::load has this in its docs

Note that if the asset at this path is already loaded, this function will return the existing handle, and will not waste work spawning a new load task.

so you could keep assets loaded by dumping the handles into some resource, and still use AssetServer::load with their path to access them. Thats about the same amount of code as using a custom resource which stores the handles you need. I would still go with a custom resource "registry struct" though, as it makes thigns like having a number of handles and randomly choosing from them easier.

As for using assets for ephemeral things like sound effects, i would use Events/Observers for that. That allows you to do commands.trigger(PlaySound(" some-key")) and have any of the logic for that abstracted away in a observer.

For other kinds of using the assets, like for spawning, i think it makes the most sense to access your registry resource directly. You can always define helper methods on it.

Keep in mind though, that theres a tradeoff between registry struct keeping handles alive, and letting assets be unloaded and re-loading them when necessary. The prior ensures lower latency, as it doesn't need to kick off a loafing task, and the latter ensures unusef assets don't use up memory. For things where the number of unnecessary assets outnumber the number of needed ones, and where a bit of latency isn't a big deal, i would forego a central place to store them, and let bevy unload them when nothings using them anymore, to reduce memory consumption. Things like chunks of the game world or levels, assuming you store them as individual assets, don't need to stay loaded all the time.

[formal thunder]

Thanks, that's a substantial amount of things to keep in mind,
I think I need to read much more about assets management

and let bevy unload them when nothings using them anymore
bevy runtime has a garbage collector??

[river ivy]

Not a garbage collector, but it does use reference counting for assets. Handle is a wrapper around a Arc, and when no Handles exist anymore the asset is dropped.

[formal thunder]

that's an important part

is it a failing on my end, to lack findings on documentation about bevy assets system?

because by scrollign around in the example I find some stuff like https://github.com/bevyengine/bevy/blob/main/examples/asset/embedded_asset.rs#L2
embeded assets which answer a question I was to ask later

[river ivy]

Partly, but not entirely. A lot is documented in the API and module docs like https://docs.rs/bevy/latest/bevy/asset/index.html but its also not the ideal form for that kind of documentation to have

plus stuff like asset processing, custom asset loaders/formats, etc is a bit under-documented

but yeah, important lesson: bevy usually has module-level docs, and if you only ever look for specific types you won't see them

[formal thunder]

ah I didn't found that doc, forgot that the rust community put documentation on that website

[river ivy]

Its the same docs you can get with cargo doc --open

its made from all the docstrings from the code

but yea, docs.rs is generally the main place for docs, only a handful of crates have docs hosted elsewhere

[formal thunder]

which contrast with other programming community which never put any docs from the code and always host it somewhere else if it's documented at all

but the doc also don't speak about embedded assets, so yeah it's under documented

also ergonomics is extremely important for me and I find documentation on ergonomics with bevy super hard to find

by ergonomics I mean splitting logic and bridging the modules with events, or how to properly register bind a resource with a "symbol"

Godot has a metric tons of documentation about these kind of matter

[river ivy]

yeah, theres really not much "high level" docs about patterns etc.

i can recommend https://taintedcoders.com/ tho

[formal thunder]

it's no longer maintained unfortunately, but I've read a fair bit ofi t

at least 6 month ago tainted coder wasn't up to date

[formal thunder]

I tried to make my own tutorials about bevy a bit ago, but I don't know enough to make some

oh nvm some part has been update to bevy17, that's pretty cool

oh the whole is 17 that's very fortunate, gotta binge that then