Assets with embedded handles to other assets

[viridia]

What problem does this solve or what need does it fill?

Complex assets such as scenes, UI layouts, and other high-level game data (quests, dialogues, skills, etc.) often contain embedded references to other, lower-level assets. I want to simplify how these dependent assets are loaded by allowing embedded asset references to be resolved by the asset loader for the containing asset.

For example, I'm working on a GUI asset format which contains a tree of nodes (widgets) that can reference other assets (stylesheets). A typical widget looks like this (in JSON):

{
  "type": "element",
  "id": "left",
  "styleset": ["#/styles/sub-panel"],
  "style": {
    "width": 200
  }
},

The styleset property is a list of relative asset paths (resolving using my other PR #9473). When I decode the asset, the asset path is deserialized into a string; later, there's a system which walks the tree and calls server.load() on each asset path.

However, it would be more efficient if I could create the asset handles in the decoder itself. This has several advantages:

• It means less complexity, since I no longer have to have a separate system for loading the dependent assets.
• It means faster loading, since the dependent handles get added earlier in the lifecycle.
• It means that I can declare the linked assets as dependencies using the add_asset_dependency method.

Unfortunately, an asset loader doesn't have access to the APIs needed to load another asset (at least, not that I can see). The only context available to an asset loader is LoadContext. LoadContext does have a get_handle method, but it takes a handle id, not a path. There doesn't seem to be any equivalent to server.load().

A description of why this particular feature should be added.

What solution would you like?

The easiest solution would be add a method to LoadContext that returns a handle given an AssetPath.

Additional Context

Note that the embedded references are handles, not the loaded data. In other words, the widget contains a handle to a stylesheet, not a stylesheet itself. This is by design - it facilitates hot reloading of stylesheets, so that when I edit the JSON file it doesn't need to completely re-create the UI, only the styles.

[mockersf]

get_handle takes a Into<HandleId>, which AssetPath implements

[viridia]

OK, that's interesting. I would not have been able to figure that out just from reading the documentation.

Also, I'm not sure it completely addresses the issue - get_handle() creates a strong handle, but it doesn't appear to actually initiate loading of the asset for that path. Here's what the implementation looks like:

pub fn get_handle<I: Into<HandleId>, T: Asset>(&self, id: I) -> Handle<T> {
    Handle::strong(id.into(), self.ref_change_channel.sender.clone())
}