Asset V2: GLTF parts are available as soon as possible instead of when everything's ready

[mockersf]

Bevy version

main with Asset V2 merged: 5eb292dc10b99e13c6f606b7d9f0018f59052574

What you did

Run example load_gltf

What went wrong

The GLTF used to be displayed all at once. Now each part is displayed when it's ready.

https://github.com/bevyengine/bevy/assets/8672791/dc87ea09-09ef-4585-b4da-8ea78bb5fcf2

Additional information

Not sure which is the best behaviour, but I think the difference is noticeable enough to discuss

[cart]

I'm guessing this will be context dependent. I think this default behavior for assets is generally desirable (make sub assets available for use as soon as they are ready). To introduce the old behavior we can gate scene spawns on AssetEvent::LoadedWithDependencies if we want to.

[cart]

This could be configurable (either a setting on scenes themselves or as part of the loading process).

[dannymcgee]

To introduce the old behavior we can gate scene spawns on AssetEvent::LoadedWithDependencies if we want to.

I tried to set this up manually in our WASM app today, but it doesn't seem to be working as expected.

What I did:

• load the *.gltf file in a Startup system and store its handle in a Resource
• Create a scene_loaded predicate system that returns true if any AssetEvent<Scene>::LoadedWithDependencies has an ID that matches the stored glTF's default_scene
• Add a spawn_gltf_scene system to Update with .run_if(scene_loaded)
• Add an Update system that logs every AssetEvent<Scene>, AssetEvent<Mesh> and AssetEvent<StandardMaterial> so I can see what's happening

What I'm seeing:

• A stream of LoadedWithDependencies events comes through for the scene and all its meshes and materials
• spawn_gltf_scene runs
• A stream of AssetEvent::Added events comes through for everything
• A slow trickle of AssetEvent::Modified events comes through, first for all of the meshes, then for all of their materials. The meshes each pop into view in time with the Modified events for their materials.

I suspect this may be causing a perf regression for us. (EDIT: After further investigation, I actually think the perf problem is a separate issue.) We're loading kind of a large scene (118 distinct materials), and we see a hiccup every time a new mesh (or material?) is rendered for the first time. In 0.11 this happened all at once, so we saw one pretty large hiccup when the scene spawned in. But in 0.12, we're basically seeing smaller hiccups repeated over the course of many update cycles in a row, because each of those updates is spawning new stuff.

Unfortunately the sum of the individual hiccups is noticeably longer than the one original hiccup. Looking at the timestamps in the console, we're seeing deltas ranging from ~100-500ms between Modified events, sometimes a bit longer. (It also looks pretty goofy — e.g., our character's eyes and hair seem to like spawning before her body. 😆) I haven't measured the net time difference from 0.11 to 0.12 yet, but I'll do that shortly and update this comment.

EDIT: Total times from fully loaded to fully spawned:

Bevy	Start	End	Time Elapsed
v0.11	asset_server.get_load_state(gltf) == LoadState::Loaded	scene_spawner.instance_is_ready(gltf.default_scene)	10.502s
v0.12	AssetEvent<Scene>::LoadedWithDependencies	Final AssetEvent<StandardMaterial>::Modified	30.278s

EDIT 2: Just wanted to make it super clear that we're only seeing this issue in WASM. I usually run the app as a native executable during development, and I haven't seen enough of a difference there to even look into it.