Adding full support for custom materials to GltfLoader#2725
Adding full support for custom materials to GltfLoader#2725theMinka wants to merge 10 commits intojMonkeyEngine:masterfrom
Conversation
If multiple GLTF extensions are present on an element, the CustomContentManager now processes all supported ones instead of just the first one.
…al creation process
* Step 1: Collect all material data in the new GltfMaterialData object * Step 1.1: GltfLoader reads all standard GLTF parameters * Step 1.2: ExtensionLoader and ExtrasLoader can read additional GLTF parameters * Step 2: Find a matching GltfMaterialFactory and use it to create the material
…ensionLoaders * Retains the old MaterialAdapter handling for backward compatibility
…d material * Added both material factories as the default ones to the GltfLoader
Reason: Setting default values directly in GltfMaterialData obscures whether a parameter is actually defined in the glTF material. The presence of material parameters may be relevant for some material factories. Therefore, default values should be set by the material factories themselves.
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a new material factory system for the GLTF loader, deprecating the legacy material adapter system. The new architecture uses GltfMaterialData and GltfMaterialFactory to provide a more extensible approach to material creation. Feedback was provided to correct a typo in the EMISSIV constant names within GltfMaterialData.java to improve code consistency.
| public static final String EMISSIV_TEXTURE_PARAM = "material.emissiveTexture"; | ||
|
|
||
| public static final String EMISSIV_COLOR_PARAM = "material.emissiveFactor"; |
There was a problem hiding this comment.
There appears to be a typo in the constant names. EMISSIV should likely be EMISSIVE. Correcting this would improve consistency and maintainability.
This change would also need to be propagated to GltfLoader.java, PBRLightingMaterialFactory.java, and UnshadedMaterialFactory.java where these constants are used.
| public static final String EMISSIV_TEXTURE_PARAM = "material.emissiveTexture"; | |
| public static final String EMISSIV_COLOR_PARAM = "material.emissiveFactor"; | |
| public static final String EMISSIVE_TEXTURE_PARAM = "material.emissiveTexture"; | |
| public static final String EMISSIVE_COLOR_PARAM = "material.emissiveFactor"; |
1 participant
Reworked the material creation process in
GltfLoader, to allow for custom materials to be created.Supporting a custom material definition
To support a new material definition, one simply needs to implement a new
GltfMaterialFactoryand register it with theGltfLoader. It is important to consider the overall order of all registered material factories, because only the first factory that accepts a given material data instance will be used. By default, there are already two material factories: one for thePBRLightingmaterial and one for theUnshadedmaterial.One special use case would be when someone creates a copy of the standard
PBRLightingmaterial to add additional functionality. If none of the original material parameters have been changed (adding new ones is not a problem), one can simply extendPBRLightingMaterialFactoryand modify the material definition path returned by thegetMaterialDefPath()method. Finally, the originalPBRLightingMaterialFactoryjust needs to be replaced in theGltfLoaderwith the custom one. This way, all loaded models will use the extendedPBRLightingmaterial.Backward compatibility
As mentioned earlier, my new system is not backward compatible with regard to custom
MaterialAdapters. Therefore, I have kept the old implementation but disabled it. To reactivate it, a specific flag must be set in theGltfModelKey. This will fully switch back to the old material creation process when loading the corresponding 3D model.However, I believe that keeping the old
MaterialAdaptersystem in the engine is not a good long-term solution. I suggest removing it in one or two future releases. To reflect this, I have already marked most classes, methods, and fields related to the old process as deprecated.Forum discussion:
https://hub.jmonkeyengine.org/t/adding-full-support-for-custom-materials-to-gltfloader/49444
Also fixed some related bugs:
CustomContentManagercan now handle multiple GLTF extensions per elementBlendMode.AlphaAdditiveare now added toQueueBucket.Transparent