Adding full support for custom materials to GltfLoader

pspeed:

Yeah, those are static because they have to be available at loader instantiation time.

Sorry, I overlooked that they are static. Forget my comment about those config methodes.

pspeed:

If this is just about loading a regular GLTF with a different material then I think the only way would be to replace the existing GltfLoader with your own (which could be a subclass if you want most of the behavior and then override createMaterial()).

True, but as I was looking into this, I realized that this could be a neat little improvement in general.

pspeed:

Else there would have to be something about the gltf file that signaled the customization…

Yes, you are right, but this is no different from the current process. If the GLTF file contains the KHR_materials_unlit extension, then an “Unshaded” material is created—unless the KHR_materials_emissive_strength extension is also present (and comes second). In that case, it overrides this decision by reverting to the standard PBRLighting material.

My suggested approach works in a similar way: every registered GltfMaterialFactory has the potential to define which material gets created, and its decision is based on the actual data provided by the GLTF file. The new system provides even more flexibility in making these decisions, because they are not only based on extensions and extras, but can consider all kinds of combinations of extensions, extras, material parameters and AssetKey parameters.