# Objective
Currently, `DynamicScene`s extract all components listed in the given
(or the world's) type registry. This acts as a quasi-filter of sorts.
However, it can be troublesome to use effectively and lacks decent
control.
For example, say you need to serialize only the following component over
the network:
```rust
#[derive(Reflect, Component, Default)]
#[reflect(Component)]
struct NPC {
name: Option<String>
}
```
To do this, you'd need to:
1. Create a new `AppTypeRegistry`
2. Register `NPC`
3. Register `Option<String>`
If we skip Step 3, then the entire scene might fail to serialize as
`Option<String>` requires registration.
Not only is this annoying and easy to forget, but it can leave users
with an impossible task: serializing a third-party type that contains
private types.
Generally, the third-party crate will register their private types
within a plugin so the user doesn't need to do it themselves. However,
this means we are now unable to serialize _just_ that type— we're forced
to allow everything!
## Solution
Add the `SceneFilter` enum for filtering components to extract.
This filter can be used to optionally allow or deny entire sets of
components/resources. With the `DynamicSceneBuilder`, users have more
control over how their `DynamicScene`s are built.
To only serialize a subset of components, use the `allow` method:
```rust
let scene = builder
.allow::<ComponentA>()
.allow::<ComponentB>()
.extract_entity(entity)
.build();
```
To serialize everything _but_ a subset of components, use the `deny`
method:
```rust
let scene = builder
.deny::<ComponentA>()
.deny::<ComponentB>()
.extract_entity(entity)
.build();
```
Or create a custom filter:
```rust
let components = HashSet::from([type_id]);
let filter = SceneFilter::Allowlist(components);
// let filter = SceneFilter::Denylist(components);
let scene = builder
.with_filter(Some(filter))
.extract_entity(entity)
.build();
```
Similar operations exist for resources:
<details>
<summary>View Resource Methods</summary>
To only serialize a subset of resources, use the `allow_resource`
method:
```rust
let scene = builder
.allow_resource::<ResourceA>()
.extract_resources()
.build();
```
To serialize everything _but_ a subset of resources, use the
`deny_resource` method:
```rust
let scene = builder
.deny_resource::<ResourceA>()
.extract_resources()
.build();
```
Or create a custom filter:
```rust
let resources = HashSet::from([type_id]);
let filter = SceneFilter::Allowlist(resources);
// let filter = SceneFilter::Denylist(resources);
let scene = builder
.with_resource_filter(Some(filter))
.extract_resources()
.build();
```
</details>
### Open Questions
- [x] ~~`allow` and `deny` are mutually exclusive. Currently, they
overwrite each other. Should this instead be a panic?~~ Took @soqb's
suggestion and made it so that the opposing method simply removes that
type from the list.
- [x] ~~`DynamicSceneBuilder` extracts entity data as soon as
`extract_entity`/`extract_entities` is called. Should this behavior
instead be moved to the `build` method to prevent ordering mixups (e.g.
`.allow::<Foo>().extract_entity(entity)` vs
`.extract_entity(entity).allow::<Foo>()`)? The tradeoff would be
iterating over the given entities twice: once at extraction and again at
build.~~ Based on the feedback from @Testare it sounds like it might be
better to just keep the current functionality (if anything we can open a
separate PR that adds deferred methods for extraction, so the
choice/performance hit is up to the user).
- [ ] An alternative might be to remove the filter from
`DynamicSceneBuilder` and have it as a separate parameter to the
extraction methods (either in the existing ones or as added
`extract_entity_with_filter`-type methods). Is this preferable?
- [x] ~~Should we include constructors that include common types to
allow/deny? For example, a `SceneFilter::standard_allowlist` that
includes things like `Parent` and `Children`?~~ Consensus suggests we
should. I may split this out into a followup PR, though.
- [x] ~~Should we add the ability to remove types from the filter
regardless of whether an allowlist or denylist (e.g.
`filter.remove::<Foo>()`)?~~ See the first list item
- [x] ~~Should `SceneFilter` be an enum? Would it make more sense as a
struct that contains an `is_denylist` boolean?~~ With the added
`SceneFilter::None` state (replacing the need to wrap in an `Option` or
rely on an empty `Denylist`), it seems an enum is better suited now
- [x] ~~Bikeshed: Do we like the naming convention? Should we instead
use `include`/`exclude` terminology?~~ Sounds like we're sticking with
`allow`/`deny`!
- [x] ~~Does this feature need a new example? Do we simply include it in
the existing one (maybe even as a comment?)? Should this be done in a
followup PR instead?~~ Example will be added in a followup PR
### Followup Tasks
- [ ] Add a dedicated `SceneFilter` example
- [ ] Possibly add default types to the filter (e.g. deny things like
`ComputedVisibility`, allow `Parent`, etc)
---
## Changelog
- Added the `SceneFilter` enum for filtering components and resources
when building a `DynamicScene`
- Added methods:
- `DynamicSceneBuilder::with_filter`
- `DynamicSceneBuilder::allow`
- `DynamicSceneBuilder::deny`
- `DynamicSceneBuilder::allow_all`
- `DynamicSceneBuilder::deny_all`
- `DynamicSceneBuilder::with_resource_filter`
- `DynamicSceneBuilder::allow_resource`
- `DynamicSceneBuilder::deny_resource`
- `DynamicSceneBuilder::allow_all_resources`
- `DynamicSceneBuilder::deny_all_resources`
- Removed methods:
- `DynamicSceneBuilder::from_world_with_type_registry`
- `DynamicScene::from_scene` and `DynamicScene::from_world` no longer
require an `AppTypeRegistry` reference
## Migration Guide
- `DynamicScene::from_scene` and `DynamicScene::from_world` no longer
require an `AppTypeRegistry` reference:
```rust
// OLD
let registry = world.resource::<AppTypeRegistry>();
let dynamic_scene = DynamicScene::from_world(&world, registry);
// let dynamic_scene = DynamicScene::from_scene(&scene, registry);
// NEW
let dynamic_scene = DynamicScene::from_world(&world);
// let dynamic_scene = DynamicScene::from_scene(&scene);
```
- Removed `DynamicSceneBuilder::from_world_with_type_registry`. Now the
registry is automatically taken from the given world:
```rust
// OLD
let registry = world.resource::<AppTypeRegistry>();
let builder = DynamicSceneBuilder::from_world_with_type_registry(&world,
registry);
// NEW
let builder = DynamicSceneBuilder::from_world(&world);
```
168 lines
6.4 KiB
Rust
168 lines
6.4 KiB
Rust
//! This example illustrates loading scenes from files.
|
|
use bevy::{asset::ChangeWatcher, prelude::*, tasks::IoTaskPool, utils::Duration};
|
|
use std::{fs::File, io::Write};
|
|
|
|
fn main() {
|
|
App::new()
|
|
.add_plugins(DefaultPlugins.set(AssetPlugin {
|
|
// This tells the AssetServer to watch for changes to assets.
|
|
// It enables our scenes to automatically reload in game when we modify their files.
|
|
watch_for_changes: ChangeWatcher::with_delay(Duration::from_millis(200)),
|
|
..default()
|
|
}))
|
|
.register_type::<ComponentA>()
|
|
.register_type::<ComponentB>()
|
|
.register_type::<ResourceA>()
|
|
.add_systems(
|
|
Startup,
|
|
(save_scene_system, load_scene_system, infotext_system),
|
|
)
|
|
.add_systems(Update, log_system)
|
|
.run();
|
|
}
|
|
|
|
// Registered components must implement the `Reflect` and `FromWorld` traits.
|
|
// The `Reflect` trait enables serialization, deserialization, and dynamic property access.
|
|
// `Reflect` enable a bunch of cool behaviors, so its worth checking out the dedicated `reflect.rs`
|
|
// example. The `FromWorld` trait determines how your component is constructed when it loads.
|
|
// For simple use cases you can just implement the `Default` trait (which automatically implements
|
|
// FromResources). The simplest registered component just needs these two derives:
|
|
#[derive(Component, Reflect, Default)]
|
|
#[reflect(Component)] // this tells the reflect derive to also reflect component behaviors
|
|
struct ComponentA {
|
|
pub x: f32,
|
|
pub y: f32,
|
|
}
|
|
|
|
// Some components have fields that cannot (or should not) be written to scene files. These can be
|
|
// ignored with the #[reflect(skip_serializing)] attribute. This is also generally where the `FromWorld`
|
|
// trait comes into play. `FromWorld` gives you access to your App's current ECS `Resources`
|
|
// when you construct your component.
|
|
#[derive(Component, Reflect)]
|
|
#[reflect(Component)]
|
|
struct ComponentB {
|
|
pub value: String,
|
|
#[reflect(skip_serializing)]
|
|
pub _time_since_startup: Duration,
|
|
}
|
|
|
|
impl FromWorld for ComponentB {
|
|
fn from_world(world: &mut World) -> Self {
|
|
let time = world.resource::<Time>();
|
|
ComponentB {
|
|
_time_since_startup: time.elapsed(),
|
|
value: "Default Value".to_string(),
|
|
}
|
|
}
|
|
}
|
|
|
|
// Resources can be serialized in scenes as well, with the same requirements `Component`s have.
|
|
#[derive(Resource, Reflect, Default)]
|
|
#[reflect(Resource)]
|
|
struct ResourceA {
|
|
pub score: u32,
|
|
}
|
|
|
|
// The initial scene file will be loaded below and not change when the scene is saved
|
|
const SCENE_FILE_PATH: &str = "scenes/load_scene_example.scn.ron";
|
|
|
|
// The new, updated scene data will be saved here so that you can see the changes
|
|
const NEW_SCENE_FILE_PATH: &str = "scenes/load_scene_example-new.scn.ron";
|
|
|
|
fn load_scene_system(mut commands: Commands, asset_server: Res<AssetServer>) {
|
|
// "Spawning" a scene bundle creates a new entity and spawns new instances
|
|
// of the given scene's entities as children of that entity.
|
|
commands.spawn(DynamicSceneBundle {
|
|
// Scenes are loaded just like any other asset.
|
|
scene: asset_server.load(SCENE_FILE_PATH),
|
|
..default()
|
|
});
|
|
}
|
|
|
|
// This system logs all ComponentA components in our world. Try making a change to a ComponentA in
|
|
// load_scene_example.scn. You should immediately see the changes appear in the console.
|
|
fn log_system(
|
|
query: Query<(Entity, &ComponentA), Changed<ComponentA>>,
|
|
res: Option<Res<ResourceA>>,
|
|
) {
|
|
for (entity, component_a) in &query {
|
|
info!(" Entity({})", entity.index());
|
|
info!(
|
|
" ComponentA: {{ x: {} y: {} }}\n",
|
|
component_a.x, component_a.y
|
|
);
|
|
}
|
|
if let Some(res) = res {
|
|
if res.is_added() {
|
|
info!(" New ResourceA: {{ score: {} }}\n", res.score);
|
|
}
|
|
}
|
|
}
|
|
|
|
fn save_scene_system(world: &mut World) {
|
|
// Scenes can be created from any ECS World.
|
|
// You can either create a new one for the scene or use the current World.
|
|
// For demonstration purposes, we'll create a new one.
|
|
let mut scene_world = World::new();
|
|
|
|
// The `TypeRegistry` resource contains information about all registered types (including components).
|
|
// This is used to construct scenes, so we'll want to ensure that our previous type registrations
|
|
// exist in this new scene world as well.
|
|
// To do this, we can simply clone the `AppTypeRegistry` resource.
|
|
let type_registry = world.resource::<AppTypeRegistry>().clone();
|
|
scene_world.insert_resource(type_registry);
|
|
|
|
let mut component_b = ComponentB::from_world(world);
|
|
component_b.value = "hello".to_string();
|
|
scene_world.spawn((
|
|
component_b,
|
|
ComponentA { x: 1.0, y: 2.0 },
|
|
Transform::IDENTITY,
|
|
));
|
|
scene_world.spawn(ComponentA { x: 3.0, y: 4.0 });
|
|
scene_world.insert_resource(ResourceA { score: 1 });
|
|
|
|
// With our sample world ready to go, we can now create our scene:
|
|
let scene = DynamicScene::from_world(&scene_world);
|
|
|
|
// Scenes can be serialized like this:
|
|
let type_registry = world.resource::<AppTypeRegistry>();
|
|
let serialized_scene = scene.serialize_ron(type_registry).unwrap();
|
|
|
|
// Showing the scene in the console
|
|
info!("{}", serialized_scene);
|
|
|
|
// Writing the scene to a new file. Using a task to avoid calling the filesystem APIs in a system
|
|
// as they are blocking
|
|
// This can't work in WASM as there is no filesystem access
|
|
#[cfg(not(target_arch = "wasm32"))]
|
|
IoTaskPool::get()
|
|
.spawn(async move {
|
|
// Write the scene RON data to file
|
|
File::create(format!("assets/{NEW_SCENE_FILE_PATH}"))
|
|
.and_then(|mut file| file.write(serialized_scene.as_bytes()))
|
|
.expect("Error while writing scene to file");
|
|
})
|
|
.detach();
|
|
}
|
|
|
|
// This is only necessary for the info message in the UI. See examples/ui/text.rs for a standalone
|
|
// text example.
|
|
fn infotext_system(mut commands: Commands) {
|
|
commands.spawn(Camera2dBundle::default());
|
|
commands.spawn(
|
|
TextBundle::from_section(
|
|
"Nothing to see in this window! Check the console output!",
|
|
TextStyle {
|
|
font_size: 50.0,
|
|
color: Color::WHITE,
|
|
..default()
|
|
},
|
|
)
|
|
.with_style(Style {
|
|
align_self: AlignSelf::FlexEnd,
|
|
..default()
|
|
}),
|
|
);
|
|
}
|