mirror of
https://github.com/bevyengine/bevy
synced 2024-11-10 07:04:33 +00:00
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); ```
167 lines
6.4 KiB
Rust
167 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()
|
|
}),
|
|
);
|
|
}
|