Asset System Pain Points

[andriyDev]

Derived Assets

The Bevy asset system is missing the ability to take assets/files and produce a new asset from it. For example, you could use a height map image to produce a mesh.

There is no good solution for this today. Either you can create an asset processor (which means you can't access the original image), or you have to manually listen for asset load events and manually store the asset in the Assets resource (which is basically just duplicating all the file-watching code, and doesn't allow for caching to disk).

Ideally, derived assets should be able to load as many assets as it wants and produce a corresponding asset. For example, you could load up a game map, which might contain other "prefabs" (nested scenes), and produce a bunch of AI cover points.

Whether this asset is cached to disk (like asset preprocessing today) should be up to the user. Some assets may want to be cached (like AI cover points), but some assets might not in order to save on disk space (like the height map example above).

Another related feature is "synthetic assets" - derived assets created from nothing. This could be something like a lookup table. Again, whether this asset is cached or not should be up to the user. These synthetic assets may not be necessary, but if a design could support it as well, that would be nice!

Asset preprocessing is not extensible

Asset preprocessing decides which processor to use based on a file's associated meta file. This is a problem since one file can be composed of several assets. For example, GLTF files contain meshes, textures, animations, etc. Unfortunately, if you want to preprocess just the meshes (for example, you want to create a MeshletMesh), you have to create a preprocessor for GLTF files in general that internally only looks at the meshes. If you want to have additional processing of your meshes, you have to make your meshlet processor more complicated (since there is no way to chain processors except by making a bigger one).

Ideally, there would be some way to "build up" preprocessors. Note we don't need to serialize the intermediate states to disk, only the final state. Along the same lines, having some way of processing subassets individually would also be useful.

AssetSaver is a lie

The AssetSaver struct is a sort of misleading name. It suggests that you can use this to save assets. Today, this is not really the case (see #14950, #14638, #11216). AssetSaver only works as expected in the context of asset processors.

Other pain points

Please add more here! Understanding where users are suffering is the first step to fixing things!

[JMS55]

I strongly agree with everything written here. These are all very real pain points that I've personally run into in the past.

How we solve them, I'm unsure. BSN will definitely help somewhat, as we can spit out a bsn scene that loads assets, but yeah lots of improvements need to be made to asset processing APIs themselves.