Meta-issue for improving reflect-deserialized asset loading

[aecsocket]

This is a meta-issue for tracking the progress of improving how reflect-deserialized assets get loaded. This is a cross-cutting concern between both reflection and assets.

The motivating use case comes from bevy_animation_graph, where we deserialize AnimationGraphs from RON files. This looks like:

#[derive(Asset, Reflect)]
struct AnimationGraph {
    pub nodes: Vec<AnimationNode>,
    pub edges: (...),
}

#[derive(Reflect)]
struct AnimationNode {
    pub name: String,
    pub inner: Box<dyn NodeLike>, // NodeLike: Reflect
}

#[derive(Reflect)]
#[reflect(NodeLike)]
struct AnimationClipNode {
    pub clip: Handle<AnimationClip>,
}

#[derive(Reflect)]
#[reflect(NodeLike)]
struct ChangeSpeedNode;

(
    nodes: [
        (
            name: "Walk clip",
            ty: "bevy_animation_graph::node::AnimationClipNode",
            inner: (
                clip: "animation_clips/walk.animclip.ron",
            )
        ),
        (
            name: "Change speed",
            ty: "bevy_animation_graph::node::ChangeSpeedNode",
            inner: (),
        ),
    ],
    edges: ( ... ),
)

The two important things here are:

• AnimationNode stores a type-erased NodeLike
• AnimationClipNode, and other node types, may store asset handles

However, it's currently very annoying to write code to deserialize and load this asset properly. Why?

• AnimationNode can't derive Reflect because Box<dyn NodeLike> isn't Reflect
  • bevy_reflect: Add ReflectBox to remotely reflect Box #14776
  • bevy_reflect: Add casting traits to support Box and other wrapper types #15532
  • This means you have to write a manual impl Reflect for AnimationNode
• We need a way to read the value of that ty field, and deserialize inner based on the TypeRegistration we look up
  • This is a perfect candidate for DeserializeFromRegistry
  • bevy_reflect: Add DeserializeWithRegistry and SerializeWithRegistry #8611
• When Handle<T> is deserialized, it gets set to Handle::default which is useless
  • In the AssetLoader::load call, we get a LoadContext - we should use that to actually kick off a load for this asset handle when we encounter it
  • bevy_reflect: Add ReflectDeserializerProcessor #15482
  • Note: the difference between what we're doing here and what we're doing in the step above, is that in this step, we have access to a &mut LoadContext which we only get inside the asset processor. It doesn't exist in the TypeRegistry used by DeserializeFromRegistry.
• Using the LoadContext / NestedLoader, we can't load a dynamic-typed asset (since we're using reflection, we do know the T in the Handle<T>, but only at runtime - i.e. only its TypeId)
  • bevy_asset: Improve NestedLoader API #15509
• There should be an inbuilt impl of ReflectDeserializerProcessor which accepts a LoadContext and does the two above steps for you
  • PR to be written
• You have to write boilerplate DeserializeSeed code for custom deserialization of an AnimationNode because of that ty
  • Honestly not sure what to do for this. The custom DeserializeSeed actually isn't too bad compared to the rest of the boilerplate that you have to write, but I'm sure there is a better way to do this.
  • The better way of doing this is using DeserializeFromRegistry from bevy_reflect: Add DeserializeWithRegistry and SerializeWithRegistry #8611
• Also have to be able to save this kind of asset back to disk, serializing Handle<T>s as just string asset paths
  • bevy_reflect: Add ReflectSerializerProcessor #15548

If these issues are solved, we have a much more powerful way to easily define these kinds of complex assets which depend on other assets, and that also use reflection to deserialize values of unknown types.

Once these are resolved, I would like to write an example which deserializes an asset in this reflective way, showing off the automatic recursive Handle loading, and deserializing type-erased Box<dyn Reflect>s.