Restructure rendering crates

[superdump]

Discussions have been happening on Discord about some restructuring the rendering crates and there is some alignment across multiple independent thinkers so I wanted to capture it here. This is open for discussion. Comment and we can update this initial description as we change our minds / gain clarity.

Current state

• bevy_mesh
• bevy_render
• bevy_core_pipeline
• bevy_sprite
• bevy_pbr

Proposed states

Names can be discussed but should be illustrative of the kind of groupings we have in mind.

Rob's suggestion

• bevy_mesh - mesh stuff not dependent on bevy_render
• bevy_render - agnostic rendering infrastructure like low level resources, render graph infrastructure, etc
• bevy_camera - camera stuff
• bevy_material - contains the one and only Material API
• bevy_post_processing - post-processing effects like bloom, motion blur, chromatic aberration, etc, etc
• bevy_antialiasing - all the AA implementations, FXAA, TAA, SMAA, etc
• bevy_2d - contains the code specific to 2D mesh material rendering, maybe also the default/base 2d render graph
• bevy_3d - contains the code specific to 3D mesh material rendering, including building blocks like clustering, lights, shadow mapping, etc, maybe also the default/base 3d render graph
• bevy_standard_material - the implementation of our standard PBR material using the other crates as necessary
• bevy_color_material - the implementation of a texture + color tint material that could be used also to support sprites, and the sprite abstraction on top of that

Things like lights, clustering, shadow mapping, should all be reusable for custom materials without having to pull in bevy's default materials (standard material, color material).

I think whether to use the 2D or 3D render graph should depend on the camera entity, and that the render phases should be functional for either. A phase is just a collection of drawable entities. The entities may have mesh data, and do have materials (sprites will be converted to color material using a shared and batchable quad mesh, or whatever mesh data performs best). 2D is then basically 3D in practice (the GPU thinks so) but perhaps you don't use 3D lighting infrastructure most of the time, but you could.

Emerson's suggestion

• bevy material
• bevy_3d (contains infra for mesh rendering, light clustering, general 3d algos)
• bevy_2d (similar but probably cut down to 2d mesh rendering)
• bevy_pbr (library crate for pbr-specific stuff, probably mostly shaders and lights, maybe physical camera settings)
• (all of our effects crates like bevy_post_processing, bevy_aa, etc. Hopefully made graph agnostic at some point)
• bevy_default_graph (name very bikesheddable, contains StandardMaterial and default render graph setup/plugin)

[ecoskey]

Looks good! I like the idea of sharing phases between graphs, just one comment on your suggestion: I don't think bevy_2d/3d should include a default graph config, it feels kinda close to what we're doing now with bevy_core_pipeline which isn't working too great IMO. Other than that I'd be fine with either proposal probably.

[hukasu]

I started with moving things in and out of beby_mesh, which is in line with Rob's suggestion

I see bevy_render as having the tools to push things to the GPU and bevy_camera using it to push the views, bevy_mesh using it to push the meshes, bevy_[2d|3d] using it to push the materials, etc

[JMS55]

We should restructure in such a way that we can still do #16721.

Combining render passes where we can is very important.

[mgi388]

If it's helpful feedback, I'm a huge fan of bevy_camera. In my app, I depend on bevy sub-crates, not bevy proper, and I have imports like use bevy_core_pipeline::prelude::*; just to refer to or spawn a Camera in my code, and all else aside, use bevy_camera::prelude::*; is much clearer and more intuitive. Even if bevy_core_pipeline still existed, it doesn't say anything about what my unit of code is dependent on: a simple Camera type.

[aloucks]

Would it be possible to simplify the way WGPU is re-exported as part of this initiative? See: #3823

I believe WGPU uses reference counting internally now, so that blocker might be resolved. I'm not sure about some of the other points that were brought up.