Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Custom Materials
Adds support for user defined materials, using WESL.
Background (Runtime Materials)
The implementation here is a bit tricky. In Bevy, materials are Rust structs that are processed at compile time with the
AsBindGroupmacro, which produces a shader layout and associated metadata for the given material type/struct.This kind of compile time material definition doesn't work for Processing, since our goal is to allow users to define materials in Python at runtime.
Consequently, we take advantage of recent work in Bevy, which allows supplying material information to the renderer at runtime as extracted data. These changes are being made in Bevy in order to support more runtime material definition in the upcoming Bevy Editor.
Warning
This is a relatively low level API that is likely to change in the future.
Reflection
One of the most difficult things for new learners of WebGPU is understanding shader layout (i.e.
BindGroupLayout). Our goal here is to abstract over layout entirely so that users only need to know the bare minimum which is that they have to add shader resources as@group(3) @binding(1), etc.To do so, we use shader reflection, which introspects the user's shader and generates a layout for that shader automatically. As such, when the user sets a value for their shader, we simply can look up to see if that value has a matching declaration in the shader, or ignore it.
This also means that, in the context of hot reloading, we do not require the user to specify every value. We can default initialize values for the user until they modify their sketch to set that value.
Bevy Integration
We are using a library I maintain, bevy_naga_reflect, which has a type
DynamicShaderthat wraps a naga module and provides runtime reflection over its bind group layout. Given a compiled shader module,DynamicShadercan:BindGroupLayoutDescriptorentries for a given bind group indexThis is what lets us bridge the gap between Bevy's compile-time material system and Processing's runtime API. The
CustomMaterialasset stores aDynamicShaderalongside a handle to the compiledShaderasset, and implementsErasedRenderAssetto producePreparedMaterialdata for the renderer.Custom Imports
We provide a shader prelude that shadows Bevy's own types (i.e.
bevy_pbr::forward_io::VertexOutput). Additionally, I'm packaging Lygia which users can import as well.Demo