 d96933ad9c
			
		
	
	
		d96933ad9c
		
			
		
	
	
	
	
		
			
			# 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()
 | |
|         }),
 | |
|     );
 | |
| }
 |