Trait bevy::render::render_phase::PhaseItem

pub trait PhaseItem: Sized + Send + Sync + 'static {
    type SortKey: Ord;

    // Required methods
    fn entity(&self) -> Entity;
    fn sort_key(&self) -> Self::SortKey;
    fn draw_function(&self) -> DrawFunctionId;

    // Provided method
    fn sort(items: &mut [Self]) { ... }
}
Expand description

An item (entity of the render world) which will be drawn to a texture or the screen, as part of a RenderPhase.

The data required for rendering an entity is extracted from the main world in the ExtractSchedule. Then it has to be queued up for rendering during the RenderSet::Queue, by adding a corresponding phase item to a render phase. Afterwards it will be sorted and rendered automatically in the RenderSet::PhaseSort and RenderSet::Render, respectively.

Required Associated Types§

type SortKey: Ord

The type used for ordering the items. The smallest values are drawn first. This order can be calculated using the ViewRangefinder3d, based on the view-space Z value of the corresponding view matrix.

Required Methods§

fn entity(&self) -> Entity

The corresponding entity that will be drawn.

This is used to fetch the render data of the entity, required by the draw function, from the render world .

fn sort_key(&self) -> Self::SortKey

Determines the order in which the items are drawn.

fn draw_function(&self) -> DrawFunctionId

Specifies the Draw function used to render the item.

Provided Methods§

fn sort(items: &mut [Self])

Sorts a slice of phase items into render order. Generally if the same type implements BatchedPhaseItem, this should use a stable sort like slice::sort_by_key. In almost all other cases, this should not be altered from the default, which uses a unstable sort, as this provides the best balance of CPU and GPU performance.

Implementers can optionally not sort the list at all. This is generally advisable if and only if the renderer supports a depth prepass, which is by default not supported by the rest of Bevy’s first party rendering crates. Even then, this may have a negative impact on GPU-side performance due to overdraw.

It’s advised to always profile for performance changes when changing this implementation.

Implementors§