Support systems with `In` parameters in schedules

[eira-fransham]

Motivation

Recently I’ve been working on scene loading with bevy_trenchbroom, and something that’s come up is the way a user can customise how scenes are loaded. Often, a game may want to have some domain-specific metadata that can customise (for example) properties of materials, the components that get applied to newly-created entities, etc. The current solution is using "hooks" - basically a set of domain-specific linked lists of function pointers, inserted at specific points in the loading process with specific responsibilities. A design we came up with is to have all user code be handled by systems that run in the scene's inner World. For this, we’d like to be able to define phases, to allow users to ensure the order their code runs in comparison to the processing done in bevy_trenchbroom by default. However, in an ideal world we would be able to pass the LoadContext in to the systems, to allow customising loading external dependencies etc. Anything accessible to systems needs to either be added as a resource (in which case it needs to be 'static, which LoadContext isn’t), or passed in via run_system_with. Since the schedule graph uses Systems, which bounds systems to use In = (), this means we can’t use schedules to handle this.

Proposed solution

My proposal would simply be to have SystemWithAccess, Systems, and Schedule have type parameters for input and output, which would both default to (). These would not change the implementation at all (users are considered responsible for handling order w.r.t to inputs/outputs), the new method for relevant types would only be for the <(), ()> instantiation, so users would need to use Default::default() to instantiate other versions, and Schedule::run(..) would only be available for Schedule<(), ()>. For simplicity, instead of introducing Schedule::run_with, the way to actually run these systems would probably be to just use topsort_graph and run the systems in sequence. On the topic of simplicity, I also think it’s fine to require all systems in Systems/Schedule to have the same inputs and outputs, rather than letting them store dynamic system IDs. This is a very minimal change but would be a nice quality-of-life feature for anyone who uses schedules outside of the context of an App and/or wants to run a one-shot schedule.

For the purposes of scene loading, I do feel that loading scenes that include entities with behaviour has unique-enough requirements that something more dedicated built in to Bevy could be useful, but this would, at least, give us primitives that we can experiment with.

Alternatives

The standard way to handle the original motivation is, as far as I know, to load all the assets in some basic form, wait for them to be loaded, then process them in the main loop to create the relevant entities. This works, but has a few issues:

• The systems operate on the main world instead of in a completely separate world in a completely separate thread (potentially causing frame drops if significant processing is needed).
• It doesn’t have easy access to assets before handles have been created from them, for example if you want to edit an image before applying it to a material you need to mark it as being CPU-accessible
• Loading is a one-shot process, and you should ideally not have these systems in the main loop

[ChristopherBiscardi]

Doing work inside of a Scene World is also something that I've brought up in Skein (blender) and Avian (ColliderConstructor) contexts (along with the material, etc modifications mentioned above).

I've mostly been working towards try to push Skein's component processing (especially Relationships, which require all entitys to have been created) into the gltf loader, but without asset processing support the Scene World is the next logical userspace location to do the work.

Similarly for Avian, Scenes can have colliders that take multiple frames to generate (ex: a large terrain collider). the "spawn-time" option is what most people currently use, which uses the "hooks" approach described above. When ColliderConstructor is inserted, a collider is generated and cached, which can take multiple frames and often results in users being confused as to why their character is now falling through the world.

Note

Doing this kind of processing ahead of time might have impact on the ability to do asset streaming? but we don't have that at all yet so...

Users also take advantage of component lifecycle events (hooks/observers) when Skein inserts components during scene instantiation (including swapping materials, etc). That is to say, there are things you want to customize at spawn time (the edit_material_on_gltf example uses a "configuration component on parent" pattern) and things you want to customize "for all scenes instanced from this scene", which is what this issue is talking about.

---

Overall this feels a bit like an asset processing problem to me. If we had more flexible asset import pipelines, we could change materials, generate heavy colliders, or do any other necessary work to "prepare" a scene when they were being imported.

An alternative to the asset processing flexibility is to construct scenes from other scenes. Trenchbroom/Blender/etc cause scenes to be created, then a user hooks into AssetEvent::LoadedWithDependencies, does their work, and registers a new Scene that is fully "processed".

Trenchbroom could also take advantage of this (or in-place processing), and fire an event after it processed the scene, which would allow a user to arbitrarily work with the post-trenchbroom-processed Scene World. and that starts to get close to what I think is the suggestion here, using schedules, etc for ordering this kind of processing in a Scene World.

[eira-fransham]

I just had the thought: I wonder if having a way to "scope" a resource would also resolve this. For example:

let foo = some_value;
world.with_resource(&foo, |scoped_world| {
  my_schedule.run(scoped_world);
});

This would add some non-'static resource to the world that gets removed once the scope returns. This could be implemented as an external library, although it’d be even better if there was a way to express the concept of a Resource that isn’t 'static.

EDIT: On second thought, I don’t think there’s really a good way to do this in a sound way as an external library in a way that’s also resilient to possible future Bevy API changes