2022-10-12 01:48:16 +00:00
|
|
|
use crate::{DynamicEntity, DynamicScene};
|
(De) serialize resources in scenes (#6846)
# Objective
Co-Authored-By: davier
[bricedavier@gmail.com](mailto:bricedavier@gmail.com)
Fixes #3576.
Adds a `resources` field in scene serialization data to allow
de/serializing resources that have reflection enabled.
## Solution
Most of this code is taken from a previous closed PR:
https://github.com/bevyengine/bevy/pull/3580. Most of the credit goes to
@Davier , what I did was mostly getting it to work on the latest main
branch of Bevy, along with adding a few asserts in the currently
existing tests to be sure everything is working properly.
This PR changes the scene format to include resources in this way:
```
(
resources: {
// List of resources here, keyed by resource type name.
},
entities: [
// Previous scene format here
],
)
```
An example taken from the tests:
```
(
resources: {
"bevy_scene::serde::tests::MyResource": (
foo: 123,
),
},
entities: {
// Previous scene format here
},
)
```
For this, a `resources` fields has been added on the `DynamicScene` and
the `DynamicSceneBuilder` structs. The latter now also has a method
named `extract_resources` to properly extract the existing resources
registered in the local type registry, in a similar way to
`extract_entities`.
---
## Changelog
Added: Reflect resources registered in the type registry used by dynamic
scenes will now be properly de/serialized in scene data.
## Migration Guide
Since the scene format has been changed, the user may not be able to use
scenes saved prior to this PR due to the `resources` scene field being
missing. ~~To preserve backwards compatibility, I will try to make the
`resources` fully optional so that old scenes can be loaded without
issue.~~
## TODOs
- [x] I may have to update a few doc blocks still referring to dynamic
scenes as mere container of entities, since they now include resources
as well.
- [x] ~~I want to make the `resources` key optional, as specified in the
Migration Guide, so that old scenes will be compatible with this
change.~~ Since this would only be trivial for ron format, I think it
might be better to consider it in a separate PR/discussion to figure out
if it could be done for binary serialization too.
- [x] I suppose it might be a good idea to add a resources in the scene
example so that users will quickly notice they can serialize resources
just like entities.
---------
Co-authored-by: Carter Anderson <mcanders1@gmail.com>
2023-03-20 21:17:02 +00:00
|
|
|
use bevy_ecs::component::ComponentId;
|
|
|
|
use bevy_ecs::{
|
|
|
|
prelude::Entity,
|
2023-06-21 17:25:01 +00:00
|
|
|
reflect::{AppTypeRegistry, ReflectComponent, ReflectResource},
|
(De) serialize resources in scenes (#6846)
# Objective
Co-Authored-By: davier
[bricedavier@gmail.com](mailto:bricedavier@gmail.com)
Fixes #3576.
Adds a `resources` field in scene serialization data to allow
de/serializing resources that have reflection enabled.
## Solution
Most of this code is taken from a previous closed PR:
https://github.com/bevyengine/bevy/pull/3580. Most of the credit goes to
@Davier , what I did was mostly getting it to work on the latest main
branch of Bevy, along with adding a few asserts in the currently
existing tests to be sure everything is working properly.
This PR changes the scene format to include resources in this way:
```
(
resources: {
// List of resources here, keyed by resource type name.
},
entities: [
// Previous scene format here
],
)
```
An example taken from the tests:
```
(
resources: {
"bevy_scene::serde::tests::MyResource": (
foo: 123,
),
},
entities: {
// Previous scene format here
},
)
```
For this, a `resources` fields has been added on the `DynamicScene` and
the `DynamicSceneBuilder` structs. The latter now also has a method
named `extract_resources` to properly extract the existing resources
registered in the local type registry, in a similar way to
`extract_entities`.
---
## Changelog
Added: Reflect resources registered in the type registry used by dynamic
scenes will now be properly de/serialized in scene data.
## Migration Guide
Since the scene format has been changed, the user may not be able to use
scenes saved prior to this PR due to the `resources` scene field being
missing. ~~To preserve backwards compatibility, I will try to make the
`resources` fully optional so that old scenes can be loaded without
issue.~~
## TODOs
- [x] I may have to update a few doc blocks still referring to dynamic
scenes as mere container of entities, since they now include resources
as well.
- [x] ~~I want to make the `resources` key optional, as specified in the
Migration Guide, so that old scenes will be compatible with this
change.~~ Since this would only be trivial for ron format, I think it
might be better to consider it in a separate PR/discussion to figure out
if it could be done for binary serialization too.
- [x] I suppose it might be a good idea to add a resources in the scene
example so that users will quickly notice they can serialize resources
just like entities.
---------
Co-authored-by: Carter Anderson <mcanders1@gmail.com>
2023-03-20 21:17:02 +00:00
|
|
|
world::World,
|
|
|
|
};
|
|
|
|
use bevy_reflect::Reflect;
|
2022-10-27 23:38:03 +00:00
|
|
|
use bevy_utils::default;
|
|
|
|
use std::collections::BTreeMap;
|
2022-10-12 01:48:16 +00:00
|
|
|
|
(De) serialize resources in scenes (#6846)
# Objective
Co-Authored-By: davier
[bricedavier@gmail.com](mailto:bricedavier@gmail.com)
Fixes #3576.
Adds a `resources` field in scene serialization data to allow
de/serializing resources that have reflection enabled.
## Solution
Most of this code is taken from a previous closed PR:
https://github.com/bevyengine/bevy/pull/3580. Most of the credit goes to
@Davier , what I did was mostly getting it to work on the latest main
branch of Bevy, along with adding a few asserts in the currently
existing tests to be sure everything is working properly.
This PR changes the scene format to include resources in this way:
```
(
resources: {
// List of resources here, keyed by resource type name.
},
entities: [
// Previous scene format here
],
)
```
An example taken from the tests:
```
(
resources: {
"bevy_scene::serde::tests::MyResource": (
foo: 123,
),
},
entities: {
// Previous scene format here
},
)
```
For this, a `resources` fields has been added on the `DynamicScene` and
the `DynamicSceneBuilder` structs. The latter now also has a method
named `extract_resources` to properly extract the existing resources
registered in the local type registry, in a similar way to
`extract_entities`.
---
## Changelog
Added: Reflect resources registered in the type registry used by dynamic
scenes will now be properly de/serialized in scene data.
## Migration Guide
Since the scene format has been changed, the user may not be able to use
scenes saved prior to this PR due to the `resources` scene field being
missing. ~~To preserve backwards compatibility, I will try to make the
`resources` fully optional so that old scenes can be loaded without
issue.~~
## TODOs
- [x] I may have to update a few doc blocks still referring to dynamic
scenes as mere container of entities, since they now include resources
as well.
- [x] ~~I want to make the `resources` key optional, as specified in the
Migration Guide, so that old scenes will be compatible with this
change.~~ Since this would only be trivial for ron format, I think it
might be better to consider it in a separate PR/discussion to figure out
if it could be done for binary serialization too.
- [x] I suppose it might be a good idea to add a resources in the scene
example so that users will quickly notice they can serialize resources
just like entities.
---------
Co-authored-by: Carter Anderson <mcanders1@gmail.com>
2023-03-20 21:17:02 +00:00
|
|
|
/// A [`DynamicScene`] builder, used to build a scene from a [`World`] by extracting some entities and resources.
|
2022-10-12 01:48:16 +00:00
|
|
|
///
|
2022-10-27 23:38:03 +00:00
|
|
|
/// # Entity Order
|
|
|
|
///
|
2022-11-02 15:19:50 +00:00
|
|
|
/// Extracted entities will always be stored in ascending order based on their [id](Entity::index).
|
2022-10-27 23:38:03 +00:00
|
|
|
/// This means that inserting `Entity(1v0)` then `Entity(0v0)` will always result in the entities
|
|
|
|
/// being ordered as `[Entity(0v0), Entity(1v0)]`.
|
|
|
|
///
|
|
|
|
/// # Example
|
2022-10-12 01:48:16 +00:00
|
|
|
/// ```
|
|
|
|
/// # use bevy_scene::DynamicSceneBuilder;
|
2023-06-21 17:25:01 +00:00
|
|
|
/// # use bevy_ecs::reflect::AppTypeRegistry;
|
2022-10-12 01:48:16 +00:00
|
|
|
/// # use bevy_ecs::{
|
|
|
|
/// # component::Component, prelude::Entity, query::With, reflect::ReflectComponent, world::World,
|
|
|
|
/// # };
|
|
|
|
/// # use bevy_reflect::Reflect;
|
|
|
|
/// # #[derive(Component, Reflect, Default, Eq, PartialEq, Debug)]
|
|
|
|
/// # #[reflect(Component)]
|
|
|
|
/// # struct ComponentA;
|
|
|
|
/// # let mut world = World::default();
|
|
|
|
/// # world.init_resource::<AppTypeRegistry>();
|
|
|
|
/// # let entity = world.spawn(ComponentA).id();
|
|
|
|
/// let mut builder = DynamicSceneBuilder::from_world(&world);
|
|
|
|
/// builder.extract_entity(entity);
|
|
|
|
/// let dynamic_scene = builder.build();
|
|
|
|
/// ```
|
|
|
|
pub struct DynamicSceneBuilder<'w> {
|
(De) serialize resources in scenes (#6846)
# Objective
Co-Authored-By: davier
[bricedavier@gmail.com](mailto:bricedavier@gmail.com)
Fixes #3576.
Adds a `resources` field in scene serialization data to allow
de/serializing resources that have reflection enabled.
## Solution
Most of this code is taken from a previous closed PR:
https://github.com/bevyengine/bevy/pull/3580. Most of the credit goes to
@Davier , what I did was mostly getting it to work on the latest main
branch of Bevy, along with adding a few asserts in the currently
existing tests to be sure everything is working properly.
This PR changes the scene format to include resources in this way:
```
(
resources: {
// List of resources here, keyed by resource type name.
},
entities: [
// Previous scene format here
],
)
```
An example taken from the tests:
```
(
resources: {
"bevy_scene::serde::tests::MyResource": (
foo: 123,
),
},
entities: {
// Previous scene format here
},
)
```
For this, a `resources` fields has been added on the `DynamicScene` and
the `DynamicSceneBuilder` structs. The latter now also has a method
named `extract_resources` to properly extract the existing resources
registered in the local type registry, in a similar way to
`extract_entities`.
---
## Changelog
Added: Reflect resources registered in the type registry used by dynamic
scenes will now be properly de/serialized in scene data.
## Migration Guide
Since the scene format has been changed, the user may not be able to use
scenes saved prior to this PR due to the `resources` scene field being
missing. ~~To preserve backwards compatibility, I will try to make the
`resources` fully optional so that old scenes can be loaded without
issue.~~
## TODOs
- [x] I may have to update a few doc blocks still referring to dynamic
scenes as mere container of entities, since they now include resources
as well.
- [x] ~~I want to make the `resources` key optional, as specified in the
Migration Guide, so that old scenes will be compatible with this
change.~~ Since this would only be trivial for ron format, I think it
might be better to consider it in a separate PR/discussion to figure out
if it could be done for binary serialization too.
- [x] I suppose it might be a good idea to add a resources in the scene
example so that users will quickly notice they can serialize resources
just like entities.
---------
Co-authored-by: Carter Anderson <mcanders1@gmail.com>
2023-03-20 21:17:02 +00:00
|
|
|
extracted_resources: BTreeMap<ComponentId, Box<dyn Reflect>>,
|
Make scene handling of entity references robust (#7335)
# Objective
- Handle dangling entity references inside scenes
- Handle references to entities with generation > 0 inside scenes
- Fix a latent bug in `Parent`'s `MapEntities` implementation, which
would, if the parent was outside the scene, cause the scene to be loaded
into the new world with a parent reference potentially pointing to some
random entity in that new world.
- Fixes #4793 and addresses #7235
## Solution
- DynamicScenes now identify entities with a `Entity` instead of a u32,
therefore including generation
- `World` exposes a new `reserve_generations` function that despawns an
entity and advances its generation by some extra amount.
- `MapEntities` implementations have a new `get_or_reserve` function
available that will always return an `Entity`, establishing a new
mapping to a dead entity when the entity they are called with is not in
the `EntityMap`. Subsequent calls with that same `Entity` will return
the same newly created dead entity reference, preserving equality
semantics.
- As a result, after loading a scene containing references to dead
entities (or entities otherwise outside the scene), those references
will all point to different generations on a single entity id in the new
world.
---
## Changelog
### Changed
- In serialized scenes, entities are now identified by a u64 instead of
a u32.
- In serialized scenes, components with entity references now have those
references serialize as u64s instead of structs.
### Fixed
- Scenes containing components with entity references will now
deserialize and add to a world reliably.
## Migration Guide
- `MapEntities` implementations must change from a `&EntityMap`
parameter to a `&mut EntityMapper` parameter and can no longer return a
`Result`. Finally, they should switch from calling `EntityMap::get` to
calling `EntityMapper::get_or_reserve`.
---------
Co-authored-by: Nicola Papale <nicopap@users.noreply.github.com>
2023-05-01 15:49:27 +00:00
|
|
|
extracted_scene: BTreeMap<Entity, DynamicEntity>,
|
2022-10-12 01:48:16 +00:00
|
|
|
type_registry: AppTypeRegistry,
|
2022-12-20 16:16:58 +00:00
|
|
|
original_world: &'w World,
|
2022-10-12 01:48:16 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
impl<'w> DynamicSceneBuilder<'w> {
|
|
|
|
/// Prepare a builder that will extract entities and their component from the given [`World`].
|
|
|
|
/// All components registered in that world's [`AppTypeRegistry`] resource will be extracted.
|
|
|
|
pub fn from_world(world: &'w World) -> Self {
|
|
|
|
Self {
|
(De) serialize resources in scenes (#6846)
# Objective
Co-Authored-By: davier
[bricedavier@gmail.com](mailto:bricedavier@gmail.com)
Fixes #3576.
Adds a `resources` field in scene serialization data to allow
de/serializing resources that have reflection enabled.
## Solution
Most of this code is taken from a previous closed PR:
https://github.com/bevyengine/bevy/pull/3580. Most of the credit goes to
@Davier , what I did was mostly getting it to work on the latest main
branch of Bevy, along with adding a few asserts in the currently
existing tests to be sure everything is working properly.
This PR changes the scene format to include resources in this way:
```
(
resources: {
// List of resources here, keyed by resource type name.
},
entities: [
// Previous scene format here
],
)
```
An example taken from the tests:
```
(
resources: {
"bevy_scene::serde::tests::MyResource": (
foo: 123,
),
},
entities: {
// Previous scene format here
},
)
```
For this, a `resources` fields has been added on the `DynamicScene` and
the `DynamicSceneBuilder` structs. The latter now also has a method
named `extract_resources` to properly extract the existing resources
registered in the local type registry, in a similar way to
`extract_entities`.
---
## Changelog
Added: Reflect resources registered in the type registry used by dynamic
scenes will now be properly de/serialized in scene data.
## Migration Guide
Since the scene format has been changed, the user may not be able to use
scenes saved prior to this PR due to the `resources` scene field being
missing. ~~To preserve backwards compatibility, I will try to make the
`resources` fully optional so that old scenes can be loaded without
issue.~~
## TODOs
- [x] I may have to update a few doc blocks still referring to dynamic
scenes as mere container of entities, since they now include resources
as well.
- [x] ~~I want to make the `resources` key optional, as specified in the
Migration Guide, so that old scenes will be compatible with this
change.~~ Since this would only be trivial for ron format, I think it
might be better to consider it in a separate PR/discussion to figure out
if it could be done for binary serialization too.
- [x] I suppose it might be a good idea to add a resources in the scene
example so that users will quickly notice they can serialize resources
just like entities.
---------
Co-authored-by: Carter Anderson <mcanders1@gmail.com>
2023-03-20 21:17:02 +00:00
|
|
|
extracted_resources: default(),
|
2022-12-20 16:16:58 +00:00
|
|
|
extracted_scene: default(),
|
2022-10-12 01:48:16 +00:00
|
|
|
type_registry: world.resource::<AppTypeRegistry>().clone(),
|
2022-12-20 16:16:58 +00:00
|
|
|
original_world: world,
|
2022-10-12 01:48:16 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Prepare a builder that will extract entities and their component from the given [`World`].
|
|
|
|
/// Only components registered in the given [`AppTypeRegistry`] will be extracted.
|
|
|
|
pub fn from_world_with_type_registry(world: &'w World, type_registry: AppTypeRegistry) -> Self {
|
|
|
|
Self {
|
(De) serialize resources in scenes (#6846)
# Objective
Co-Authored-By: davier
[bricedavier@gmail.com](mailto:bricedavier@gmail.com)
Fixes #3576.
Adds a `resources` field in scene serialization data to allow
de/serializing resources that have reflection enabled.
## Solution
Most of this code is taken from a previous closed PR:
https://github.com/bevyengine/bevy/pull/3580. Most of the credit goes to
@Davier , what I did was mostly getting it to work on the latest main
branch of Bevy, along with adding a few asserts in the currently
existing tests to be sure everything is working properly.
This PR changes the scene format to include resources in this way:
```
(
resources: {
// List of resources here, keyed by resource type name.
},
entities: [
// Previous scene format here
],
)
```
An example taken from the tests:
```
(
resources: {
"bevy_scene::serde::tests::MyResource": (
foo: 123,
),
},
entities: {
// Previous scene format here
},
)
```
For this, a `resources` fields has been added on the `DynamicScene` and
the `DynamicSceneBuilder` structs. The latter now also has a method
named `extract_resources` to properly extract the existing resources
registered in the local type registry, in a similar way to
`extract_entities`.
---
## Changelog
Added: Reflect resources registered in the type registry used by dynamic
scenes will now be properly de/serialized in scene data.
## Migration Guide
Since the scene format has been changed, the user may not be able to use
scenes saved prior to this PR due to the `resources` scene field being
missing. ~~To preserve backwards compatibility, I will try to make the
`resources` fully optional so that old scenes can be loaded without
issue.~~
## TODOs
- [x] I may have to update a few doc blocks still referring to dynamic
scenes as mere container of entities, since they now include resources
as well.
- [x] ~~I want to make the `resources` key optional, as specified in the
Migration Guide, so that old scenes will be compatible with this
change.~~ Since this would only be trivial for ron format, I think it
might be better to consider it in a separate PR/discussion to figure out
if it could be done for binary serialization too.
- [x] I suppose it might be a good idea to add a resources in the scene
example so that users will quickly notice they can serialize resources
just like entities.
---------
Co-authored-by: Carter Anderson <mcanders1@gmail.com>
2023-03-20 21:17:02 +00:00
|
|
|
extracted_resources: default(),
|
2022-12-20 16:16:58 +00:00
|
|
|
extracted_scene: default(),
|
2022-10-12 01:48:16 +00:00
|
|
|
type_registry,
|
2022-12-20 16:16:58 +00:00
|
|
|
original_world: world,
|
2022-10-12 01:48:16 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Consume the builder, producing a [`DynamicScene`].
|
2022-12-20 16:16:58 +00:00
|
|
|
///
|
|
|
|
/// To make sure the dynamic scene doesn't contain entities without any components, call
|
|
|
|
/// [`Self::remove_empty_entities`] before building the scene.
|
2022-10-12 01:48:16 +00:00
|
|
|
pub fn build(self) -> DynamicScene {
|
|
|
|
DynamicScene {
|
(De) serialize resources in scenes (#6846)
# Objective
Co-Authored-By: davier
[bricedavier@gmail.com](mailto:bricedavier@gmail.com)
Fixes #3576.
Adds a `resources` field in scene serialization data to allow
de/serializing resources that have reflection enabled.
## Solution
Most of this code is taken from a previous closed PR:
https://github.com/bevyengine/bevy/pull/3580. Most of the credit goes to
@Davier , what I did was mostly getting it to work on the latest main
branch of Bevy, along with adding a few asserts in the currently
existing tests to be sure everything is working properly.
This PR changes the scene format to include resources in this way:
```
(
resources: {
// List of resources here, keyed by resource type name.
},
entities: [
// Previous scene format here
],
)
```
An example taken from the tests:
```
(
resources: {
"bevy_scene::serde::tests::MyResource": (
foo: 123,
),
},
entities: {
// Previous scene format here
},
)
```
For this, a `resources` fields has been added on the `DynamicScene` and
the `DynamicSceneBuilder` structs. The latter now also has a method
named `extract_resources` to properly extract the existing resources
registered in the local type registry, in a similar way to
`extract_entities`.
---
## Changelog
Added: Reflect resources registered in the type registry used by dynamic
scenes will now be properly de/serialized in scene data.
## Migration Guide
Since the scene format has been changed, the user may not be able to use
scenes saved prior to this PR due to the `resources` scene field being
missing. ~~To preserve backwards compatibility, I will try to make the
`resources` fully optional so that old scenes can be loaded without
issue.~~
## TODOs
- [x] I may have to update a few doc blocks still referring to dynamic
scenes as mere container of entities, since they now include resources
as well.
- [x] ~~I want to make the `resources` key optional, as specified in the
Migration Guide, so that old scenes will be compatible with this
change.~~ Since this would only be trivial for ron format, I think it
might be better to consider it in a separate PR/discussion to figure out
if it could be done for binary serialization too.
- [x] I suppose it might be a good idea to add a resources in the scene
example so that users will quickly notice they can serialize resources
just like entities.
---------
Co-authored-by: Carter Anderson <mcanders1@gmail.com>
2023-03-20 21:17:02 +00:00
|
|
|
resources: self.extracted_resources.into_values().collect(),
|
2022-12-20 16:16:58 +00:00
|
|
|
entities: self.extracted_scene.into_values().collect(),
|
2022-10-12 01:48:16 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Extract one entity from the builder's [`World`].
|
|
|
|
///
|
|
|
|
/// Re-extracting an entity that was already extracted will have no effect.
|
|
|
|
pub fn extract_entity(&mut self, entity: Entity) -> &mut Self {
|
|
|
|
self.extract_entities(std::iter::once(entity))
|
|
|
|
}
|
|
|
|
|
2023-01-06 00:43:30 +00:00
|
|
|
/// Despawns all entities with no components.
|
2022-12-20 16:16:58 +00:00
|
|
|
///
|
|
|
|
/// These were likely created because none of their components were present in the provided type registry upon extraction.
|
|
|
|
pub fn remove_empty_entities(&mut self) -> &mut Self {
|
|
|
|
self.extracted_scene
|
|
|
|
.retain(|_, entity| !entity.components.is_empty());
|
|
|
|
|
|
|
|
self
|
|
|
|
}
|
|
|
|
|
2022-10-12 01:48:16 +00:00
|
|
|
/// Extract entities from the builder's [`World`].
|
|
|
|
///
|
|
|
|
/// Re-extracting an entity that was already extracted will have no effect.
|
|
|
|
///
|
|
|
|
/// Extracting entities can be used to extract entities from a query:
|
|
|
|
/// ```
|
|
|
|
/// # use bevy_scene::DynamicSceneBuilder;
|
2023-06-21 17:25:01 +00:00
|
|
|
/// # use bevy_ecs::reflect::AppTypeRegistry;
|
2022-10-12 01:48:16 +00:00
|
|
|
/// # use bevy_ecs::{
|
|
|
|
/// # component::Component, prelude::Entity, query::With, reflect::ReflectComponent, world::World,
|
|
|
|
/// # };
|
|
|
|
/// # use bevy_reflect::Reflect;
|
|
|
|
/// #[derive(Component, Default, Reflect)]
|
|
|
|
/// #[reflect(Component)]
|
|
|
|
/// struct MyComponent;
|
|
|
|
///
|
|
|
|
/// # let mut world = World::default();
|
|
|
|
/// # world.init_resource::<AppTypeRegistry>();
|
|
|
|
/// # let _entity = world.spawn(MyComponent).id();
|
|
|
|
/// let mut query = world.query_filtered::<Entity, With<MyComponent>>();
|
|
|
|
///
|
|
|
|
/// let mut builder = DynamicSceneBuilder::from_world(&world);
|
|
|
|
/// builder.extract_entities(query.iter(&world));
|
|
|
|
/// let scene = builder.build();
|
|
|
|
/// ```
|
|
|
|
pub fn extract_entities(&mut self, entities: impl Iterator<Item = Entity>) -> &mut Self {
|
|
|
|
let type_registry = self.type_registry.read();
|
|
|
|
|
|
|
|
for entity in entities {
|
Make scene handling of entity references robust (#7335)
# Objective
- Handle dangling entity references inside scenes
- Handle references to entities with generation > 0 inside scenes
- Fix a latent bug in `Parent`'s `MapEntities` implementation, which
would, if the parent was outside the scene, cause the scene to be loaded
into the new world with a parent reference potentially pointing to some
random entity in that new world.
- Fixes #4793 and addresses #7235
## Solution
- DynamicScenes now identify entities with a `Entity` instead of a u32,
therefore including generation
- `World` exposes a new `reserve_generations` function that despawns an
entity and advances its generation by some extra amount.
- `MapEntities` implementations have a new `get_or_reserve` function
available that will always return an `Entity`, establishing a new
mapping to a dead entity when the entity they are called with is not in
the `EntityMap`. Subsequent calls with that same `Entity` will return
the same newly created dead entity reference, preserving equality
semantics.
- As a result, after loading a scene containing references to dead
entities (or entities otherwise outside the scene), those references
will all point to different generations on a single entity id in the new
world.
---
## Changelog
### Changed
- In serialized scenes, entities are now identified by a u64 instead of
a u32.
- In serialized scenes, components with entity references now have those
references serialize as u64s instead of structs.
### Fixed
- Scenes containing components with entity references will now
deserialize and add to a world reliably.
## Migration Guide
- `MapEntities` implementations must change from a `&EntityMap`
parameter to a `&mut EntityMapper` parameter and can no longer return a
`Result`. Finally, they should switch from calling `EntityMap::get` to
calling `EntityMapper::get_or_reserve`.
---------
Co-authored-by: Nicola Papale <nicopap@users.noreply.github.com>
2023-05-01 15:49:27 +00:00
|
|
|
if self.extracted_scene.contains_key(&entity) {
|
2022-10-12 01:48:16 +00:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
let mut entry = DynamicEntity {
|
Make scene handling of entity references robust (#7335)
# Objective
- Handle dangling entity references inside scenes
- Handle references to entities with generation > 0 inside scenes
- Fix a latent bug in `Parent`'s `MapEntities` implementation, which
would, if the parent was outside the scene, cause the scene to be loaded
into the new world with a parent reference potentially pointing to some
random entity in that new world.
- Fixes #4793 and addresses #7235
## Solution
- DynamicScenes now identify entities with a `Entity` instead of a u32,
therefore including generation
- `World` exposes a new `reserve_generations` function that despawns an
entity and advances its generation by some extra amount.
- `MapEntities` implementations have a new `get_or_reserve` function
available that will always return an `Entity`, establishing a new
mapping to a dead entity when the entity they are called with is not in
the `EntityMap`. Subsequent calls with that same `Entity` will return
the same newly created dead entity reference, preserving equality
semantics.
- As a result, after loading a scene containing references to dead
entities (or entities otherwise outside the scene), those references
will all point to different generations on a single entity id in the new
world.
---
## Changelog
### Changed
- In serialized scenes, entities are now identified by a u64 instead of
a u32.
- In serialized scenes, components with entity references now have those
references serialize as u64s instead of structs.
### Fixed
- Scenes containing components with entity references will now
deserialize and add to a world reliably.
## Migration Guide
- `MapEntities` implementations must change from a `&EntityMap`
parameter to a `&mut EntityMapper` parameter and can no longer return a
`Result`. Finally, they should switch from calling `EntityMap::get` to
calling `EntityMapper::get_or_reserve`.
---------
Co-authored-by: Nicola Papale <nicopap@users.noreply.github.com>
2023-05-01 15:49:27 +00:00
|
|
|
entity,
|
2022-10-12 01:48:16 +00:00
|
|
|
components: Vec::new(),
|
|
|
|
};
|
|
|
|
|
Make scene handling of entity references robust (#7335)
# Objective
- Handle dangling entity references inside scenes
- Handle references to entities with generation > 0 inside scenes
- Fix a latent bug in `Parent`'s `MapEntities` implementation, which
would, if the parent was outside the scene, cause the scene to be loaded
into the new world with a parent reference potentially pointing to some
random entity in that new world.
- Fixes #4793 and addresses #7235
## Solution
- DynamicScenes now identify entities with a `Entity` instead of a u32,
therefore including generation
- `World` exposes a new `reserve_generations` function that despawns an
entity and advances its generation by some extra amount.
- `MapEntities` implementations have a new `get_or_reserve` function
available that will always return an `Entity`, establishing a new
mapping to a dead entity when the entity they are called with is not in
the `EntityMap`. Subsequent calls with that same `Entity` will return
the same newly created dead entity reference, preserving equality
semantics.
- As a result, after loading a scene containing references to dead
entities (or entities otherwise outside the scene), those references
will all point to different generations on a single entity id in the new
world.
---
## Changelog
### Changed
- In serialized scenes, entities are now identified by a u64 instead of
a u32.
- In serialized scenes, components with entity references now have those
references serialize as u64s instead of structs.
### Fixed
- Scenes containing components with entity references will now
deserialize and add to a world reliably.
## Migration Guide
- `MapEntities` implementations must change from a `&EntityMap`
parameter to a `&mut EntityMapper` parameter and can no longer return a
`Result`. Finally, they should switch from calling `EntityMap::get` to
calling `EntityMapper::get_or_reserve`.
---------
Co-authored-by: Nicola Papale <nicopap@users.noreply.github.com>
2023-05-01 15:49:27 +00:00
|
|
|
let original_entity = self.original_world.entity(entity);
|
|
|
|
for component_id in original_entity.archetype().components() {
|
(De) serialize resources in scenes (#6846)
# Objective
Co-Authored-By: davier
[bricedavier@gmail.com](mailto:bricedavier@gmail.com)
Fixes #3576.
Adds a `resources` field in scene serialization data to allow
de/serializing resources that have reflection enabled.
## Solution
Most of this code is taken from a previous closed PR:
https://github.com/bevyengine/bevy/pull/3580. Most of the credit goes to
@Davier , what I did was mostly getting it to work on the latest main
branch of Bevy, along with adding a few asserts in the currently
existing tests to be sure everything is working properly.
This PR changes the scene format to include resources in this way:
```
(
resources: {
// List of resources here, keyed by resource type name.
},
entities: [
// Previous scene format here
],
)
```
An example taken from the tests:
```
(
resources: {
"bevy_scene::serde::tests::MyResource": (
foo: 123,
),
},
entities: {
// Previous scene format here
},
)
```
For this, a `resources` fields has been added on the `DynamicScene` and
the `DynamicSceneBuilder` structs. The latter now also has a method
named `extract_resources` to properly extract the existing resources
registered in the local type registry, in a similar way to
`extract_entities`.
---
## Changelog
Added: Reflect resources registered in the type registry used by dynamic
scenes will now be properly de/serialized in scene data.
## Migration Guide
Since the scene format has been changed, the user may not be able to use
scenes saved prior to this PR due to the `resources` scene field being
missing. ~~To preserve backwards compatibility, I will try to make the
`resources` fully optional so that old scenes can be loaded without
issue.~~
## TODOs
- [x] I may have to update a few doc blocks still referring to dynamic
scenes as mere container of entities, since they now include resources
as well.
- [x] ~~I want to make the `resources` key optional, as specified in the
Migration Guide, so that old scenes will be compatible with this
change.~~ Since this would only be trivial for ron format, I think it
might be better to consider it in a separate PR/discussion to figure out
if it could be done for binary serialization too.
- [x] I suppose it might be a good idea to add a resources in the scene
example so that users will quickly notice they can serialize resources
just like entities.
---------
Co-authored-by: Carter Anderson <mcanders1@gmail.com>
2023-03-20 21:17:02 +00:00
|
|
|
let mut extract_and_push = || {
|
|
|
|
let type_id = self
|
|
|
|
.original_world
|
|
|
|
.components()
|
|
|
|
.get_info(component_id)?
|
|
|
|
.type_id()?;
|
|
|
|
let component = type_registry
|
|
|
|
.get(type_id)?
|
|
|
|
.data::<ReflectComponent>()?
|
Make scene handling of entity references robust (#7335)
# Objective
- Handle dangling entity references inside scenes
- Handle references to entities with generation > 0 inside scenes
- Fix a latent bug in `Parent`'s `MapEntities` implementation, which
would, if the parent was outside the scene, cause the scene to be loaded
into the new world with a parent reference potentially pointing to some
random entity in that new world.
- Fixes #4793 and addresses #7235
## Solution
- DynamicScenes now identify entities with a `Entity` instead of a u32,
therefore including generation
- `World` exposes a new `reserve_generations` function that despawns an
entity and advances its generation by some extra amount.
- `MapEntities` implementations have a new `get_or_reserve` function
available that will always return an `Entity`, establishing a new
mapping to a dead entity when the entity they are called with is not in
the `EntityMap`. Subsequent calls with that same `Entity` will return
the same newly created dead entity reference, preserving equality
semantics.
- As a result, after loading a scene containing references to dead
entities (or entities otherwise outside the scene), those references
will all point to different generations on a single entity id in the new
world.
---
## Changelog
### Changed
- In serialized scenes, entities are now identified by a u64 instead of
a u32.
- In serialized scenes, components with entity references now have those
references serialize as u64s instead of structs.
### Fixed
- Scenes containing components with entity references will now
deserialize and add to a world reliably.
## Migration Guide
- `MapEntities` implementations must change from a `&EntityMap`
parameter to a `&mut EntityMapper` parameter and can no longer return a
`Result`. Finally, they should switch from calling `EntityMap::get` to
calling `EntityMapper::get_or_reserve`.
---------
Co-authored-by: Nicola Papale <nicopap@users.noreply.github.com>
2023-05-01 15:49:27 +00:00
|
|
|
.reflect(original_entity)?;
|
(De) serialize resources in scenes (#6846)
# Objective
Co-Authored-By: davier
[bricedavier@gmail.com](mailto:bricedavier@gmail.com)
Fixes #3576.
Adds a `resources` field in scene serialization data to allow
de/serializing resources that have reflection enabled.
## Solution
Most of this code is taken from a previous closed PR:
https://github.com/bevyengine/bevy/pull/3580. Most of the credit goes to
@Davier , what I did was mostly getting it to work on the latest main
branch of Bevy, along with adding a few asserts in the currently
existing tests to be sure everything is working properly.
This PR changes the scene format to include resources in this way:
```
(
resources: {
// List of resources here, keyed by resource type name.
},
entities: [
// Previous scene format here
],
)
```
An example taken from the tests:
```
(
resources: {
"bevy_scene::serde::tests::MyResource": (
foo: 123,
),
},
entities: {
// Previous scene format here
},
)
```
For this, a `resources` fields has been added on the `DynamicScene` and
the `DynamicSceneBuilder` structs. The latter now also has a method
named `extract_resources` to properly extract the existing resources
registered in the local type registry, in a similar way to
`extract_entities`.
---
## Changelog
Added: Reflect resources registered in the type registry used by dynamic
scenes will now be properly de/serialized in scene data.
## Migration Guide
Since the scene format has been changed, the user may not be able to use
scenes saved prior to this PR due to the `resources` scene field being
missing. ~~To preserve backwards compatibility, I will try to make the
`resources` fully optional so that old scenes can be loaded without
issue.~~
## TODOs
- [x] I may have to update a few doc blocks still referring to dynamic
scenes as mere container of entities, since they now include resources
as well.
- [x] ~~I want to make the `resources` key optional, as specified in the
Migration Guide, so that old scenes will be compatible with this
change.~~ Since this would only be trivial for ron format, I think it
might be better to consider it in a separate PR/discussion to figure out
if it could be done for binary serialization too.
- [x] I suppose it might be a good idea to add a resources in the scene
example so that users will quickly notice they can serialize resources
just like entities.
---------
Co-authored-by: Carter Anderson <mcanders1@gmail.com>
2023-03-20 21:17:02 +00:00
|
|
|
entry.components.push(component.clone_value());
|
|
|
|
Some(())
|
|
|
|
};
|
|
|
|
extract_and_push();
|
2022-10-12 01:48:16 +00:00
|
|
|
}
|
Make scene handling of entity references robust (#7335)
# Objective
- Handle dangling entity references inside scenes
- Handle references to entities with generation > 0 inside scenes
- Fix a latent bug in `Parent`'s `MapEntities` implementation, which
would, if the parent was outside the scene, cause the scene to be loaded
into the new world with a parent reference potentially pointing to some
random entity in that new world.
- Fixes #4793 and addresses #7235
## Solution
- DynamicScenes now identify entities with a `Entity` instead of a u32,
therefore including generation
- `World` exposes a new `reserve_generations` function that despawns an
entity and advances its generation by some extra amount.
- `MapEntities` implementations have a new `get_or_reserve` function
available that will always return an `Entity`, establishing a new
mapping to a dead entity when the entity they are called with is not in
the `EntityMap`. Subsequent calls with that same `Entity` will return
the same newly created dead entity reference, preserving equality
semantics.
- As a result, after loading a scene containing references to dead
entities (or entities otherwise outside the scene), those references
will all point to different generations on a single entity id in the new
world.
---
## Changelog
### Changed
- In serialized scenes, entities are now identified by a u64 instead of
a u32.
- In serialized scenes, components with entity references now have those
references serialize as u64s instead of structs.
### Fixed
- Scenes containing components with entity references will now
deserialize and add to a world reliably.
## Migration Guide
- `MapEntities` implementations must change from a `&EntityMap`
parameter to a `&mut EntityMapper` parameter and can no longer return a
`Result`. Finally, they should switch from calling `EntityMap::get` to
calling `EntityMapper::get_or_reserve`.
---------
Co-authored-by: Nicola Papale <nicopap@users.noreply.github.com>
2023-05-01 15:49:27 +00:00
|
|
|
self.extracted_scene.insert(entity, entry);
|
2022-10-12 01:48:16 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
drop(type_registry);
|
|
|
|
self
|
|
|
|
}
|
(De) serialize resources in scenes (#6846)
# Objective
Co-Authored-By: davier
[bricedavier@gmail.com](mailto:bricedavier@gmail.com)
Fixes #3576.
Adds a `resources` field in scene serialization data to allow
de/serializing resources that have reflection enabled.
## Solution
Most of this code is taken from a previous closed PR:
https://github.com/bevyengine/bevy/pull/3580. Most of the credit goes to
@Davier , what I did was mostly getting it to work on the latest main
branch of Bevy, along with adding a few asserts in the currently
existing tests to be sure everything is working properly.
This PR changes the scene format to include resources in this way:
```
(
resources: {
// List of resources here, keyed by resource type name.
},
entities: [
// Previous scene format here
],
)
```
An example taken from the tests:
```
(
resources: {
"bevy_scene::serde::tests::MyResource": (
foo: 123,
),
},
entities: {
// Previous scene format here
},
)
```
For this, a `resources` fields has been added on the `DynamicScene` and
the `DynamicSceneBuilder` structs. The latter now also has a method
named `extract_resources` to properly extract the existing resources
registered in the local type registry, in a similar way to
`extract_entities`.
---
## Changelog
Added: Reflect resources registered in the type registry used by dynamic
scenes will now be properly de/serialized in scene data.
## Migration Guide
Since the scene format has been changed, the user may not be able to use
scenes saved prior to this PR due to the `resources` scene field being
missing. ~~To preserve backwards compatibility, I will try to make the
`resources` fully optional so that old scenes can be loaded without
issue.~~
## TODOs
- [x] I may have to update a few doc blocks still referring to dynamic
scenes as mere container of entities, since they now include resources
as well.
- [x] ~~I want to make the `resources` key optional, as specified in the
Migration Guide, so that old scenes will be compatible with this
change.~~ Since this would only be trivial for ron format, I think it
might be better to consider it in a separate PR/discussion to figure out
if it could be done for binary serialization too.
- [x] I suppose it might be a good idea to add a resources in the scene
example so that users will quickly notice they can serialize resources
just like entities.
---------
Co-authored-by: Carter Anderson <mcanders1@gmail.com>
2023-03-20 21:17:02 +00:00
|
|
|
|
|
|
|
/// Extract resources from the builder's [`World`].
|
|
|
|
///
|
|
|
|
/// Only resources registered in the builder's [`AppTypeRegistry`] will be extracted.
|
|
|
|
/// Re-extracting a resource that was already extracted will have no effect.
|
|
|
|
/// ```
|
|
|
|
/// # use bevy_scene::DynamicSceneBuilder;
|
2023-06-21 17:25:01 +00:00
|
|
|
/// # use bevy_ecs::reflect::AppTypeRegistry;
|
(De) serialize resources in scenes (#6846)
# Objective
Co-Authored-By: davier
[bricedavier@gmail.com](mailto:bricedavier@gmail.com)
Fixes #3576.
Adds a `resources` field in scene serialization data to allow
de/serializing resources that have reflection enabled.
## Solution
Most of this code is taken from a previous closed PR:
https://github.com/bevyengine/bevy/pull/3580. Most of the credit goes to
@Davier , what I did was mostly getting it to work on the latest main
branch of Bevy, along with adding a few asserts in the currently
existing tests to be sure everything is working properly.
This PR changes the scene format to include resources in this way:
```
(
resources: {
// List of resources here, keyed by resource type name.
},
entities: [
// Previous scene format here
],
)
```
An example taken from the tests:
```
(
resources: {
"bevy_scene::serde::tests::MyResource": (
foo: 123,
),
},
entities: {
// Previous scene format here
},
)
```
For this, a `resources` fields has been added on the `DynamicScene` and
the `DynamicSceneBuilder` structs. The latter now also has a method
named `extract_resources` to properly extract the existing resources
registered in the local type registry, in a similar way to
`extract_entities`.
---
## Changelog
Added: Reflect resources registered in the type registry used by dynamic
scenes will now be properly de/serialized in scene data.
## Migration Guide
Since the scene format has been changed, the user may not be able to use
scenes saved prior to this PR due to the `resources` scene field being
missing. ~~To preserve backwards compatibility, I will try to make the
`resources` fully optional so that old scenes can be loaded without
issue.~~
## TODOs
- [x] I may have to update a few doc blocks still referring to dynamic
scenes as mere container of entities, since they now include resources
as well.
- [x] ~~I want to make the `resources` key optional, as specified in the
Migration Guide, so that old scenes will be compatible with this
change.~~ Since this would only be trivial for ron format, I think it
might be better to consider it in a separate PR/discussion to figure out
if it could be done for binary serialization too.
- [x] I suppose it might be a good idea to add a resources in the scene
example so that users will quickly notice they can serialize resources
just like entities.
---------
Co-authored-by: Carter Anderson <mcanders1@gmail.com>
2023-03-20 21:17:02 +00:00
|
|
|
/// # use bevy_ecs::prelude::{ReflectResource, Resource, World};
|
|
|
|
/// # use bevy_reflect::Reflect;
|
|
|
|
/// #[derive(Resource, Default, Reflect)]
|
|
|
|
/// #[reflect(Resource)]
|
|
|
|
/// struct MyResource;
|
|
|
|
///
|
|
|
|
/// # let mut world = World::default();
|
|
|
|
/// # world.init_resource::<AppTypeRegistry>();
|
|
|
|
/// world.insert_resource(MyResource);
|
|
|
|
///
|
|
|
|
/// let mut builder = DynamicSceneBuilder::from_world(&world);
|
|
|
|
/// builder.extract_resources();
|
|
|
|
/// let scene = builder.build();
|
|
|
|
/// ```
|
|
|
|
pub fn extract_resources(&mut self) -> &mut Self {
|
|
|
|
let type_registry = self.type_registry.read();
|
|
|
|
for (component_id, _) in self.original_world.storages().resources.iter() {
|
|
|
|
let mut extract_and_push = || {
|
|
|
|
let type_id = self
|
|
|
|
.original_world
|
|
|
|
.components()
|
|
|
|
.get_info(component_id)?
|
|
|
|
.type_id()?;
|
|
|
|
let resource = type_registry
|
|
|
|
.get(type_id)?
|
|
|
|
.data::<ReflectResource>()?
|
|
|
|
.reflect(self.original_world)?;
|
|
|
|
self.extracted_resources
|
|
|
|
.insert(component_id, resource.clone_value());
|
|
|
|
Some(())
|
|
|
|
};
|
|
|
|
extract_and_push();
|
|
|
|
}
|
|
|
|
|
|
|
|
drop(type_registry);
|
|
|
|
self
|
|
|
|
}
|
2022-10-12 01:48:16 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
#[cfg(test)]
|
|
|
|
mod tests {
|
|
|
|
use bevy_ecs::{
|
(De) serialize resources in scenes (#6846)
# Objective
Co-Authored-By: davier
[bricedavier@gmail.com](mailto:bricedavier@gmail.com)
Fixes #3576.
Adds a `resources` field in scene serialization data to allow
de/serializing resources that have reflection enabled.
## Solution
Most of this code is taken from a previous closed PR:
https://github.com/bevyengine/bevy/pull/3580. Most of the credit goes to
@Davier , what I did was mostly getting it to work on the latest main
branch of Bevy, along with adding a few asserts in the currently
existing tests to be sure everything is working properly.
This PR changes the scene format to include resources in this way:
```
(
resources: {
// List of resources here, keyed by resource type name.
},
entities: [
// Previous scene format here
],
)
```
An example taken from the tests:
```
(
resources: {
"bevy_scene::serde::tests::MyResource": (
foo: 123,
),
},
entities: {
// Previous scene format here
},
)
```
For this, a `resources` fields has been added on the `DynamicScene` and
the `DynamicSceneBuilder` structs. The latter now also has a method
named `extract_resources` to properly extract the existing resources
registered in the local type registry, in a similar way to
`extract_entities`.
---
## Changelog
Added: Reflect resources registered in the type registry used by dynamic
scenes will now be properly de/serialized in scene data.
## Migration Guide
Since the scene format has been changed, the user may not be able to use
scenes saved prior to this PR due to the `resources` scene field being
missing. ~~To preserve backwards compatibility, I will try to make the
`resources` fully optional so that old scenes can be loaded without
issue.~~
## TODOs
- [x] I may have to update a few doc blocks still referring to dynamic
scenes as mere container of entities, since they now include resources
as well.
- [x] ~~I want to make the `resources` key optional, as specified in the
Migration Guide, so that old scenes will be compatible with this
change.~~ Since this would only be trivial for ron format, I think it
might be better to consider it in a separate PR/discussion to figure out
if it could be done for binary serialization too.
- [x] I suppose it might be a good idea to add a resources in the scene
example so that users will quickly notice they can serialize resources
just like entities.
---------
Co-authored-by: Carter Anderson <mcanders1@gmail.com>
2023-03-20 21:17:02 +00:00
|
|
|
component::Component, prelude::Entity, prelude::Resource, query::With,
|
2023-06-21 17:25:01 +00:00
|
|
|
reflect::AppTypeRegistry, reflect::ReflectComponent, reflect::ReflectResource,
|
|
|
|
world::World,
|
2022-10-12 01:48:16 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
use bevy_reflect::Reflect;
|
|
|
|
|
|
|
|
use super::DynamicSceneBuilder;
|
|
|
|
|
|
|
|
#[derive(Component, Reflect, Default, Eq, PartialEq, Debug)]
|
|
|
|
#[reflect(Component)]
|
|
|
|
struct ComponentA;
|
(De) serialize resources in scenes (#6846)
# Objective
Co-Authored-By: davier
[bricedavier@gmail.com](mailto:bricedavier@gmail.com)
Fixes #3576.
Adds a `resources` field in scene serialization data to allow
de/serializing resources that have reflection enabled.
## Solution
Most of this code is taken from a previous closed PR:
https://github.com/bevyengine/bevy/pull/3580. Most of the credit goes to
@Davier , what I did was mostly getting it to work on the latest main
branch of Bevy, along with adding a few asserts in the currently
existing tests to be sure everything is working properly.
This PR changes the scene format to include resources in this way:
```
(
resources: {
// List of resources here, keyed by resource type name.
},
entities: [
// Previous scene format here
],
)
```
An example taken from the tests:
```
(
resources: {
"bevy_scene::serde::tests::MyResource": (
foo: 123,
),
},
entities: {
// Previous scene format here
},
)
```
For this, a `resources` fields has been added on the `DynamicScene` and
the `DynamicSceneBuilder` structs. The latter now also has a method
named `extract_resources` to properly extract the existing resources
registered in the local type registry, in a similar way to
`extract_entities`.
---
## Changelog
Added: Reflect resources registered in the type registry used by dynamic
scenes will now be properly de/serialized in scene data.
## Migration Guide
Since the scene format has been changed, the user may not be able to use
scenes saved prior to this PR due to the `resources` scene field being
missing. ~~To preserve backwards compatibility, I will try to make the
`resources` fully optional so that old scenes can be loaded without
issue.~~
## TODOs
- [x] I may have to update a few doc blocks still referring to dynamic
scenes as mere container of entities, since they now include resources
as well.
- [x] ~~I want to make the `resources` key optional, as specified in the
Migration Guide, so that old scenes will be compatible with this
change.~~ Since this would only be trivial for ron format, I think it
might be better to consider it in a separate PR/discussion to figure out
if it could be done for binary serialization too.
- [x] I suppose it might be a good idea to add a resources in the scene
example so that users will quickly notice they can serialize resources
just like entities.
---------
Co-authored-by: Carter Anderson <mcanders1@gmail.com>
2023-03-20 21:17:02 +00:00
|
|
|
|
2022-10-12 01:48:16 +00:00
|
|
|
#[derive(Component, Reflect, Default, Eq, PartialEq, Debug)]
|
|
|
|
#[reflect(Component)]
|
|
|
|
struct ComponentB;
|
|
|
|
|
(De) serialize resources in scenes (#6846)
# Objective
Co-Authored-By: davier
[bricedavier@gmail.com](mailto:bricedavier@gmail.com)
Fixes #3576.
Adds a `resources` field in scene serialization data to allow
de/serializing resources that have reflection enabled.
## Solution
Most of this code is taken from a previous closed PR:
https://github.com/bevyengine/bevy/pull/3580. Most of the credit goes to
@Davier , what I did was mostly getting it to work on the latest main
branch of Bevy, along with adding a few asserts in the currently
existing tests to be sure everything is working properly.
This PR changes the scene format to include resources in this way:
```
(
resources: {
// List of resources here, keyed by resource type name.
},
entities: [
// Previous scene format here
],
)
```
An example taken from the tests:
```
(
resources: {
"bevy_scene::serde::tests::MyResource": (
foo: 123,
),
},
entities: {
// Previous scene format here
},
)
```
For this, a `resources` fields has been added on the `DynamicScene` and
the `DynamicSceneBuilder` structs. The latter now also has a method
named `extract_resources` to properly extract the existing resources
registered in the local type registry, in a similar way to
`extract_entities`.
---
## Changelog
Added: Reflect resources registered in the type registry used by dynamic
scenes will now be properly de/serialized in scene data.
## Migration Guide
Since the scene format has been changed, the user may not be able to use
scenes saved prior to this PR due to the `resources` scene field being
missing. ~~To preserve backwards compatibility, I will try to make the
`resources` fully optional so that old scenes can be loaded without
issue.~~
## TODOs
- [x] I may have to update a few doc blocks still referring to dynamic
scenes as mere container of entities, since they now include resources
as well.
- [x] ~~I want to make the `resources` key optional, as specified in the
Migration Guide, so that old scenes will be compatible with this
change.~~ Since this would only be trivial for ron format, I think it
might be better to consider it in a separate PR/discussion to figure out
if it could be done for binary serialization too.
- [x] I suppose it might be a good idea to add a resources in the scene
example so that users will quickly notice they can serialize resources
just like entities.
---------
Co-authored-by: Carter Anderson <mcanders1@gmail.com>
2023-03-20 21:17:02 +00:00
|
|
|
#[derive(Resource, Reflect, Default, Eq, PartialEq, Debug)]
|
|
|
|
#[reflect(Resource)]
|
|
|
|
struct ResourceA;
|
|
|
|
|
2022-10-12 01:48:16 +00:00
|
|
|
#[test]
|
|
|
|
fn extract_one_entity() {
|
|
|
|
let mut world = World::default();
|
|
|
|
|
|
|
|
let atr = AppTypeRegistry::default();
|
|
|
|
atr.write().register::<ComponentA>();
|
|
|
|
world.insert_resource(atr);
|
|
|
|
|
|
|
|
let entity = world.spawn((ComponentA, ComponentB)).id();
|
|
|
|
|
|
|
|
let mut builder = DynamicSceneBuilder::from_world(&world);
|
|
|
|
builder.extract_entity(entity);
|
|
|
|
let scene = builder.build();
|
|
|
|
|
|
|
|
assert_eq!(scene.entities.len(), 1);
|
Make scene handling of entity references robust (#7335)
# Objective
- Handle dangling entity references inside scenes
- Handle references to entities with generation > 0 inside scenes
- Fix a latent bug in `Parent`'s `MapEntities` implementation, which
would, if the parent was outside the scene, cause the scene to be loaded
into the new world with a parent reference potentially pointing to some
random entity in that new world.
- Fixes #4793 and addresses #7235
## Solution
- DynamicScenes now identify entities with a `Entity` instead of a u32,
therefore including generation
- `World` exposes a new `reserve_generations` function that despawns an
entity and advances its generation by some extra amount.
- `MapEntities` implementations have a new `get_or_reserve` function
available that will always return an `Entity`, establishing a new
mapping to a dead entity when the entity they are called with is not in
the `EntityMap`. Subsequent calls with that same `Entity` will return
the same newly created dead entity reference, preserving equality
semantics.
- As a result, after loading a scene containing references to dead
entities (or entities otherwise outside the scene), those references
will all point to different generations on a single entity id in the new
world.
---
## Changelog
### Changed
- In serialized scenes, entities are now identified by a u64 instead of
a u32.
- In serialized scenes, components with entity references now have those
references serialize as u64s instead of structs.
### Fixed
- Scenes containing components with entity references will now
deserialize and add to a world reliably.
## Migration Guide
- `MapEntities` implementations must change from a `&EntityMap`
parameter to a `&mut EntityMapper` parameter and can no longer return a
`Result`. Finally, they should switch from calling `EntityMap::get` to
calling `EntityMapper::get_or_reserve`.
---------
Co-authored-by: Nicola Papale <nicopap@users.noreply.github.com>
2023-05-01 15:49:27 +00:00
|
|
|
assert_eq!(scene.entities[0].entity, entity);
|
2022-10-12 01:48:16 +00:00
|
|
|
assert_eq!(scene.entities[0].components.len(), 1);
|
|
|
|
assert!(scene.entities[0].components[0].represents::<ComponentA>());
|
|
|
|
}
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
fn extract_one_entity_twice() {
|
|
|
|
let mut world = World::default();
|
|
|
|
|
|
|
|
let atr = AppTypeRegistry::default();
|
|
|
|
atr.write().register::<ComponentA>();
|
|
|
|
world.insert_resource(atr);
|
|
|
|
|
|
|
|
let entity = world.spawn((ComponentA, ComponentB)).id();
|
|
|
|
|
|
|
|
let mut builder = DynamicSceneBuilder::from_world(&world);
|
|
|
|
builder.extract_entity(entity);
|
|
|
|
builder.extract_entity(entity);
|
|
|
|
let scene = builder.build();
|
|
|
|
|
|
|
|
assert_eq!(scene.entities.len(), 1);
|
Make scene handling of entity references robust (#7335)
# Objective
- Handle dangling entity references inside scenes
- Handle references to entities with generation > 0 inside scenes
- Fix a latent bug in `Parent`'s `MapEntities` implementation, which
would, if the parent was outside the scene, cause the scene to be loaded
into the new world with a parent reference potentially pointing to some
random entity in that new world.
- Fixes #4793 and addresses #7235
## Solution
- DynamicScenes now identify entities with a `Entity` instead of a u32,
therefore including generation
- `World` exposes a new `reserve_generations` function that despawns an
entity and advances its generation by some extra amount.
- `MapEntities` implementations have a new `get_or_reserve` function
available that will always return an `Entity`, establishing a new
mapping to a dead entity when the entity they are called with is not in
the `EntityMap`. Subsequent calls with that same `Entity` will return
the same newly created dead entity reference, preserving equality
semantics.
- As a result, after loading a scene containing references to dead
entities (or entities otherwise outside the scene), those references
will all point to different generations on a single entity id in the new
world.
---
## Changelog
### Changed
- In serialized scenes, entities are now identified by a u64 instead of
a u32.
- In serialized scenes, components with entity references now have those
references serialize as u64s instead of structs.
### Fixed
- Scenes containing components with entity references will now
deserialize and add to a world reliably.
## Migration Guide
- `MapEntities` implementations must change from a `&EntityMap`
parameter to a `&mut EntityMapper` parameter and can no longer return a
`Result`. Finally, they should switch from calling `EntityMap::get` to
calling `EntityMapper::get_or_reserve`.
---------
Co-authored-by: Nicola Papale <nicopap@users.noreply.github.com>
2023-05-01 15:49:27 +00:00
|
|
|
assert_eq!(scene.entities[0].entity, entity);
|
2022-10-12 01:48:16 +00:00
|
|
|
assert_eq!(scene.entities[0].components.len(), 1);
|
|
|
|
assert!(scene.entities[0].components[0].represents::<ComponentA>());
|
|
|
|
}
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
fn extract_one_entity_two_components() {
|
|
|
|
let mut world = World::default();
|
|
|
|
|
|
|
|
let atr = AppTypeRegistry::default();
|
|
|
|
{
|
|
|
|
let mut register = atr.write();
|
|
|
|
register.register::<ComponentA>();
|
|
|
|
register.register::<ComponentB>();
|
|
|
|
}
|
|
|
|
world.insert_resource(atr);
|
|
|
|
|
|
|
|
let entity = world.spawn((ComponentA, ComponentB)).id();
|
|
|
|
|
|
|
|
let mut builder = DynamicSceneBuilder::from_world(&world);
|
|
|
|
builder.extract_entity(entity);
|
|
|
|
let scene = builder.build();
|
|
|
|
|
|
|
|
assert_eq!(scene.entities.len(), 1);
|
Make scene handling of entity references robust (#7335)
# Objective
- Handle dangling entity references inside scenes
- Handle references to entities with generation > 0 inside scenes
- Fix a latent bug in `Parent`'s `MapEntities` implementation, which
would, if the parent was outside the scene, cause the scene to be loaded
into the new world with a parent reference potentially pointing to some
random entity in that new world.
- Fixes #4793 and addresses #7235
## Solution
- DynamicScenes now identify entities with a `Entity` instead of a u32,
therefore including generation
- `World` exposes a new `reserve_generations` function that despawns an
entity and advances its generation by some extra amount.
- `MapEntities` implementations have a new `get_or_reserve` function
available that will always return an `Entity`, establishing a new
mapping to a dead entity when the entity they are called with is not in
the `EntityMap`. Subsequent calls with that same `Entity` will return
the same newly created dead entity reference, preserving equality
semantics.
- As a result, after loading a scene containing references to dead
entities (or entities otherwise outside the scene), those references
will all point to different generations on a single entity id in the new
world.
---
## Changelog
### Changed
- In serialized scenes, entities are now identified by a u64 instead of
a u32.
- In serialized scenes, components with entity references now have those
references serialize as u64s instead of structs.
### Fixed
- Scenes containing components with entity references will now
deserialize and add to a world reliably.
## Migration Guide
- `MapEntities` implementations must change from a `&EntityMap`
parameter to a `&mut EntityMapper` parameter and can no longer return a
`Result`. Finally, they should switch from calling `EntityMap::get` to
calling `EntityMapper::get_or_reserve`.
---------
Co-authored-by: Nicola Papale <nicopap@users.noreply.github.com>
2023-05-01 15:49:27 +00:00
|
|
|
assert_eq!(scene.entities[0].entity, entity);
|
2022-10-12 01:48:16 +00:00
|
|
|
assert_eq!(scene.entities[0].components.len(), 2);
|
|
|
|
assert!(scene.entities[0].components[0].represents::<ComponentA>());
|
|
|
|
assert!(scene.entities[0].components[1].represents::<ComponentB>());
|
|
|
|
}
|
|
|
|
|
2022-10-27 23:38:03 +00:00
|
|
|
#[test]
|
|
|
|
fn extract_entity_order() {
|
|
|
|
let mut world = World::default();
|
|
|
|
world.init_resource::<AppTypeRegistry>();
|
|
|
|
|
|
|
|
// Spawn entities in order
|
|
|
|
let entity_a = world.spawn_empty().id();
|
|
|
|
let entity_b = world.spawn_empty().id();
|
|
|
|
let entity_c = world.spawn_empty().id();
|
|
|
|
let entity_d = world.spawn_empty().id();
|
|
|
|
|
|
|
|
let mut builder = DynamicSceneBuilder::from_world(&world);
|
|
|
|
|
|
|
|
// Insert entities out of order
|
|
|
|
builder.extract_entity(entity_b);
|
|
|
|
builder.extract_entities([entity_d, entity_a].into_iter());
|
|
|
|
builder.extract_entity(entity_c);
|
|
|
|
|
|
|
|
let mut entities = builder.build().entities.into_iter();
|
|
|
|
|
|
|
|
// Assert entities are ordered
|
Make scene handling of entity references robust (#7335)
# Objective
- Handle dangling entity references inside scenes
- Handle references to entities with generation > 0 inside scenes
- Fix a latent bug in `Parent`'s `MapEntities` implementation, which
would, if the parent was outside the scene, cause the scene to be loaded
into the new world with a parent reference potentially pointing to some
random entity in that new world.
- Fixes #4793 and addresses #7235
## Solution
- DynamicScenes now identify entities with a `Entity` instead of a u32,
therefore including generation
- `World` exposes a new `reserve_generations` function that despawns an
entity and advances its generation by some extra amount.
- `MapEntities` implementations have a new `get_or_reserve` function
available that will always return an `Entity`, establishing a new
mapping to a dead entity when the entity they are called with is not in
the `EntityMap`. Subsequent calls with that same `Entity` will return
the same newly created dead entity reference, preserving equality
semantics.
- As a result, after loading a scene containing references to dead
entities (or entities otherwise outside the scene), those references
will all point to different generations on a single entity id in the new
world.
---
## Changelog
### Changed
- In serialized scenes, entities are now identified by a u64 instead of
a u32.
- In serialized scenes, components with entity references now have those
references serialize as u64s instead of structs.
### Fixed
- Scenes containing components with entity references will now
deserialize and add to a world reliably.
## Migration Guide
- `MapEntities` implementations must change from a `&EntityMap`
parameter to a `&mut EntityMapper` parameter and can no longer return a
`Result`. Finally, they should switch from calling `EntityMap::get` to
calling `EntityMapper::get_or_reserve`.
---------
Co-authored-by: Nicola Papale <nicopap@users.noreply.github.com>
2023-05-01 15:49:27 +00:00
|
|
|
assert_eq!(entity_a, entities.next().map(|e| e.entity).unwrap());
|
|
|
|
assert_eq!(entity_b, entities.next().map(|e| e.entity).unwrap());
|
|
|
|
assert_eq!(entity_c, entities.next().map(|e| e.entity).unwrap());
|
|
|
|
assert_eq!(entity_d, entities.next().map(|e| e.entity).unwrap());
|
2022-10-27 23:38:03 +00:00
|
|
|
}
|
|
|
|
|
2022-10-12 01:48:16 +00:00
|
|
|
#[test]
|
|
|
|
fn extract_query() {
|
|
|
|
let mut world = World::default();
|
|
|
|
|
|
|
|
let atr = AppTypeRegistry::default();
|
|
|
|
{
|
|
|
|
let mut register = atr.write();
|
|
|
|
register.register::<ComponentA>();
|
|
|
|
register.register::<ComponentB>();
|
|
|
|
}
|
|
|
|
world.insert_resource(atr);
|
|
|
|
|
|
|
|
let entity_a_b = world.spawn((ComponentA, ComponentB)).id();
|
|
|
|
let entity_a = world.spawn(ComponentA).id();
|
|
|
|
let _entity_b = world.spawn(ComponentB).id();
|
|
|
|
|
|
|
|
let mut query = world.query_filtered::<Entity, With<ComponentA>>();
|
|
|
|
let mut builder = DynamicSceneBuilder::from_world(&world);
|
|
|
|
builder.extract_entities(query.iter(&world));
|
|
|
|
let scene = builder.build();
|
|
|
|
|
|
|
|
assert_eq!(scene.entities.len(), 2);
|
|
|
|
let mut scene_entities = vec![scene.entities[0].entity, scene.entities[1].entity];
|
|
|
|
scene_entities.sort();
|
Make scene handling of entity references robust (#7335)
# Objective
- Handle dangling entity references inside scenes
- Handle references to entities with generation > 0 inside scenes
- Fix a latent bug in `Parent`'s `MapEntities` implementation, which
would, if the parent was outside the scene, cause the scene to be loaded
into the new world with a parent reference potentially pointing to some
random entity in that new world.
- Fixes #4793 and addresses #7235
## Solution
- DynamicScenes now identify entities with a `Entity` instead of a u32,
therefore including generation
- `World` exposes a new `reserve_generations` function that despawns an
entity and advances its generation by some extra amount.
- `MapEntities` implementations have a new `get_or_reserve` function
available that will always return an `Entity`, establishing a new
mapping to a dead entity when the entity they are called with is not in
the `EntityMap`. Subsequent calls with that same `Entity` will return
the same newly created dead entity reference, preserving equality
semantics.
- As a result, after loading a scene containing references to dead
entities (or entities otherwise outside the scene), those references
will all point to different generations on a single entity id in the new
world.
---
## Changelog
### Changed
- In serialized scenes, entities are now identified by a u64 instead of
a u32.
- In serialized scenes, components with entity references now have those
references serialize as u64s instead of structs.
### Fixed
- Scenes containing components with entity references will now
deserialize and add to a world reliably.
## Migration Guide
- `MapEntities` implementations must change from a `&EntityMap`
parameter to a `&mut EntityMapper` parameter and can no longer return a
`Result`. Finally, they should switch from calling `EntityMap::get` to
calling `EntityMapper::get_or_reserve`.
---------
Co-authored-by: Nicola Papale <nicopap@users.noreply.github.com>
2023-05-01 15:49:27 +00:00
|
|
|
assert_eq!(scene_entities, [entity_a_b, entity_a]);
|
2022-10-12 01:48:16 +00:00
|
|
|
}
|
2022-12-20 16:16:58 +00:00
|
|
|
|
|
|
|
#[test]
|
|
|
|
fn remove_componentless_entity() {
|
|
|
|
let mut world = World::default();
|
|
|
|
|
|
|
|
let atr = AppTypeRegistry::default();
|
|
|
|
atr.write().register::<ComponentA>();
|
|
|
|
world.insert_resource(atr);
|
|
|
|
|
|
|
|
let entity_a = world.spawn(ComponentA).id();
|
|
|
|
let entity_b = world.spawn(ComponentB).id();
|
|
|
|
|
|
|
|
let mut builder = DynamicSceneBuilder::from_world(&world);
|
|
|
|
builder.extract_entities([entity_a, entity_b].into_iter());
|
|
|
|
builder.remove_empty_entities();
|
|
|
|
let scene = builder.build();
|
|
|
|
|
|
|
|
assert_eq!(scene.entities.len(), 1);
|
Make scene handling of entity references robust (#7335)
# Objective
- Handle dangling entity references inside scenes
- Handle references to entities with generation > 0 inside scenes
- Fix a latent bug in `Parent`'s `MapEntities` implementation, which
would, if the parent was outside the scene, cause the scene to be loaded
into the new world with a parent reference potentially pointing to some
random entity in that new world.
- Fixes #4793 and addresses #7235
## Solution
- DynamicScenes now identify entities with a `Entity` instead of a u32,
therefore including generation
- `World` exposes a new `reserve_generations` function that despawns an
entity and advances its generation by some extra amount.
- `MapEntities` implementations have a new `get_or_reserve` function
available that will always return an `Entity`, establishing a new
mapping to a dead entity when the entity they are called with is not in
the `EntityMap`. Subsequent calls with that same `Entity` will return
the same newly created dead entity reference, preserving equality
semantics.
- As a result, after loading a scene containing references to dead
entities (or entities otherwise outside the scene), those references
will all point to different generations on a single entity id in the new
world.
---
## Changelog
### Changed
- In serialized scenes, entities are now identified by a u64 instead of
a u32.
- In serialized scenes, components with entity references now have those
references serialize as u64s instead of structs.
### Fixed
- Scenes containing components with entity references will now
deserialize and add to a world reliably.
## Migration Guide
- `MapEntities` implementations must change from a `&EntityMap`
parameter to a `&mut EntityMapper` parameter and can no longer return a
`Result`. Finally, they should switch from calling `EntityMap::get` to
calling `EntityMapper::get_or_reserve`.
---------
Co-authored-by: Nicola Papale <nicopap@users.noreply.github.com>
2023-05-01 15:49:27 +00:00
|
|
|
assert_eq!(scene.entities[0].entity, entity_a);
|
2022-12-20 16:16:58 +00:00
|
|
|
}
|
(De) serialize resources in scenes (#6846)
# Objective
Co-Authored-By: davier
[bricedavier@gmail.com](mailto:bricedavier@gmail.com)
Fixes #3576.
Adds a `resources` field in scene serialization data to allow
de/serializing resources that have reflection enabled.
## Solution
Most of this code is taken from a previous closed PR:
https://github.com/bevyengine/bevy/pull/3580. Most of the credit goes to
@Davier , what I did was mostly getting it to work on the latest main
branch of Bevy, along with adding a few asserts in the currently
existing tests to be sure everything is working properly.
This PR changes the scene format to include resources in this way:
```
(
resources: {
// List of resources here, keyed by resource type name.
},
entities: [
// Previous scene format here
],
)
```
An example taken from the tests:
```
(
resources: {
"bevy_scene::serde::tests::MyResource": (
foo: 123,
),
},
entities: {
// Previous scene format here
},
)
```
For this, a `resources` fields has been added on the `DynamicScene` and
the `DynamicSceneBuilder` structs. The latter now also has a method
named `extract_resources` to properly extract the existing resources
registered in the local type registry, in a similar way to
`extract_entities`.
---
## Changelog
Added: Reflect resources registered in the type registry used by dynamic
scenes will now be properly de/serialized in scene data.
## Migration Guide
Since the scene format has been changed, the user may not be able to use
scenes saved prior to this PR due to the `resources` scene field being
missing. ~~To preserve backwards compatibility, I will try to make the
`resources` fully optional so that old scenes can be loaded without
issue.~~
## TODOs
- [x] I may have to update a few doc blocks still referring to dynamic
scenes as mere container of entities, since they now include resources
as well.
- [x] ~~I want to make the `resources` key optional, as specified in the
Migration Guide, so that old scenes will be compatible with this
change.~~ Since this would only be trivial for ron format, I think it
might be better to consider it in a separate PR/discussion to figure out
if it could be done for binary serialization too.
- [x] I suppose it might be a good idea to add a resources in the scene
example so that users will quickly notice they can serialize resources
just like entities.
---------
Co-authored-by: Carter Anderson <mcanders1@gmail.com>
2023-03-20 21:17:02 +00:00
|
|
|
|
|
|
|
#[test]
|
|
|
|
fn extract_one_resource() {
|
|
|
|
let mut world = World::default();
|
|
|
|
|
|
|
|
let atr = AppTypeRegistry::default();
|
|
|
|
atr.write().register::<ResourceA>();
|
|
|
|
world.insert_resource(atr);
|
|
|
|
|
|
|
|
world.insert_resource(ResourceA);
|
|
|
|
|
|
|
|
let mut builder = DynamicSceneBuilder::from_world(&world);
|
|
|
|
builder.extract_resources();
|
|
|
|
let scene = builder.build();
|
|
|
|
|
|
|
|
assert_eq!(scene.resources.len(), 1);
|
|
|
|
assert!(scene.resources[0].represents::<ResourceA>());
|
|
|
|
}
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
fn extract_one_resource_twice() {
|
|
|
|
let mut world = World::default();
|
|
|
|
|
|
|
|
let atr = AppTypeRegistry::default();
|
|
|
|
atr.write().register::<ResourceA>();
|
|
|
|
world.insert_resource(atr);
|
|
|
|
|
|
|
|
world.insert_resource(ResourceA);
|
|
|
|
|
|
|
|
let mut builder = DynamicSceneBuilder::from_world(&world);
|
|
|
|
builder.extract_resources();
|
|
|
|
builder.extract_resources();
|
|
|
|
let scene = builder.build();
|
|
|
|
|
|
|
|
assert_eq!(scene.resources.len(), 1);
|
|
|
|
assert!(scene.resources[0].represents::<ResourceA>());
|
|
|
|
}
|
2022-10-12 01:48:16 +00:00
|
|
|
}
|