Using customShaderNameResolve properly

Questions
1

Hi!

I am working on a web app where I need to extend the current BABYLON.StandardMaterial to add some custom behaviors.
Using BABYLON.CustomMaterial would lead to many superfluous material compilations, provoking webGL context losses on large scenes. Thus, I am now directly extending the BABYLON.StandardMaterial class.

I reproduced my way of extending the standard material in this playground :

I created a new pair of shaders from the standard material, modifying it thanks to the #define handles for the custom Material.
Then, I only use customShaderNameResolve to return the name of the shader I previously created.
Finally, to support new uniforms, I have to overload the whole StandardMaterial.isReadyForSubMesh() function, and add my new uniform in the uniform array.

I find this way quite convoluted and hacky. Am I using the system correctly, or did I overcomplicate my usage of customShaderNameResolve?

Although, if it is the only way for this to save avoid some shader complations, I would like to work on a PR to add documentation and some handles in the code (maybe a “customUniforms” and a “customSamplers” property in the Standard Material class that the isReadyForSubMesh() could take into account?) to make my current “hack” into something cleaner and easier to use.

Thanks in advance for your answer!

2 Likes
2

Have you taken a look at material plugins?

3

As @Heaust-ops said, the preferred (and most efficient) way to extend materials is to create a material plugin.

1 Like
4

@Heaust-ops @Evgeni_Popov I didn’t hear about material plugins! I’ll take a more precise look into it but it looks like the kind of solution that would work for me :slight_smile:

Thanks!

Are you planning on depreciating the CustomMaterial system?

1 Like
5

No plan to depreciate CustomMaterial. It’s a community contribution outside Babylon core (it’s in the material-library package), so we are fine with it.

1 Like