add a method on AssetServer to create an asset from an existing one

[mockersf]

Some assets loaded from disk by the asset server have extra fields that are not possible to setup on load, as the asset loader is picking the values. Changing those values is quite bothersome as it requires the user to:

• save the asset handle in a resource
• add a system that will wait for the asset to be loaded then modify it

This PR add a method on AssetServer to simplify that:

// load the texture from disk
let texture_handle = asset_server.load("branding/icon.png");

// new texture with one pixel every two removed
let texture_handle_1 =
    asset_server.create_from(texture_handle, |texture: &Texture| {
        let new_data = texture
            .data
            .iter()
            .enumerate()
            .map(|(i, v)| {
                if i / texture.format.pixel_size() % 2 == 0 {
                    0
                } else {
                    *v
                }
            })
            .collect();
        Some(Texture {
            data: new_data,
            ..*texture
        })
    });

screenshot from example

[mockersf]

could this get considered for 0.5? I have a new (but very small, ~50 LoC) feature depending on it that I would love to see in the release to help build assets very easily from a ron file

[alice-i-cecile]

could this get considered for 0.5? I have a new (but very small, ~50 LoC) feature depending on it that I would love to see in the release

(ping @cart on the above)

[alice-i-cecile]

Seems like a useful piece of functionality, especially when extended with more tools.

This will be a solid building block for real asset-transformation pipelines.

[alice-i-cecile]

Suggested change

	.expect("Error converting an asset to it's type, please open an issue in Bevy GitHub repository"),
	.expect("Error converting an asset to its type, please open an issue in Bevy GitHub repository"),

[alice-i-cecile]

Is there no end-user workaround for this?

[mockersf]

it could be logged and ignored instead of expect, but this one actually can't happen as it's the one place where we know the actual types and they are constrained by the function signature

[mockersf]

I opened #1673 as an example of something that can be build on this

[alec-deason]

This is a super useful tool. I have a couple of style nits which you should feel free to ignore if they don't make sense to you.

[alec-deason]

When reading through this I stumbled on the name to_system several times because it seems like it must be connected to the IntoSystem but that doesn't make sense in context. I think I actually prefer the original sender and receiver, they're slightly more cryptic but they're conventional which makes them instantly recognizable.

[mockersf]

I disagree on that, but I guess it's a taste/habit situation. Plus I don't like having a variable named after its type.

I'm open to changing it back if others feel the same way

[alec-deason]

Your reason for making the change is good, I don't object to keeping it.

[alice-i-cecile]

Closes #1833.

[cart]

I think this might be better solved by #1393 (or some other async implementation). I think that would enable defining a system that (1) awaits an async load of the initial asset (2) yields control until the asset is finished loading (3) runs the post processing logic after the system has run.

There is some nuance, such as needing to call AssetServer::update_asset_storage() manually after the load finishes, but this might be solveable in a nice way.

I'd largely just like to try to build this out of existing/planned pieces (systems, events, asset server, etc) instead of adding new ones, if at all possible. This is a "dataflow" problem, which is a class of problem we've spend a lot of time solving in Bevy already.

[inodentry]

This PR feels very similar to my old API proposal in #1307, in that both of these things are attempts to hook functionality into the asset system to run when an asset loads.

If async systems are the new suggested way to go about this sort of stuff, I guess they could address all of these scenarios and would resolve that old discussion, too?

[mockersf]

(1) awaits an async load of the initial asset (2) yields control until the asset is finished loading (3) runs the post processing logic after the system has run.

This is already possible without async systems, having a system that wait for an asset to be loaded then transform it. It's more an ergonomic question:

• A system can't be planned at start to run specifically for an asset handle that may be created during run, one would have to add a resource, something like ListOfAssetsToTransform and watch it in the system created at start.
• Listening for an asset to be loaded then reacting to do something else is something that is not obvious.

This PR doesn't really do anything async, it just wraps that in a neat little function.

I'd largely just like to try to build this out of existing/planned pieces (systems, events, asset server, etc) instead of adding new ones, if at all possible. This is a "dataflow" problem, which is a class of problem we've spend a lot of time solving in Bevy already.

I would argue that this reuse completely the asset server and the system added when adding an asset type. The only new thing here is a variant of an enum that can be sent through an existing channel

[cart]

My only major concern with the current implementation is that it adds a new api for registering "app logic" that is specific to AssetServer. If we can do this inside the ECS, we get the added flexibility of ECS / full access to the data encoded there.

I do acknowledge that from a different perspective this isn't "app logic" but rather "asset logic". Back when I was investigating evolving bevy_assets vs adopting Distill, I added the concept of "derived assets", which I used to enable things like "optimized textures derived from source textures". I think theres a world where we could integrate those changes and make them usable for these types of things. But if we go that route, I think we would need to reconsider Distill adoption as we'd be starting to encroach on that territory.

[mockersf]

This would probably work completely differently/not be needed in a post Distill world 👍

[mockersf]

closing as too controversial