Hi, I love the functionality of the Material Parameter Collections. The Scalar and Vector Parameters works very well but static Boolean Parameters would make it incredible. I know much more shader permutations have to be compiled but without this some features are impossible.
Currently I have the following problem:
I want to use imposters as LOD for trees. It works very well. But for winter I needs a different set of textures without leafes. Currently I have to fade this with a lerp but this creates so much texture samples and much more use of texture memory. If this can be switched with a global parameter all would be fine. (If this feature ins’t possible until release of our game: Is there any other way to get what I want?)
Another Example is scalability. Currently we only have low and high Materials and nothing in between. With global static bools we are able to enable or disable some features.
I don’t understand why you can’t use the current static bool parameters in material instances. I’m thinking: make two material instances, one each way, controlled via the static bool. Then on the object you can set whichever version you want via something like UMeshComponent::SetMaterial.
I don’t think it would fit very well on nature of Material parameter collection.(basically wrapper around uniform/constant buffer object)
But I do like the idea of global static switches. Maybe this would need some careful planning that it would avoid 2^amountOfBools shader permutation explosion.
A Material parameter collection is meant to be able to be manipulated at runtime.
Static bools are meant to be manipulated at shader compile time.
These two concepts don’t really play well together. You would have to recompile shaders at runtime for all the materials with a static bool change, which is a bit… much.
That being said, I’d still like the ability to do this, but it might be a bit impractical.
As long as you don’t have a huge number of combos, it seems to me like you can get this effect right now if you want.
There’s of course no API to set these values at runtime (as you say it would need either a runtime compilation or at least pre-compiling all the combos), but if you have just a few combinations you care about, you can create material instances for each one and switch them in and out with UMeshComponent::SetMaterial() at runtime.
If you have more than 1 axis, you could stash them in a little array and select each one individually, which should be OK as long as the number of switches is on the small side. 2-3 might be okay. 50, not so much
This is possible but it isn’t very useful when updating e.g. thousands of foliage instances.
The Permutation System for this feature already exists. All variants have to be compiled in editor or when cooking. Its the same like the “Quality Switch Node” that works great. So they “only” have to implement custom static switches equally to the quality switch.
