Create a Dynamic Scene From a Query Filter

[Carter0]

Objective

This PR copies over the scene_from_query_components function from iyes_scene_tools. I am not the author of that code I am merely copying it over.

This allows users to do something like...

let my_scene = DynamicScene::from_query_filter::<(With<ComponentA>, Without<ComponentB>)>(
    &mut world,
    &type_registry,
);

This is my first Bevy PR!

[alice-i-cecile]

This is an interesting bound; we don't require ReadOnlyWorldQuery on the F in Query<Q, F>. Perhaps we should though?

[mockersf]

I don't think creating a scene from a query filter is a good api. I would prefer to have an api like in #6013 to extract part of the world from a scene and a root, mainly because:

• the query filter is not hierarchy aware
• the query filter is not reflect aware

[Carter0]

I don't think creating a scene from a query filter is a good api. I would prefer to have an api like in #6013 to extract part of the world from a scene and a root, mainly because:

• the query filter is not hierarchy aware
• the query filter is not reflect aware

I don't know that much about the implementation issues you are describing. But I think this could be a useful feature. I could imagine myself making a savable component or something similar. Then I would just update my save file using a filter for anything with that component.

[alice-i-cecile]

I could imagine myself making a savable component or something similar. Then I would just update my save file using a filter for anything with that component.

So, this seems like a reasonable solution! There are two problems here, that Francois is attempting to point out:

1. There's no guarantee that all of the components on these entities are reflected correctly and stored in the type registry.
2. There's no guarantee that our hierarchies won't break; we may get children but not parents or vice-versa.

I think the first needs to be fixed in some form, but the second can be cautioned against.

[alice-i-cecile]

IMO we should probably force users to pass in this type explicitly, in order to clarify which type registry they want to use.

[Carter0]

Wouldn't there just be one type registry per world? Or per app? How could there be multiple?

[Carter0]

Ahh I see whats going on.

In order for a component to be saved to a scene, it needs to be registered in the type registry. If a user tried to use this method without registering their types first, then the scene would not be created with that component on it.

[mockersf]

The type registry works actually as a filter of which component you can extract, but unlike a QueryFilter all the components in one can be extracted. With a QueryFilter you can ask for components that are impossible to extract.

There is one built in in the main world with all registered components, but building one with just the components is easy, see the second example in #6013.

The API proposed in this PR is pretty much equivalent to https://docs.rs/bevy/latest/bevy/prelude/struct.DynamicScene.html#method.from_world. Rather than specify a QueryFilter with your components, you setup a type registry with your components.

This proposed API:

DynamicScene::from_query_filter::<(With<ComponentA>, With<ComponentB>)>(&mut world);

What already exist in Bevy:

let mut atr = AppTypeRegistry::default();
atr.write().register::<ComponentA>();
atr.write().register::<ComponentB>();
DynamicScene::from_world(&world);

The current API is a little more verbose, but you can't specify an invalid filter with it.

[mockersf]

Never mind my comment above, I rechecked the doc you wrote. Your PR extracts all components, but only for entities in the filter 👍

Then adding a type registry would allow you to chose which components to extract

[alice-i-cecile]

Closed in favor of #6227.