mirror of
https://github.com/bevyengine/bevy
synced 2024-12-24 12:03:14 +00:00
a78c4d78d5
# Objective When browsing the bevy source code to try and learn about `bevy_core_pipeline`, I noticed that the `DrawFunctions` resources, `sort_phase_system`s and texture preparation for the `Opaque3d` and `AlphaMask3d` phase items are all set up in `bevy_core_pipeline`, while the `Opaque3dPrepass` and `AlphaMask3dPrepass` phase items are only *declared* in `bevy_core_pipeline`, and actually registered properly with the renderer in `bevy_pbr`. This means that, if I am trying to make crate that replaces `bevy_pbr`, I need to make sure I manually fix this unfinished setup the same way that `bevy_pbr` does. Worse, it means that if I try to use the `PrepassNode` `bevy_core_pipeline` adds *without* fixing this, the engine will simply crash because the `DrawFunctions<T>` resources cannot be accessed. The only advantage I can think of for bevy doing it this way is an ambiguous performance save due to the prepass render phases not being present unless you are using prepass materials with PBR. ## Solution I have moved the registration of `DrawFunctions<T>`, `sort_phase_system::<T>`, camera `RenderPhase` extraction, and texture preparation for prepass's phase items into `bevy_core_pipeline` alongside the equivalent code that sets up the `Opaque3d`, `AlphaMask3d` and `Transparent3d` phase items. Am open to tweaking this to improve the performance impact of prepass things being around if the app doesn't use them if needed. I've tested that the `shader_prepass` example still works with this change. |
||
|---|---|---|
| .. | ||
| blit | ||
| bloom | ||
| contrast_adaptive_sharpening | ||
| core_2d | ||
| core_3d | ||
| fullscreen_vertex_shader | ||
| fxaa | ||
| prepass | ||
| skybox | ||
| taa | ||
| tonemapping | ||
| upscaling | ||
| clear_color.rs | ||
| lib.rs | ||
| msaa_writeback.rs | ||