Make Visibility affect children entities

[nicopap]

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 ActualVisibility non-public component that is given to all children of Changed<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 Inheritance component or as an additional field to Parent and Children that 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

• `Visibility` inheritance for ui entities #3723
• discord discussion
• relations: Entity-entity relations 🌈  #3742

[forbjok]

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]

@alice-i-cecile This might be a duplicate of #838.

[alice-i-cecile]

Agreed. Closing as a duplicate of #838.

[nicopap]

Note that as discussed in #3723 For UI entities, it's possible to get that behavior by setting the display field of the Style component to Display::None.