-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Align Scene::write_to_world_with
to match DynamicScene::write_to_world_with
#13714
Conversation
It looks like your PR is a breaking change, but you didn't provide a migration guide. Could you add some context on what users should update when this change get released in a new version of Bevy? |
At some point it might make sense to use a trait to capture the API of these two types like we do in bevy_color: their type signatures should generally line up. |
…into scene-write-to-world
@alice-i-cecile Any chance this makes it for 0.14? Or are things locked in place with the release candidate out now? |
If you can convince others that this is relatively important, we will be able to cherrypick this up until 0.14.0 itself is released. |
…orld_with` (#13714) # Objective `Scene` and `DynamicScene` work with `InstanceInfo` at different levels of abstraction - `Scene::write_to_world_with` returns an `InstanceInfo` whereas `DynamicScene::write_to_world_with` returns `()`. Instances are created one level higher at the `SceneSpawner` API level. - `DynamicScene::write_to_world_with` takes the `entity_map` as an argument whereas the `Scene` version is less flexible and creates a new one for you. No reason this needs to be the case. ## Solution I propose changing `Scene::write_to_world_with` to match the API we have for `DynamicScene`. Returning the `InstanceInfo` as we do today just seems like a leaky abstraction - it's only used in `spawn_sync_internal`. Being able to pass in an entity_map gives you more flexibility with how you write entities to a world. This also moves `InstanceInfo` out of `Scene` which is cleaner conceptually. If someone wants to work with instances then they should work with `SceneSpawner` - I see `write_to_world_with` as a lower-level API to be used with exclusive world access. ## Testing Code is just shifting things around. ## Changelog Changed `Scene::write_to_world_with` to take `entity_map` as an argument and no longer return an `InstanceInfo` ## Migration Guide `Scene::write_to_world_with` no longer returns an `InstanceInfo`. Before ```rust scene.write_to_world_with(world, ®istry) ``` After ```rust let mut entity_map = EntityHashMap::default(); scene.write_to_world_with(world, &mut entity_map, ®istry) ```
This broke |
…ite_to_world_with` (bevyengine#13714)" This reverts commit 1f61c26.
…orld_with` (bevyengine#13855) # Objective Fixes a regression in [previously merged but then reverted pr](bevyengine#13714) that aligns lower-level `Scene` API with that in `DynamicScene`. Please look at the original pr for more details. The problem was `spawn_sync_internal` is used in `spawn_queued_scenes`. Since instance creation was moved up a level we need to make sure we add a specific instance to `SceneSpawner::spawned_instances` when using `spawn_sync_internal` (just like we do for `DynamicScene`). Please look at the last commit when reviewing. ## Testing `alien_cake_addict` and `deferred_rendering` examples look as expected. ## Changelog Changed `Scene::write_to_world_with` to take `entity_map` as an argument and no longer return an `InstanceInfo` ## Migration Guide `Scene::write_to_world_with` no longer returns an `InstanceInfo`. Before ```rust scene.write_to_world_with(world, ®istry) ``` After ```rust let mut entity_map = EntityHashMap::default(); scene.write_to_world_with(world, &mut entity_map, ®istry) ```
Objective
Scene
andDynamicScene
work withInstanceInfo
at different levels of abstractionScene::write_to_world_with
returns anInstanceInfo
whereasDynamicScene::write_to_world_with
returns()
. Instances are created one level higher at theSceneSpawner
API level.DynamicScene::write_to_world_with
takes theentity_map
as an argument whereas theScene
version is less flexible and creates a new one for you. No reason this needs to be the case.Solution
I propose changing
Scene::write_to_world_with
to match the API we have forDynamicScene
. Returning theInstanceInfo
as we do today just seems like a leaky abstraction - it's only used inspawn_sync_internal
. Being able to pass in an entity_map gives you more flexibility with how you write entities to a world.This also moves
InstanceInfo
out ofScene
which is cleaner conceptually. If someone wants to work with instances then they should work withSceneSpawner
- I seewrite_to_world_with
as a lower-level API to be used with exclusive world access.Testing
Code is just shifting things around.
Changelog
Changed
Scene::write_to_world_with
to takeentity_map
as an argument and no longer return anInstanceInfo
Migration Guide
Scene::write_to_world_with
no longer returns anInstanceInfo
.Before
After