Restructure Rendering Crates

It seems like there's agreement among Bevy's rendering devs that our current
crate structure is confusing, makes features harder to implement, and makes it
difficult for crate authors to integrate their code with the engine. This
document can serve as a place to propose a new crate hierarchy to improve on
these issues.

previous github issue

Questions to answer

1. What are the new crates?
2. Where should existing rendering code be placed?
3. Where should future code be placed/what is the relationship between the new crates?
4. Which areas does the proposal improve? How so?
   a. compile-time performance
   b. modularity: how much coupling exists between each crate and downstream crates?
   c. extensibility: how easy is it for users to extend the engine to do cool stuff?
   c. clarity: how easy is it to find relevant code?
   (non-exhaustive)
5. How do we get there?

---

Rob's proposal

• 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 Proposal

Things I don't know where to put yet:
- tilemaps,
- shadows/pcss
- decals
- POM
- OIT
- Skybox

Low-level crates

bevy_render:
Our lowest-level crate, providing wgpu integration and basic resource abstractions
Ex:
- extraction and pipelining
- AsBindGroup (or its successor)
- RenderPhase/PhaseItem + batching
- specialization
- render graph abstraction
- rename CameraRenderGraph to RenderGraphDriver, CameraDriverNode to RenderGraphDriverNode
- let RenderGraphDriver act on its own, have Camera require RenderGraphDriver
- lets us move camera abstraction to bevy_camera while keeping sub graph drivers here
This crate would stay mostly as-is, providing a single RenderPlugin and several other smaller utilities.

bevy_camera:
- basic Camera, detached from 2d/3d/pbr, and concept of a View.
- manages ViewTarget (or its successor)
- controls presentation to the final Surface.
- ordering primitives for camera render graph (more on this later, basically just SystemSet)
- tonemapping, upscaling, (hdr output when we have it)
- should deferred/visbuffer go here?
This crate would contain mostly low-level, but flexible camera features:
for example, DLSS and stylized low-res renderers should be able to control
creation of the ViewTarget and choose their own upscaler without tearing
out CameraPlugin. I chose to put all the tonemapping and presentation-related
passes here since they feel low-level and fairly essential
compared to more opinionated effects, but I don't mind too much where they go.

bevy_material: provides bevy's unified Material abstraction.
- needs design

bevy_mesh_render: mesh rendering backend for 2d and 3d

bevy_lighting:
- provides built-in light types: DirectionalLight, SpotLight, PointLight
- clustering?

bevy_pbr: contains the base for bevy's PBR lights and materials
- PhysicalCameraSettings
- common shader libs
- pbr lighting functions, etc

Mid-level/Effects crates

bevy_volumetrics:
- volumetric fog
- atmosphere
- will be the target of the unified volumetrics proposal

bevy_anti_aliasing: TAA, SMAA, FXAA, (CAS?)

bevy_post_processing: Purely screenspace post-processing effects.
- color grading
- chromatic aberration
- bloom?

bevy_vfx: Effects that are more physical, or aren't "pure" post processing
- SSAO
- SSR?
- DoF
- Motion blur
- auto exposure?

Top level API

bevy_idk: Wraps all of bevy's rendering APIs into a common, friendly frontend.
- Equivalent to current PbrPlugin in scope
- needs a name, maybe a fancy branding one?
- Anything that we can't abstract into one of the lower-level crates should go here.