[Merged by Bors] - Improve render phase documentation#7016
[Merged by Bors] - Improve render phase documentation#7016kurtkuehnert wants to merge 4 commits intobevyengine:mainfrom
Conversation
|
@kurtkuehnert Do you think you can isolate this from the other PRs? Chained PRs like this tend to be a nightmare to contend with in terms of merge conflicts, and even harder to review while those other PRs are in flux. |
|
I could probably separate this PR from |
|
@JoJoJet Yes. |
9286dc2 to
30d3f3d
Compare
|
@james7132 This PR now only depends on #6885 and should be rebased+merged once your PR has been merged. |
|
For now, reviewers can just take a look at commit 384a287 following. |
|
@kurtkuehnert with #6885 merged, can you rebase this PR so it can be reviewed? |
70d3233 to
78195de
Compare
|
@james7132 I have rebased this PR onto main. |
james7132
left a comment
There was a problem hiding this comment.
Just a cursory run through. Will give a thorough review later.
There was a problem hiding this comment.
| /// A render phase sorts and renders all [`PhaseItem`]s (entities) that are assigned to it. | |
| /// A collection of all rendering commands for a single rendering phase for a single view. | |
| /// | |
| /// These commands are included as individual [`PhaseItem`] that encodes how to draw one ore more | |
| /// entities to the screen. |
There was a problem hiding this comment.
It is not really collecting rendering commands, but rather PhaseItems.
How about
/// A collection of all [`PhaseItem`]s for a single rendering phase for a single view.
There was a problem hiding this comment.
In a way, each phase item is a bundle of rendering commands. As a summary of what the type does, I'd rather us avoid referential descriptions, especially when it's not clear to the normal user what a PhaseItem is from a glance.
There was a problem hiding this comment.
I use the term rendering instructions instead of rendering commands because the latter are stored in DrawFunctionsInternal instead. I think this is a good compromise. Do you agree?
/// A collection of all rendering instructions, that will be executed by the GPU, for a
/// single rendering phase for a single view.
There was a problem hiding this comment.
Works for me, though it could be a bit confusing since "instructions" usually imply CPU/GPU machine instructions.
There was a problem hiding this comment.
Mhh, yeah both are not ideal. I will change it back to commands if other reviewers agree that this is the better term. 👍
d37e989 to
a641ca1
Compare
alice-i-cecile
left a comment
There was a problem hiding this comment.
Generally a clear improvement.
Some doc suggestions, and TODO comments should be moved into issues instead so they can be better tracked and discussed.
bce5792 to
d7e2357
Compare
djeedai
left a comment
There was a problem hiding this comment.
Mostly OK for me, some minor corrections.
Once this is in I intend to merge this PR :) |
@alice-i-cecile I have addressed the feedback :). |
|
bors r+ |
# Objective The documentation of the bevy_render crate is still pretty incomplete. This PR follows up on #6885 and improves the documentation of the `render_phase` module. This module contains one of our most important rendering abstractions and the current documentation is pretty confusing. This PR tries to clarify what all of these pieces are for and how they work together to form bevy`s modular rendering logic. ## Solution ### Code Reformating - I have moved the `rangefinder` into the `render_phase` module since it is only used there. - I have moved the `PhaseItem` (and the `BatchedPhaseItem`) from `render_phase::draw` over to `render_phase::mod`. This does not change the public-facing API since they are reexported anyway, but this change makes the relation between `RenderPhase` and `PhaseItem` clear and easier to discover. ### Documentation - revised all documentation in the `render_phase` module - added a module-level explanation of how `RenderPhase`s, `RenderPass`es, `PhaseItem`s, `Draw` functions, and `RenderCommands` relate to each other and how they are used --- ## Changelog - The `rangefinder` module has been moved into the `render_phase` module. ## Migration Guide - The `rangefinder` module has been moved into the `render_phase` module. ```rust //old use bevy::render::rangefinder::*; // new use bevy::render::render_phase::rangefinder::*; ```
# Objective The documentation of the bevy_render crate is still pretty incomplete. This PR follows up on bevyengine#6885 and improves the documentation of the `render_phase` module. This module contains one of our most important rendering abstractions and the current documentation is pretty confusing. This PR tries to clarify what all of these pieces are for and how they work together to form bevy`s modular rendering logic. ## Solution ### Code Reformating - I have moved the `rangefinder` into the `render_phase` module since it is only used there. - I have moved the `PhaseItem` (and the `BatchedPhaseItem`) from `render_phase::draw` over to `render_phase::mod`. This does not change the public-facing API since they are reexported anyway, but this change makes the relation between `RenderPhase` and `PhaseItem` clear and easier to discover. ### Documentation - revised all documentation in the `render_phase` module - added a module-level explanation of how `RenderPhase`s, `RenderPass`es, `PhaseItem`s, `Draw` functions, and `RenderCommands` relate to each other and how they are used --- ## Changelog - The `rangefinder` module has been moved into the `render_phase` module. ## Migration Guide - The `rangefinder` module has been moved into the `render_phase` module. ```rust //old use bevy::render::rangefinder::*; // new use bevy::render::render_phase::rangefinder::*; ```
# Objective The documentation of the bevy_render crate is still pretty incomplete. This PR follows up on bevyengine#6885 and improves the documentation of the `render_phase` module. This module contains one of our most important rendering abstractions and the current documentation is pretty confusing. This PR tries to clarify what all of these pieces are for and how they work together to form bevy`s modular rendering logic. ## Solution ### Code Reformating - I have moved the `rangefinder` into the `render_phase` module since it is only used there. - I have moved the `PhaseItem` (and the `BatchedPhaseItem`) from `render_phase::draw` over to `render_phase::mod`. This does not change the public-facing API since they are reexported anyway, but this change makes the relation between `RenderPhase` and `PhaseItem` clear and easier to discover. ### Documentation - revised all documentation in the `render_phase` module - added a module-level explanation of how `RenderPhase`s, `RenderPass`es, `PhaseItem`s, `Draw` functions, and `RenderCommands` relate to each other and how they are used --- ## Changelog - The `rangefinder` module has been moved into the `render_phase` module. ## Migration Guide - The `rangefinder` module has been moved into the `render_phase` module. ```rust //old use bevy::render::rangefinder::*; // new use bevy::render::render_phase::rangefinder::*; ```
Objective
The documentation of the bevy_render crate is still pretty incomplete.
This PR follows up on #6885 and improves the documentation of the
render_phasemodule.This module contains one of our most important rendering abstractions and the current documentation is pretty confusing. This PR tries to clarify what all of these pieces are for and how they work together to form bevy`s modular rendering logic.
Solution
Code Reformating
rangefinderinto therender_phasemodule since it is only used there.PhaseItem(and theBatchedPhaseItem) fromrender_phase::drawover torender_phase::mod. This does not change the public-facing API since they are reexported anyway, but this change makes the relation betweenRenderPhaseandPhaseItemclear and easier to discover.Documentation
render_phasemoduleRenderPhases,RenderPasses,PhaseItems,Drawfunctions, andRenderCommandsrelate to each other and how they are usedChangelog
rangefindermodule has been moved into therender_phasemodule.Migration Guide
rangefindermodule has been moved into therender_phasemodule.