-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
Scene not loading when entity has GlobalTransform or Children #6573
Labels
A-Reflection
Runtime information about types
A-Scenes
Serialized ECS data stored on the disk
C-Bug
An unexpected or incorrect behavior
Comments
ShinySapphic
added
C-Bug
An unexpected or incorrect behavior
S-Needs-Triage
This issue needs to be labelled
labels
Nov 13, 2022
ShinySapphic
changed the title
Scene not loading when entity has GlobalTransform & Children
Scene not loading when entity has GlobalTransform or Children
Nov 13, 2022
MrGVSV
added
A-Reflection
Runtime information about types
A-Scenes
Serialized ECS data stored on the disk
and removed
S-Needs-Triage
This issue needs to be labelled
labels
Nov 13, 2022
Can confirm, have the same problem. ^^" Edit: Seems like that the problem is from parsing the Ron file (inside the library), maybe because it's a tuple? ^^" |
bors bot
pushed a commit
that referenced
this issue
Nov 14, 2022
# Objective > Part of #6573 `Children` was not being properly deserialized in scenes. This was due to a missing registration on `SmallVec<[Entity; 8]>`, which is used by `Children`. ## Solution Register `SmallVec<[Entity; 8]>`. --- ## Changelog - Registered `SmallVec<[Entity; 8]>`
This was referenced Nov 20, 2022
bors bot
pushed a commit
that referenced
this issue
Nov 25, 2022
…strations from most glam types (#6580) # Objective > Part of #6573 When serializing a `DynamicScene` we end up treating almost all non-value types as though their type data doesn't exist. This is because when creating the `DynamicScene` we call `Reflect::clone_value` on the components, which generates a Dynamic type for all non-value types. What this means is that the `glam` types are treated as though their `ReflectSerialize` registrations don't exist. However, the deserializer _does_ pick up the registration and attempts to use that instead. This results in the deserializer trying to operate on "malformed" data, causing this error: ``` WARN bevy_asset::asset_server: encountered an error while loading an asset: Expected float ``` ## Solution Ideally, we should better handle the serialization of possibly-Dynamic types. However, this runs into issues where the `ReflectSerialize` expects the concrete type and not a Dynamic representation, resulting in a panic: https://github.com/bevyengine/bevy/blob/0aa4147af6d583c707863484d6a8ad50ed0ed984/crates/bevy_reflect/src/type_registry.rs#L402-L413 Since glam types are so heavily used in Bevy (specifically in `Transform` and `GlobalTransform`), it makes sense to just a quick fix in that enables them to be used properly in scenes while a proper solution is found. This PR simply removes all `ReflectSerialize` and `ReflectDeserialize` registrations from the glam types that are reflected as structs. --- ## Changelog - Remove `ReflectSerialize` and `ReflectDeserialize` registrations from most glam types ## Migration Guide This PR removes `ReflectSerialize` and `ReflectDeserialize` registrations from most glam types. This means any code relying on either of those type data existing for those glam types will need to not do that. This also means that some serialized glam types will need to be updated. For example, here is `Affine3A`: ```rust // BEFORE ( "glam::f32::affine3a::Affine3A": (1.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0), // AFTER "glam::f32::affine3a::Affine3A": ( matrix3: ( x_axis: ( x: 1.0, y: 0.0, z: 0.0, ), y_axis: ( x: 0.0, y: 1.0, z: 0.0, ), z_axis: ( x: 0.0, y: 0.0, z: 1.0, ), ), translation: ( x: 0.0, y: 0.0, z: 0.0, ), ) ) ```
bors bot
pushed a commit
that referenced
this issue
Nov 25, 2022
…strations from most glam types (#6580) # Objective > Part of #6573 When serializing a `DynamicScene` we end up treating almost all non-value types as though their type data doesn't exist. This is because when creating the `DynamicScene` we call `Reflect::clone_value` on the components, which generates a Dynamic type for all non-value types. What this means is that the `glam` types are treated as though their `ReflectSerialize` registrations don't exist. However, the deserializer _does_ pick up the registration and attempts to use that instead. This results in the deserializer trying to operate on "malformed" data, causing this error: ``` WARN bevy_asset::asset_server: encountered an error while loading an asset: Expected float ``` ## Solution Ideally, we should better handle the serialization of possibly-Dynamic types. However, this runs into issues where the `ReflectSerialize` expects the concrete type and not a Dynamic representation, resulting in a panic: https://github.com/bevyengine/bevy/blob/0aa4147af6d583c707863484d6a8ad50ed0ed984/crates/bevy_reflect/src/type_registry.rs#L402-L413 Since glam types are so heavily used in Bevy (specifically in `Transform` and `GlobalTransform`), it makes sense to just a quick fix in that enables them to be used properly in scenes while a proper solution is found. This PR simply removes all `ReflectSerialize` and `ReflectDeserialize` registrations from the glam types that are reflected as structs. --- ## Changelog - Remove `ReflectSerialize` and `ReflectDeserialize` registrations from most glam types ## Migration Guide This PR removes `ReflectSerialize` and `ReflectDeserialize` registrations from most glam types. This means any code relying on either of those type data existing for those glam types will need to not do that. This also means that some serialized glam types will need to be updated. For example, here is `Affine3A`: ```rust // BEFORE ( "glam::f32::affine3a::Affine3A": (1.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0), // AFTER "glam::f32::affine3a::Affine3A": ( matrix3: ( x_axis: ( x: 1.0, y: 0.0, z: 0.0, ), y_axis: ( x: 0.0, y: 1.0, z: 0.0, ), z_axis: ( x: 0.0, y: 0.0, z: 1.0, ), ), translation: ( x: 0.0, y: 0.0, z: 0.0, ), ) ) ```
archsolar
pushed a commit
to archsolar/bevy
that referenced
this issue
Nov 29, 2022
…strations from most glam types (bevyengine#6580) # Objective > Part of bevyengine#6573 When serializing a `DynamicScene` we end up treating almost all non-value types as though their type data doesn't exist. This is because when creating the `DynamicScene` we call `Reflect::clone_value` on the components, which generates a Dynamic type for all non-value types. What this means is that the `glam` types are treated as though their `ReflectSerialize` registrations don't exist. However, the deserializer _does_ pick up the registration and attempts to use that instead. This results in the deserializer trying to operate on "malformed" data, causing this error: ``` WARN bevy_asset::asset_server: encountered an error while loading an asset: Expected float ``` ## Solution Ideally, we should better handle the serialization of possibly-Dynamic types. However, this runs into issues where the `ReflectSerialize` expects the concrete type and not a Dynamic representation, resulting in a panic: https://github.com/bevyengine/bevy/blob/0aa4147af6d583c707863484d6a8ad50ed0ed984/crates/bevy_reflect/src/type_registry.rs#L402-L413 Since glam types are so heavily used in Bevy (specifically in `Transform` and `GlobalTransform`), it makes sense to just a quick fix in that enables them to be used properly in scenes while a proper solution is found. This PR simply removes all `ReflectSerialize` and `ReflectDeserialize` registrations from the glam types that are reflected as structs. --- ## Changelog - Remove `ReflectSerialize` and `ReflectDeserialize` registrations from most glam types ## Migration Guide This PR removes `ReflectSerialize` and `ReflectDeserialize` registrations from most glam types. This means any code relying on either of those type data existing for those glam types will need to not do that. This also means that some serialized glam types will need to be updated. For example, here is `Affine3A`: ```rust // BEFORE ( "glam::f32::affine3a::Affine3A": (1.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0), // AFTER "glam::f32::affine3a::Affine3A": ( matrix3: ( x_axis: ( x: 1.0, y: 0.0, z: 0.0, ), y_axis: ( x: 0.0, y: 1.0, z: 0.0, ), z_axis: ( x: 0.0, y: 0.0, z: 1.0, ), ), translation: ( x: 0.0, y: 0.0, z: 0.0, ), ) ) ```
cart
pushed a commit
that referenced
this issue
Nov 30, 2022
# Objective > Part of #6573 `Children` was not being properly deserialized in scenes. This was due to a missing registration on `SmallVec<[Entity; 8]>`, which is used by `Children`. ## Solution Register `SmallVec<[Entity; 8]>`. --- ## Changelog - Registered `SmallVec<[Entity; 8]>`
cart
pushed a commit
that referenced
this issue
Nov 30, 2022
…strations from most glam types (#6580) # Objective > Part of #6573 When serializing a `DynamicScene` we end up treating almost all non-value types as though their type data doesn't exist. This is because when creating the `DynamicScene` we call `Reflect::clone_value` on the components, which generates a Dynamic type for all non-value types. What this means is that the `glam` types are treated as though their `ReflectSerialize` registrations don't exist. However, the deserializer _does_ pick up the registration and attempts to use that instead. This results in the deserializer trying to operate on "malformed" data, causing this error: ``` WARN bevy_asset::asset_server: encountered an error while loading an asset: Expected float ``` ## Solution Ideally, we should better handle the serialization of possibly-Dynamic types. However, this runs into issues where the `ReflectSerialize` expects the concrete type and not a Dynamic representation, resulting in a panic: https://github.com/bevyengine/bevy/blob/0aa4147af6d583c707863484d6a8ad50ed0ed984/crates/bevy_reflect/src/type_registry.rs#L402-L413 Since glam types are so heavily used in Bevy (specifically in `Transform` and `GlobalTransform`), it makes sense to just a quick fix in that enables them to be used properly in scenes while a proper solution is found. This PR simply removes all `ReflectSerialize` and `ReflectDeserialize` registrations from the glam types that are reflected as structs. --- ## Changelog - Remove `ReflectSerialize` and `ReflectDeserialize` registrations from most glam types ## Migration Guide This PR removes `ReflectSerialize` and `ReflectDeserialize` registrations from most glam types. This means any code relying on either of those type data existing for those glam types will need to not do that. This also means that some serialized glam types will need to be updated. For example, here is `Affine3A`: ```rust // BEFORE ( "glam::f32::affine3a::Affine3A": (1.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0), // AFTER "glam::f32::affine3a::Affine3A": ( matrix3: ( x_axis: ( x: 1.0, y: 0.0, z: 0.0, ), y_axis: ( x: 0.0, y: 1.0, z: 0.0, ), z_axis: ( x: 0.0, y: 0.0, z: 1.0, ), ), translation: ( x: 0.0, y: 0.0, z: 0.0, ), ) ) ```
Repository owner
moved this from In Progress
to Done
in Reflection
Dec 3, 2022
ItsDoot
pushed a commit
to ItsDoot/bevy
that referenced
this issue
Feb 1, 2023
…yengine#6578) # Objective > Part of bevyengine#6573 `Children` was not being properly deserialized in scenes. This was due to a missing registration on `SmallVec<[Entity; 8]>`, which is used by `Children`. ## Solution Register `SmallVec<[Entity; 8]>`. --- ## Changelog - Registered `SmallVec<[Entity; 8]>`
ItsDoot
pushed a commit
to ItsDoot/bevy
that referenced
this issue
Feb 1, 2023
…strations from most glam types (bevyengine#6580) # Objective > Part of bevyengine#6573 When serializing a `DynamicScene` we end up treating almost all non-value types as though their type data doesn't exist. This is because when creating the `DynamicScene` we call `Reflect::clone_value` on the components, which generates a Dynamic type for all non-value types. What this means is that the `glam` types are treated as though their `ReflectSerialize` registrations don't exist. However, the deserializer _does_ pick up the registration and attempts to use that instead. This results in the deserializer trying to operate on "malformed" data, causing this error: ``` WARN bevy_asset::asset_server: encountered an error while loading an asset: Expected float ``` ## Solution Ideally, we should better handle the serialization of possibly-Dynamic types. However, this runs into issues where the `ReflectSerialize` expects the concrete type and not a Dynamic representation, resulting in a panic: https://github.com/bevyengine/bevy/blob/0aa4147af6d583c707863484d6a8ad50ed0ed984/crates/bevy_reflect/src/type_registry.rs#L402-L413 Since glam types are so heavily used in Bevy (specifically in `Transform` and `GlobalTransform`), it makes sense to just a quick fix in that enables them to be used properly in scenes while a proper solution is found. This PR simply removes all `ReflectSerialize` and `ReflectDeserialize` registrations from the glam types that are reflected as structs. --- ## Changelog - Remove `ReflectSerialize` and `ReflectDeserialize` registrations from most glam types ## Migration Guide This PR removes `ReflectSerialize` and `ReflectDeserialize` registrations from most glam types. This means any code relying on either of those type data existing for those glam types will need to not do that. This also means that some serialized glam types will need to be updated. For example, here is `Affine3A`: ```rust // BEFORE ( "glam::f32::affine3a::Affine3A": (1.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0), // AFTER "glam::f32::affine3a::Affine3A": ( matrix3: ( x_axis: ( x: 1.0, y: 0.0, z: 0.0, ), y_axis: ( x: 0.0, y: 1.0, z: 0.0, ), z_axis: ( x: 0.0, y: 0.0, z: 1.0, ), ), translation: ( x: 0.0, y: 0.0, z: 0.0, ), ) ) ```
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
A-Reflection
Runtime information about types
A-Scenes
Serialized ECS data stored on the disk
C-Bug
An unexpected or incorrect behavior
Bevy version
0.9.0
What you did
I attempted to save and load a scene
What went wrong
Scene does not load and logs a message to the console.
Additional information
Logs
When an entity is saved with a GlobalTransform component
When loading a scene with an entity that has children.
Removing both components from the ron file allows the scene to load. Obviously doing so might cause weird behaviors since entities don't have any of these components anymore.
The text was updated successfully, but these errors were encountered: