LoadingManager: onLoad invoked early by loaders with async parsing

GLTFLoader goes through the following steps for .gltf assets.

1. request .gltf JSON manifest
2. parse JSON, request necessary .bin and texture resources
3. assemble scene graph and call loader’s onLoad callback

All three of those steps are asynchronous, but LoadingManager invokes its on onLoad after any file request finishes if there are no outstanding requests. So the manager calls onLoad after steps (1) and (2), both. The issue is still there for .glb, because assembly is still asynchronous.

COLLADALoader gets around this because its parsing step is synchronous. As soon as the .dae file is obtained, it synchronously parses, calls the loader onLoad, and then the manager’s onLoad is invoked. Texture requests will finish some time after that.

That approach isn’t an option for glTF — we could hack a solution:

const fakeRequestURL = '[[my-fake-request-232932929]]';
manager.itemStart( fakeRequestURL );

// ... do async requests and assembly ...

manager.itemEnd( fakeRequestURL );

This makes itemsLoaded / itemsTotal incorrect, but isn’t the worst outcome. Otherwise I think we’d need to change the LoadingManager API a bit.

[Mugen87]

@donmccurdy For now, I think creating a proxy request via manager.itemStart() and manager.itemEnd() is the best solution for GLTFLoader.

[pailhead]

Please consider that the tone of one’s posts may be misinterpreted based on a language barrier. I believe that there is some frustration among the users who don’t have stakes in other libraries, products and companies.

GLTFLoader definitely comes off as a first class citizen, and seems to be influencing many three.js core changes. This is a very valid concern:

Please pay attention and don’t mess up the THREE LoadingManager just to make the GLTF loader run “better”. That’s all I ask here.

Possibly could be reworded as:

Please proceed with care when refactoring THREE.LoadingManager and consider the fact that GLTFLoader is not the only loader present in /examples. Thank you.

Please consult other loaders for possible alternate patterns that might remove the requirement to modify THREE.LoadingManager. Thank you.