Adds GlobalRenderResourcesNode to easily bind Resources

[mtsr]

To expose a ECS Resource as a custom uniform requires reimplementing most of the stuff that camera_node.rs or lights_node.rs do. My idea here was to see if this can be significantly reduced for Resources that implement RenderResources.

One of the use cases is being able to easily expose values to FullscreenPassNode shaders, which do not use any entities.

It currently works, although it's quite possible I missed some edge cases. Also I'm aware it doesn't currently support Textures.

Before I put in the work polishing this, I'd like to hear what people think.

[CptPotato]

Before I put in the work polishing this, I'd like to hear what people think.

I might be a bit biased since I was somewhat involved in this. But in terms of general ergonomics, using a Resource felt like the most natural way to go and was the first thing I've tried when attempting to use "global" uniforms.

[msklywenn]

This seems like a really neat feature. For clarity and ease of comprehension, may I suggest renaming GlobalRenderResourcesNode into ResourcesNode and RenderResourcesNode into ComponentsNode? It would match their source object and I think the "Render" is superfluous since this is all already in the render_graph crate.

Edit: I just saw there was an AssetRenderResourcesNode too and the naming I just proposed might be confusing in the global context. I also find that RenderResource might be confused with ECS Resources while they are in fact completely unrelated. So may I actually suggest:

• RenderResourcesNode => ComponentDataNode
• GlobalRenderResourcesNode => ResourceDataNode
• AssetRenderResourcesNode => AssetDataNode

[superdump]

What about added?

[mtsr]

is_changed() is also true for added. Although I guess it doesn't hurt to add it for clarity.

[alice-i-cecile]

How does this relate to the modern ExtractResource approach? Is this still needed?

[IceSentry]

I believe this is too outdated to be relevant. ExtractResource covers most of this.