Dynamic UI Materials

[amytimed]

Objective

• The objective is to allow having a dynamic material for UI, where different instances of it can have a different shader only known at runtime, instead of hardcoding a single shader at compile time
  • In my case, the utility is in my project I am adding background: shader(...) to CSS stylesheets that style Bevy UI. This requires dynamic shaders

Solution

• UIMaterial's vertex_shader and fragment_shader functions get a &self parameter, and the code now calls those with the self and understands that the shader may vary

Testing

• Tested in my codebase with 2 instances of the same material, but each with different shader (shown in showcase)
• Tested ui_material example and it still works fine

---

Showcase

#[derive(AsBindGroup, Asset, TypePath, Debug, Clone)]
struct CustomUiMaterial {
    shader_handle: Handle<Shader>,
}

impl UiMaterial for CustomUiMaterial {
    fn fragment_shader(&self) -> bevy::shader::ShaderRef {
        self.shader_handle.clone().into() // intuitive dynamic materials !!!
    }
}

Migration

Users would just need to add a &self to their UI materials

[github-actions]

It looks like your PR is a breaking change, but you didn't provide a migration guide.

Please review the instructions for writing migration guides, then expand or revise the content in the migration guides directory to reflect your changes.

[IceSentry]

I don't like how this introduces a difference with Material and Material2d. Also, I'm not sure of the potential side effects of adding 'static to the trait bound.

[amytimed]

I don't like how this introduces a difference with Material and Material2d

i think the best solution is to give them the same change

but that seems more suited for separate PRs

[tychedelia]

Hi! I'm definitely interested in supporting this use case, and indeed it was one of my original motivations for #14856 which was the work that inspired #19667. In the case of 3d materials, I discovered that adding the &self param resulted in a significant performance regression. While it's likely less severe in ui given the relatively smaller sets of entities (particularly with materials) at play, I'm reluctant to make this change until we can make it across all 3 material types at the same time. The good news is that this work is planned as a high priority for 0.18 and will allow us to be able to support this without any risk of performance problems. :)

[amytimed]

okie dokie, that's fine, since bevy is modular I'm able to use this version instead of bevy_ui_render without forking all of bevy which is great 🕊️