Add DefaultQueryFilters #13120
Add DefaultQueryFilters #13120
Conversation
|
Two things you should probably do:
|
This seems reasonable, yet it might also be problematic for things that get added to the list in the future. It's hard to anticipiate all the uses for this before people have a chance to use it. It's hard to say if a universal bypass makes sense or if we'd be better off with some alternative approach like assigning a group to each filter, and allowing groups to be bypassed. Or perhaps bypassing default filters won't even be needed in practice. It might be better to leave it until people report running into issues, or until we start including default features and know we need a way to bypass them collectively.
This behavior feels a bit implicit, but I think creating a list of components retain shouldn't touch could make a lot of sense, it would also be a lot easier to explain and reason about for users. There might even be uses that do want to bypass retain but not be filtered out, or the other way around. But it should probably be in a separate PR. The bypass variant might also have the same issues as the point above. |
At the very least it should be the same list. It shouldn't be a different one. I still think it would be a good idea to include this now anyway even if you don't want to add bypasses yet because introducing it later will be a breaking change & using it without default filters applied will surprise users. |
I'm thinking more along the lines: Most users wouldn't manually add default filters, we'll probably want built-in abstractions on top in a future release. Meaning they'd probably be configured by plugins (something like a Tho I've never actually used retain so it's a bit hard for me to comment on how it should behave. |
alice-i-cecile
added
A-ECS
alice-i-cecile
added
the
M-Needs-Release-Note
NiseVoid
added
S-Needs-Review
BenjaminBrienen
added
the
D-Modest
NthTensor
added
S-Ready-For-Final-Review
There was a problem hiding this comment.
@maniwani and I have signed off on the core design as SME-ECS (hence the change to X-Blessed a while back). The core challenge here is how to handle disabling entities WRT relations. After discussing this with Sander Martens (of flecs), I'm of the opinion that the simple, intuitive behavior here is the right one to ship with, while making sure that it's easy to "disable/enable recursively".
Before 0.16, I think it's important that we:
- Ship a first party
Disabledcomponent. - Demonstrate this feature in an example, which showcases the hierarchical disabling pattern.
@NiseVoid has suffered long enough waiting for this to land though, and those are easily moved to follow-up. Merging as soon as CI is green.
NiseVoid
force-pushed
the
default_filters
branch
from
10d8c25 to
93f952d
Compare
…tyCommands` (#17463) # Objective While being able to quickly add / remove components down a tree is broadly useful (material changing!), it's particularly necessary when combined with the newly added #13120. ## Solution Write four methods: covering both adding and removal on both `EntityWorldMut` and `EntityCommands`. These methods are generic over the `RelationshipTarget`, thanks to the freshly merged relations 🎉 ## Testing I've added a simple unit test for these methods. --------- Co-authored-by: Zachary Harrold <[email protected]>
# Objective Some usecases in the ecosystems are blocked by the inability to stop bevy internals and third party plugins from touching their entities. However the specifics of a general purpose entity disabling system are controversial and further complicated by hierarchies. We can partially unblock these usecases with an opt-in approach: default query filters. ## Solution - Introduce DefaultQueryFilters, these filters are automatically applied to queries that don't otherwise mention the filtered component. - End users and third party plugins can register default filters and are responsible for handling entities they have hidden this way. - Extra features can be left for after user feedback - The default value could later include official ways to hide entities --- ## Changelog - Add DefaultQueryFilters
…tyCommands` (bevyengine#17463) # Objective While being able to quickly add / remove components down a tree is broadly useful (material changing!), it's particularly necessary when combined with the newly added bevyengine#13120. ## Solution Write four methods: covering both adding and removal on both `EntityWorldMut` and `EntityCommands`. These methods are generic over the `RelationshipTarget`, thanks to the freshly merged relations 🎉 ## Testing I've added a simple unit test for these methods. --------- Co-authored-by: Zachary Harrold <[email protected]>
# Objective The entity disabling / default query filter work added in #17514 and #13120 is neat, but we don't teach users how it works! We should fix that before 0.16. ## Solution Write a simple example to teach the basics of entity disabling! ## Testing `cargo run --example entity_disabling` ## Showcase  --------- Co-authored-by: Zachary Harrold <[email protected]>
…y filters (#17768) # Objective Currently, default query filters, as added in #13120 / #17514 are hardcoded to only use a single query filter. This is limiting, as multiple distinct disabling components can serve important distinct roles. I ran into this limitation when experimenting with a workflow for prefabs, which don't represent the same state as "an entity which is temporarily nonfunctional". ## Solution 1. Change `DefaultQueryFilters` to store a SmallVec of ComponentId, rather than an Option. 2. Expose methods on `DefaultQueryFilters`, `World` and `App` to actually configure this. 3. While we're here, improve the docs, write some tests, make use of FromWorld and make some method names more descriptive. ## Follow-up I'm not convinced that supporting sparse set disabling components is useful, given the hit to iteration performance and runtime checks incurred. That's disjoint from this PR though, so I'm not doing it here. The existing warnings are fine for now. ## Testing I've added both a doc test and an mid-level unit test to verify that this works!
# Objective The entity disabling / default query filter work added in bevyengine#17514 and bevyengine#13120 is neat, but we don't teach users how it works! We should fix that before 0.16. ## Solution Write a simple example to teach the basics of entity disabling! ## Testing `cargo run --example entity_disabling` ## Showcase  --------- Co-authored-by: Zachary Harrold <[email protected]>
|
Thank you to everyone involved with the authoring or reviewing of this PR! This work is relatively important and needs release notes! Head over to bevyengine/bevy-website#1982 if you'd like to help out. |
Objective
Some usecases in the ecosystems are blocked by the inability to stop bevy internals and third party plugins from touching their entities. However the specifics of a general purpose entity disabling system are controversial and further complicated by hierarchies. We can partially unblock these usecases with an opt-in approach: default query filters.
Solution
Changelog