Stop automatically generating meta files for assets while using asset processing.#17216
Stop automatically generating meta files for assets while using asset processing.#17216cart merged 9 commits intobevyengine:mainfrom
Conversation
IQuick143
added
A-Assets
|
It looks like your PR is a breaking change, but you didn't provide a migration guide. Could you add some context on what users should update when this change get released in a new version of Bevy? |
|
I don't think this PR needs a migration guide since users don't need to change any existing stuff for their assets to work. New assets will also continue to work, though new meta files will have to be created using the provided function or manually created. |
BenjaminBrienen
removed
the
M-Migration-Guide
viridia
left a comment
viridia
left a comment
There was a problem hiding this comment.
Looks fine to me. Do we want to wait for cart to weigh in on this?
|
In terms of guides, I can write up something once all changes are in and the dust has settled. Not a migration guide so much as a description of the new workflow. |
BenjaminBrienen
added
S-Ready-For-Final-Review
|
And for reference: (This is somewhat blessed) |
mockersf
left a comment
mockersf
left a comment
There was a problem hiding this comment.
to keep the same behaviour, I would prefer if the new function didn't overwrite files
alice-i-cecile
added
S-Waiting-on-Author
|
I went with returning an error if the meta file already exists (as opposed to silently succeeding). Unfortunately this required me to try to read the meta file just to check if it's there, but that doesn't seem too bad. |
mockersf
dismissed
their stale review
previous review no longer applicable, will re-review... when I can
andriyDev
added
S-Needs-Review
andriyDev
added
S-Ready-For-Final-Review
alice-i-cecile
added
M-Release-Note
|
Waiting for @cart's re-review before merging, but if that's not forthcoming I intend to merge this before we cut the 0.16 release candidate :) |
|
Thank you to everyone involved with the authoring or reviewing of this PR! This work is relatively important and needs release notes! Head over to bevyengine/bevy-website#2000 if you'd like to help out. |
…t keep the instrumentation. (#22213) # Objective - In #12988, we added tracing spans to asset loading and processing, by creating wrapper structs `InstrumentedAssetLoader` and `InstrumentedAssetProcessor`. - Unfortunately, this causes an issue where `ErasedAssetLoader::{default_meta, type_path}` and `ErasedProcessor::default_meta` can return the wrong type path when using the `trace` feature, and this type path could be written into a meta file, which will be rendered unloadable/unprocessable. - Note even though the loader/processor's type use to have the instrumentation wrapper, when registering the loader/processor, we would actually register the loader/processor under the original type names. So you could still load non-`trace` written meta files, but `trace` written meta files would fail to load whether `trace` was enabled or not! ## Solution - Remove the wrapper loader/processor and instead just create the spans at the callsites. I checked and there's a single callsite of `load` and a single callsite of `process` - very good! - I also added testing that was omitted in #17216 (due to missing test utilities which have since been added). This is how I found out about this problem! Score one for testing. ## Testing - We still produce spans in the `asset_processing` example for both loading and processing. Note: We don't need a migration guide since users should really not be using these directly, and any meta files using these would just be broken.
…tead of the long type path. (#22208) # Objective - Context: In #17216, we stopped automatically generating meta files for assets, but provided explicit functions for generating meta files. - In #21339, we allowed asset processors to be specified by their short type path in meta files. - However, the meta file generating functions still produced fully-qualified type paths for processors. So even though we supported much more readable processor meta files, we didn't take advantage of that when generating meta files. - Fulfilling my obligations to cart: #21339 (comment) ## Solution - Make `ErasedProcessor` have a method for returning its `short_type_path`, and make its `default_meta` method take an enum to choose between using the short or long type path. - When generating the default meta, first lookup the processor using its short type name. If it's ambiguous, use the long type path. - Add tests to show the short/long selection. As part of this, I forced all meta files to be serialized with `\n` as the new line character. - Bonus: add more tests for `write_default_meta_file_for_path` and `write_default_loader_meta_file_for_path` which were omitted in #17216 due to missing appropriate testing utilities (specifically a memory asset writer). ## Testing - Added tests!
7 participants
Objective
Solution
AssetServer::write_default_meta_file_for_pathTesting
write_default_meta_file_for_pathsince we don't have an in-memory asset writer. Writing one could be useful in the future.Showcase
Asset processing no longer automatically generates meta files! This makes it much easier to transition to using asset processing since you don't suddenly get many meta files when turning it on.
You can still manually generate meta files using the new
AssetServer::write_default_meta_file_for_pathfunction.