Materials Library revisited

[JCPalmer]

When materials library was being developed / part of the monthly contest, I did not have time to pay that much attention.  Now I had a thought I might make a material for an eye maybe like this, but also normalish eyes with settable eye color, pupil size:

Am already planning to use separate the left & right eye & place the origin in the back center of each.  Simple rotations can then be done, eliminating the need for a bone. 

Am now trying to catch up.  Does this look like a good candidate?  This material would probably not be repo'ed.  It is kind of custom, and only would work if you had separated eye meshes.  Is there a technical requirement to be in the repo?

Did not see any topic in documentation (did not search the forum yet).  Spot checking the source, it was encouraging to see the attribute, vEyePosition, being passed to shaders.  Is this the center of the pupil?

Finally, there were not base Material library classes, so I side by side diff'ed simple vs Lava.  There are enormous quantities of similarities, but did notice that somethings that should be the same were not, like bone handling (that's what I was working back then).  Might not a base class that has all the standard stuff make this a simple effort be a good idea?  Have method for subclasser to call in their constructor to specify the unique attributes for them.  Would make what was unique stand out.  Or is this what procedureTexturesLibrary is for?

[JCPalmer]

Ok, do not know how I missed those Materials & Procedure Textures doc pages.  Still not understand the difference.  Both are straight to the task, but most is spend on getting them into either library

[GameMonetize]

procedural textures are...textures and have to be used by material

Materials can be directly applied to mesh. For me this is the differentiator: if you need a mesh it is a material else it is a procedural texture

[GameMonetize]

Regarding the first questions, I did not think about a smart way to share common part as everything rely on what you do INSIDe your shader.

You can inherit from JS code for sure but what about GLSL? You still have to provide the complete file unfortunately

So this may appear as a lot of copy/paste but I don't know how to proceed differently. 

[GameMonetize]

Oh last but not least  materials in material library are not part of the core and thus are maintained by their respective authors.

But when a material starts being powerful and used enough we can think about moving it into the core where it will be keep in sync with the engine (for instance, we will certainly do it for the PBR). This means adding support for it in exporters for instance

Think about libraries (material and procedural textures) as incubators for the core engine

[GameMonetize]

BUT...this gave me an idea  please keep posted!

[GameMonetize]

HA HA! I introduced shaders includes

https://github.com/BabylonJS/Babylon.js/blob/master/src/Shaders/default.vertex.fx#L18

which injects:

https://github.com/BabylonJS/Babylon.js/blob/master/src/Shaders/ShadersInclude/bonesDeclaration.fx

This will help developing materials for sure

[JCPalmer]

Yeah, your first observation of the obvious, that textures are used by materials & materials are used by meshes had escaped me, thanks.

The code replication of each material in the library is controllable entirely with subclassing on JS side though.  Any time there is a barrier or change in environment, JS to GLSL, or Python to JS , it is an opportunity to switch to WMD's, code that writes code.  It also can provide things that just cannot be done, like dynamic sub-classing of meshes with complex inline data.

Replicating entire shader pairs & JS files for every material seems counter productive at best, more likely as quick sand to moving to WebGL 2.0 or other future improvements.  Staying within the lines with C preprocessor commands certainly helps though.  Includes get some of the boiler plate out of the individual shader, but the concept could also be accomplished with strings inside JS.  #DEFINES can still be used for much of the heavy lifting.  The fact that there is no need for quotes inside of GLSL makes things easier / more readable.  Did you notice how militant I got with using single & double quotes when I first refactored the Blender exporter?

If a base TS class for a material was made, which built the shader pair strings, you could provide methods where subclasses could inject the GLSL parts that makes them special.  This base class should reside in the core.  The base class does a lot of string concatenation ( 1 string per GLSL line for readability), but I bet Gulp strips that out.  You get high modifiability, the subclass would only have what made fire special.  Just something to think about.