-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
Simplified scene and reflection serialization #4153
Comments
I like this a lot: it's shorter, clearer, and easier to both read and write! For me, 3 > 2 >> 1. Are you interested in submitting a PR for this? We're about to take a serious look at scenes, and this is high on my list for improvements I'd like to see. |
I like the last version, but how would it work if we ever want to add more metadata to a scene that isn't just another entity? |
Top level sections? e.g.: scene::Metadata1 (
),
scene::Entities(
0: [
bevy_transform::components::transform::Transform(
translation: glam::vec3::Vec3(0.0, 0.0, 0.0),
# ...
)
],
) |
How is this issue different to #92? It appears to me to be covering the same ground. But I do agree, those formats are much nicer |
I kinda assumed the scene format would support nested scene or even multiple scene in a file. Assuming it's only one per file it makes sense to only use top level sections though |
I'll give it a shot and we'll see what happens
I like what @aevyrie suggested but I don't think it's possible to have multiple top level values. In that case we could simply wrap it all in a struct: Scene( // optional
metadata1: ...
metadata2: ...
entities: {
0: [
bevy_transform::components::transform::Transform(
translation: glam::vec3::Vec3(0.0, 0.0, 0.0),
rotation: glam::quat::Quat(0.0, 0.0, 0.0, 1.0),
scale: glam::vec3::Vec3(1.0, 1.0, 1.0),
),
...
],
...
}
) |
Sounds good. @AronDerenyi, feel free to reach out on the PR thread or on Discord if you need a hand with the PR :) |
Just a small note about external compatibility: RON isn't all that well supported outside of the Rust ecosystem. Until a fully-capable scene editor is available in some format, some form of consideration for third-party tooling should be kept in mind. |
@james7132 I (think) we would always have the option to deserialize into another format like JSON, we would just need to implement ser/de for the scene type. Are there external tools you have in mind that would consume bevy's custom scene format?
@AronDerenyi FWIW this looks shockingly similar to the example in the |
Not gonna lie, that gave me the idea to add the "Scene" to the beginning. |
In the early days of bevy i tried making "struct name style" RON work for dynamic scenes, but couldn't do it, because RON (and serde for that matter) were designed under the assumption that we are serializing / deserializing "static" structs where you already know the type before you start deserializing. I have yet to see any RON that uses "fully qualified type names" in the struct-location, because (at least last time I checked) this is hard coded functionality that uses serde-provided short names. We will need to support fully qualified type names to resolve naming conflicts. After my initial investigation, I was also under the assumption that dynamically deserializing based on struct name alone wasn't possible without forking RON (which I did do 😄). Ultimately I decided it wasn't worth it because it couldn't support fully qualified type names. @lassade has done some great work in this space here: https://github.com/lassade/bevy_prefab. It seems like they have somehow managed to dynamically load via struct names (see the arbitrary lists of prefab types and lists of component types in the |
So long as it works strictly with Reflect without needing explicit Serialize/Deserialize implementations, this could tentatively work. |
GitHub didn't link the mention so I'll do it myself 😄 |
Completed! |
What problem does this solve or what need does it fill?
Right now serialized scene files are too big and verbose. Take for example the scene example file:
It takes 64 lines to describe 2 entities with a total of 4 components. It's also hard to read and understand with all the indentation. This is mostly because of the way reflected items are serialized so all of the above also apply to them.
What solution would you like?
Luckily the Rusty Object Notation (RON) has introduced named structs which can be used to merge the type and value into a single item like so:
changing
to
This way we remove the "type" and "value" keys and also a layer of indentation. Applying all of this to the example file we get the following:
This is only 28 lines long with a lot less indentation while keeping all of the information of the current file. This is subjective but to me it's just as if not more readable than the current one. And while we're at it we can further simplify by treating the scene as a map where each key is and entity and their corresponding values are lists of their components. Like so:
I prefer the last version for the following reasons:
The text was updated successfully, but these errors were encountered: