Skip to content
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

Add common component conditions #7711

Closed
wants to merge 14 commits into from

Conversation

Shatur
Copy link
Contributor

@Shatur Shatur commented Feb 16, 2023

Add two useful common run conditions for components similar to any_with_component from #7579. Unlike any_with_component these two conditions could be potentially expensive, but super useful if user knows that there is only a few entities with a component.


Changelog

Added

  • Add any_component_added and any_component_changed.

@alice-i-cecile alice-i-cecile added A-ECS Entities, components, systems, and events C-Usability A targeted quality-of-life change that makes Bevy easier to use labels Feb 16, 2023
Copy link
Member

@alice-i-cecile alice-i-cecile left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Otherwise this check could be expensive and hold up the executor preventing it from running any systems during the check.

I think this can be more clearly phrased by replacing your warning with the following:

Run conditions are evaluated on the main thread, blocking any other systems from running.
This run condition is relatively expensive, as it iterates over every entity with this component.
As a result, you likely only want to use this run condition when the number of entitities with the component T is small.

One more request: can we have the same flavor of run condition, but for RemovedComponent<T>?

@Shatur
Copy link
Contributor Author

Shatur commented Feb 16, 2023

I think this can be more clearly phrased by replacing your warning with the following:

I like it!

One more request: can we have the same flavor of run condition, but for RemovedComponent?

I think we switched to events for this: #5680

@alice-i-cecile
Copy link
Member

I think we switched to events for this: #5680

That PR was effectively non-breaking :) The RemovedComponents system param is still around, it's just now double-buffered and no longer quite as bespoke.

@Shatur
Copy link
Contributor Author

Shatur commented Feb 16, 2023

The RemovedComponents system param is still around, it's just now double-buffered and no longer quite as bespoke.

Right, missed that it was an internal change. Will add the condition.

@Shatur
Copy link
Contributor Author

Shatur commented Feb 16, 2023

Right, missed that it was an internal change. Will add the condition.

We probably should add RemovedComponents::is_empty() for it to avoid calling iter().count().

/// This run condition is relatively expensive, as it iterates over every entity with this component.
/// As a result, you likely only want to use this run condition when the number of entitities with the component `T` is small.
pub fn any_component_added<T: Component>() -> impl FnMut(Query<(), Added<T>>) -> bool {
move |query: Query<(), Added<T>>| !query.is_empty()
Copy link
Member

@james7132 james7132 Feb 16, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These potentially do a full world scan in the multithreaded executor, which not only runs single threaded but blocks any further system's run conditions from being evaluated and tasks launched. The only early return is if no archetypes match the query, everything else does a full scan, and will scale linearly with the number of those components in the world. This is relatively easy performance footgun, same with the other condition below.

Even with it documented, I still don't think it's a good idea to readily provide this to users without some form of archetype-level change detection optimization.

Copy link
Contributor Author

@Shatur Shatur Feb 16, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, this is what I mentioned in the description. I thought it's fine if documented. But your concern is exactly why it wasn't included in #7579.

@james7132 james7132 added the X-Controversial There is active debate or serious implications around merging this PR label Feb 16, 2023
Co-authored-by: Ida "Iyes" <[email protected]>
Copy link
Contributor

@inodentry inodentry left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggesting better wording for the doc comments!

crates/bevy_ecs/src/schedule/condition.rs Outdated Show resolved Hide resolved
crates/bevy_ecs/src/schedule/condition.rs Outdated Show resolved Hide resolved
Shatur and others added 2 commits February 20, 2023 18:01
Co-authored-by: Ida "Iyes" <[email protected]>
@Shatur
Copy link
Contributor Author

Shatur commented Feb 20, 2023

Thanks!

@inodentry
Copy link
Contributor

Other than the little things I pointed out above, I approve! Given the warning in the documentation, I think this is worth including in Bevy.

As implemented, if, in the future, change detection gets optimized so that the queries don't have to iterate, this API will just magically become fast, and we can remove the perf warning. :)

@alice-i-cecile alice-i-cecile added the S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it label Feb 20, 2023
@alice-i-cecile alice-i-cecile removed the S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it label Feb 20, 2023
@Shatur Shatur added the S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it label Feb 20, 2023
alice-i-cecile pushed a commit that referenced this pull request Apr 18, 2023
Added helper extracted from #7711. that PR contains some controversy
conditions, but this one should be good to go.

---

## Changelog

### Added

- `any_component_removed` condition.

---------

Co-authored-by: François <[email protected]>
@Shatur
Copy link
Contributor Author

Shatur commented Apr 18, 2023

I moved non-controversial any_component_removed to a separate PR (#8326) that was merged. Updated this PR with to the latest master just in case someone will be interested to include these two other conditions.

@Shatur
Copy link
Contributor Author

Shatur commented Feb 17, 2024

It was decided to not implement it, closing.

@Shatur Shatur closed this Feb 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-ECS Entities, components, systems, and events C-Usability A targeted quality-of-life change that makes Bevy easier to use S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it X-Controversial There is active debate or serious implications around merging this PR
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants