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

GlobalTransform not being updated #3329

Closed
yilinwei opened this issue Dec 14, 2021 · 6 comments
Closed

GlobalTransform not being updated #3329

yilinwei opened this issue Dec 14, 2021 · 6 comments
Labels
A-Hierarchy Parent-child entity hierarchies A-Transform Translations, rotations and scales C-Bug An unexpected or incorrect behavior C-Usability A simple quality-of-life change that makes Bevy easier to use

Comments

@yilinwei
Copy link
Contributor

Bevy version

ffecb05

Operating system & version

Linux

What you did

Link to repo here.

The only file is src/main.rs. The bevy submodule is simply to add some extra logging.

What you expected to happen

The TransformPlugin has two systems parent_update and transform_propagate. parent_update is always meant to run before transform_propagate according to the run criteria.

If an Entity has a Parent but no Children, parent_update creates one. The transform_propagate then queries from the root nodes and updates the GlobalTransform.

Whether you insert a Children component shouldn't matter. The Children should be inserted by the parent_update and the transform_propagate should pick up the inserted Children.

What actually happened

Whether you insert the Children does matter, if you comment the line out you get the unexpected matrix: log line, whereas otherwise you don't.

Adding some more println! statements, the root node query doesn't pick up Children at all - it's empty, but you can clearly see the new Children in the later query and adding the println! directly where the Children is added shows that it does hit that part of the code.

Additional information

@yilinwei yilinwei added C-Bug An unexpected or incorrect behavior S-Needs-Triage This issue needs to be labelled labels Dec 14, 2021
@alice-i-cecile alice-i-cecile added A-Transform Translations, rotations and scales C-Usability A simple quality-of-life change that makes Bevy easier to use C-Bug An unexpected or incorrect behavior and removed S-Needs-Triage This issue needs to be labelled C-Bug An unexpected or incorrect behavior labels Dec 14, 2021
@alice-i-cecile
Copy link
Member

Adding some more println! statements, the root node query doesn't pick up Children at all - it's empty, but you can clearly see the new Children in the later query and adding the println! directly where the Children is added shows that it does hit that part of the code.

The reason for this is that Commands aren't processed until the end of the current stage. The behavior observed here is probably expected, but unfortunate.

yilinwei added a commit to yilinwei/bevy that referenced this issue Dec 15, 2021
`parent_update` and `transform_propagate` run in the same stage but
`parent_update` can spawn `Children`. This means that the `system`
can enter an inconsistent state where the `GlobalTransform` has not
been updated on `Children` when spawning an `Entity` where the `Parent`
does not have an existing `Children` component.

Introduce a marker trait, `DirtyParent`, so that the system will revert
to the correct state the next time the systems run.
yilinwei added a commit to yilinwei/bevy that referenced this issue Dec 15, 2021
`parent_update` and `transform_propagate` run in the same stage but
`parent_update` can spawn `Children`. This means that the `system`
can enter an inconsistent state where the `GlobalTransform` has not
been updated on `Children` when spawning an `Entity` where the `Parent`
does not have an existing `Children` component.

Introduce a marker trait, `DirtyParent`, so that the system will revert
to the correct state the next time the systems run.
yilinwei added a commit to yilinwei/bevy that referenced this issue Dec 15, 2021
`parent_update` and `transform_propagate` run in the same stage but `parent_update` can spawn `Children`. This means that the `system` can enter an inconsistent state where the `GlobalTransform` has not been updated on `Children` when spawning an `Entity` where the `Parent` does not have an existing `Children` component.

Introduce a marker trait, `DirtyParent`, so that the system will revert to the correct state the next time the systems run.
yilinwei added a commit to yilinwei/bevy that referenced this issue Dec 15, 2021
`parent_update` and `transform_propagate` run in the same stage but `parent_update` can spawn `Children`. This means that the `system` can enter an inconsistent state where the `GlobalTransform` has not been updated on `Children` when spawning an `Entity` where the `Parent` does not have an existing `Children` component.

Introduce a marker trait, `DirtyParent`, so that the system will revert to the correct state the next time the systems run.
@lukors
Copy link
Contributor

lukors commented Jan 29, 2022

I've ran into this twice now, and my solution has been to manually update the GlobalTransform to match the Transform. I've read this is bad practice, are there better workarounds?

@yilinwei
Copy link
Contributor Author

@lukors

The easiest way to get around this issue is to insert the Children component on the parent entity when spawning it.

@lukors
Copy link
Contributor

lukors commented Jan 29, 2022

@yilinwei I tried adding .insert(Children::with(&[])); when spawning my parent entity. But when I later spawn an entity, set its transform and make it a child of the parent with commands.entity(parent).push_children(&[entity]) in the same frame, the transform does not take.

@yilinwei
Copy link
Contributor Author

@lukors

The below in a single system should work. It is a little finicky, but it's easiest to check the behaviour by vendoring bevy and debugging the two systems.

let parent = commands.spawn().insert_bundle(
  (Children::with(&[]), Transform::default(), GlobalTransform::default())
).id();

let child = commands.spawn().insert_bundle(
  (Parent(parent), Transform::default(), GlobalTransform::default())
);

@maniwani
Copy link
Contributor

maniwani commented Mar 8, 2022

So, internally, we should be applying the commands from parent_update before transform_propagate runs, but we can't do that nicely right now because of all the awkwardness around stages and exclusive system insertion points.

This could be resolved with the changes proposed in bevyengine/rfcs#45.

@alice-i-cecile alice-i-cecile added the A-Hierarchy Parent-child entity hierarchies label Apr 4, 2022
DJMcNab pushed a commit to DJMcNab/bevy that referenced this issue Apr 26, 2022
`parent_update` and `transform_propagate` run in the same stage but `parent_update` can spawn `Children`. This means that the `system` can enter an inconsistent state where the `GlobalTransform` has not been updated on `Children` when spawning an `Entity` where the `Parent` does not have an existing `Children` component.

Introduce a marker trait, `DirtyParent`, so that the system will revert to the correct state the next time the systems run.
DJMcNab pushed a commit to DJMcNab/bevy that referenced this issue Apr 26, 2022
`parent_update` and `transform_propagate` run in the same stage but `parent_update` can spawn `Children`. This means that the `system` can enter an inconsistent state where the `GlobalTransform` has not been updated on `Children` when spawning an `Entity` where the `Parent` does not have an existing `Children` component.

Introduce a marker trait, `DirtyParent`, so that the system will revert to the correct state the next time the systems run.
bors bot pushed a commit that referenced this issue May 2, 2022
…ren (#4608)

Supercedes #3340, and absorbs the test from there.

# Objective

- Fixes #3329

## Solution

- If the `Children` component has changed, we currently do not have a way to know how it has changed.
- Therefore, we must update the hierarchy downwards  from that point to be correct.

Co-authored-by: Daniel McNab <36049421+DJMcNab@users.noreply.github.com>
bors bot pushed a commit that referenced this issue May 2, 2022
…ren (#4608)

Supercedes #3340, and absorbs the test from there.

# Objective

- Fixes #3329

## Solution

- If the `Children` component has changed, we currently do not have a way to know how it has changed.
- Therefore, we must update the hierarchy downwards  from that point to be correct.

Co-authored-by: Daniel McNab <36049421+DJMcNab@users.noreply.github.com>
@bors bors bot closed this as completed in a011f4d May 2, 2022
exjam pushed a commit to exjam/bevy that referenced this issue May 22, 2022
…ren (bevyengine#4608)

Supercedes bevyengine#3340, and absorbs the test from there.

# Objective

- Fixes bevyengine#3329

## Solution

- If the `Children` component has changed, we currently do not have a way to know how it has changed.
- Therefore, we must update the hierarchy downwards  from that point to be correct.

Co-authored-by: Daniel McNab <36049421+DJMcNab@users.noreply.github.com>
ItsDoot pushed a commit to ItsDoot/bevy that referenced this issue Feb 1, 2023
…ren (bevyengine#4608)

Supercedes bevyengine#3340, and absorbs the test from there.

# Objective

- Fixes bevyengine#3329

## Solution

- If the `Children` component has changed, we currently do not have a way to know how it has changed.
- Therefore, we must update the hierarchy downwards  from that point to be correct.

Co-authored-by: Daniel McNab <36049421+DJMcNab@users.noreply.github.com>
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 A-Transform Translations, rotations and scales C-Bug An unexpected or incorrect behavior C-Usability A simple quality-of-life change that makes Bevy easier to use
Projects
None yet
4 participants