2024-07-31 18:24:58 +00:00
|
|
|
//! Demonstrates how to define and use specialized mesh pipeline
|
|
|
|
//!
|
|
|
|
//! This example shows how to use the built-in [`SpecializedMeshPipeline`]
|
|
|
|
//! functionality with a custom [`RenderCommand`] to allow custom mesh rendering with
|
|
|
|
//! more flexibility than the material api.
|
|
|
|
//!
|
|
|
|
//! [`SpecializedMeshPipeline`] let's you customize the entire pipeline used when rendering a mesh.
|
|
|
|
|
|
|
|
use bevy::{
|
Use multidraw for opaque meshes when GPU culling is in use. (#16427)
This commit adds support for *multidraw*, which is a feature that allows
multiple meshes to be drawn in a single drawcall. `wgpu` currently
implements multidraw on Vulkan, so this feature is only enabled there.
Multiple meshes can be drawn at once if they're in the same vertex and
index buffers and are otherwise placed in the same bin. (Thus, for
example, at present the materials and textures must be identical, but
see #16368.) Multidraw is a significant performance improvement during
the draw phase because it reduces the number of rebindings, as well as
the number of drawcalls.
This feature is currently only enabled when GPU culling is used: i.e.
when `GpuCulling` is present on a camera. Therefore, if you run for
example `scene_viewer`, you will not see any performance improvements,
because `scene_viewer` doesn't add the `GpuCulling` component to its
camera.
Additionally, the multidraw feature is only implemented for opaque 3D
meshes and not for shadows or 2D meshes. I plan to make GPU culling the
default and to extend the feature to shadows in the future. Also, in the
future I suspect that polyfilling multidraw on APIs that don't support
it will be fruitful, as even without driver-level support use of
multidraw allows us to avoid expensive `wgpu` rebindings.
2024-12-06 17:22:03 +00:00
|
|
|
core_pipeline::core_3d::{Opaque3d, Opaque3dBatchSetKey, Opaque3dBinKey, CORE_3D_DEPTH_FORMAT},
|
2024-07-31 18:24:58 +00:00
|
|
|
math::{vec3, vec4},
|
|
|
|
pbr::{
|
|
|
|
DrawMesh, MeshPipeline, MeshPipelineKey, MeshPipelineViewLayoutKey, RenderMeshInstances,
|
|
|
|
SetMeshBindGroup, SetMeshViewBindGroup,
|
|
|
|
},
|
|
|
|
prelude::*,
|
|
|
|
render::{
|
|
|
|
extract_component::{ExtractComponent, ExtractComponentPlugin},
|
|
|
|
mesh::{Indices, MeshVertexBufferLayoutRef, PrimitiveTopology, RenderMesh},
|
|
|
|
render_asset::{RenderAssetUsages, RenderAssets},
|
|
|
|
render_phase::{
|
|
|
|
AddRenderCommand, BinnedRenderPhaseType, DrawFunctions, SetItemPipeline,
|
|
|
|
ViewBinnedRenderPhases,
|
|
|
|
},
|
|
|
|
render_resource::{
|
|
|
|
ColorTargetState, ColorWrites, CompareFunction, DepthStencilState, Face, FragmentState,
|
|
|
|
FrontFace, MultisampleState, PipelineCache, PolygonMode, PrimitiveState,
|
|
|
|
RenderPipelineDescriptor, SpecializedMeshPipeline, SpecializedMeshPipelineError,
|
|
|
|
SpecializedMeshPipelines, TextureFormat, VertexState,
|
|
|
|
},
|
Type safe retained render world (#15756)
# Objective
In the Render World, there are a number of collections that are derived
from Main World entities and are used to drive rendering. The most
notable are:
- `VisibleEntities`, which is generated in the `check_visibility` system
and contains visible entities for a view.
- `ExtractedInstances`, which maps entity ids to asset ids.
In the old model, these collections were trivially kept in sync -- any
extracted phase item could look itself up because the render entity id
was guaranteed to always match the corresponding main world id.
After #15320, this became much more complicated, and was leading to a
number of subtle bugs in the Render World. The main rendering systems,
i.e. `queue_material_meshes` and `queue_material2d_meshes`, follow a
similar pattern:
```rust
for visible_entity in visible_entities.iter::<With<Mesh2d>>() {
let Some(mesh_instance) = render_mesh_instances.get_mut(visible_entity) else {
continue;
};
// Look some more stuff up and specialize the pipeline...
let bin_key = Opaque2dBinKey {
pipeline: pipeline_id,
draw_function: draw_opaque_2d,
asset_id: mesh_instance.mesh_asset_id.into(),
material_bind_group_id: material_2d.get_bind_group_id().0,
};
opaque_phase.add(
bin_key,
*visible_entity,
BinnedRenderPhaseType::mesh(mesh_instance.automatic_batching),
);
}
```
In this case, `visible_entities` and `render_mesh_instances` are both
collections that are created and keyed by Main World entity ids, and so
this lookup happens to work by coincidence. However, there is a major
unintentional bug here: namely, because `visible_entities` is a
collection of Main World ids, the phase item being queued is created
with a Main World id rather than its correct Render World id.
This happens to not break mesh rendering because the render commands
used for drawing meshes do not access the `ItemQuery` parameter, but
demonstrates the confusion that is now possible: our UI phase items are
correctly being queued with Render World ids while our meshes aren't.
Additionally, this makes it very easy and error prone to use the wrong
entity id to look up things like assets. For example, if instead we
ignored visibility checks and queued our meshes via a query, we'd have
to be extra careful to use `&MainEntity` instead of the natural
`Entity`.
## Solution
Make all collections that are derived from Main World data use
`MainEntity` as their key, to ensure type safety and avoid accidentally
looking up data with the wrong entity id:
```rust
pub type MainEntityHashMap<V> = hashbrown::HashMap<MainEntity, V, EntityHash>;
```
Additionally, we make all `PhaseItem` be able to provide both their Main
and Render World ids, to allow render phase implementors maximum
flexibility as to what id should be used to look up data.
You can think of this like tracking at the type level whether something
in the Render World should use it's "primary key", i.e. entity id, or
needs to use a foreign key, i.e. `MainEntity`.
## Testing
##### TODO:
This will require extensive testing to make sure things didn't break!
Additionally, some extraction logic has become more complicated and
needs to be checked for regressions.
## Migration Guide
With the advent of the retained render world, collections that contain
references to `Entity` that are extracted into the render world have
been changed to contain `MainEntity` in order to prevent errors where a
render world entity id is used to look up an item by accident. Custom
rendering code may need to be changed to query for `&MainEntity` in
order to look up the correct item from such a collection. Additionally,
users who implement their own extraction logic for collections of main
world entity should strongly consider extracting into a different
collection that uses `MainEntity` as a key.
Additionally, render phases now require specifying both the `Entity` and
`MainEntity` for a given `PhaseItem`. Custom render phases should ensure
`MainEntity` is available when queuing a phase item.
2024-10-10 18:47:04 +00:00
|
|
|
view::{self, ExtractedView, RenderVisibleEntities, ViewTarget, VisibilitySystems},
|
2024-07-31 18:24:58 +00:00
|
|
|
Render, RenderApp, RenderSet,
|
|
|
|
},
|
|
|
|
};
|
|
|
|
|
|
|
|
const SHADER_ASSET_PATH: &str = "shaders/specialized_mesh_pipeline.wgsl";
|
|
|
|
|
|
|
|
fn main() {
|
|
|
|
App::new()
|
|
|
|
.add_plugins(DefaultPlugins)
|
|
|
|
.add_plugins(CustomRenderedMeshPipelinePlugin)
|
|
|
|
.add_systems(Startup, setup)
|
|
|
|
.run();
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Spawns the objects in the scene.
|
|
|
|
fn setup(mut commands: Commands, mut meshes: ResMut<Assets<Mesh>>) {
|
|
|
|
// Build a custom triangle mesh with colors
|
|
|
|
// We define a custom mesh because the examples only uses a limited
|
|
|
|
// set of vertex attributes for simplicity
|
|
|
|
let mesh = Mesh::new(
|
|
|
|
PrimitiveTopology::TriangleList,
|
|
|
|
RenderAssetUsages::default(),
|
|
|
|
)
|
2024-10-15 02:34:33 +00:00
|
|
|
.with_inserted_indices(Indices::U32(vec![0, 1, 2]))
|
2024-07-31 18:24:58 +00:00
|
|
|
.with_inserted_attribute(
|
|
|
|
Mesh::ATTRIBUTE_POSITION,
|
|
|
|
vec![
|
|
|
|
vec3(-0.5, -0.5, 0.0),
|
|
|
|
vec3(0.5, -0.5, 0.0),
|
|
|
|
vec3(0.0, 0.25, 0.0),
|
|
|
|
],
|
|
|
|
)
|
|
|
|
.with_inserted_attribute(
|
|
|
|
Mesh::ATTRIBUTE_COLOR,
|
|
|
|
vec![
|
|
|
|
vec4(1.0, 0.0, 0.0, 1.0),
|
|
|
|
vec4(0.0, 1.0, 0.0, 1.0),
|
|
|
|
vec4(0.0, 0.0, 1.0, 1.0),
|
|
|
|
],
|
|
|
|
);
|
|
|
|
|
|
|
|
// spawn 3 triangles to show that batching works
|
|
|
|
for (x, y) in [-0.5, 0.0, 0.5].into_iter().zip([-0.25, 0.5, -0.25]) {
|
|
|
|
// Spawn an entity with all the required components for it to be rendered with our custom pipeline
|
|
|
|
commands.spawn((
|
|
|
|
// We use a marker component to identify the mesh that will be rendered
|
|
|
|
// with our specialized pipeline
|
|
|
|
CustomRenderedEntity,
|
|
|
|
// We need to add the mesh handle to the entity
|
2024-10-09 21:10:01 +00:00
|
|
|
Mesh3d(meshes.add(mesh.clone())),
|
Deprecate SpatialBundle (#15830)
# Objective
- Required components replace bundles, but `SpatialBundle` is yet to be
deprecated
## Solution
- Deprecate `SpatialBundle`
- Insert `Transform` and `Visibility` instead in examples using it
- In `spawn` or `insert` inserting a default `Transform` or `Visibility`
with component already requiring either, remove those components from
the tuple
## Testing
- Did you test these changes? If so, how?
Yes, I ran the examples I changed and tests
- Are there any parts that need more testing?
The `gamepad_viewer` and and `custom_shader_instancing` examples don't
work as intended due to entirely unrelated code, didn't check main.
- How can other people (reviewers) test your changes? Is there anything
specific they need to know?
Run examples, or just check that all spawned values are identical
- If relevant, what platforms did you test these changes on, and are
there any important ones you can't test?
Linux, wayland trough x11 (cause that's the default feature)
---
## Migration Guide
`SpatialBundle` is now deprecated, insert `Transform` and `Visibility`
instead which will automatically insert all other components that were
in the bundle. If you do not specify these values and any other
components in your `spawn`/`insert` call already requires either of
these components you can leave that one out.
before:
```rust
commands.spawn(SpatialBundle::default());
```
after:
```rust
commands.spawn((Transform::default(), Visibility::default());
```
2024-10-13 17:28:22 +00:00
|
|
|
Transform::from_xyz(x, y, 0.0),
|
2024-07-31 18:24:58 +00:00
|
|
|
));
|
|
|
|
}
|
|
|
|
|
|
|
|
// Spawn the camera.
|
2024-10-05 01:59:52 +00:00
|
|
|
commands.spawn((
|
|
|
|
Camera3d::default(),
|
2024-07-31 18:24:58 +00:00
|
|
|
// Move the camera back a bit to see all the triangles
|
2024-10-05 01:59:52 +00:00
|
|
|
Transform::from_xyz(0.0, 0.0, 3.0).looking_at(Vec3::ZERO, Vec3::Y),
|
|
|
|
));
|
2024-07-31 18:24:58 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// When writing custom rendering code it's generally recommended to use a plugin.
|
|
|
|
// The main reason for this is that it gives you access to the finish() hook
|
|
|
|
// which is called after rendering resources are initialized.
|
|
|
|
struct CustomRenderedMeshPipelinePlugin;
|
|
|
|
impl Plugin for CustomRenderedMeshPipelinePlugin {
|
|
|
|
fn build(&self, app: &mut App) {
|
|
|
|
app.add_plugins(ExtractComponentPlugin::<CustomRenderedEntity>::default())
|
|
|
|
.add_systems(
|
|
|
|
PostUpdate,
|
|
|
|
// Make sure to tell Bevy to check our entity for visibility. Bevy won't
|
|
|
|
// do this by default, for efficiency reasons.
|
|
|
|
// This will do things like frustum culling and hierarchy visibility
|
|
|
|
view::check_visibility::<WithCustomRenderedEntity>
|
|
|
|
.in_set(VisibilitySystems::CheckVisibility),
|
|
|
|
);
|
|
|
|
|
|
|
|
// We make sure to add these to the render app, not the main app.
|
|
|
|
let Some(render_app) = app.get_sub_app_mut(RenderApp) else {
|
|
|
|
return;
|
|
|
|
};
|
|
|
|
render_app
|
|
|
|
// This is needed to tell bevy about your custom pipeline
|
|
|
|
.init_resource::<SpecializedMeshPipelines<CustomMeshPipeline>>()
|
|
|
|
// We need to use a custom draw command so we need to register it
|
|
|
|
.add_render_command::<Opaque3d, DrawSpecializedPipelineCommands>()
|
|
|
|
.add_systems(Render, queue_custom_mesh_pipeline.in_set(RenderSet::Queue));
|
|
|
|
}
|
|
|
|
|
|
|
|
fn finish(&self, app: &mut App) {
|
|
|
|
let Some(render_app) = app.get_sub_app_mut(RenderApp) else {
|
|
|
|
return;
|
|
|
|
};
|
|
|
|
// Creating this pipeline needs the RenderDevice and RenderQueue
|
|
|
|
// which are only available once rendering plugins are initialized.
|
|
|
|
render_app.init_resource::<CustomMeshPipeline>();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/// A marker component that represents an entity that is to be rendered using
|
|
|
|
/// our specialized pipeline.
|
|
|
|
///
|
|
|
|
/// Note the [`ExtractComponent`] trait implementation. This is necessary to
|
|
|
|
/// tell Bevy that this object should be pulled into the render world.
|
|
|
|
#[derive(Clone, Component, ExtractComponent)]
|
|
|
|
struct CustomRenderedEntity;
|
|
|
|
|
|
|
|
/// The custom draw commands that Bevy executes for each entity we enqueue into
|
|
|
|
/// the render phase.
|
|
|
|
type DrawSpecializedPipelineCommands = (
|
|
|
|
// Set the pipeline
|
|
|
|
SetItemPipeline,
|
|
|
|
// Set the view uniform at bind group 0
|
|
|
|
SetMeshViewBindGroup<0>,
|
|
|
|
// Set the mesh uniform at bind group 1
|
|
|
|
SetMeshBindGroup<1>,
|
|
|
|
// Draw the mesh
|
|
|
|
DrawMesh,
|
|
|
|
);
|
|
|
|
|
|
|
|
/// A query filter that tells [`view::check_visibility`] about our custom
|
|
|
|
/// rendered entity.
|
|
|
|
type WithCustomRenderedEntity = With<CustomRenderedEntity>;
|
|
|
|
|
:pencil2: Fix typos across bevy (#16702)
# Objective
Fixes typos in bevy project, following suggestion in
https://github.com/bevyengine/bevy-website/pull/1912#pullrequestreview-2483499337
## Solution
I used https://github.com/crate-ci/typos to find them.
I included only the ones that feel undebatable too me, but I am not in
game engine so maybe some terms are expected.
I left out the following typos:
- `reparametrize` => `reparameterize`: There are a lot of occurences, I
believe this was expected
- `semicircles` => `hemicircles`: 2 occurences, may mean something
specific in geometry
- `invertation` => `inversion`: may mean something specific
- `unparented` => `parentless`: may mean something specific
- `metalness` => `metallicity`: may mean something specific
## Testing
- Did you test these changes? If so, how? I did not test the changes,
most changes are related to raw text. I expect the others to be tested
by the CI.
- Are there any parts that need more testing? I do not think
- How can other people (reviewers) test your changes? Is there anything
specific they need to know? To me there is nothing to test
- If relevant, what platforms did you test these changes on, and are
there any important ones you can't test?
---
## Migration Guide
> This section is optional. If there are no breaking changes, you can
delete this section.
(kept in case I include the `reparameterize` change here)
- If this PR is a breaking change (relative to the last release of
Bevy), describe how a user might need to migrate their code to support
these changes
- Simply adding new functionality is not a breaking change.
- Fixing behavior that was definitely a bug, rather than a questionable
design choice is not a breaking change.
## Questions
- [x] Should I include the above typos? No
(https://github.com/bevyengine/bevy/pull/16702#issuecomment-2525271152)
- [ ] Should I add `typos` to the CI? (I will check how to configure it
properly)
This project looks awesome, I really enjoy reading the progress made,
thanks to everyone involved.
2024-12-08 01:18:39 +00:00
|
|
|
// This contains the state needed to specialize a mesh pipeline
|
2024-07-31 18:24:58 +00:00
|
|
|
#[derive(Resource)]
|
|
|
|
struct CustomMeshPipeline {
|
|
|
|
/// The base mesh pipeline defined by bevy
|
|
|
|
///
|
|
|
|
/// This isn't required, but if you want to use a bevy `Mesh` it's easier when you
|
|
|
|
/// have access to the base `MeshPipeline` that bevy already defines
|
|
|
|
mesh_pipeline: MeshPipeline,
|
|
|
|
/// Stores the shader used for this pipeline directly on the pipeline.
|
|
|
|
/// This isn't required, it's only done like this for simplicity.
|
|
|
|
shader_handle: Handle<Shader>,
|
|
|
|
}
|
|
|
|
impl FromWorld for CustomMeshPipeline {
|
|
|
|
fn from_world(world: &mut World) -> Self {
|
|
|
|
// Load the shader
|
|
|
|
let shader_handle: Handle<Shader> = world.resource::<AssetServer>().load(SHADER_ASSET_PATH);
|
|
|
|
Self {
|
|
|
|
mesh_pipeline: MeshPipeline::from_world(world),
|
|
|
|
shader_handle,
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl SpecializedMeshPipeline for CustomMeshPipeline {
|
|
|
|
/// Pipeline use keys to determine how to specialize it.
|
|
|
|
/// The key is also used by the pipeline cache to determine if
|
|
|
|
/// it needs to create a new pipeline or not
|
|
|
|
///
|
|
|
|
/// In this example we just use the base `MeshPipelineKey` defined by bevy, but this could be anything.
|
|
|
|
/// For example, if you want to make a pipeline with a procedural shader you could add the Handle<Shader> to the key.
|
|
|
|
type Key = MeshPipelineKey;
|
|
|
|
|
|
|
|
fn specialize(
|
|
|
|
&self,
|
|
|
|
mesh_key: Self::Key,
|
|
|
|
layout: &MeshVertexBufferLayoutRef,
|
|
|
|
) -> Result<RenderPipelineDescriptor, SpecializedMeshPipelineError> {
|
|
|
|
// Define the vertex attributes based on a standard bevy [`Mesh`]
|
|
|
|
let mut vertex_attributes = Vec::new();
|
|
|
|
if layout.0.contains(Mesh::ATTRIBUTE_POSITION) {
|
|
|
|
// Make sure this matches the shader location
|
|
|
|
vertex_attributes.push(Mesh::ATTRIBUTE_POSITION.at_shader_location(0));
|
|
|
|
}
|
|
|
|
if layout.0.contains(Mesh::ATTRIBUTE_COLOR) {
|
|
|
|
// Make sure this matches the shader location
|
|
|
|
vertex_attributes.push(Mesh::ATTRIBUTE_COLOR.at_shader_location(1));
|
|
|
|
}
|
|
|
|
// This will automatically generate the correct `VertexBufferLayout` based on the vertex attributes
|
|
|
|
let vertex_buffer_layout = layout.0.get_layout(&vertex_attributes)?;
|
|
|
|
|
|
|
|
Ok(RenderPipelineDescriptor {
|
|
|
|
label: Some("Specialized Mesh Pipeline".into()),
|
|
|
|
layout: vec![
|
|
|
|
// Bind group 0 is the view uniform
|
|
|
|
self.mesh_pipeline
|
|
|
|
.get_view_layout(MeshPipelineViewLayoutKey::from(mesh_key))
|
|
|
|
.clone(),
|
|
|
|
// Bind group 1 is the mesh uniform
|
|
|
|
self.mesh_pipeline.mesh_layouts.model_only.clone(),
|
|
|
|
],
|
|
|
|
push_constant_ranges: vec![],
|
|
|
|
vertex: VertexState {
|
|
|
|
shader: self.shader_handle.clone(),
|
|
|
|
shader_defs: vec![],
|
|
|
|
entry_point: "vertex".into(),
|
|
|
|
// Customize how to store the meshes' vertex attributes in the vertex buffer
|
|
|
|
buffers: vec![vertex_buffer_layout],
|
|
|
|
},
|
|
|
|
fragment: Some(FragmentState {
|
|
|
|
shader: self.shader_handle.clone(),
|
|
|
|
shader_defs: vec![],
|
|
|
|
entry_point: "fragment".into(),
|
|
|
|
targets: vec![Some(ColorTargetState {
|
|
|
|
// This isn't required, but bevy supports HDR and non-HDR rendering
|
|
|
|
// so it's generally recommended to specialize the pipeline for that
|
|
|
|
format: if mesh_key.contains(MeshPipelineKey::HDR) {
|
|
|
|
ViewTarget::TEXTURE_FORMAT_HDR
|
|
|
|
} else {
|
|
|
|
TextureFormat::bevy_default()
|
|
|
|
},
|
|
|
|
// For this example we only use opaque meshes,
|
|
|
|
// but if you wanted to use alpha blending you would need to set it here
|
|
|
|
blend: None,
|
|
|
|
write_mask: ColorWrites::ALL,
|
|
|
|
})],
|
|
|
|
}),
|
|
|
|
primitive: PrimitiveState {
|
|
|
|
topology: mesh_key.primitive_topology(),
|
|
|
|
front_face: FrontFace::Ccw,
|
|
|
|
cull_mode: Some(Face::Back),
|
|
|
|
polygon_mode: PolygonMode::Fill,
|
|
|
|
..default()
|
|
|
|
},
|
|
|
|
// Note that if your view has no depth buffer this will need to be
|
|
|
|
// changed.
|
|
|
|
depth_stencil: Some(DepthStencilState {
|
|
|
|
format: CORE_3D_DEPTH_FORMAT,
|
|
|
|
depth_write_enabled: true,
|
|
|
|
depth_compare: CompareFunction::GreaterEqual,
|
|
|
|
stencil: default(),
|
|
|
|
bias: default(),
|
|
|
|
}),
|
|
|
|
// It's generally recommended to specialize your pipeline for MSAA,
|
|
|
|
// but it's not always possible
|
|
|
|
multisample: MultisampleState {
|
|
|
|
count: mesh_key.msaa_samples(),
|
|
|
|
..MultisampleState::default()
|
|
|
|
},
|
2024-11-08 21:42:37 +00:00
|
|
|
zero_initialize_workgroup_memory: false,
|
2024-07-31 18:24:58 +00:00
|
|
|
})
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/// A render-world system that enqueues the entity with custom rendering into
|
|
|
|
/// the opaque render phases of each view.
|
|
|
|
#[allow(clippy::too_many_arguments)]
|
|
|
|
fn queue_custom_mesh_pipeline(
|
|
|
|
pipeline_cache: Res<PipelineCache>,
|
|
|
|
custom_mesh_pipeline: Res<CustomMeshPipeline>,
|
|
|
|
mut opaque_render_phases: ResMut<ViewBinnedRenderPhases<Opaque3d>>,
|
|
|
|
opaque_draw_functions: Res<DrawFunctions<Opaque3d>>,
|
|
|
|
mut specialized_mesh_pipelines: ResMut<SpecializedMeshPipelines<CustomMeshPipeline>>,
|
Type safe retained render world (#15756)
# Objective
In the Render World, there are a number of collections that are derived
from Main World entities and are used to drive rendering. The most
notable are:
- `VisibleEntities`, which is generated in the `check_visibility` system
and contains visible entities for a view.
- `ExtractedInstances`, which maps entity ids to asset ids.
In the old model, these collections were trivially kept in sync -- any
extracted phase item could look itself up because the render entity id
was guaranteed to always match the corresponding main world id.
After #15320, this became much more complicated, and was leading to a
number of subtle bugs in the Render World. The main rendering systems,
i.e. `queue_material_meshes` and `queue_material2d_meshes`, follow a
similar pattern:
```rust
for visible_entity in visible_entities.iter::<With<Mesh2d>>() {
let Some(mesh_instance) = render_mesh_instances.get_mut(visible_entity) else {
continue;
};
// Look some more stuff up and specialize the pipeline...
let bin_key = Opaque2dBinKey {
pipeline: pipeline_id,
draw_function: draw_opaque_2d,
asset_id: mesh_instance.mesh_asset_id.into(),
material_bind_group_id: material_2d.get_bind_group_id().0,
};
opaque_phase.add(
bin_key,
*visible_entity,
BinnedRenderPhaseType::mesh(mesh_instance.automatic_batching),
);
}
```
In this case, `visible_entities` and `render_mesh_instances` are both
collections that are created and keyed by Main World entity ids, and so
this lookup happens to work by coincidence. However, there is a major
unintentional bug here: namely, because `visible_entities` is a
collection of Main World ids, the phase item being queued is created
with a Main World id rather than its correct Render World id.
This happens to not break mesh rendering because the render commands
used for drawing meshes do not access the `ItemQuery` parameter, but
demonstrates the confusion that is now possible: our UI phase items are
correctly being queued with Render World ids while our meshes aren't.
Additionally, this makes it very easy and error prone to use the wrong
entity id to look up things like assets. For example, if instead we
ignored visibility checks and queued our meshes via a query, we'd have
to be extra careful to use `&MainEntity` instead of the natural
`Entity`.
## Solution
Make all collections that are derived from Main World data use
`MainEntity` as their key, to ensure type safety and avoid accidentally
looking up data with the wrong entity id:
```rust
pub type MainEntityHashMap<V> = hashbrown::HashMap<MainEntity, V, EntityHash>;
```
Additionally, we make all `PhaseItem` be able to provide both their Main
and Render World ids, to allow render phase implementors maximum
flexibility as to what id should be used to look up data.
You can think of this like tracking at the type level whether something
in the Render World should use it's "primary key", i.e. entity id, or
needs to use a foreign key, i.e. `MainEntity`.
## Testing
##### TODO:
This will require extensive testing to make sure things didn't break!
Additionally, some extraction logic has become more complicated and
needs to be checked for regressions.
## Migration Guide
With the advent of the retained render world, collections that contain
references to `Entity` that are extracted into the render world have
been changed to contain `MainEntity` in order to prevent errors where a
render world entity id is used to look up an item by accident. Custom
rendering code may need to be changed to query for `&MainEntity` in
order to look up the correct item from such a collection. Additionally,
users who implement their own extraction logic for collections of main
world entity should strongly consider extracting into a different
collection that uses `MainEntity` as a key.
Additionally, render phases now require specifying both the `Entity` and
`MainEntity` for a given `PhaseItem`. Custom render phases should ensure
`MainEntity` is available when queuing a phase item.
2024-10-10 18:47:04 +00:00
|
|
|
views: Query<(Entity, &RenderVisibleEntities, &ExtractedView, &Msaa), With<ExtractedView>>,
|
2024-07-31 18:24:58 +00:00
|
|
|
render_meshes: Res<RenderAssets<RenderMesh>>,
|
|
|
|
render_mesh_instances: Res<RenderMeshInstances>,
|
|
|
|
) {
|
|
|
|
// Get the id for our custom draw function
|
|
|
|
let draw_function_id = opaque_draw_functions
|
|
|
|
.read()
|
|
|
|
.id::<DrawSpecializedPipelineCommands>();
|
|
|
|
|
|
|
|
// Render phases are per-view, so we need to iterate over all views so that
|
|
|
|
// the entity appears in them. (In this example, we have only one view, but
|
|
|
|
// it's good practice to loop over all views anyway.)
|
|
|
|
for (view_entity, view_visible_entities, view, msaa) in views.iter() {
|
|
|
|
let Some(opaque_phase) = opaque_render_phases.get_mut(&view_entity) else {
|
|
|
|
continue;
|
|
|
|
};
|
|
|
|
|
|
|
|
// Create the key based on the view. In this case we only care about MSAA and HDR
|
|
|
|
let view_key = MeshPipelineKey::from_msaa_samples(msaa.samples())
|
|
|
|
| MeshPipelineKey::from_hdr(view.hdr);
|
|
|
|
|
|
|
|
// Find all the custom rendered entities that are visible from this
|
|
|
|
// view.
|
Type safe retained render world (#15756)
# Objective
In the Render World, there are a number of collections that are derived
from Main World entities and are used to drive rendering. The most
notable are:
- `VisibleEntities`, which is generated in the `check_visibility` system
and contains visible entities for a view.
- `ExtractedInstances`, which maps entity ids to asset ids.
In the old model, these collections were trivially kept in sync -- any
extracted phase item could look itself up because the render entity id
was guaranteed to always match the corresponding main world id.
After #15320, this became much more complicated, and was leading to a
number of subtle bugs in the Render World. The main rendering systems,
i.e. `queue_material_meshes` and `queue_material2d_meshes`, follow a
similar pattern:
```rust
for visible_entity in visible_entities.iter::<With<Mesh2d>>() {
let Some(mesh_instance) = render_mesh_instances.get_mut(visible_entity) else {
continue;
};
// Look some more stuff up and specialize the pipeline...
let bin_key = Opaque2dBinKey {
pipeline: pipeline_id,
draw_function: draw_opaque_2d,
asset_id: mesh_instance.mesh_asset_id.into(),
material_bind_group_id: material_2d.get_bind_group_id().0,
};
opaque_phase.add(
bin_key,
*visible_entity,
BinnedRenderPhaseType::mesh(mesh_instance.automatic_batching),
);
}
```
In this case, `visible_entities` and `render_mesh_instances` are both
collections that are created and keyed by Main World entity ids, and so
this lookup happens to work by coincidence. However, there is a major
unintentional bug here: namely, because `visible_entities` is a
collection of Main World ids, the phase item being queued is created
with a Main World id rather than its correct Render World id.
This happens to not break mesh rendering because the render commands
used for drawing meshes do not access the `ItemQuery` parameter, but
demonstrates the confusion that is now possible: our UI phase items are
correctly being queued with Render World ids while our meshes aren't.
Additionally, this makes it very easy and error prone to use the wrong
entity id to look up things like assets. For example, if instead we
ignored visibility checks and queued our meshes via a query, we'd have
to be extra careful to use `&MainEntity` instead of the natural
`Entity`.
## Solution
Make all collections that are derived from Main World data use
`MainEntity` as their key, to ensure type safety and avoid accidentally
looking up data with the wrong entity id:
```rust
pub type MainEntityHashMap<V> = hashbrown::HashMap<MainEntity, V, EntityHash>;
```
Additionally, we make all `PhaseItem` be able to provide both their Main
and Render World ids, to allow render phase implementors maximum
flexibility as to what id should be used to look up data.
You can think of this like tracking at the type level whether something
in the Render World should use it's "primary key", i.e. entity id, or
needs to use a foreign key, i.e. `MainEntity`.
## Testing
##### TODO:
This will require extensive testing to make sure things didn't break!
Additionally, some extraction logic has become more complicated and
needs to be checked for regressions.
## Migration Guide
With the advent of the retained render world, collections that contain
references to `Entity` that are extracted into the render world have
been changed to contain `MainEntity` in order to prevent errors where a
render world entity id is used to look up an item by accident. Custom
rendering code may need to be changed to query for `&MainEntity` in
order to look up the correct item from such a collection. Additionally,
users who implement their own extraction logic for collections of main
world entity should strongly consider extracting into a different
collection that uses `MainEntity` as a key.
Additionally, render phases now require specifying both the `Entity` and
`MainEntity` for a given `PhaseItem`. Custom render phases should ensure
`MainEntity` is available when queuing a phase item.
2024-10-10 18:47:04 +00:00
|
|
|
for &(render_entity, visible_entity) in view_visible_entities
|
2024-07-31 18:24:58 +00:00
|
|
|
.get::<WithCustomRenderedEntity>()
|
|
|
|
.iter()
|
|
|
|
{
|
|
|
|
// Get the mesh instance
|
|
|
|
let Some(mesh_instance) = render_mesh_instances.render_mesh_queue_data(visible_entity)
|
|
|
|
else {
|
|
|
|
continue;
|
|
|
|
};
|
|
|
|
|
|
|
|
// Get the mesh data
|
|
|
|
let Some(mesh) = render_meshes.get(mesh_instance.mesh_asset_id) else {
|
|
|
|
continue;
|
|
|
|
};
|
|
|
|
|
|
|
|
// Specialize the key for the current mesh entity
|
|
|
|
// For this example we only specialize based on the mesh topology
|
|
|
|
// but you could have more complex keys and that's where you'd need to create those keys
|
|
|
|
let mut mesh_key = view_key;
|
|
|
|
mesh_key |= MeshPipelineKey::from_primitive_topology(mesh.primitive_topology());
|
|
|
|
|
|
|
|
// Finally, we can specialize the pipeline based on the key
|
|
|
|
let pipeline_id = specialized_mesh_pipelines
|
|
|
|
.specialize(
|
|
|
|
&pipeline_cache,
|
|
|
|
&custom_mesh_pipeline,
|
|
|
|
mesh_key,
|
|
|
|
&mesh.layout,
|
|
|
|
)
|
|
|
|
// This should never with this example, but if your pipeline specialization
|
|
|
|
// can fail you need to handle the error here
|
|
|
|
.expect("Failed to specialize mesh pipeline");
|
|
|
|
|
|
|
|
// Add the mesh with our specialized pipeline
|
|
|
|
opaque_phase.add(
|
|
|
|
Opaque3dBinKey {
|
Use multidraw for opaque meshes when GPU culling is in use. (#16427)
This commit adds support for *multidraw*, which is a feature that allows
multiple meshes to be drawn in a single drawcall. `wgpu` currently
implements multidraw on Vulkan, so this feature is only enabled there.
Multiple meshes can be drawn at once if they're in the same vertex and
index buffers and are otherwise placed in the same bin. (Thus, for
example, at present the materials and textures must be identical, but
see #16368.) Multidraw is a significant performance improvement during
the draw phase because it reduces the number of rebindings, as well as
the number of drawcalls.
This feature is currently only enabled when GPU culling is used: i.e.
when `GpuCulling` is present on a camera. Therefore, if you run for
example `scene_viewer`, you will not see any performance improvements,
because `scene_viewer` doesn't add the `GpuCulling` component to its
camera.
Additionally, the multidraw feature is only implemented for opaque 3D
meshes and not for shadows or 2D meshes. I plan to make GPU culling the
default and to extend the feature to shadows in the future. Also, in the
future I suspect that polyfilling multidraw on APIs that don't support
it will be fruitful, as even without driver-level support use of
multidraw allows us to avoid expensive `wgpu` rebindings.
2024-12-06 17:22:03 +00:00
|
|
|
batch_set_key: Opaque3dBatchSetKey {
|
|
|
|
draw_function: draw_function_id,
|
|
|
|
pipeline: pipeline_id,
|
|
|
|
material_bind_group_index: None,
|
|
|
|
vertex_slab: default(),
|
|
|
|
index_slab: None,
|
|
|
|
lightmap_image: None,
|
|
|
|
},
|
2024-07-31 18:24:58 +00:00
|
|
|
// The asset ID is arbitrary; we simply use [`AssetId::invalid`],
|
|
|
|
// but you can use anything you like. Note that the asset ID need
|
|
|
|
// not be the ID of a [`Mesh`].
|
|
|
|
asset_id: AssetId::<Mesh>::invalid().untyped(),
|
|
|
|
},
|
Type safe retained render world (#15756)
# Objective
In the Render World, there are a number of collections that are derived
from Main World entities and are used to drive rendering. The most
notable are:
- `VisibleEntities`, which is generated in the `check_visibility` system
and contains visible entities for a view.
- `ExtractedInstances`, which maps entity ids to asset ids.
In the old model, these collections were trivially kept in sync -- any
extracted phase item could look itself up because the render entity id
was guaranteed to always match the corresponding main world id.
After #15320, this became much more complicated, and was leading to a
number of subtle bugs in the Render World. The main rendering systems,
i.e. `queue_material_meshes` and `queue_material2d_meshes`, follow a
similar pattern:
```rust
for visible_entity in visible_entities.iter::<With<Mesh2d>>() {
let Some(mesh_instance) = render_mesh_instances.get_mut(visible_entity) else {
continue;
};
// Look some more stuff up and specialize the pipeline...
let bin_key = Opaque2dBinKey {
pipeline: pipeline_id,
draw_function: draw_opaque_2d,
asset_id: mesh_instance.mesh_asset_id.into(),
material_bind_group_id: material_2d.get_bind_group_id().0,
};
opaque_phase.add(
bin_key,
*visible_entity,
BinnedRenderPhaseType::mesh(mesh_instance.automatic_batching),
);
}
```
In this case, `visible_entities` and `render_mesh_instances` are both
collections that are created and keyed by Main World entity ids, and so
this lookup happens to work by coincidence. However, there is a major
unintentional bug here: namely, because `visible_entities` is a
collection of Main World ids, the phase item being queued is created
with a Main World id rather than its correct Render World id.
This happens to not break mesh rendering because the render commands
used for drawing meshes do not access the `ItemQuery` parameter, but
demonstrates the confusion that is now possible: our UI phase items are
correctly being queued with Render World ids while our meshes aren't.
Additionally, this makes it very easy and error prone to use the wrong
entity id to look up things like assets. For example, if instead we
ignored visibility checks and queued our meshes via a query, we'd have
to be extra careful to use `&MainEntity` instead of the natural
`Entity`.
## Solution
Make all collections that are derived from Main World data use
`MainEntity` as their key, to ensure type safety and avoid accidentally
looking up data with the wrong entity id:
```rust
pub type MainEntityHashMap<V> = hashbrown::HashMap<MainEntity, V, EntityHash>;
```
Additionally, we make all `PhaseItem` be able to provide both their Main
and Render World ids, to allow render phase implementors maximum
flexibility as to what id should be used to look up data.
You can think of this like tracking at the type level whether something
in the Render World should use it's "primary key", i.e. entity id, or
needs to use a foreign key, i.e. `MainEntity`.
## Testing
##### TODO:
This will require extensive testing to make sure things didn't break!
Additionally, some extraction logic has become more complicated and
needs to be checked for regressions.
## Migration Guide
With the advent of the retained render world, collections that contain
references to `Entity` that are extracted into the render world have
been changed to contain `MainEntity` in order to prevent errors where a
render world entity id is used to look up an item by accident. Custom
rendering code may need to be changed to query for `&MainEntity` in
order to look up the correct item from such a collection. Additionally,
users who implement their own extraction logic for collections of main
world entity should strongly consider extracting into a different
collection that uses `MainEntity` as a key.
Additionally, render phases now require specifying both the `Entity` and
`MainEntity` for a given `PhaseItem`. Custom render phases should ensure
`MainEntity` is available when queuing a phase item.
2024-10-10 18:47:04 +00:00
|
|
|
(render_entity, visible_entity),
|
2024-07-31 18:24:58 +00:00
|
|
|
// This example supports batching, but if your pipeline doesn't
|
|
|
|
// support it you can use `BinnedRenderPhaseType::UnbatchableMesh`
|
|
|
|
BinnedRenderPhaseType::BatchableMesh,
|
|
|
|
);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|