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

Adding Entity as child to other entity makes it invisible #5081

Closed
ashirviskas opened this issue Jun 23, 2022 · 9 comments
Closed

Adding Entity as child to other entity makes it invisible #5081

ashirviskas opened this issue Jun 23, 2022 · 9 comments
Labels
A-Rendering Drawing game state to the screen A-Transform Translations, rotations and scales C-Bug An unexpected or incorrect behavior

Comments

@ashirviskas
Copy link

Bevy version

0.7.0

[Optional] Relevant system information

OS: Arch Linux
Cargo version: cargo 1.63.0-nightly

2022-06-23T15:29:27.512314Z  INFO bevy_render::renderer: AdapterInfo { name: "AMD RADV RENOIR", vendor: 4098, device: 5708, device_type: IntegratedGpu, backend: Vulkan }

What you did

I tried adding new entities as children to parent entity.

What went wrong

Child entities are invisible, but they still function (as colliders for example).

Additional information

Code that works and renders all entities (only included shortened version for the left wall, but code does the same for all of the walls):

let cell_wall_entity_left = commands
    .spawn()
    .insert_bundle(
        SpriteBundle {
            sprite: Sprite {
                color: Color::rgb(0.5, 0.5, 0.3),
                ..default()
            },
            transform: Transform {
                translation: wall_position.extend(0.1),
                scale: Vec3::new(40., 5. , 1.),
                ..default()
            },
            ..default()
        },
    )
    .insert(Collider)
    .id();
let parent_cell = commands
    .spawn_bundle(CellBundle::new(
        SpriteBundle {
            sprite: Sprite {
                color: cell_type.to_color(),
                ..default()
            },
            transform: Transform {
                translation: cell_position.extend(0.),
                scale: Vec3::new(CELL_SIZE.x, CELL_SIZE.y, 1.0),
                ..default()
            },
            ..default()
        },
        Cell::new(),
        Collider,
    ));

image

If I change the last line to:

    )).insert(CellType::Cell).push_children(&[cell_wall_entity_left]);

Then it looks like this:
image

@ashirviskas ashirviskas added C-Bug An unexpected or incorrect behavior S-Needs-Triage This issue needs to be labelled labels Jun 23, 2022
@DJMcNab
Copy link
Member

DJMcNab commented Jun 23, 2022

Are you sure it's invisible and not just outside the screen boundaries?

You have requested for the wall to be placed at (CELL_SIZE.x*wall_position.x, CELL_SIZE.y*wall_position.y). I would be surprised if that is within the screenshot area you have given, given its small size.

@DJMcNab DJMcNab added A-Rendering Drawing game state to the screen A-Transform Translations, rotations and scales and removed S-Needs-Triage This issue needs to be labelled labels Jun 23, 2022
@tim-blackbird
Copy link
Contributor

Transform defines a position relative to a parent.
So the final position of cell_wall_entity_left is it's Transform plus the Transform of the parent.
The bug here is actually the collider still being in that spot. I believe this is a known issue with bevy_rapier.

@ashirviskas
Copy link
Author

You have requested for the wall to be placed at (CELL_SIZE.xwall_position.x, CELL_SIZE.ywall_position.y). I would be surprised if that is within the screenshot area you have given, given its small size.

I might have. So basically you have to use sizes/positions for children relative to the parent. I think I got it now, thank you!

@ashirviskas
Copy link
Author

The bug here is actually the collider still being in that spot. I believe this is a known issue with bevy_rapier.

Oh, that might explain it. Any issue I could track?

@tim-blackbird
Copy link
Contributor

Hmm. Looks like this issue should be fixed in version 0.14 of bevy_rapier dimforge/bevy_rapier#172

@ashirviskas
Copy link
Author

ashirviskas commented Jun 23, 2022

Huh, I've upgraded to bevy_rapier2d = "0.14.1" but it does not seem fixed as particles can still get through the child walls, even though they're displayed correctly.

@ashirviskas
Copy link
Author

My cell wall spawning code and Cell spawning code + adding cell walls as children that does not work as intended. I can now see the walls being rendered properly, but their collider boxes are in the middle of the world and you can see the particles bouncing off of them:

Peek.2022-06-23.20-15.mp4

@tim-blackbird
Copy link
Contributor

Try using the debug-render feature of bevy_rapier2d and fiddle with your code a bit. Can't help much as I'm on my phone right now.

@ashirviskas
Copy link
Author

Try using the debug-render feature of bevy_rapier2d and fiddle with your code a bit. Can't help much as I'm on my phone right now.

Thanks for the tips! I enabled debug-render, and refactored child spawning several times, but still no go. It either messes up the Sprite or the Collider position. Can't have both it seems

bors bot pushed a commit that referenced this issue Sep 19, 2022
# Objective

A common pitfall since 0.8 is the requirement on `ComputedVisibility`
being present on all ancestors of an entity that itself has
`ComputedVisibility`, without which, the entity becomes invisible.

I myself hit the issue and got very confused, and saw a few people hit
it as well, so it makes sense to provide a hint of what to do when such
a situation is encountered.

- Fixes #5849
- Closes #5616
- Closes #2277 
- Closes #5081

## Solution

We now check that all entities with both a `Parent` and a
`ComputedVisibility` component have parents that themselves have a
`ComputedVisibility` component.

Note that the warning is only printed once.

We also add a similar warning to `GlobalTransform`.

This only emits a warning. Because sometimes it could be an intended
behavior.

Alternatives:
- Do nothing and keep repeating to newcomers how to avoid recurring
  pitfalls
- Make the transform and visibility propagation tolerant to missing
  components (#5616)
- Probably archetype invariants, though the current draft would not
  allow detecting that kind of errors

---

## Changelog

- Add a warning when encountering dubious component hierarchy structure


Co-authored-by: Nicola Papale <nicopap@users.noreply.github.com>
@bors bors bot closed this as completed in 6c5403c Sep 19, 2022
james7132 pushed a commit to james7132/bevy that referenced this issue Oct 19, 2022
# Objective

A common pitfall since 0.8 is the requirement on `ComputedVisibility`
being present on all ancestors of an entity that itself has
`ComputedVisibility`, without which, the entity becomes invisible.

I myself hit the issue and got very confused, and saw a few people hit
it as well, so it makes sense to provide a hint of what to do when such
a situation is encountered.

- Fixes bevyengine#5849
- Closes bevyengine#5616
- Closes bevyengine#2277 
- Closes bevyengine#5081

## Solution

We now check that all entities with both a `Parent` and a
`ComputedVisibility` component have parents that themselves have a
`ComputedVisibility` component.

Note that the warning is only printed once.

We also add a similar warning to `GlobalTransform`.

This only emits a warning. Because sometimes it could be an intended
behavior.

Alternatives:
- Do nothing and keep repeating to newcomers how to avoid recurring
  pitfalls
- Make the transform and visibility propagation tolerant to missing
  components (bevyengine#5616)
- Probably archetype invariants, though the current draft would not
  allow detecting that kind of errors

---

## Changelog

- Add a warning when encountering dubious component hierarchy structure


Co-authored-by: Nicola Papale <nicopap@users.noreply.github.com>
james7132 pushed a commit to james7132/bevy that referenced this issue Oct 28, 2022
# Objective

A common pitfall since 0.8 is the requirement on `ComputedVisibility`
being present on all ancestors of an entity that itself has
`ComputedVisibility`, without which, the entity becomes invisible.

I myself hit the issue and got very confused, and saw a few people hit
it as well, so it makes sense to provide a hint of what to do when such
a situation is encountered.

- Fixes bevyengine#5849
- Closes bevyengine#5616
- Closes bevyengine#2277 
- Closes bevyengine#5081

## Solution

We now check that all entities with both a `Parent` and a
`ComputedVisibility` component have parents that themselves have a
`ComputedVisibility` component.

Note that the warning is only printed once.

We also add a similar warning to `GlobalTransform`.

This only emits a warning. Because sometimes it could be an intended
behavior.

Alternatives:
- Do nothing and keep repeating to newcomers how to avoid recurring
  pitfalls
- Make the transform and visibility propagation tolerant to missing
  components (bevyengine#5616)
- Probably archetype invariants, though the current draft would not
  allow detecting that kind of errors

---

## Changelog

- Add a warning when encountering dubious component hierarchy structure


Co-authored-by: Nicola Papale <nicopap@users.noreply.github.com>
ItsDoot pushed a commit to ItsDoot/bevy that referenced this issue Feb 1, 2023
# Objective

A common pitfall since 0.8 is the requirement on `ComputedVisibility`
being present on all ancestors of an entity that itself has
`ComputedVisibility`, without which, the entity becomes invisible.

I myself hit the issue and got very confused, and saw a few people hit
it as well, so it makes sense to provide a hint of what to do when such
a situation is encountered.

- Fixes bevyengine#5849
- Closes bevyengine#5616
- Closes bevyengine#2277 
- Closes bevyengine#5081

## Solution

We now check that all entities with both a `Parent` and a
`ComputedVisibility` component have parents that themselves have a
`ComputedVisibility` component.

Note that the warning is only printed once.

We also add a similar warning to `GlobalTransform`.

This only emits a warning. Because sometimes it could be an intended
behavior.

Alternatives:
- Do nothing and keep repeating to newcomers how to avoid recurring
  pitfalls
- Make the transform and visibility propagation tolerant to missing
  components (bevyengine#5616)
- Probably archetype invariants, though the current draft would not
  allow detecting that kind of errors

---

## Changelog

- Add a warning when encountering dubious component hierarchy structure


Co-authored-by: Nicola Papale <nicopap@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Rendering Drawing game state to the screen A-Transform Translations, rotations and scales C-Bug An unexpected or incorrect behavior
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants