# 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](https://github.com/bevyengine/bevy/issues/18423)

## 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
- low-level "View" interface: camera composition, ordering, viewport selection. See the [Camera Restructure](/Bynv5tv6RqiB6xoha_S-Vw) proposal.
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
- manages `ViewTarget` (or its successor)
- common 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](https://github.com/bevyengine/bevy/issues/18151)

`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.