Open cart opened 1 year ago
I think we also need a fallback feature for asset sources. i.e. you tried to load from the file system, but that didn't exist so you now go to a LFS server to get the asset.
Maybe this can just be an asset source type that can use other asset sources.
Maybe this can just be an asset source type that can use other asset sources.
@hymm yeah I think this would be best expressed as a FallbackAssetReader / Writer / etc that can be configured with an ordered list of sources to try.
trying to understand. for asset v2, would settings field allow passing assets/dependencies? an example is loading midi file and setting sound font as a dependency?
trying to understand. for asset v2, would settings field allow passing assets/dependencies? an example is loading midi file and setting sound font as a dependency?
Yup this is possible. You could pass in an AssetPath string via the settings and then use that to load a dependency.
I recently (on Bevy main
) tried doing something to this effect:
fn system(asset_server: Res<AssetServer>) {
let handle1: Handle<Foo> = asset_server.load("cool1.ron");
let handle2: Handle<Bar> = asset_server.load("cool2.ron");
}
and I naively registered multiple asset loaders for the ron
extension- one for output Foo
and the other for Bar
. At runtime it seems only the last loader was applied, so then I get an error when Foo
is being deserialized (since it tries to make it a Bar
).
(EDIT: So in my head without knowledge of bevy_asset
I was hoping somehow the asset system would choose a loader based on my stated output handle type Handle<T>
instead of the file extension).
Is this use-case somehow covered by v2? The closest issue I found was this https://github.com/bevyengine/bevy/issues/367
My workaround workflow is this:
MegaWrapper
asset which covers all T
which are going to be deserialized from extension .ron
LoadContext
to inspect the path to figure out which wrapped variant I want to actually deserialize (which happens to work in my use-case since the file names are very specific)Which feels less elegant than I'd hoped.
I think another workaround is to change files around to new extensions, e.g.
cool1.ron
-> cool1.foo.ron
cool2.ron
-> cool2.bar.ron
and register separate loaders for them.
But in my case the .ron
files belong to a larger Rust project where Bevy doesn't "own" these assets and changing their names would implicate the larger project, so I'm looking for other workflows.
The v2 update breaks all prior code, and that's why I personally, in this moment, hate this poorly documented and poor quality change.
All the bevy code I have seen on github is now utterly broken by this; Worse, The update path is not clear as the "initial migration guide" noted above isn't even linked to, so how are people going to find it?
Please understand that you are creating pain and suffering for others with these poorly documented changes.
Here is a list of recently open issue on assets:
Add true
Ignore
AssetAction that does not copy the asset to the imported_assets folder
I would make a PR for this if its ok, just for clarification: Do we want to change the behavior of Ignore
that the files are not copied anymore, or do we want a new AssetAction?
Yeah that would be welcome! I think we might want two AssetActions (names TBD):
Skip
: skips the asset during processing, attempting to load directly would fail (no copy to processed folder)Ignore
: copies the asset to the processed folder, but without a configured loader or processor. Trying to load would fail (the current behavior)However I think implementing Skip
is the most important thing. I'm not yet sure we actually need Ignore
.
@cart Okay fine, I did a PR which actually does no copy when asset action is Ignore
a few days ago (#12605). If we still want Ignore
, I can make a second PR that introduces the behavior you described :)
Starting work on folder meta and per-type defaults here... #13785
I think comfortable N to one processing could be done using meta defaults and @BeastLe9enD 's ignore feature. You could ignore the input assets using a meta_default file and have the processing rule in another asset type. So, for a texture atlas, you'd have the pngs be ignored by png.meta_default and a texture_atlas.meta_default would describe how to process the texture atlas. (Or my_items.texture_atlas.meta if you wanted to customize a particular atlas... etc...)
(In my testing of this idea, a RawTextureAtlasLoader reads the images and TextureAtlasTransformer turns it into an atlas. With some other minor changes, the resulting stitched image and TextureAtlasLayout are written by a TextureAtlasSaver.)
To finish that entire chain of thought, we would need:
Bevy Asset V2 PR is merged, but there is still plenty of followup work to do! This issue exists to enumerate and track all of this work, although I suspect once the dust settles and we resolve the important stuff, we'll eventually want to close this rather than keep it alive indefinitely.
Immediate Short Term Followups And Tweaks
These are relatively scoped tweaks and fixes that should be resolved in the short term, prior to kicking off other larger efforts.
Add a changelog entry to the Bevy Asset V2 PRload
for non-existent labeled assets fails silentlyIgnore
AssetAction that does not copy the asset to the imported_assets folder.TODO
comment inassets.rs
)Larger Next Steps / Things to Investigate
These are larger changes and features that we will ultimately want.
Assets
collection currently usesOption<T>
for internal asset storage, which should allow us to remove a value while still keeping it "alive" ... is this the right path? This will require some investigation.webserver://some_path/image.png
backed by an Http webserver AssetReader). The "default" asset reader would use normalsome_path/image.png
paths. Ideally this works in combination with multiple AssetWatchers for hot-reloadingstd::any::type_name
. This makes defining assets easier (no need to generate a new uuid / use weird proc macro syntax). It also makes reading meta files easier (because things have "friendly names"). We also use type names for components in scene files. If they are good enough for components, they are good enough for assets. And consistency across Bevy pillars is desirable. However,std::any::type_name
is not guaranteed to be stable (although in practice it is). We've developed a stable type path to resolve this, which should be adopted when it is ready..meta
file already has its own format version. Migrating that to new versions should also be possible. We should support migrations well before the release after Bevy Asset V2 lands (aka before Bevy 0.13).asset_server.load_asset(StandardMaterial::default())
. I think with some cleverness we could also do this formaterials.add(StandardMaterial::default())
, making tracking work "everywhere". There are challenges here relating to change detection / ensuring the server is made aware of dependency changes. This could be expensive in some cases.handle.is_loaded()
would be very cool). Should we store the entire asset and remove theAssets<T>
collection? (Arc<RwLock<Option<Image>>>
?).meta
or.folder_meta
file). Things like "default to linear filtering for all Images in this folder".debug://bevy_pbr/src/render/pbr.wgsl
asset paths) in combination with an AssetWatcher for that asset source and support for "manually loading pats with asset bytes instead of AssetReaders". The old DebugAssetServer was quite nasty and I'd love to avoid that hackery going forward.subdivide_mesh
transform, followed by aflip_normals
transform, then save the mesh to an efficient compressed format).