feat: visibility component propagateToChildren

[pravusjif]

Add propagate_to_children field to PBVisibilityComponent.

The rules for propagation are introduced as code comments and are:

1. If child has own PBVisibilityComponent -> Own component takes priority, skip in propagation
2. Child's PBVisibilityComponent removed -> Re-inherit from parent hierarchy
3. Child has own component + propagateToChildren=TRUE -> Child's propagation takes over for grandchildren (blocks ancestor)
4. Child has own component + propagateToChildren=FALSE -> "Pass-through": grandchildren inherit from ancestor, not child
5. Entity reparented into non-propagating hierarchy -> Reset to visible
6. Entity reparented into propagating hierarchy -> Inherit new hierarchy visibility
7. Reparented entity has children -> Propagate visibility to all descendants of reparented entity
8. Parent's PBVisibilityComponent removed -> Children reset to visible

Related PRS

• chore: visibility component propagateToChildren (experimental) #329
• chore: visibility component propagate to children (experimental) js-sdk-toolchain#1260
• chore: sdk visibility component propagate to children unity-explorer#6442
• chore: sdk visibility component propagation test scene sdk7-test-scenes#39

[github-actions]

Test this pull request

• The @dcl/protocol package can be tested in scenes by running

  npm install "https://sdk-team-cdn.decentraland.org/@dcl/protocol/branch//dcl-protocol-1.0.0-20440016425.commit-449da37.tgz"

[robtfm]

it's quite complex to read the rules, i think it is more simply (and still completely) expressed with:

- any own visibility component takes priority
- if no own visibility component, visibility is determined by visibility of the nearest parent with propagate = true
- if no own component and no parent with propagate = true, visibility is "visible"
- visibility is always updated, whenever hierarchy, parent component or own component changes

[robtfm]

the current rules are useful for implementers though...

    // Propagation follows certain rules:
    // 1. If child has own PBVisibilityComponent -> Own component takes priority, skip in propagation
    // 2. Child's PBVisibilityComponent removed -> Re-inherit from parent hierarchy
    // 3. Child has own component + propagateToChildren=TRUE -> Child's propagation takes over for grandchildren (blocks ancestor)
    // 4. Child has own component + propagateToChildren=FALSE -> "Pass-through": grandchildren inherit from ancestor, not child
    // 5. Entity reparented into non-propagating hierarchy -> Reset to visible
    // 6. Entity reparented into propagating hierarchy -> Inherit new hierarchy visibility
    // 7. Reparented entity has children -> Propagate visibility to all descendants of reparented entity
    // 8. Parent's PBVisibilityComponent removed -> Children reset to visible

so it's up to you i guess, i approve as is, the functionality and description is sound as is

[robtfm]

maybe it should be default=true?

i have it like that in bevy currently and didn't see any issues (though maybe that's because they are .... invisible)

[pravusjif]

maybe it should be default=true?

i have it like that in bevy currently and didn't see any issues (though maybe that's because they are .... invisible)

I wouldn't put it to default true because that will potentially break existent scenes behaviour.

Imagine a scene that uses the VisibilityComponent today and if we start using the propagation to be true by default that current usage would start hiding things that weren't intended to be hidden...

I know at least content team does use the component so ti will at the very least affect probably every complex scene already deployed by the content team (minigames, genesis plaza, some festival scenes)