Adjust bevy_asset::AssetMode::Processed to take an Option<bool>th…

[OvermindDL1]

Adjust bevy_asset::AssetMode::Processed to take an Option<bool>that if None will default to whether the asset_processor feature is enabled or not.

Objective

• Allowing the asset_processor feature to be user controllable at runtime, though default to the prior functionality

Solution

• Added an Option<bool> to the bevy_asset::AssetMode::Processed head and dispatched on it falling back to the cfg!(feature = "asset_processor") value.

---

Changelog

Changed: bevy_asset::AssetMode::Processed acquired a new argument of bevy_asset::AssetMode::Processed(Option<boo>), if None then prior functionality else it will enable the processor if Some(true) or disable it if Some(false) overriding the feature.

Migration Guide

To continue with the prior functionality just adjust any AssetMode::Processed to bevy_asset's plugin loader to be AssetMode::Processed(None).

[github-actions]

Welcome, new contributor!

Please make sure you've read our contributing guide and we look forward to reviewing your pull request shortly ✨

[cart]

One thing to consider for this impl: while the asset_processor currently is "just" a flag to enable the asset processor, but ultimately I think it should also determine whether or not to compile the asset processor (this was omitted for 0.12 because the changes are non-trivial and require some refactors).

I think the behavior should be:

1. If asset_processor is not present, it is not compiled and we assume that for AssetMode::Processed, assets have already been compiled.
2. If asset_processor is present, and we are in AssetMode::Processed it is compiled and (by default) we assume that we will start the asset processor (enabling the "standard" workflow as described).
3. If asset_processor is present, we are in AssetMode::Processed and the user has opted out from starting the processor as a runtime configuration on AssetPlugin, we will not start the server and we will exhibit the same behavior as (1).

I think Processed should hold a bool. I would like to keep that as a simple global "Processed vs Unprocessed" configuration so we can make this behavior work transparently.

Instead I think we should probably adopt the AssetPlugin::watch_for_changes_override pattern. Ex: AssetPlugin::start_asset_processor_override: Option<bool>, which will be considered when AssetMode::Processed is enabled with the asset_processor feature.

[OvermindDL1]

One thing to consider for this impl: while the asset_processor currently is "just" a flag to enable the asset processor, but ultimately I think it should also determine whether or not to compile the asset processor (this was omitted for 0.12 because the changes are non-trivial and require some refactors).

I expected it to work like this and was surprised when it didn't, I would expect this in the future as well (especially with how heavy some preprocessors might be when compiled in).

I think the behavior should be:
...snip ...

This works quite well.

Instead I think we should probably adopt the AssetPlugin::watch_for_changes_override pattern. Ex: AssetPlugin::start_asset_processor_override: Option<bool>, which will be considered when AssetMode::Processed is enabled with the asset_processor feature.

Effected this change, just pushed.

I do wonder if it should be AssetPlugin::start_asset_processor_override: Option<bool>, or if it should just be AssetPlugin::start_asset_processor_override: bool, that defaults to true though, that's basically what is already happening so the Option might be superfluous here. Should I make it just a bool instead?