I have a three.js project that loads about 6 gltf files in sequence using the GLTFLoader.load function. The files are up to a couple MB each. This works fairly quickly on revision 103, but after an update to 119 I am having much more lockup as the files load. I load the first 2 files, then I add them to the scene, then I continue loading the ‘remaining’ models. The remaining models are not needed right away, so I was hoping the app would be interactive and the remaining models could load silently in the background.
It seems to load and parse the json quickly, but in my browser performance monitor I’m seeing much more time spent in the buildNodeHierarchy function in the loadScene of GLTFLoader. I compare the functions and don’t see many differences. So I don’t think the cause is just the GLTFLoader.
Do you have any idea what might be causing this? Maybe other changes in three.js that are used in this buildNodeHierarchy function?
Is there extra work being done now in the later versions during mesh creation that maybe I could bypass? I don’t put the ‘remaining’ models in the scene till they are needed so I simply load them and store them in a cache array till needed. So it’s not a render issue, just something that happens after parsing json and before returning the three objects. I would also just be happy with a way to split out to a webworker the job of parsing and creating the three objects and meshes. I just don’t want the main thread to block.
The lag I’m seeing is not the file loading, it is just sometime after the json.parse happens in the GLTFLoader and before that load completes.
This is easy to switch back to older versions of THREE and it speeds up again, so I know it’s not just something outside of THREE that has changed.
Thanks.
I’m not aware of any extra work being done in this method. Can you share an example (JSFiddle?) before and after, to compare the differences?
For me the r119 link is loading only some of the time, it shows an error usually:
I tried running the Chrome Dev Tools profiler, and it doesn’t really show much time at all being spent in GLTFLoader, but maybe i’m seeing something different because of the error? What does the chart on the Dev Tools profiler show for you?
Looking at the two .gltf files I see requested on that page, the only thing that I’d expect to cause a hitch is the embedded data URIs. It would be more efficient to convert them to binary .glb with glTF-Pipeline. But that shouldn’t be any different between r119 and r103.
Sorry I was trying to debug this and had one line commented out. It should be working again now.
I did take your advice and I now convert to glb instead of gltf and it is saving me about 50% on file sizes across most of our models. That’s AWESOME. I didn’t even have to change my JS code at all. Just worked. That will help initial load, but I think the processing lag is still about the same.
Here’s the profiling output, this is what you’ll want to optimize:
The glTF parsing took only 18ms, and much of that would be fixed by switching to the more efficient binary (.glb) variant of glTF. It seems like your new demo on r119 uses .gltf and the old one uses .glb?
Before:
After:
I don’t recommend that, it would be better to stick with .glb. I don’t think it’s the main difference between these, but it’s a bit hard to compare when they’re not loading the same content.
Zooming in on the 1st frame more:
The last chunk is React, I can’t comment on that. I’m not sure what the first chunk is doing, compiling materials maybe? It would be worth comparing r118 and r119 to see if the difference is still there, I might have a guess if so.