Looking for pipeline specialization examples

[viridia]

I'm attempting to solve a difficult problem and I need help. The use case is an app that interactively generates shaders, such as ShaderToy or Blender's shader editor. I already have code that can procedurally generate the .wgsl source and generate a Handle<Shader>. However, now I want to preview what the shader looks like on a Bevy primitive such as Sphere or Cuboid.

Ideally, what I want is something that behaves mostly like StandardMaterial, except with the vertex shader replaced with my generated shader. In this sense, it's much like ExtendedMaterial, except that won't work in this case because Bevy materials are (mostly) stateless: the fragment_shader() and vertex_shader() methods have no self param, they can only return static constants.

Also, because I want to be able to preview multiple materials at the same time, the shader can't be a static global or a handle in a resource. Similarly, writing out the shader code to a file and then loading the file as an asset doesn't work either, since the asset path to the file would have to be dynamic too.

From what I can tell, the only solution is to create a custom render pipeline. There are only a tiny number of examples on the web showing how to set up a pipeline in Bevy: two official examples, the one in Hanabi, and one older message board post from the Bevy 0.11 era.

Most of these examples are somewhat problematic because they set up a pipeline from scratch: that is, they don't leverage much of the functionality of the existing pipelines. This makes sense for something like Hanabi, which is creating a new type of primitive (particles) that doesn't overlap much with the existing Bevy primitives. I would much rather be able to invoke the standard mesh pipeline and then tweak the output - this means that I wouldn't have to duplicate all the complex logic around MSAA, buffer layouts, vertex formats, and so on. Also, a lot of these examples omit details for clarity - like for example always using the MSAA default setting instead of the "real" value.

The one example that sort of does what I want is the mesh2d_manual example: it uses the standard mesh2d pipeline to create a RenderPipelineDescriptor and then modifies some of the properties afterwards. Unfortunately, the 2d pipelines are just different enough from the 3d pipelines (in terms of how things are constructed) that I have been unable to figure out how to adapt this same approach to 3d rendering.

So basically I need an example showing how to do this.

I should mention, BTW, that the work I'm doing is part of porting one of my apps from three.js to Bevy, and generating shader code algorithmically and assigning it to a material is fairly trivial to do in three.js.

[mosure]

would the specialize implementation work?

• sort of like this:

  bevy/crates/bevy_pbr/src/material.rs

  Lines 379 to 404 in b231ebb

  	impl<M: Material> SpecializedMeshPipeline for MaterialPipeline<M>
  	where
  	M::Data: PartialEq + Eq + Hash + Clone,
  	{
  	type Key = MaterialPipelineKey<M>;
  	fn specialize(
  	&self,
  	key: Self::Key,
  	layout: &MeshVertexBufferLayoutRef,
  	) -> Result<RenderPipelineDescriptor, SpecializedMeshPipelineError> {
  	let mut descriptor = self.mesh_pipeline.specialize(key.mesh_key, layout)?;
  	if let Some(vertex_shader) = &self.vertex_shader {
  	descriptor.vertex.shader = vertex_shader.clone();
  	}
  	if let Some(fragment_shader) = &self.fragment_shader {
  	descriptor.fragment.as_mut().unwrap().shader = fragment_shader.clone();
  	}
  	descriptor.layout.insert(2, self.material_layout.clone());
  	M::specialize(self, &mut descriptor, layout, key)?;
  	Ok(descriptor)
  	}
  	}

• more like this: https://github.com/mosure/bevy_zeroverse/blob/01c04977b2d337b493601eb708181a2508700522/src/render/depth.rs#L73-L91

e.g.

#[derive(Default, Resource, Debug, Clone)]
pub struct DynamicShaderMaterial(Handle<Shader>);

impl Material for DynamicShaderMaterial {
    fn specialize(
        _pipeline: &MaterialPipeline<Self>,
        descriptor: &mut RenderPipelineDescriptor,
        _layout: &MeshVertexBufferLayoutRef,
        _key: MaterialPipelineKey<Self>,
    ) -> Result<(), SpecializedMeshPipelineError> {
        descriptor.vertex.shader = self.0.clone();
        descriptor.fragment.as_mut().unwrap().shader = self.0.clone();
        Ok(())
    }
}

[viridia]

In your code example, you're getting the shader from self.0 - but the specialize method has no self argument.

[mosure]

right.. 😅 it seems like Material::specialize should have a self argument.

[IceSentry]

Do you need to be able to update the bindings dynamically too or only the fragment/vertex shader with fixed material bindings?

If you don't need to update the bindings at runtime I'm not entirely sure I understand why you can't just store the shader handle in a const associated with a material that uses that const?

[viridia]

That only works if the material is a singleton, that is, if I only ever view one generated material at a time.

Again, consider something like shadertoy, where you have a gallery view showing multiple different materials, each with its own preview.

[IceSentry]

This example should have what you need for a custom 3d pipeline. https://github.com/bevyengine/bevy/blob/main/examples/shader/custom_phase_item.rs

[viridia]

I've been looking at both your (deleted) example and the linked example. There's still a bunch of details I'm not grasping.

Your example is better in some ways than the custom_phase_item example: for one thing, your version makes fewer assumptions about the mesh topology. Your example works with regular Bevy Mesh objects, whereas the CPI example is doing something strange with buffers.

OTOH, your snippet makes reference to RenderMesh, which is not defined in Bevy.

[IceSentry]

Ah, I deleted my snippet because it did essentially the same thing as the example so I just linked it instead. I didn't really consider the mesh assumptions to be that important.

I don't have the snippet code available because I just deleted it once I realized the example existed 😅 but I know it compiled and ran so not sure what the RenderMesh thing is.

[IceSentry]

The example should be able to be adapted to not make any mesh assumptions too. I can help you with that if you'd like.

[viridia]

Haha, I still had your previous code in my email history :)

Here's a gist showing a sketch of what I have so far: https://gist.github.com/viridia/f3abbe83fcf970f6e4ec5c43416c5f96 - note this code doesn't compile, it's a weird hybrid of the various examples mentioned in this thread and there's parts that are incomplete that I haven't figured out yet.

The basic concept of the Gist is that you spawn a bundle that contains a Mesh along with a NodeShader3d(Handle<Shader>) component; the Handle<Shader> becomes one of the fields of the pipeline key.

When the user edits the shader code, it replaces the Shader resource, so you don't need to respawn the mesh (hopefully).