-
-
Notifications
You must be signed in to change notification settings - Fork 3.4k
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
Add ViewNode to simplify render node management #8118
Conversation
I'd go with just ViewNode, or ViewNodeWrapper or something
Ok(()) is fine. The query failing isn't actually an error. It just means no views are relevant to that node, e.g. if the FXAA node exists but no views are using FXAA, then the node just has nothing to do, but that's not an error.
I'd remove it. There's no need to filter by the time it gets to the node, usually you filter earlier on in extract or prepare and stuff. Adding this just adds boilerplate and complexity for no benefit. |
Any reason you're not using ViewQueryNode for the main pass nodes? |
I should probably have made this a draft PR, but I wanted to play with the idea a bit first before updating everything. That's also the advantage of this approach, it doesn't force it on every node, but there's nothing blocking it for the main pass node. |
73de468
to
86539c6
Compare
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 really like the direction of this PR.
Doing the same for the resources in a followup PR would be great as well.
I second @JMS55's suggestion on naming: |
Renamed to ViewNode and ViewNodeRunner. I think I prefer Runner instead of Wrapper since it's a bit more explicit in my head. I also removed the filter since we agree that it seems unnecessary. |
3cbfa5e
to
b6f82e0
Compare
da15a35
to
c769440
Compare
I implemented a bunch more nodes. I added a new question to the description. Essentially, after this PR, most Nodes are just empty structs because they only held the view query state and a couple of them create an empty mutex that is initialized on the first run. I'm trying to impl FromWorld on the |
3fb1285
to
eb988fd
Compare
554802e
to
806ba7b
Compare
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.
Excellent job. Useful abstraction, also helps document the patterns used for render graph nodes in bevy.
a74e0a0
to
5b4cdee
Compare
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.
This looks great!
Just pushed some (very) minor tweaks:
- In the ViewNode interface, ROQueryItem can just be QueryItem for simplicity. The "read-onlyness" is implied by the ReadOnlyWorldQuery constraint
- I took this as a chance to use
&'static
everywhere (for consistency), rather than mixing and matching withRead<>
- Renamed ViewWorldQuery to ViewQuery to match the variable name and reduce "concept noise". I think "world-query-ness" can be implied here.
Objective
Query
on the associated view and make sure to update it manually and query it manually. This is verbose and error prone.Solution
ViewNode
trait andViewNodeRunner
Node
that will take care of managing the associated view query automatically.Node
trait. So it still has the update/run with all the same data passed in.ViewNodeRunner
is the actual node that is added to the render graph and it contains the custom node. This is necessary because it's the one that takes care of updating the node.Changelog
ViewNode
ViewNodeRunner
Notes
Currently, this only handles the view query, but it could probably have a ReadOnlySystemState that would also simplify querying all the readonly resources that most render nodes currently query manually. The issue is that I don't know how to do that without a
&mut self
.At first, I tried making this a default feature of all
Node
, but I kept hitting errors related to traits and generics and stuff I'm not super comfortable with. This implementations is much simpler and keeps the default Node behaviour so isn't a breaking changeReviewer Notes
The PR looks quite big, but the core of the PR is the changes in
render_graph/node.rs
. Every other change is simply updating existing nodes to use this new feature.Open questions
- Naming is not final, I'm opened to anything. I named it ViewQueryNode because it's a node with a managed Query on a View.- What to do when the query fails? All nodes using this pattern currently justreturn Ok(())
when it fails, so I chose that, but should it be more flexible?- Is the ViewQueryFilter actually necessary? All view queries run on the entity that is already guaranteed to be a view. Filtering won't do much, but maybe someone wants to control an effect with the presence of a component instead of a flag.- What to do with Nodes that are empty struct? ImplementingFromWorld
is pretty verbose but not implementing it means there's 2 ways to create aViewNodeRunner
which seems less ideal. This is an issue now because most node simply existed to hold the query, but now that they don't hold the query state we are left with a bunch of empty structs.RenderGraphApp::add_render_graph_view_node()
, this isn't necessary, but it could make the code a bit shorter.