What problem does this solve or what need does it fill?
bevy_hierarchy is in an uncomfortable place: technically existing outside of bevy_ecs, but in practice generally privileged by the ecosystem.
One day (🥺), #3742 will replace bevy_hierarchy completely, allowing for generalized relations in a more robust fashion. This needs to be part of bevy_ecs, so bevy_hierarchy's days are numbered.
What solution would you like?
Move the core parent-child components and logic to bevy_ecs.
Feature flag this under an on-by-default hierarchy flag.
Move any transform propagation logic to bevy_transform.
Move any visibility propagation logic to bevy_render.
As follow-up, consider changing the default despawn behavior to act recursively.
What alternative(s) have you considered?
We could leave this alone, but this is causing problems when trying to tackle how #11090 interacts with hierarchies.
Additional context
Desired by @mockersf (maintainer), @maniwani (SME-ECS) and myself (SME-ECS and maintainer).
What problem does this solve or what need does it fill?
bevy_hierarchy
is in an uncomfortable place: technically existing outside ofbevy_ecs
, but in practice generally privileged by the ecosystem.One day (🥺), #3742 will replace
bevy_hierarchy
completely, allowing for generalized relations in a more robust fashion. This needs to be part ofbevy_ecs
, sobevy_hierarchy
's days are numbered.What solution would you like?
bevy_ecs
.hierarchy
flag.bevy_transform
.bevy_render
.As follow-up, consider changing the default despawn behavior to act recursively.
What alternative(s) have you considered?
We could leave this alone, but this is causing problems when trying to tackle how #11090 interacts with hierarchies.
Additional context
Desired by @mockersf (maintainer), @maniwani (SME-ECS) and myself (SME-ECS and maintainer).