Integrate Asset management with Renderer

[ghost]

It would be nice if we could abstract away the Textures/Vertex Buffers so that the ECS does not need to retain direct links to the data. The asset manager would be responsible to for loading and unloading assets and provide handles to said assets. That way user code never has to touch gfx-rs unless they are directly working on extending the renderer for their game.

[msiglreith]

I toyed around with a possible asset pipeline and want to share my quick/ugly prototype (unfortunatley requiring nightly features!) https://gist.github.com/anonymous/176941be70ac1747c557ba68c47b56eb

Possible pipeline for an asset load request:

AssetStores -> (raw data) -> [AssetSubLoader(raw) -> (data) -> AssetSubLoader(asset)] -> Asset

AssetStore: A storage (similiar to a package manager), which returns a [u8] byte stream for the specific asset requested. Possible storage types would be a file archive(zip), directory or an http-server.

It should be possible to run the different stages parallel and asynchronous. Interesting would be using the new future library.

If the corresponding loader and some asset stores are registered to the asset manager, an assert can be loaded directly by AssetType + an identifier(e.g. file extension) or preloaded by using an identifier only.

Example usage (only implemented the actual loading from data to asset):

asset_manager.load_asset_from_data::<Mesh, Vec<VertexNormals>>(&vertex_data); // doesn't require storage
asset_manager.load_asset::<Mesh>("obj", &[0; 24])); // raw [u8] data from storage
asset_manager.preload_asset("obj", &[0; 24]));

Writing a loader for an combination of Asset + AssetSource:
https://gist.github.com/anonymous/176941be70ac1747c557ba68c47b56eb#file-playground-rs-L157-L172

I hope this was helpful to some extent!

[fHachenberg]

Is the amethyst roadmap aiming for the possibility of hot swapping assets? I consider this an essential feature to speedup iteration cycles and thus increase productivity.

Edit: see #43

[bjadamson]

Has the asset manager become too big? It seems like this kind of code should be represented via ecs components and processors, no?

https://github.com/amethyst/amethyst/blob/develop/examples/03_renderable/main.rs#L44

This also includes the example above, couldn't/shouldn't the mesh's be components with processors that iterate over them?

edit: include "processors" in my sentence.

[jFransham]

Whatever the design is, it needs to support cascading resource loading - currently you can only load one asset per identifier. Asset loaders need to be able to load other assets (ideally only passing the asset store that the loader is loading from). You can, of course, implement this as another parameter to AssetLoader::from_data, but it seems like there has to be a better way. Of course, I might be missing something and this might already be possible.

[ghost]

@bjadamson: Yeah, I ran into this while working on an nphysics integration demo. Basically, I could load the meshes just fine, but couldn't find a way of extracting them to pass them to the physics processor. Definitely something to consider for whatever solution is chosen.

[msiglreith]

@jFransham Good point! A possible solution might be to pass the AssetManager instead of Assets, which would allow to call load_asset() in from_data(), but I haven't tested this yet.

@mechaxl The currently intended usage is to add the AsetManager as resource to the world. Systems can then read the AssetManager on fetch(). The assets ids would be stored inside the components, which can be then used for getting the assets from the manager.

For the moment the asset manager is stored in the context, but this will be changed in future with #133 and #134.

Additionally the current Mesh is built for the renderer only, a physics processor would probably need an other mesh representation, which stores the mesh data in the main memory.

Nonetheless, it seems we need to document this part better. I'll try to address it in #134.

[jFransham]

@msiglreith So I added another method to AssetLoader that takes an AssetManager on my fork. See the (hacky) implementation here and a usage here. You run into borrowing problems very quickly that I had to get around by making the closures field on the AssetManager be populated by function pointers instead of closures (since the former are Copy whereas the latter are not). This is ok since the only point to the closures was to make concrete some type parameters, but it kinda proves that a function taking the entire AssetManager is overly limiting. For example, you can't load in parallel now. You also have a problem with duplicated code, since most asset loaders only want the Assets struct.

I think the best way to do this would be to have a function that is called before from_data that returns a list of assets to preload based on the data from from_raw. This enforces an abstraction barrier, since each loader only knows about the loaders immediately beneath them (i.e. they can't use the value of a loaded asset to branch and choose further assets to load). That means that a programming style that allows more parallelism is enforced statically, which is even more important for IO-bound operations.

I might implement this if it become necessary, but I'm only making changes that I actually need in my own project for now.

[zakarumych]

This issue is outdated as there is new asset management system