mirror of
https://github.com/bevyengine/bevy
synced 2024-09-21 06:52:04 +00:00
613b5a69ae
# 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. --------- Co-authored-by: Carter Anderson <mcanders1@gmail.com> |
||
|---|---|---|
| .. | ||
| macros | ||
| src | ||
| Cargo.toml | ||