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

[Merged by Bors] - fix parenting of scenes #2410

Closed
wants to merge 5 commits into from

Conversation

mockersf
Copy link
Member

Objective

Fix #2406

Scene parenting was not done completely, leaving the hierarchy maintenance to the standard system. As scene spawning happens in stage PreUpdate and hierarchy maintenance in stage PostUpdate, this left the scene in an invalid state parent wise for part of a frame

Solution

Also add/update the Children component when spawning the scene.

I kept the Children component as a SmallVec, it could be moved to an HashSet to guarantee uniqueness

@github-actions github-actions bot added the S-Needs-Triage This issue needs to be labelled label Jun 28, 2021
@NathanSWard NathanSWard added C-Bug An unexpected or incorrect behavior core and removed S-Needs-Triage This issue needs to be labelled labels Jun 28, 2021
@NathanSWard
Copy link
Contributor

NathanSWard commented Jun 28, 2021

Could we add a test for this?
(You can probably just copy the code from the related issue and use that. Or make something similar)

@mockersf
Copy link
Member Author

Not easily possible to add a test, at least as a unit test: it would need to access assets, which can't be added without the asset server, which needs a thread pool... this is more an integration test, and I would rather not add those at the moment

@NathanSWard
Copy link
Contributor

this is more an integration test, and I would rather not add those at the moment

I would argue and say then, we should start to add integration testing haha 😄
If this fix was a response to a bug, we should prevent this bug from happening again if/when this logic gets refactored/changed in the future.

@NathanSWard
Copy link
Contributor

I'm happy not to block this PR on testing, however, we should seriously consider integration testing for scenarios like this.

Comment on lines 282 to 285
let children = &**children;
let mut children = children.to_vec();
children.push(entity);
parent_entity.insert(Children::with(&children));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems like quite a bit of vector coppying.
Is it possible to just push entity to the parent's children component?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the SmallVec inside Children is not mutably accessible because it caused a lot of sync issues:

pub struct Children(pub(crate) SmallVec<[Entity; 8]>);

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be nice to add a comment about this?

@cart cart added this to the Bevy 0.6 milestone Jul 1, 2021
@cart cart added the S-Pre-Relicense This PR was made before Bevy added the Apache license. Cannot be merged or used for other work label Jul 23, 2021
@mockersf mockersf removed the S-Pre-Relicense This PR was made before Bevy added the Apache license. Cannot be merged or used for other work label Jul 24, 2021
Comment on lines 282 to 285
let children = &**children;
let mut children = children.to_vec();
children.push(entity);
parent_entity.insert(Children::with(&children));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be nice to add a comment about this?

if !entity_mut.contains::<Parent>() {
entity_mut.insert(Parent(parent));
}
}
// Add the scene root to the `Children` component on the parent
if let Some(mut parent_entity) = world.get_entity_mut(parent) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This feels like quite the hack, both because we're duplicating parenting logic in scenes and because of the children copy. I want to fix this bug, but maybe we need a slightly more holistic solution. Hard-coding logic here seems like a reasonable short term fix (with a TODO to improve this later), but reallocating Children for each child in a scene is hard to accept. One way to implement this without directly exposing internals is to add a new AddChild command to bevy_transform, which takes advantage of crate-only access to the Children internals. Then you could just construct the Command for each entity and immediately apply it (no need for command buffers / allocations).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(AddChild would transactionally set the proper values for the Parent and Children components)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

added AddChild command. It's the only command with pub fields to be able to create and execute it directly

@cart
Copy link
Member

cart commented Dec 23, 2021

bors r+

bors bot pushed a commit that referenced this pull request Dec 23, 2021
# Objective

Fix #2406 

Scene parenting was not done completely, leaving the hierarchy maintenance to the standard system. As scene spawning happens in stage `PreUpdate` and hierarchy maintenance in stage `PostUpdate`, this left the scene in an invalid state parent wise for part of a frame

## Solution

Also add/update the `Children` component when spawning the scene.

I kept the `Children` component as a `SmallVec`, it could be moved to an `HashSet` to guarantee uniqueness


Co-authored-by: François <8672791+mockersf@users.noreply.github.com>
@bors
Copy link
Contributor

bors bot commented Dec 23, 2021

Build failed:

@cart
Copy link
Member

cart commented Dec 23, 2021

bors r+

bors bot pushed a commit that referenced this pull request Dec 23, 2021
# Objective

Fix #2406 

Scene parenting was not done completely, leaving the hierarchy maintenance to the standard system. As scene spawning happens in stage `PreUpdate` and hierarchy maintenance in stage `PostUpdate`, this left the scene in an invalid state parent wise for part of a frame

## Solution

Also add/update the `Children` component when spawning the scene.

I kept the `Children` component as a `SmallVec`, it could be moved to an `HashSet` to guarantee uniqueness


Co-authored-by: François <8672791+mockersf@users.noreply.github.com>
@bors
Copy link
Contributor

bors bot commented Dec 23, 2021

Build failed (retrying...):

bors bot pushed a commit that referenced this pull request Dec 23, 2021
# Objective

Fix #2406 

Scene parenting was not done completely, leaving the hierarchy maintenance to the standard system. As scene spawning happens in stage `PreUpdate` and hierarchy maintenance in stage `PostUpdate`, this left the scene in an invalid state parent wise for part of a frame

## Solution

Also add/update the `Children` component when spawning the scene.

I kept the `Children` component as a `SmallVec`, it could be moved to an `HashSet` to guarantee uniqueness


Co-authored-by: François <8672791+mockersf@users.noreply.github.com>
@bors
Copy link
Contributor

bors bot commented Dec 23, 2021

Build failed:

@cart
Copy link
Member

cart commented Dec 23, 2021

bors r+

bors bot pushed a commit that referenced this pull request Dec 23, 2021
# Objective

Fix #2406 

Scene parenting was not done completely, leaving the hierarchy maintenance to the standard system. As scene spawning happens in stage `PreUpdate` and hierarchy maintenance in stage `PostUpdate`, this left the scene in an invalid state parent wise for part of a frame

## Solution

Also add/update the `Children` component when spawning the scene.

I kept the `Children` component as a `SmallVec`, it could be moved to an `HashSet` to guarantee uniqueness


Co-authored-by: François <8672791+mockersf@users.noreply.github.com>
@bors
Copy link
Contributor

bors bot commented Dec 23, 2021

Build failed (retrying...):

bors bot pushed a commit that referenced this pull request Dec 23, 2021
# Objective

Fix #2406 

Scene parenting was not done completely, leaving the hierarchy maintenance to the standard system. As scene spawning happens in stage `PreUpdate` and hierarchy maintenance in stage `PostUpdate`, this left the scene in an invalid state parent wise for part of a frame

## Solution

Also add/update the `Children` component when spawning the scene.

I kept the `Children` component as a `SmallVec`, it could be moved to an `HashSet` to guarantee uniqueness


Co-authored-by: François <8672791+mockersf@users.noreply.github.com>
@bors
Copy link
Contributor

bors bot commented Dec 23, 2021

Build failed:

@cart
Copy link
Member

cart commented Dec 24, 2021

bors r+

bors bot pushed a commit that referenced this pull request Dec 24, 2021
# Objective

Fix #2406 

Scene parenting was not done completely, leaving the hierarchy maintenance to the standard system. As scene spawning happens in stage `PreUpdate` and hierarchy maintenance in stage `PostUpdate`, this left the scene in an invalid state parent wise for part of a frame

## Solution

Also add/update the `Children` component when spawning the scene.

I kept the `Children` component as a `SmallVec`, it could be moved to an `HashSet` to guarantee uniqueness


Co-authored-by: François <8672791+mockersf@users.noreply.github.com>
@bors bors bot changed the title fix parenting of scenes [Merged by Bors] - fix parenting of scenes Dec 24, 2021
@bors bors bot closed this Dec 24, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-Bug An unexpected or incorrect behavior
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Panic when despawning entity with child scene just after creation
5 participants