Allow phase items not associated with meshes to be binned. (#14029)
As reported in #14004, many third-party plugins, such as Hanabi, enqueue
entities that don't have meshes into render phases. However, the
introduction of indirect mode added a dependency on mesh-specific data,
breaking this workflow. This is because GPU preprocessing requires that
the render phases manage indirect draw parameters, which don't apply to
objects that aren't meshes. The existing code skips over binned entities
that don't have indirect draw parameters, which causes the rendering to
be skipped for such objects.
To support this workflow, this commit adds a new field,
`non_mesh_items`, to `BinnedRenderPhase`. This field contains a simple
list of (bin key, entity) pairs. After drawing batchable and unbatchable
objects, the non-mesh items are drawn one after another. Bevy itself
doesn't enqueue any items into this list; it exists solely for the
application and/or plugins to use.
Additionally, this commit switches the asset ID in the standard bin keys
to be an untyped asset ID rather than that of a mesh. This allows more
flexibility, allowing bins to be keyed off any type of asset.
This patch adds a new example, `custom_phase_item`, which simultaneously
serves to demonstrate how to use this new feature and to act as a
regression test so this doesn't break again.
Fixes #14004.
## Changelog
### Added
* `BinnedRenderPhase` now contains a `non_mesh_items` field for plugins
to add custom items to.
2024-06-27 16:13:03 +00:00
|
|
|
//! Demonstrates how to enqueue custom draw commands in a render phase.
|
|
|
|
//!
|
|
|
|
//! This example shows how to use the built-in
|
|
|
|
//! [`bevy_render::render_phase::BinnedRenderPhase`] functionality with a
|
|
|
|
//! custom [`RenderCommand`] to allow inserting arbitrary GPU drawing logic
|
|
|
|
//! into Bevy's pipeline. This is not the only way to add custom rendering code
|
|
|
|
//! into Bevy—render nodes are another, lower-level method—but it does allow
|
|
|
|
//! for better reuse of parts of Bevy's built-in mesh rendering logic.
|
|
|
|
|
|
|
|
use bevy::{
|
|
|
|
core_pipeline::core_3d::{Opaque3d, Opaque3dBinKey, CORE_3D_DEPTH_FORMAT},
|
|
|
|
ecs::{
|
|
|
|
query::ROQueryItem,
|
|
|
|
system::{lifetimeless::SRes, SystemParamItem},
|
|
|
|
},
|
|
|
|
prelude::*,
|
|
|
|
render::{
|
|
|
|
extract_component::{ExtractComponent, ExtractComponentPlugin},
|
|
|
|
primitives::Aabb,
|
|
|
|
render_phase::{
|
|
|
|
AddRenderCommand, BinnedRenderPhaseType, DrawFunctions, PhaseItem, RenderCommand,
|
|
|
|
RenderCommandResult, SetItemPipeline, TrackedRenderPass, ViewBinnedRenderPhases,
|
|
|
|
},
|
|
|
|
render_resource::{
|
|
|
|
BufferUsages, ColorTargetState, ColorWrites, CompareFunction, DepthStencilState,
|
|
|
|
FragmentState, IndexFormat, MultisampleState, PipelineCache, PrimitiveState,
|
|
|
|
RawBufferVec, RenderPipelineDescriptor, SpecializedRenderPipeline,
|
|
|
|
SpecializedRenderPipelines, TextureFormat, VertexAttribute, VertexBufferLayout,
|
|
|
|
VertexFormat, VertexState, VertexStepMode,
|
|
|
|
},
|
|
|
|
renderer::{RenderDevice, RenderQueue},
|
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, VisibilitySystems},
|
Allow phase items not associated with meshes to be binned. (#14029)
As reported in #14004, many third-party plugins, such as Hanabi, enqueue
entities that don't have meshes into render phases. However, the
introduction of indirect mode added a dependency on mesh-specific data,
breaking this workflow. This is because GPU preprocessing requires that
the render phases manage indirect draw parameters, which don't apply to
objects that aren't meshes. The existing code skips over binned entities
that don't have indirect draw parameters, which causes the rendering to
be skipped for such objects.
To support this workflow, this commit adds a new field,
`non_mesh_items`, to `BinnedRenderPhase`. This field contains a simple
list of (bin key, entity) pairs. After drawing batchable and unbatchable
objects, the non-mesh items are drawn one after another. Bevy itself
doesn't enqueue any items into this list; it exists solely for the
application and/or plugins to use.
Additionally, this commit switches the asset ID in the standard bin keys
to be an untyped asset ID rather than that of a mesh. This allows more
flexibility, allowing bins to be keyed off any type of asset.
This patch adds a new example, `custom_phase_item`, which simultaneously
serves to demonstrate how to use this new feature and to act as a
regression test so this doesn't break again.
Fixes #14004.
## Changelog
### Added
* `BinnedRenderPhase` now contains a `non_mesh_items` field for plugins
to add custom items to.
2024-06-27 16:13:03 +00:00
|
|
|
Render, RenderApp, RenderSet,
|
|
|
|
},
|
|
|
|
};
|
|
|
|
use bytemuck::{Pod, Zeroable};
|
|
|
|
|
|
|
|
/// A marker component that represents an entity that is to be rendered using
|
|
|
|
/// our custom phase item.
|
|
|
|
///
|
|
|
|
/// 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;
|
|
|
|
|
|
|
|
/// Holds a reference to our shader.
|
|
|
|
///
|
|
|
|
/// This is loaded at app creation time.
|
|
|
|
#[derive(Resource)]
|
|
|
|
struct CustomPhasePipeline {
|
|
|
|
shader: Handle<Shader>,
|
|
|
|
}
|
|
|
|
|
|
|
|
/// A [`RenderCommand`] that binds the vertex and index buffers and issues the
|
|
|
|
/// draw command for our custom phase item.
|
|
|
|
struct DrawCustomPhaseItem;
|
|
|
|
|
|
|
|
impl<P> RenderCommand<P> for DrawCustomPhaseItem
|
|
|
|
where
|
|
|
|
P: PhaseItem,
|
|
|
|
{
|
|
|
|
type Param = SRes<CustomPhaseItemBuffers>;
|
|
|
|
|
|
|
|
type ViewQuery = ();
|
|
|
|
|
|
|
|
type ItemQuery = ();
|
|
|
|
|
|
|
|
fn render<'w>(
|
|
|
|
_: &P,
|
|
|
|
_: ROQueryItem<'w, Self::ViewQuery>,
|
|
|
|
_: Option<ROQueryItem<'w, Self::ItemQuery>>,
|
|
|
|
custom_phase_item_buffers: SystemParamItem<'w, '_, Self::Param>,
|
|
|
|
pass: &mut TrackedRenderPass<'w>,
|
|
|
|
) -> RenderCommandResult {
|
|
|
|
// Borrow check workaround.
|
|
|
|
let custom_phase_item_buffers = custom_phase_item_buffers.into_inner();
|
|
|
|
|
|
|
|
// Tell the GPU where the vertices are.
|
|
|
|
pass.set_vertex_buffer(
|
|
|
|
0,
|
|
|
|
custom_phase_item_buffers
|
|
|
|
.vertices
|
|
|
|
.buffer()
|
|
|
|
.unwrap()
|
|
|
|
.slice(..),
|
|
|
|
);
|
|
|
|
|
|
|
|
// Tell the GPU where the indices are.
|
|
|
|
pass.set_index_buffer(
|
|
|
|
custom_phase_item_buffers
|
|
|
|
.indices
|
|
|
|
.buffer()
|
|
|
|
.unwrap()
|
|
|
|
.slice(..),
|
|
|
|
0,
|
|
|
|
IndexFormat::Uint32,
|
|
|
|
);
|
|
|
|
|
|
|
|
// Draw one triangle (3 vertices).
|
|
|
|
pass.draw_indexed(0..3, 0, 0..1);
|
|
|
|
|
|
|
|
RenderCommandResult::Success
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/// The GPU vertex and index buffers for our custom phase item.
|
|
|
|
///
|
|
|
|
/// As the custom phase item is a single triangle, these are uploaded once and
|
|
|
|
/// then left alone.
|
|
|
|
#[derive(Resource)]
|
|
|
|
struct CustomPhaseItemBuffers {
|
|
|
|
/// The vertices for the single triangle.
|
|
|
|
///
|
|
|
|
/// This is a [`RawBufferVec`] because that's the simplest and fastest type
|
|
|
|
/// of GPU buffer, and [`Vertex`] objects are simple.
|
|
|
|
vertices: RawBufferVec<Vertex>,
|
|
|
|
|
|
|
|
/// The indices of the single triangle.
|
|
|
|
///
|
|
|
|
/// As above, this is a [`RawBufferVec`] because `u32` values have trivial
|
|
|
|
/// size and alignment.
|
|
|
|
indices: RawBufferVec<u32>,
|
|
|
|
}
|
|
|
|
|
|
|
|
/// The CPU-side structure that describes a single vertex of the triangle.
|
|
|
|
#[derive(Clone, Copy, Pod, Zeroable)]
|
|
|
|
#[repr(C)]
|
|
|
|
struct Vertex {
|
|
|
|
/// The 3D position of the triangle vertex.
|
|
|
|
position: Vec3,
|
|
|
|
/// Padding.
|
|
|
|
pad0: u32,
|
|
|
|
/// The color of the triangle vertex.
|
|
|
|
color: Vec3,
|
|
|
|
/// Padding.
|
|
|
|
pad1: u32,
|
|
|
|
}
|
|
|
|
|
|
|
|
impl Vertex {
|
|
|
|
/// Creates a new vertex structure.
|
|
|
|
const fn new(position: Vec3, color: Vec3) -> Vertex {
|
|
|
|
Vertex {
|
|
|
|
position,
|
|
|
|
color,
|
|
|
|
pad0: 0,
|
|
|
|
pad1: 0,
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/// The custom draw commands that Bevy executes for each entity we enqueue into
|
|
|
|
/// the render phase.
|
|
|
|
type DrawCustomPhaseItemCommands = (SetItemPipeline, DrawCustomPhaseItem);
|
|
|
|
|
|
|
|
/// A query filter that tells [`view::check_visibility`] about our custom
|
|
|
|
/// rendered entity.
|
|
|
|
type WithCustomRenderedEntity = With<CustomRenderedEntity>;
|
|
|
|
|
|
|
|
/// A single triangle's worth of vertices, for demonstration purposes.
|
|
|
|
static VERTICES: [Vertex; 3] = [
|
|
|
|
Vertex::new(vec3(-0.866, -0.5, 0.5), vec3(1.0, 0.0, 0.0)),
|
|
|
|
Vertex::new(vec3(0.866, -0.5, 0.5), vec3(0.0, 1.0, 0.0)),
|
|
|
|
Vertex::new(vec3(0.0, 1.0, 0.5), vec3(0.0, 0.0, 1.0)),
|
|
|
|
];
|
|
|
|
|
|
|
|
/// The entry point.
|
|
|
|
fn main() {
|
|
|
|
let mut app = App::new();
|
|
|
|
app.add_plugins(DefaultPlugins)
|
|
|
|
.add_plugins(ExtractComponentPlugin::<CustomRenderedEntity>::default())
|
|
|
|
.add_systems(Startup, setup)
|
|
|
|
// Make sure to tell Bevy to check our entity for visibility. Bevy won't
|
|
|
|
// do this by default, for efficiency reasons.
|
|
|
|
.add_systems(
|
|
|
|
PostUpdate,
|
|
|
|
view::check_visibility::<WithCustomRenderedEntity>
|
|
|
|
.in_set(VisibilitySystems::CheckVisibility),
|
|
|
|
);
|
|
|
|
|
|
|
|
// We make sure to add these to the render app, not the main app.
|
|
|
|
app.get_sub_app_mut(RenderApp)
|
|
|
|
.unwrap()
|
|
|
|
.init_resource::<CustomPhasePipeline>()
|
|
|
|
.init_resource::<SpecializedRenderPipelines<CustomPhasePipeline>>()
|
|
|
|
.add_render_command::<Opaque3d, DrawCustomPhaseItemCommands>()
|
|
|
|
.add_systems(
|
|
|
|
Render,
|
|
|
|
prepare_custom_phase_item_buffers.in_set(RenderSet::Prepare),
|
|
|
|
)
|
|
|
|
.add_systems(Render, queue_custom_phase_item.in_set(RenderSet::Queue));
|
|
|
|
|
|
|
|
app.run();
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Spawns the objects in the scene.
|
|
|
|
fn setup(mut commands: Commands) {
|
|
|
|
// Spawn a single entity that has custom rendering. It'll be extracted into
|
|
|
|
// the render world via [`ExtractComponent`].
|
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
|
|
|
commands.spawn((
|
|
|
|
Visibility::default(),
|
|
|
|
Transform::default(),
|
Allow phase items not associated with meshes to be binned. (#14029)
As reported in #14004, many third-party plugins, such as Hanabi, enqueue
entities that don't have meshes into render phases. However, the
introduction of indirect mode added a dependency on mesh-specific data,
breaking this workflow. This is because GPU preprocessing requires that
the render phases manage indirect draw parameters, which don't apply to
objects that aren't meshes. The existing code skips over binned entities
that don't have indirect draw parameters, which causes the rendering to
be skipped for such objects.
To support this workflow, this commit adds a new field,
`non_mesh_items`, to `BinnedRenderPhase`. This field contains a simple
list of (bin key, entity) pairs. After drawing batchable and unbatchable
objects, the non-mesh items are drawn one after another. Bevy itself
doesn't enqueue any items into this list; it exists solely for the
application and/or plugins to use.
Additionally, this commit switches the asset ID in the standard bin keys
to be an untyped asset ID rather than that of a mesh. This allows more
flexibility, allowing bins to be keyed off any type of asset.
This patch adds a new example, `custom_phase_item`, which simultaneously
serves to demonstrate how to use this new feature and to act as a
regression test so this doesn't break again.
Fixes #14004.
## Changelog
### Added
* `BinnedRenderPhase` now contains a `non_mesh_items` field for plugins
to add custom items to.
2024-06-27 16:13:03 +00:00
|
|
|
// This `Aabb` is necessary for the visibility checks to work.
|
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
|
|
|
Aabb {
|
Allow phase items not associated with meshes to be binned. (#14029)
As reported in #14004, many third-party plugins, such as Hanabi, enqueue
entities that don't have meshes into render phases. However, the
introduction of indirect mode added a dependency on mesh-specific data,
breaking this workflow. This is because GPU preprocessing requires that
the render phases manage indirect draw parameters, which don't apply to
objects that aren't meshes. The existing code skips over binned entities
that don't have indirect draw parameters, which causes the rendering to
be skipped for such objects.
To support this workflow, this commit adds a new field,
`non_mesh_items`, to `BinnedRenderPhase`. This field contains a simple
list of (bin key, entity) pairs. After drawing batchable and unbatchable
objects, the non-mesh items are drawn one after another. Bevy itself
doesn't enqueue any items into this list; it exists solely for the
application and/or plugins to use.
Additionally, this commit switches the asset ID in the standard bin keys
to be an untyped asset ID rather than that of a mesh. This allows more
flexibility, allowing bins to be keyed off any type of asset.
This patch adds a new example, `custom_phase_item`, which simultaneously
serves to demonstrate how to use this new feature and to act as a
regression test so this doesn't break again.
Fixes #14004.
## Changelog
### Added
* `BinnedRenderPhase` now contains a `non_mesh_items` field for plugins
to add custom items to.
2024-06-27 16:13:03 +00:00
|
|
|
center: Vec3A::ZERO,
|
|
|
|
half_extents: Vec3A::splat(0.5),
|
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
|
|
|
},
|
|
|
|
CustomRenderedEntity,
|
|
|
|
));
|
Allow phase items not associated with meshes to be binned. (#14029)
As reported in #14004, many third-party plugins, such as Hanabi, enqueue
entities that don't have meshes into render phases. However, the
introduction of indirect mode added a dependency on mesh-specific data,
breaking this workflow. This is because GPU preprocessing requires that
the render phases manage indirect draw parameters, which don't apply to
objects that aren't meshes. The existing code skips over binned entities
that don't have indirect draw parameters, which causes the rendering to
be skipped for such objects.
To support this workflow, this commit adds a new field,
`non_mesh_items`, to `BinnedRenderPhase`. This field contains a simple
list of (bin key, entity) pairs. After drawing batchable and unbatchable
objects, the non-mesh items are drawn one after another. Bevy itself
doesn't enqueue any items into this list; it exists solely for the
application and/or plugins to use.
Additionally, this commit switches the asset ID in the standard bin keys
to be an untyped asset ID rather than that of a mesh. This allows more
flexibility, allowing bins to be keyed off any type of asset.
This patch adds a new example, `custom_phase_item`, which simultaneously
serves to demonstrate how to use this new feature and to act as a
regression test so this doesn't break again.
Fixes #14004.
## Changelog
### Added
* `BinnedRenderPhase` now contains a `non_mesh_items` field for plugins
to add custom items to.
2024-06-27 16:13:03 +00:00
|
|
|
|
|
|
|
// Spawn the camera.
|
2024-10-05 01:59:52 +00:00
|
|
|
commands.spawn((
|
|
|
|
Camera3d::default(),
|
|
|
|
Transform::from_xyz(0.0, 0.0, 1.0).looking_at(Vec3::ZERO, Vec3::Y),
|
|
|
|
));
|
Allow phase items not associated with meshes to be binned. (#14029)
As reported in #14004, many third-party plugins, such as Hanabi, enqueue
entities that don't have meshes into render phases. However, the
introduction of indirect mode added a dependency on mesh-specific data,
breaking this workflow. This is because GPU preprocessing requires that
the render phases manage indirect draw parameters, which don't apply to
objects that aren't meshes. The existing code skips over binned entities
that don't have indirect draw parameters, which causes the rendering to
be skipped for such objects.
To support this workflow, this commit adds a new field,
`non_mesh_items`, to `BinnedRenderPhase`. This field contains a simple
list of (bin key, entity) pairs. After drawing batchable and unbatchable
objects, the non-mesh items are drawn one after another. Bevy itself
doesn't enqueue any items into this list; it exists solely for the
application and/or plugins to use.
Additionally, this commit switches the asset ID in the standard bin keys
to be an untyped asset ID rather than that of a mesh. This allows more
flexibility, allowing bins to be keyed off any type of asset.
This patch adds a new example, `custom_phase_item`, which simultaneously
serves to demonstrate how to use this new feature and to act as a
regression test so this doesn't break again.
Fixes #14004.
## Changelog
### Added
* `BinnedRenderPhase` now contains a `non_mesh_items` field for plugins
to add custom items to.
2024-06-27 16:13:03 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/// Creates the [`CustomPhaseItemBuffers`] resource.
|
|
|
|
///
|
|
|
|
/// This must be done in a startup system because it needs the [`RenderDevice`]
|
|
|
|
/// and [`RenderQueue`] to exist, and they don't until [`App::run`] is called.
|
|
|
|
fn prepare_custom_phase_item_buffers(mut commands: Commands) {
|
|
|
|
commands.init_resource::<CustomPhaseItemBuffers>();
|
|
|
|
}
|
|
|
|
|
|
|
|
/// A render-world system that enqueues the entity with custom rendering into
|
|
|
|
/// the opaque render phases of each view.
|
|
|
|
fn queue_custom_phase_item(
|
|
|
|
pipeline_cache: Res<PipelineCache>,
|
|
|
|
custom_phase_pipeline: Res<CustomPhasePipeline>,
|
|
|
|
mut opaque_render_phases: ResMut<ViewBinnedRenderPhases<Opaque3d>>,
|
|
|
|
opaque_draw_functions: Res<DrawFunctions<Opaque3d>>,
|
|
|
|
mut specialized_render_pipelines: ResMut<SpecializedRenderPipelines<CustomPhasePipeline>>,
|
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, &Msaa), With<ExtractedView>>,
|
Allow phase items not associated with meshes to be binned. (#14029)
As reported in #14004, many third-party plugins, such as Hanabi, enqueue
entities that don't have meshes into render phases. However, the
introduction of indirect mode added a dependency on mesh-specific data,
breaking this workflow. This is because GPU preprocessing requires that
the render phases manage indirect draw parameters, which don't apply to
objects that aren't meshes. The existing code skips over binned entities
that don't have indirect draw parameters, which causes the rendering to
be skipped for such objects.
To support this workflow, this commit adds a new field,
`non_mesh_items`, to `BinnedRenderPhase`. This field contains a simple
list of (bin key, entity) pairs. After drawing batchable and unbatchable
objects, the non-mesh items are drawn one after another. Bevy itself
doesn't enqueue any items into this list; it exists solely for the
application and/or plugins to use.
Additionally, this commit switches the asset ID in the standard bin keys
to be an untyped asset ID rather than that of a mesh. This allows more
flexibility, allowing bins to be keyed off any type of asset.
This patch adds a new example, `custom_phase_item`, which simultaneously
serves to demonstrate how to use this new feature and to act as a
regression test so this doesn't break again.
Fixes #14004.
## Changelog
### Added
* `BinnedRenderPhase` now contains a `non_mesh_items` field for plugins
to add custom items to.
2024-06-27 16:13:03 +00:00
|
|
|
) {
|
|
|
|
let draw_custom_phase_item = opaque_draw_functions
|
|
|
|
.read()
|
|
|
|
.id::<DrawCustomPhaseItemCommands>();
|
|
|
|
|
|
|
|
// 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.)
|
2024-07-22 18:28:23 +00:00
|
|
|
for (view_entity, view_visible_entities, msaa) in views.iter() {
|
Allow phase items not associated with meshes to be binned. (#14029)
As reported in #14004, many third-party plugins, such as Hanabi, enqueue
entities that don't have meshes into render phases. However, the
introduction of indirect mode added a dependency on mesh-specific data,
breaking this workflow. This is because GPU preprocessing requires that
the render phases manage indirect draw parameters, which don't apply to
objects that aren't meshes. The existing code skips over binned entities
that don't have indirect draw parameters, which causes the rendering to
be skipped for such objects.
To support this workflow, this commit adds a new field,
`non_mesh_items`, to `BinnedRenderPhase`. This field contains a simple
list of (bin key, entity) pairs. After drawing batchable and unbatchable
objects, the non-mesh items are drawn one after another. Bevy itself
doesn't enqueue any items into this list; it exists solely for the
application and/or plugins to use.
Additionally, this commit switches the asset ID in the standard bin keys
to be an untyped asset ID rather than that of a mesh. This allows more
flexibility, allowing bins to be keyed off any type of asset.
This patch adds a new example, `custom_phase_item`, which simultaneously
serves to demonstrate how to use this new feature and to act as a
regression test so this doesn't break again.
Fixes #14004.
## Changelog
### Added
* `BinnedRenderPhase` now contains a `non_mesh_items` field for plugins
to add custom items to.
2024-06-27 16:13:03 +00:00
|
|
|
let Some(opaque_phase) = opaque_render_phases.get_mut(&view_entity) else {
|
|
|
|
continue;
|
|
|
|
};
|
|
|
|
|
|
|
|
// Find all the custom rendered entities that are visible from this
|
|
|
|
// view.
|
|
|
|
for &entity in view_visible_entities
|
|
|
|
.get::<WithCustomRenderedEntity>()
|
|
|
|
.iter()
|
|
|
|
{
|
|
|
|
// Ordinarily, the [`SpecializedRenderPipeline::Key`] would contain
|
|
|
|
// some per-view settings, such as whether the view is HDR, but for
|
|
|
|
// simplicity's sake we simply hard-code the view's characteristics,
|
|
|
|
// with the exception of number of MSAA samples.
|
|
|
|
let pipeline_id = specialized_render_pipelines.specialize(
|
|
|
|
&pipeline_cache,
|
|
|
|
&custom_phase_pipeline,
|
|
|
|
*msaa,
|
|
|
|
);
|
|
|
|
|
|
|
|
// Add the custom render item. We use the
|
|
|
|
// [`BinnedRenderPhaseType::NonMesh`] type to skip the special
|
|
|
|
// handling that Bevy has for meshes (preprocessing, indirect
|
|
|
|
// draws, etc.)
|
|
|
|
//
|
|
|
|
// 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`].
|
|
|
|
opaque_phase.add(
|
|
|
|
Opaque3dBinKey {
|
|
|
|
draw_function: draw_custom_phase_item,
|
|
|
|
pipeline: pipeline_id,
|
|
|
|
asset_id: AssetId::<Mesh>::invalid().untyped(),
|
Add a bindless mode to `AsBindGroup`. (#16368)
This patch adds the infrastructure necessary for Bevy to support
*bindless resources*, by adding a new `#[bindless]` attribute to
`AsBindGroup`.
Classically, only a single texture (or sampler, or buffer) can be
attached to each shader binding. This means that switching materials
requires breaking a batch and issuing a new drawcall, even if the mesh
is otherwise identical. This adds significant overhead not only in the
driver but also in `wgpu`, as switching bind groups increases the amount
of validation work that `wgpu` must do.
*Bindless resources* are the typical solution to this problem. Instead
of switching bindings between each texture, the renderer instead
supplies a large *array* of all textures in the scene up front, and the
material contains an index into that array. This pattern is repeated for
buffers and samplers as well. The renderer now no longer needs to switch
binding descriptor sets while drawing the scene.
Unfortunately, as things currently stand, this approach won't quite work
for Bevy. Two aspects of `wgpu` conspire to make this ideal approach
unacceptably slow:
1. In the DX12 backend, all binding arrays (bindless resources) must
have a constant size declared in the shader, and all textures in an
array must be bound to actual textures. Changing the size requires a
recompile.
2. Changing even one texture incurs revalidation of all textures, a
process that takes time that's linear in the total size of the binding
array.
This means that declaring a large array of textures big enough to
encompass the entire scene is presently unacceptably slow. For example,
if you declare 4096 textures, then `wgpu` will have to revalidate all
4096 textures if even a single one changes. This process can take
multiple frames.
To work around this problem, this PR groups bindless resources into
small *slabs* and maintains a free list for each. The size of each slab
for the bindless arrays associated with a material is specified via the
`#[bindless(N)]` attribute. For instance, consider the following
declaration:
```rust
#[derive(AsBindGroup)]
#[bindless(16)]
struct MyMaterial {
#[buffer(0)]
color: Vec4,
#[texture(1)]
#[sampler(2)]
diffuse: Handle<Image>,
}
```
The `#[bindless(N)]` attribute specifies that, if bindless arrays are
supported on the current platform, each resource becomes a binding array
of N instances of that resource. So, for `MyMaterial` above, the `color`
attribute is exposed to the shader as `binding_array<vec4<f32>, 16>`,
the `diffuse` texture is exposed to the shader as
`binding_array<texture_2d<f32>, 16>`, and the `diffuse` sampler is
exposed to the shader as `binding_array<sampler, 16>`. Inside the
material's vertex and fragment shaders, the applicable index is
available via the `material_bind_group_slot` field of the `Mesh`
structure. So, for instance, you can access the current color like so:
```wgsl
// `uniform` binding arrays are a non-sequitur, so `uniform` is automatically promoted
// to `storage` in bindless mode.
@group(2) @binding(0) var<storage> material_color: binding_array<Color, 4>;
...
@fragment
fn fragment(in: VertexOutput) -> @location(0) vec4<f32> {
let color = material_color[mesh[in.instance_index].material_bind_group_slot];
...
}
```
Note that portable shader code can't guarantee that the current platform
supports bindless textures. Indeed, bindless mode is only available in
Vulkan and DX12. The `BINDLESS` shader definition is available for your
use to determine whether you're on a bindless platform or not. Thus a
portable version of the shader above would look like:
```wgsl
#ifdef BINDLESS
@group(2) @binding(0) var<storage> material_color: binding_array<Color, 4>;
#else // BINDLESS
@group(2) @binding(0) var<uniform> material_color: Color;
#endif // BINDLESS
...
@fragment
fn fragment(in: VertexOutput) -> @location(0) vec4<f32> {
#ifdef BINDLESS
let color = material_color[mesh[in.instance_index].material_bind_group_slot];
#else // BINDLESS
let color = material_color;
#endif // BINDLESS
...
}
```
Importantly, this PR *doesn't* update `StandardMaterial` to be bindless.
So, for example, `scene_viewer` will currently not run any faster. I
intend to update `StandardMaterial` to use bindless mode in a follow-up
patch.
A new example, `shaders/shader_material_bindless`, has been added to
demonstrate how to use this new feature.
Here's a Tracy profile of `submit_graph_commands` of this patch and an
additional patch (not submitted yet) that makes `StandardMaterial` use
bindless. Red is those patches; yellow is `main`. The scene was Bistro
Exterior with a hack that forces all textures to opaque. You can see a
1.47x mean speedup.
![Screenshot 2024-11-12
161713](https://github.com/user-attachments/assets/4334b362-42c8-4d64-9cfb-6835f019b95c)
## Migration Guide
* `RenderAssets::prepare_asset` now takes an `AssetId` parameter.
* Bin keys now have Bevy-specific material bind group indices instead of
`wgpu` material bind group IDs, as part of the bindless change. Use the
new `MaterialBindGroupAllocator` to map from bind group index to bind
group ID.
2024-12-03 18:00:34 +00:00
|
|
|
material_bind_group_index: None,
|
Allow phase items not associated with meshes to be binned. (#14029)
As reported in #14004, many third-party plugins, such as Hanabi, enqueue
entities that don't have meshes into render phases. However, the
introduction of indirect mode added a dependency on mesh-specific data,
breaking this workflow. This is because GPU preprocessing requires that
the render phases manage indirect draw parameters, which don't apply to
objects that aren't meshes. The existing code skips over binned entities
that don't have indirect draw parameters, which causes the rendering to
be skipped for such objects.
To support this workflow, this commit adds a new field,
`non_mesh_items`, to `BinnedRenderPhase`. This field contains a simple
list of (bin key, entity) pairs. After drawing batchable and unbatchable
objects, the non-mesh items are drawn one after another. Bevy itself
doesn't enqueue any items into this list; it exists solely for the
application and/or plugins to use.
Additionally, this commit switches the asset ID in the standard bin keys
to be an untyped asset ID rather than that of a mesh. This allows more
flexibility, allowing bins to be keyed off any type of asset.
This patch adds a new example, `custom_phase_item`, which simultaneously
serves to demonstrate how to use this new feature and to act as a
regression test so this doesn't break again.
Fixes #14004.
## Changelog
### Added
* `BinnedRenderPhase` now contains a `non_mesh_items` field for plugins
to add custom items to.
2024-06-27 16:13:03 +00:00
|
|
|
lightmap_image: None,
|
|
|
|
},
|
|
|
|
entity,
|
|
|
|
BinnedRenderPhaseType::NonMesh,
|
|
|
|
);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl SpecializedRenderPipeline for CustomPhasePipeline {
|
|
|
|
type Key = Msaa;
|
|
|
|
|
|
|
|
fn specialize(&self, msaa: Self::Key) -> RenderPipelineDescriptor {
|
|
|
|
RenderPipelineDescriptor {
|
|
|
|
label: Some("custom render pipeline".into()),
|
|
|
|
layout: vec![],
|
|
|
|
push_constant_ranges: vec![],
|
|
|
|
vertex: VertexState {
|
|
|
|
shader: self.shader.clone(),
|
|
|
|
shader_defs: vec![],
|
|
|
|
entry_point: "vertex".into(),
|
|
|
|
buffers: vec![VertexBufferLayout {
|
2024-08-21 12:29:33 +00:00
|
|
|
array_stride: size_of::<Vertex>() as u64,
|
Allow phase items not associated with meshes to be binned. (#14029)
As reported in #14004, many third-party plugins, such as Hanabi, enqueue
entities that don't have meshes into render phases. However, the
introduction of indirect mode added a dependency on mesh-specific data,
breaking this workflow. This is because GPU preprocessing requires that
the render phases manage indirect draw parameters, which don't apply to
objects that aren't meshes. The existing code skips over binned entities
that don't have indirect draw parameters, which causes the rendering to
be skipped for such objects.
To support this workflow, this commit adds a new field,
`non_mesh_items`, to `BinnedRenderPhase`. This field contains a simple
list of (bin key, entity) pairs. After drawing batchable and unbatchable
objects, the non-mesh items are drawn one after another. Bevy itself
doesn't enqueue any items into this list; it exists solely for the
application and/or plugins to use.
Additionally, this commit switches the asset ID in the standard bin keys
to be an untyped asset ID rather than that of a mesh. This allows more
flexibility, allowing bins to be keyed off any type of asset.
This patch adds a new example, `custom_phase_item`, which simultaneously
serves to demonstrate how to use this new feature and to act as a
regression test so this doesn't break again.
Fixes #14004.
## Changelog
### Added
* `BinnedRenderPhase` now contains a `non_mesh_items` field for plugins
to add custom items to.
2024-06-27 16:13:03 +00:00
|
|
|
step_mode: VertexStepMode::Vertex,
|
|
|
|
// This needs to match the layout of [`Vertex`].
|
|
|
|
attributes: vec![
|
|
|
|
VertexAttribute {
|
|
|
|
format: VertexFormat::Float32x3,
|
|
|
|
offset: 0,
|
|
|
|
shader_location: 0,
|
|
|
|
},
|
|
|
|
VertexAttribute {
|
|
|
|
format: VertexFormat::Float32x3,
|
|
|
|
offset: 16,
|
|
|
|
shader_location: 1,
|
|
|
|
},
|
|
|
|
],
|
|
|
|
}],
|
|
|
|
},
|
|
|
|
fragment: Some(FragmentState {
|
|
|
|
shader: self.shader.clone(),
|
|
|
|
shader_defs: vec![],
|
|
|
|
entry_point: "fragment".into(),
|
|
|
|
targets: vec![Some(ColorTargetState {
|
|
|
|
// Ordinarily, you'd want to check whether the view has the
|
|
|
|
// HDR format and substitute the appropriate texture format
|
|
|
|
// here, but we omit that for simplicity.
|
|
|
|
format: TextureFormat::bevy_default(),
|
|
|
|
blend: None,
|
|
|
|
write_mask: ColorWrites::ALL,
|
|
|
|
})],
|
|
|
|
}),
|
|
|
|
primitive: PrimitiveState::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: false,
|
|
|
|
depth_compare: CompareFunction::Always,
|
|
|
|
stencil: default(),
|
|
|
|
bias: default(),
|
|
|
|
}),
|
|
|
|
multisample: MultisampleState {
|
|
|
|
count: msaa.samples(),
|
|
|
|
mask: !0,
|
|
|
|
alpha_to_coverage_enabled: false,
|
|
|
|
},
|
2024-11-08 21:42:37 +00:00
|
|
|
zero_initialize_workgroup_memory: false,
|
Allow phase items not associated with meshes to be binned. (#14029)
As reported in #14004, many third-party plugins, such as Hanabi, enqueue
entities that don't have meshes into render phases. However, the
introduction of indirect mode added a dependency on mesh-specific data,
breaking this workflow. This is because GPU preprocessing requires that
the render phases manage indirect draw parameters, which don't apply to
objects that aren't meshes. The existing code skips over binned entities
that don't have indirect draw parameters, which causes the rendering to
be skipped for such objects.
To support this workflow, this commit adds a new field,
`non_mesh_items`, to `BinnedRenderPhase`. This field contains a simple
list of (bin key, entity) pairs. After drawing batchable and unbatchable
objects, the non-mesh items are drawn one after another. Bevy itself
doesn't enqueue any items into this list; it exists solely for the
application and/or plugins to use.
Additionally, this commit switches the asset ID in the standard bin keys
to be an untyped asset ID rather than that of a mesh. This allows more
flexibility, allowing bins to be keyed off any type of asset.
This patch adds a new example, `custom_phase_item`, which simultaneously
serves to demonstrate how to use this new feature and to act as a
regression test so this doesn't break again.
Fixes #14004.
## Changelog
### Added
* `BinnedRenderPhase` now contains a `non_mesh_items` field for plugins
to add custom items to.
2024-06-27 16:13:03 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl FromWorld for CustomPhaseItemBuffers {
|
|
|
|
fn from_world(world: &mut World) -> Self {
|
|
|
|
let render_device = world.resource::<RenderDevice>();
|
|
|
|
let render_queue = world.resource::<RenderQueue>();
|
|
|
|
|
|
|
|
// Create the vertex and index buffers.
|
|
|
|
let mut vbo = RawBufferVec::new(BufferUsages::VERTEX);
|
|
|
|
let mut ibo = RawBufferVec::new(BufferUsages::INDEX);
|
|
|
|
|
|
|
|
for vertex in &VERTICES {
|
|
|
|
vbo.push(*vertex);
|
|
|
|
}
|
|
|
|
for index in 0..3 {
|
|
|
|
ibo.push(index);
|
|
|
|
}
|
|
|
|
|
|
|
|
// These two lines are required in order to trigger the upload to GPU.
|
|
|
|
vbo.write_buffer(render_device, render_queue);
|
|
|
|
ibo.write_buffer(render_device, render_queue);
|
|
|
|
|
|
|
|
CustomPhaseItemBuffers {
|
|
|
|
vertices: vbo,
|
|
|
|
indices: ibo,
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl FromWorld for CustomPhasePipeline {
|
|
|
|
fn from_world(world: &mut World) -> Self {
|
|
|
|
// Load and compile the shader in the background.
|
|
|
|
let asset_server = world.resource::<AssetServer>();
|
|
|
|
|
|
|
|
CustomPhasePipeline {
|
|
|
|
shader: asset_server.load("shaders/custom_phase_item.wgsl"),
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|