-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
Comments
The reason for this is that |
`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.
`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.
`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.
`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.
I've ran into this twice now, and my solution has been to manually update the |
The easiest way to get around this issue is to insert the |
@yilinwei I tried adding |
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())
); |
So, internally, we should be applying the commands from This could be resolved with the changes proposed in bevyengine/rfcs#45. |
`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.
`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.
…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 <[email protected]>
…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 <[email protected]>
…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 <[email protected]>
…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 <[email protected]>
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 systemsparent_update
andtransform_propagate
.parent_update
is always meant to run beforetransform_propagate
according to the run criteria.If an
Entity
has aParent
but noChildren
,parent_update
creates one. Thetransform_propagate
then queries from the root nodes and updates theGlobalTransform
.Whether you insert a
Children
component shouldn't matter. TheChildren
should be inserted by theparent_update
and thetransform_propagate
should pick up the insertedChildren
.What actually happened
Whether you insert the
Children
does matter, if you comment the line out you get theunexpected matrix:
log line, whereas otherwise you don't.Adding some more
println!
statements, the root node query doesn't pick upChildren
at all - it's empty, but you can clearly see the newChildren
in the later query and adding theprintln!
directly where theChildren
is added shows that it does hit that part of the code.Additional information
The text was updated successfully, but these errors were encountered: