-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Merged by Bors] - Improve render phase documentation #7016
[Merged by Bors] - Improve render phase documentation #7016
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a cursory run through. Will give a thorough review later.
|
||
/// A resource to collect and sort draw requests for specific [`PhaseItems`](PhaseItem). | ||
/// A render phase sorts and renders all [`PhaseItem`]s (entities) that are assigned to it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/// 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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_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
rangefinder
into therender_phase
module since it is only used there.PhaseItem
(and theBatchedPhaseItem
) fromrender_phase::draw
over torender_phase::mod
. This does not change the public-facing API since they are reexported anyway, but this change makes the relation betweenRenderPhase
andPhaseItem
clear and easier to discover.Documentation
render_phase
moduleRenderPhase
s,RenderPass
es,PhaseItem
s,Draw
functions, andRenderCommands
relate to each other and how they are usedChangelog
rangefinder
module has been moved into therender_phase
module.Migration Guide
rangefinder
module has been moved into therender_phase
module.