Skip to content
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

[Merged by Bors] - bevy_reflect: Remove ReflectSerialize and ReflectDeserialize registrations from most glam types #6580

Closed
wants to merge 1 commit into from

Conversation

MrGVSV
Copy link
Member

@MrGVSV MrGVSV commented Nov 13, 2022

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:

impl<T: Reflect + erased_serde::Serialize> FromType<T> for ReflectSerialize {
fn from_type() -> Self {
ReflectSerialize {
get_serializable: |value| {
let value = value.downcast_ref::<T>().unwrap_or_else(|| {
panic!("ReflectSerialize::get_serialize called with type `{}`, even though it was created for `{}`", value.type_name(), std::any::type_name::<T>())
});
Serializable::Borrowed(value)
},
}
}
}

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:

// 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,
    ),
  )
)

This only affects glam types that are treated as structs
@MrGVSV MrGVSV added C-Bug An unexpected or incorrect behavior A-Reflection Runtime information about types A-Scenes Serialized ECS data stored on the disk M-Needs-Migration-Guide A breaking change to Bevy's public API that needs to be noted in a migration guide labels Nov 13, 2022
@cart cart added this to the 0.9.1 milestone Nov 13, 2022
@TheRawMeatball
Copy link
Member

This feels like it might break semver... Are we sure it's OK to do in a patch release?

Copy link
Member

@alice-i-cecile alice-i-cecile left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we add more tests to catch this sort of issue better in the future?

@MrGVSV
Copy link
Member Author

MrGVSV commented Nov 23, 2022

Can we add more tests to catch this sort of issue better in the future?

Yes! I actually meant to create an issue for this but forgot lol. Basically we should probably have a more "real world" scene that contains usages of Transform, Visibility, and other common (or uncommon) components. I imagine we can create this in the repo's tests folder and ensure any changes to reflection/scenes doesn't break that test(s).

That should be its own PR, though.

@MrGVSV
Copy link
Member Author

MrGVSV commented Nov 23, 2022

This feels like it might break semver... Are we sure it's OK to do in a patch release?

I’m not sure what does or doesn't break semver tbh. Why might this be problematic? Isn't fixing an unintended behavior okay for a patch release?

@sQu1rr sQu1rr mentioned this pull request Nov 25, 2022
Copy link
Contributor

@PROMETHIA-27 PROMETHIA-27 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

Edit: And this doesn't break semver since we're pre-1.0. I know cargo doesn't care, but imo that's cargo's problem, not ours. And even if we overlook that, this changes a broken feature into a working one, which imo is worth it.

@alice-i-cecile alice-i-cecile added the S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it label Nov 25, 2022
@alice-i-cecile
Copy link
Member

bors r+

bors bot pushed a commit that referenced this pull request 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
Copy link
Contributor

bors bot commented Nov 25, 2022

Build failed:

@alice-i-cecile
Copy link
Member

bors retry

bors bot pushed a commit that referenced this pull request 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 bors bot changed the title bevy_reflect: Remove ReflectSerialize and ReflectDeserialize registrations from most glam types [Merged by Bors] - bevy_reflect: Remove ReflectSerialize and ReflectDeserialize registrations from most glam types Nov 25, 2022
@bors bors bot closed this Nov 25, 2022
archsolar pushed a commit to archsolar/bevy that referenced this pull request 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 pull request 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,
    ),
  )
)
```
ItsDoot pushed a commit to ItsDoot/bevy that referenced this pull request 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 M-Needs-Migration-Guide A breaking change to Bevy's public API that needs to be noted in a migration guide S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

5 participants