-
-
Notifications
You must be signed in to change notification settings - Fork 3.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add asset_processor
feature and remove AssetMode::ProcessedDev
#10194
Conversation
In the future we can consider gating the AssetProcessor code behind this feature (in the interest of slimming down the binary), but I believe that isn't trivial with the current module structure. |
I think we should ultimately add one or more "full recommended dev experience" meta-features for simplicity and ergonomics. Ex: I think the dev experience is still "in flux" enough that we should wait a bit before defining these. |
You added a new feature but didn't update the readme. Please run |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changes seem fine. Should asset_processor
be on by default? I'd like to think we should generally prioritize new users for default features, rather than shipped games (which will be more deliberate).
If it is on by default, it means that shipping would require disabling default features, which opens a huge can of worms that most users won't be equipped to manage. We aren't really even equipped to manage that, given the frequency of regressions we experience with non-default cargo feature configurations. I think we should encourage the Additionally, I think we shouldn't yet encourage most people to turn asset preprocessing on by default. So far we've only built the image processor and it is pretty bare bones. Idk if the value prop is fully there yet for most people. |
…yengine#10194) # Objective Users shouldn't need to change their source code between "development workflows" and "releasing". Currently, Bevy Asset V2 has two "processed" asset modes `Processed` (assumes assets are already processed) and `ProcessedDev` (starts an asset processor and processes assets). This means that the mode must be changed _in code_ when switching from "app dev" to "release". Very suboptimal. We have already removed "runtime opt-in" for hot-reloading. Enabling the `file_watcher` feature _automatically_ enables file watching in code. This means deploying a game (without hot reloading enabled) just means calling `cargo build --release` instead of `cargo run --features bevy/file_watcher`. We should adopt this pattern for asset processing. ## Solution This adds the `asset_processor` feature, which will start the `AssetProcessor` when an `AssetPlugin` runs in `AssetMode::Processed`. The "asset processing workflow" is now: 1. Enable `AssetMode::Processed` on `AssetPlugin` 2. When developing, run with the `asset_processor` and `file_watcher` features 3. When releasing, build without these features. The `AssetMode::ProcessedDev` mode has been removed.
…yengine#10194) # Objective Users shouldn't need to change their source code between "development workflows" and "releasing". Currently, Bevy Asset V2 has two "processed" asset modes `Processed` (assumes assets are already processed) and `ProcessedDev` (starts an asset processor and processes assets). This means that the mode must be changed _in code_ when switching from "app dev" to "release". Very suboptimal. We have already removed "runtime opt-in" for hot-reloading. Enabling the `file_watcher` feature _automatically_ enables file watching in code. This means deploying a game (without hot reloading enabled) just means calling `cargo build --release` instead of `cargo run --features bevy/file_watcher`. We should adopt this pattern for asset processing. ## Solution This adds the `asset_processor` feature, which will start the `AssetProcessor` when an `AssetPlugin` runs in `AssetMode::Processed`. The "asset processing workflow" is now: 1. Enable `AssetMode::Processed` on `AssetPlugin` 2. When developing, run with the `asset_processor` and `file_watcher` features 3. When releasing, build without these features. The `AssetMode::ProcessedDev` mode has been removed.
Objective
Users shouldn't need to change their source code between "development workflows" and "releasing". Currently, Bevy Asset V2 has two "processed" asset modes
Processed
(assumes assets are already processed) andProcessedDev
(starts an asset processor and processes assets). This means that the mode must be changed in code when switching from "app dev" to "release". Very suboptimal.We have already removed "runtime opt-in" for hot-reloading. Enabling the
file_watcher
feature automatically enables file watching in code. This means deploying a game (without hot reloading enabled) just means callingcargo build --release
instead ofcargo run --features bevy/file_watcher
.We should adopt this pattern for asset processing.
Solution
This adds the
asset_processor
feature, which will start theAssetProcessor
when anAssetPlugin
runs inAssetMode::Processed
.The "asset processing workflow" is now:
AssetMode::Processed
onAssetPlugin
asset_processor
andfile_watcher
featuresThe
AssetMode::ProcessedDev
mode has been removed.