Thank you so much, I’d be very happy to help improve this.
any other use case:
Well tinting is the most obvious. I could have also used this for atlas UV coordinates (but this turned into full asset-level material instances instead). We animate a few parameters to make enemies flash a bright emission color / pattern when they are hit (through timeline, custom track + monobehaviour, uses a chached material instance for the animation and then return to the original when the track is finished), that uses a similar approach as well.
I am currently working on dissolve effects and I reached a point where it becomes very difficult without property blocks because our inverted hull outline shader is rendered by a renderer feature and there is no way to instanciate that material properly for just one or two specific renderers. Hence I think I will have to use mpb here and break the srp batching for those instances.
Did you manage to make this generic?:
Well yes pretty much. It’s one mono behaviour that handles instanciating the material variant for a renderer. Currently for simplicity I have setup exactly one shader property (_Color) and there is only the color field in the inspector but that is the only thing keeping this from working on any property. Picking the correct property name and type and displaying a suitable property drawer would be required for a really generic solution, but that is doable I guess (but was’t prioritised so far). I could wrap the shader property selection in a small class that could handle vector, color and float values and then make the component use a list of those for example.
The code that sets the value on the material is as basic as it could be.
edit: I found one area where this approach lacks. When overriding the material with rendering features it obviously overwrites the material and opposed to propblocks the overriden values don’t carry over to the override material.