Adding full support for custom materials to GltfLoader#2725
Open
theMinka wants to merge 10 commits intojMonkeyEngine:masterfrom
Open
Adding full support for custom materials to GltfLoader#2725theMinka wants to merge 10 commits intojMonkeyEngine:masterfrom
theMinka 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}
Contributor
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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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