Repository navigation
Make Visibility affect children entities #3874
Description
What problem does this solve?
It's useful to "bulk" toggle the visibility of a group of entities.
What problems does it introduce?
User may want to toggle visibility of parent without affecting the visibility of the children. Typically, you might want some parent to become invisible while the children are still visible in cases where you also take advantage of parent/child relationship for Transform/GlobalTransform.
What solution would you like?
- My best guess would be a
ActualVisibilitynon-public component that is given to all children ofChanged<Visibility>entities. This would also require updating the component on hierarchy changes. - To be able to decouple transform hierarchy from visibility hierarchy, it would be advisable to add a
Inheritancecomponent or as an additional field toParentandChildrenthat let the user select which property is inherited (as suggested by @alice-i-cecile ) Note: this might be worth it's own separate PR
What alternative(s) have you considered?
- It might be possible to walk the hierarchy at render time to infer then whether to display or not the concerned entity.
- Relations 🌈
Additional context
Reacted by Alice Cecile, Andreas Weibye and m0nkfish
Activity
forbjok commentedon Feb 9, 2022
I kinda feel like shoehorning multiple different types of hierarchical relations into one component is less than ideal. I can think of at least 3 different use cases for it, which in some cases may be mutually exclusive.
The most obvious, and main one it's already used for is transforms. In addition to that, there's also the organizational purpose of being able to easily despawn a related group of entities (which can also currently be done with it), but you may not necessarily always want that group of objects to be anchored to each other position-wise or inherit visibility from each other.
For example, you may want to spawn a boss that consists of multiple entities, where some of them are lesser enemies that should move independently of the main boss entity. I suppose in most cases you could work around this by using container entities that have no visual component and make the "main" boss entity a child of that component alongside the other associated enemies, but it still kinda feels to me like these different use cases should just be entirely separate things.
SUPERCILEX commentedon May 9, 2022
@alice-i-cecile This might be a duplicate of #838.
alice-i-cecile commentedon May 10, 2022
Agreed. Closing as a duplicate of #838.
nicopap commentedon Jun 22, 2022
Note that as discussed in #3723 For UI entities, it's possible to get that behavior by setting the
displayfield of theStylecomponent toDisplay::None.