Bevy needs a better asset-hosting solution for example assets about bevy HOT 15 OPEN

Having an "http" asset source that knew how to fetch and cache assets from static hosting code be useful far beyond just the examples

from bevy.

Allowing multiple sources for one single asset may be enough I guess? Let bevy fetch in order and synchronize among sources. Developers can easily work on local storage and easily distribute via network. Or an asset source which handles resource in this way should make it.

Right, I think that's a reasonable feature :) What this actually reminds me of is font fallback: maybe we can reuse the mechanisms.

I think that the best way forward is:

1. Implement a general-purpose asset fallback solution.
2. Implement a blessed way to fetch assets from the web.
3. Set up our own hosting for the existing assets with an endpoint.
4. Move all of the assets out of tree and swap to a "try locally, then download" strategy for all of the examples.

from bevy.

The main thing I think we need to move away from is having assets in the repo. I don't feel strongly about git lfs on another host, or something like just separate hosting and a script or tool to update/fetch differences and having assets/ in .gitignore or something.

from bevy.

I've worked and do work with submodules quite a bit across a few projects. They are awkward, but they are a solution to a problem, as well as creating problems. :)

from bevy.

there's a risk it will be a more painful experience for anyone trying to contribute a new example: they will have to guess the new URL the asset will be available at, and the example won't work until the asset is available there

from bevy.

I think the last "No assets in repo" approach is best.
Additionally, I think that the sooner we get started on something like an asset store, the better. I think having a central place to find assets, plugins, etc. would be really nice, especially for people coming from engines like unity.
I also agree with @hxYuki, we should allow for different asset sources, and nice integration within bevy to fetch them (and potential nested dependencies) automatically.

from bevy.

Assets == "binary blobs" here.

My preferred remote solution is "search the assets folder, falling back to a download, which then populates the asset folder". Basically asset_server.load_asset("fox.glb").with_remote_fallback("https://bevyengine.org/marketplace/examples");

from bevy.

Or more likely a CachedFallback<FileAssetReader, FileAssetWriter, HttpAssetReader> source or something.

from bevy.

a small first step would be to move assets to another git repo, and make it available through a submodule

on that other repo, we could nuke history without breaking every PR when needed

we could also have an "example" data source for assets that would know how to fetch them and cache them locally

from bevy.

The Rust Project has had nothing but extremely negative things to say about git submodules, so I'm a bit nervous. I don't mind the idea in principle though!

from bevy.

Allowing multiple sources for one single asset may be enough I guess? Let bevy fetch in order and synchronize among sources. Developers can easily work on local storage and easily distribute via network.
Or an asset source which handles resource in this way should make it.

from bevy.

In a previous attempt I modified https://github.com/bevyengine/bevy/blob/main/crates/bevy_asset/src/io/wasm.rs to use reqwest, the only downside is that reqwest is fairly large for non wasm builds

from bevy.

I like the simplicity of assets go in the "assets" folder. I agree that large assets ought not go directly in the repository. But I think it'd be a shame if all the examples referred to remote assets that are unalterable for the user and potentially leave them thinking they need to setup an http server before they can use assets.

Also which assets are we talking about remoting? Shaders and other text-based assets seem like a good thing to keep in the repository because they're small and you want that version history.

from bevy.

We could do it at the "Asset Source" level to configure a global fallback for every request. Ex: override the default asset source to use a Fallback<FileAssetReader, HttpAssetReader> source.

from bevy.

Caching assets locally probably also means there needs to be a story around cache invalidation. If an asset is updated on the HTTP server, the local copies need to be replaced. Depending on the total size of assets, cache evictions might also have to be considered

from bevy.