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

Allow transformation trees to be subtrees of non-transformation trees #2402

Open
ISibboI opened this issue Jun 27, 2021 · 1 comment
Open
Labels
A-Hierarchy Parent-child entity hierarchies C-Feature A new feature, making something new possible C-Usability A targeted quality-of-life change that makes Bevy easier to use S-Needs-Design-Doc This issue or PR is particularly complex, and needs an approved design doc before it can be merged

Comments

@ISibboI
Copy link

ISibboI commented Jun 27, 2021

What problem does this solve or what need does it fill?

I'd like to organise my game level as a tree, with both non-geometrical entities and geometrical entities. For keeping order and easy unloading, it would be nice to be able to root transformation trees within another tree.

What solution would you like?

If an entity E that has both a GlobalTransform and a Transform has a parent that is missing at least one of those, then the entity should still be a valid root of a transformation tree. That is, the transformation system should update its global transformation in the same way as if E would not have any parent.

Currently, such an entity E is ignored by the transformation system, and is simply rendered at the coordinate root, independent of its transform.

What alternative(s) have you considered?

Have two or more separate trees for each level that are not related in any way by Parent or Child relationships. This is possible, but not very desirable as all the bookkeeping for these trees would need to be implemented by the game developer. Also, it prevents the game developer from representing the logical structure of their entities correctly.

Alternatively, the root of a level could get a default Transform and GlobalTransform. However this seems hacky, as the root is merely a logical dummy node and has no representation in the game world.

Additional context

A game level could for example be structured like this:

  • LevelRoot
    • EventTriggers
    • SoundTriggers
    • WorldSprites (with Transform and GlobalTransform)
    • PlayerSprites (with Transform and GlobalTransform)
@ISibboI ISibboI added C-Feature A new feature, making something new possible S-Needs-Triage This issue needs to be labelled labels Jun 27, 2021
@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 and removed S-Needs-Triage This issue needs to be labelled labels Jul 8, 2021
@alice-i-cecile
Copy link
Member

This is part of the broader question of how we handle relations (#1627). Would you be content with specifying both ChildOf and TransformChildOf for each entity pair if relations were fully implemented?

Check the RFC for a more complete explanation and example syntax.

@alice-i-cecile alice-i-cecile added the S-Needs-Design-Doc This issue or PR is particularly complex, and needs an approved design doc before it can be merged label Dec 12, 2021
@alice-i-cecile alice-i-cecile added A-Hierarchy Parent-child entity hierarchies and removed A-ECS Entities, components, systems, and events labels Apr 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Hierarchy Parent-child entity hierarchies C-Feature A new feature, making something new possible C-Usability A targeted quality-of-life change that makes Bevy easier to use S-Needs-Design-Doc This issue or PR is particularly complex, and needs an approved design doc before it can be merged
Projects
None yet
Development

No branches or pull requests

2 participants