-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
Allow opting-out of check_visibility
system and creation of their own
#17189
base: main
Are you sure you want to change the base?
Conversation
Allow bevy users create their own `check_visibility` systems
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is messy, and I don't think we should merge this. IMO the right short-term fix is:
- Disable the existing
check_visibility
system, probably with a run condition for now. - Add your own system that handles visibility checking the way that you like to
CheckVisibility
.
That provides a solid workaround (it would be better if we had system removing), and avoids cluttering the main codebase for now.
My rationale for this was that I want to use the custom visibility checking just for some entities. That way anything else can be handled by bevy. Eq: 2d game with tile world. Tiles would be handled by my custom visibility checking system while everything else - player and npc characters, dynamic structures on tiles, etc would be handled by bevy. So disabling bevy's |
That much makes sense to me 🤔 This can be improved by removing the I'll try and get more opinions on this though. |
This can be error prone because the custom system must be order after The example would be changed from this: add_systems(PostUpdate,
custom_visibility_check.in_set(VisibilitySystems::CustomCheckVisibility)) to this: add_systems(PostUpdate,
custom_visibility_check.in_set(VisibilitySystems::CheckVisibility).after(check_visibility)) I think this is from developer's UX worse because it's another thing you have to keep in mind. |
Ah, I see. In that case, I like your custom system set solution better than rolling it into |
This new system set should be part of bevy ? /// Label for systems which do their own custom visibility checking.
#[derive(Debug, Hash, PartialEq, Eq, Clone, SystemSet)]
pub struct CustomCheckVisibilitySystems; |
Yeah, your existing code is fine. I'm just not convinced that this is the best approach (broadly) to the problems outlined in the issue 🤔 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Swapping to a neutral review.
Allow users create to opt-out of bevy's
check_visibility
system and to create their own.Personally I am not too happy with this. While it gets the job done it's quite hack-job. I would like to see a better pr in future which refactors how
check_visibility
and custom check visibility systems work and interact.Also I think I need better comments for my additions.
Objective
check_visibility
systemcheck_visibility
systemSolution
CustomVisibilityCheck
and addWithout<CustomVisibilityCheck>
tocheck_visibility
's queryVisibilitySystems
system setCustomCheckVisibility
and order it aftercheck_visibility
Testing
Did you test these changes? If so, how?
I tested it with sprites and mesh3d, meshmaterial3d entities
Are there any parts that need more testing?
I am not sure
How can other people (reviewers) test your changes? Is there anything specific they need to know?
They need to properly create the system and it's logic, add it to app and annotate entities with the marker component
If relevant, what platforms did you test these changes on, and are there any important ones you can't test?
Should be platform independent
Showcase
Users of this must do what
check_visibility
does except clearing camera'sVisibleEntities
orPreviousVisibleEntities
.You will have 2 responsibilities (not in order).
Set entity's
ViewVisibility
. You must either set it as visible or hidden. To do so you must use your custom method - After all you are opting-out because it's faster than parallel frustum culling using aabb checks and visibility ranges, right ? - while maybe respectingInheritedVisibility
,NoFrustumCulling
,VisibilityClass
and others. It must be set every frameExtend camera's
VisibleEntities
. If camera is active and entities are in it's view (see 1.) then you must add the entities to the correct visibility class insideVisibleEntities
or they will be ignored. It must be set every frameBut other things like shadows depend on other components so if your system is wrong - if you will set wrong
ViewVisibility
/VisibleEntities
- it will not change how shadows and etc are rendered.Here's modified example `3d_shapes`
Modified example highlights:
Adding our custom
check_visibility
system toApp
Adding opt-out component to shape entities
and the system itself