GLTFLoader: I cannot override KHR_materials_unlit

Is your feature request related to a problem? Please describe.

Background: I’m working on VRM materials, and I’m trying to utilize the GLTFLoader plugin system. VRM uses not only the extension VRMC_materials_mtoon-1.0 (it’s still a draft of new version though) but also uses KHR_materials_unlit at the same time as a fallback, attached as material extensions.

However, the behavior of loading KHR_materials_unlit is not built on the plugin system and hardcoded on the GLTFLoader itself, prioritizing its behavior than any other plugins registered.

https://github.com/mrdoob/three.js/blob/f43ec7c849d7cecbc4831d152cf6a5d97c45ad3b/examples/jsm/loaders/GLTFLoader.js#L2759-L2763

I assume it’s because it must delete properties that is related to pbr (metallic and roughness, for example) when it uses MeshBasicMaterial to prevent emitting expected warnings (that says “hey, I don’t know this parameter”).

Describe the solution you’d like

I think I can resolve this by doing them:

• Get rid of hardcoded behavior of KHR_materials_unlit, replacing with proper plugin system. I believe we can ditch warnings I have mentioned above using delete at extendMaterialParams.
• Also, I think GLTFLoader.register should be revised. Since it pushes given plugins into pluginCallbacks, it prioritizes preinstalled plugins rather than user-defined plugins, since _invokeOne will execute plugins in the order of the array.

https://github.com/mrdoob/three.js/blob/f43ec7c849d7cecbc4831d152cf6a5d97c45ad3b/examples/jsm/loaders/GLTFLoader.js#L220-L230

Describe alternatives you’ve considered

However, I can implement the MToon import from glTF in other ways. I thought it’s great to have as a GLTFLoader plugin though. Here is the implementation without plugin system, a mere function receives a result of GLTFLoader.

https://github.com/pixiv/three-vrm/blob/dev/packages/three-vrm/src/vrm/material/VRMMaterialImporter.ts

Additional context

[takahirox]

@FMS-Cat To clarify just in case, will 1. moving the unlit extension handler to plugin system and 2. prioritizing user-defined plugins over built-in plugins resolve your case?

[takahirox]

I was imagined using unshift instead of push because it’s natural to prioritize user defined plugins

Maybe this would make sense to me in most of cases. So how about switching from push to unshift so far (I assume it resolves @FMS-Cat case), and then we start to think of the option of .order/priority if we actually get more fine priority control request?