A multithreading issue with GltfLoader

[foxcc2021]

I use multithreading to load gltf models, when loaded, all model materials are messed up.

After I debug GltfLoader, I found out that there may be threading issue in the GltfLoader. The variable "defaultMaterialAdapters" cannot be "static". This variable will be shared when all threads load materials from the model.

A simple way to resolve this issue is to remove the "static".
Hope this helps.
I use jme version: 3.5.2-stable

I use this way to resolve my problem.

The wrong materials before

The correct materials after

[stephengold]

Thanks for the bug report and suggested fix.

[stephengold]

By the way ... creating threads to load models is good trick for reducing latency in a game. Another way to reduce latency is to convert the models to JMonkeyEngine's preferred format (j3o) at build time and then load the j3o instead of the glTF. And of course one can combine both tricks.

The expectation is that the glTF loader won't be used at runtime in a production game. Perhaps that's why the original author of GltfLoader didn't worry about thread safety.

[Ali-RS]

Apparently, CustomContentManager which handles Gltf extension loading is also not thread-safe. The defaultExtensionLoaders needs to be made non-static as well.

jmonkeyengine/jme3-plugins/src/gltf/java/com/jme3/scene/plugins/gltf/CustomContentManager.java

Lines 54 to 60 in ceb3564

	private static Map<String, ExtensionLoader> defaultExtensionLoaders = new HashMap<>();
	static {
	defaultExtensionLoaders.put("KHR_materials_pbrSpecularGlossiness", new PBRSpecGlossExtensionLoader());
	defaultExtensionLoaders.put("KHR_lights_punctual", new LightsPunctualExtensionLoader());
	defaultExtensionLoaders.put("KHR_materials_unlit", new UnlitExtensionLoader());
	}

[Ali-RS]

A fix is submitted: PR #1886

[Ali-RS]

Merged in commit 92f99ef