-
-
Notifications
You must be signed in to change notification settings - Fork 3.8k
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
Generic hierarchy propagation #5507
Conversation
Can you explain the differences between this approach and #4216 ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very excited about this. Though I think we still need more things (that can be added in the future):
- Independent hierarchies (I want to be able to declare two distinct hierarchies that spans the same entities)
- Ability to tolerate missing
ComputedGlobal::Local
with a default and propagating downward to other entities with aComputedGlobal
. (people wanted to reduce the amount of "required" components I think)
Well the biggest difference is that I hadn't seen it before...
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this. Have you investigated/thought through whether it will work for RenderLayers
too? I suppose Local
would be RenderLayers
, ToPropagate
would be RenderLayers
, the from_local
would just be a clone, combine_with_local
would be an intersection(?), and value_to_propagate
would be *self
? Seems pretty intuitive. And nice that it's reusable for any hierarchy someone might want to add.
Indeed it looks pretty similar to #4216 , but it not requiring the App extension thing seems like an improvement. |
Co-authored-by: Robert Swain <robert.swain@gmail.com>
Backlog cleanup: given that |
Objective
Transform
/GlobalTransform
andVisibility
/ComputedVisibility
Solution