From 5bfbd8ffb46b1167f34b05261a81112d9a01935c Mon Sep 17 00:00:00 2001 From: IceSentry Date: Sun, 2 Jul 2023 14:21:43 -0400 Subject: [PATCH 1/3] Simpler RenderGraph construction --- content/news/2023-07-07-bevy-0.11/index.md | 51 ++++++++++++++++++++++ 1 file changed, 51 insertions(+) diff --git a/content/news/2023-07-07-bevy-0.11/index.md b/content/news/2023-07-07-bevy-0.11/index.md index 3d0bc99389..23071f8b57 100644 --- a/content/news/2023-07-07-bevy-0.11/index.md +++ b/content/news/2023-07-07-bevy-0.11/index.md @@ -23,6 +23,57 @@ Since our last release a few months ago we've added a _ton_ of new features, bug Description +## Simpler RenderGraph Construction + +
authors: @IceSentry, @cart
+ +Adding `Node`s to the `RenderGraph` requires a lot of boilerplate. In this release, we tried to reduce this for most common operations. No existing API have been removed, these are only helpers made to simplify working with the `RenderGraph`. + +We added the `RenderGraphApp` trait to the `App`. This trait contains various helper functions to reduce the boilerplate with adding nodes and edges to a graph. + +Another pain point of `RenderGraph` `Node`s is passing the view entity through each node and manually updating the query on that view. To fix this we added a `ViewNode` trait and `ViewNodeRunner` that will automatically take care of running the `Query` on the view entity. We also made the concept of the view entity a first party concept of the `RenderGraph`. So you can now access the view entity the graph is currently running on from anywhere in the graph without passing it around between each `Node`. + +All these new apis assume that your Node implements `FromWorld` or `Default`. + +Here's what it looks like in practice for the `BloomNode`: + +```rust +// Adding the node to the 3d graph +render_app + // To run a ViewNode you need to create a ViewNodeRunner + .add_render_graph_node::>( + CORE_3D, + core_3d::graph::node::BLOOM, + ); + +// Defining the node +#[derive(Default)] +struct BloomNode; +// This can replace your `impl Node` block of any existing `Node` that operated on a view +impl ViewNode for BloomNode { + // You need to define your view query as an associated type + type ViewQuery = ( + &'static ExtractedCamera, + &'static ViewTarget, + &'static BloomSettings, + ); + // You don't need Node::input() or Node::update() anymore. If you still need these they are still available but they have an empty default implementation. + fn run( + &self, + graph: &mut RenderGraphContext, + render_context: &mut RenderContext, + // This is the result of your query. If it is empty the run function will not be called + (camera, view_target, bloom_settings): QueryItem, + world: &World, + ) -> Result<(), NodeRunError> { + // When using the ViewNode you probably won't need the view entity but here's how to get it + let view_entity = graph.view_entity(); + + // Run the node + } +} +``` + ## What's Next? * **X**: Y From 580611d0968fa27fe7f71b78447643d9c27e3c63 Mon Sep 17 00:00:00 2001 From: IceSentry Date: Sun, 2 Jul 2023 14:26:46 -0400 Subject: [PATCH 2/3] remove some words --- content/news/2023-07-07-bevy-0.11/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/news/2023-07-07-bevy-0.11/index.md b/content/news/2023-07-07-bevy-0.11/index.md index 23071f8b57..a246a5a7b6 100644 --- a/content/news/2023-07-07-bevy-0.11/index.md +++ b/content/news/2023-07-07-bevy-0.11/index.md @@ -31,7 +31,7 @@ Adding `Node`s to the `RenderGraph` requires a lot of boilerplate. In this relea We added the `RenderGraphApp` trait to the `App`. This trait contains various helper functions to reduce the boilerplate with adding nodes and edges to a graph. -Another pain point of `RenderGraph` `Node`s is passing the view entity through each node and manually updating the query on that view. To fix this we added a `ViewNode` trait and `ViewNodeRunner` that will automatically take care of running the `Query` on the view entity. We also made the concept of the view entity a first party concept of the `RenderGraph`. So you can now access the view entity the graph is currently running on from anywhere in the graph without passing it around between each `Node`. +Another pain point of `RenderGraph` `Node`s is passing the view entity through each node and manually updating the query on that view. To fix this we added a `ViewNode` trait and `ViewNodeRunner` that will automatically take care of running the `Query` on the view entity. We also made the view entity a first party concept of the `RenderGraph`. So you can now access the view entity the graph is currently running on from anywhere in the graph without passing it around between each `Node`. All these new apis assume that your Node implements `FromWorld` or `Default`. From 0c803482a5c5df3903c64b2c632d3e9ea8a15b64 Mon Sep 17 00:00:00 2001 From: IceSentry Date: Tue, 4 Jul 2023 16:28:56 -0400 Subject: [PATCH 3/3] Apply suggestions from code review Co-authored-by: JMS55 <47158642+JMS55@users.noreply.github.com> --- content/news/2023-07-07-bevy-0.11/index.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/news/2023-07-07-bevy-0.11/index.md b/content/news/2023-07-07-bevy-0.11/index.md index a246a5a7b6..6516dcd999 100644 --- a/content/news/2023-07-07-bevy-0.11/index.md +++ b/content/news/2023-07-07-bevy-0.11/index.md @@ -27,13 +27,13 @@ Description
authors: @IceSentry, @cart
-Adding `Node`s to the `RenderGraph` requires a lot of boilerplate. In this release, we tried to reduce this for most common operations. No existing API have been removed, these are only helpers made to simplify working with the `RenderGraph`. +Adding `Node`s to the `RenderGraph` requires a lot of boilerplate. In this release, we tried to reduce this for most common operations. No existing APIs have been removed, these are only helpers made to simplify working with the `RenderGraph`. We added the `RenderGraphApp` trait to the `App`. This trait contains various helper functions to reduce the boilerplate with adding nodes and edges to a graph. -Another pain point of `RenderGraph` `Node`s is passing the view entity through each node and manually updating the query on that view. To fix this we added a `ViewNode` trait and `ViewNodeRunner` that will automatically take care of running the `Query` on the view entity. We also made the view entity a first party concept of the `RenderGraph`. So you can now access the view entity the graph is currently running on from anywhere in the graph without passing it around between each `Node`. +Another pain point of `RenderGraph` `Node`s is passing the view entity through each node and manually updating the query on that view. To fix this we added a `ViewNode` trait and `ViewNodeRunner` that will automatically take care of running the `Query` on the view entity. We also made the view entity a first-class concept of the `RenderGraph`. So you can now access the view entity the graph is currently running on from anywhere in the graph without passing it around between each `Node`. -All these new apis assume that your Node implements `FromWorld` or `Default`. +All these new APIs assume that your Node implements `FromWorld` or `Default`. Here's what it looks like in practice for the `BloomNode`: @@ -66,7 +66,7 @@ impl ViewNode for BloomNode { (camera, view_target, bloom_settings): QueryItem, world: &World, ) -> Result<(), NodeRunError> { - // When using the ViewNode you probably won't need the view entity but here's how to get it + // When using the ViewNode you probably won't need the view entity but here's how to get it if you do let view_entity = graph.view_entity(); // Run the node