I’d like to open a discussion on making a base material shader customizable, from the idea that came from discussions in GitHub during the VAT implementation. I’m offering myself to implement this.
What I propose that would work for me as an user:
- All the
Fragment_*methods currently in
CustomMaterial/PBRCustomMaterialwould be moved to a
- Instead of storing a single string in the class for each of these methods, a
- Possibly each of the code fragments also could have a priority (
number) so that basic trivial sorting of code can be done for the most simple and common cases.
class Materialhave a
customShaderCode: CustomShaderCodefield. Another possibility is that
Materialimplements all the methods directly, but composition seems cleaner here. It also allows to change the
CustomShaderCodeclass easily for a more specialized version.
- Pretty much the same
CustomMaterialis implemented in
PBRCustomMaterialbecome essentially aliases for
PBRMaterial, with all its methods just calling
this.customShaderCode.xxx. This keeps backwards compatibility.
What do you think? This is purely my “works as an user for my problems” view, but apparently this feature could have an impact on other parts of Babylonjs and simplify other parts of its code.