[Feature Request] Material function parameter expose and contextualization via namespaces.

General Feedback & Requests
1

Material functions would be far better if one could define parameters in them that can be exposed and contextualized instead of just putting them in the global namespace.
So I can define a group for them from the caller and make them unique using a namespace.
Say I have a generic “contrast brightness and offset” function.
If I Parametrize it directly in the function I should get 3 plain parameters “contrast”,“brightness” and “offset” in my material in the global namespace.
Say that I use this function twice, once on my roughness and once on a mask that define a color overlay and it will not work as they get exposed but shared.
On the other hand, with the contextualization improvement , you could create a namespace that makes a unique set of parameters and place them under a group always chosen on call and still in the caller we can have a sorting index to sort the inner params packed together in the outer group.

so In my example for a function having

Params

  • contrast
  • brightness
  • offset

and a material using it twice once with Roughness namespace and group and sort 1 and the other with Overlay mask I will get this configuration in the material instance editor

Roughness

  • other rough param
  • Roughness.contrast
  • Roughness.brightness
  • Roughness.offset
  • other rough param

OverlayMask

  • other params
  • OverlayMask.contrast
  • OverlayMask.brightness
  • OverlayMask.offset
  • other params
2

For a concrete example of the actual shortcomings I made a master material to support masked layering of materials. ! have 4 layers every one with manually diverse parameters (L1, L2, L3, L4) made by substitution in notepad.
Say that I made instances of these material function to make a library I would use the MF_LayeredMat1 as a base.
The problem is that all the resulting library will be applicable only to the first slot of the material as the others needs the differently named parametersor they will share parameters with another layer.

Experimental Material layers would help a lot in this specific use case, but sadly are far more inefficient as in the master material version one can precalculate a lot and then share results between layers while with material layers one cannot easely share things around( a partial solution is to pass things in attributes that arent used , but you then have to plan everything accordingly and come with its own set of limitations).
Actually material layers also burns all the available samplers not recognizing things like mask sampler being the same in every layer.