Add ViewNode to simplify render node management

[IceSentry]

Objective

• When writing render nodes that need a view, you always need to define a Query on the associated view and make sure to update it manually and query it manually. This is verbose and error prone.

Solution

• Introduce a new ViewNode trait and ViewNodeRunner Node that will take care of managing the associated view query automatically.
• The trait is currently a passthrough of the Node trait. So it still has the update/run with all the same data passed in.
• The 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

• Add ViewNode
• Add 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 change

Reviewer 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 just return 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? Implementing FromWorld is pretty verbose but not implementing it means there's 2 ways to create a ViewNodeRunner 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.

• Should we have a RenderGraphApp::add_render_graph_view_node(), this isn't necessary, but it could make the code a bit shorter.

[JMS55]

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.

I'd go with just ViewNode, or ViewNodeWrapper or something

What to do when the query fails? All nodes using this pattern currently just return Ok(()) when it fails, so I chose that, but should it be more flexible?

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.

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.

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.

[JMS55]

Any reason you're not using ViewQueryNode for the main pass nodes?

[IceSentry]

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.

[kurtkuehnert]

I really like the direction of this PR.
Doing the same for the resources in a followup PR would be great as well.

[kurtkuehnert]

I second @JMS55's suggestion on naming: ViewNode for ViewQueryNode and ViewNodeWrapper for the ViewQueryNodeRunner.

[IceSentry]

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.

[IceSentry]

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 ViewNodeRunner, but now most nodes don't need the World to be created, which means that if we want to use ViewNodeRunner::<Node>::from_world(&mut world) to create all view nodes we also need a bunch of empty impl FromWorld. I'm not sure how to tackle this issue.

[nicopap]

Excellent job. Useful abstraction, also helps document the patterns used for render graph nodes in bevy.

[cart]

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 with Read<>
• Renamed ViewWorldQuery to ViewQuery to match the variable name and reduce "concept noise". I think "world-query-ness" can be implied here.