Page MenuHome

glTF file loads extremely slowly (5+ min)
Closed, InvalidPublicKNOWN ISSUE


System Information
Operating system: Windows 10
Graphics card:

Blender Version
Broken: 2.81 beta, 2019-11-18 12:53

Short description of error

glTF file takes 5 minutes to load into Blender, although it loads almost instantly into web viewers and other tools.

Exact steps for others to reproduce the error

  • Start Blender, default General project
  • File > Import > glTF 2.0, choose attached modelGroup.glb file (unzip it first)
  • Watch how long it takes; on my relatively fast machine, it takes over 5 min.
  • Load the same .glb into a web glTF viewer such as; it loads in a couple of seconds.

This model is 3 MB, with 120 meshes, no animations or anything fancy. 7.7M vertices, with vertex colors.
No errors appear in the Blender console.
The model is fully validated by the glTF 2.0 validators.

I tried enabling Draco mesh compression, but apparently that's not yet supported by the Blender glTF importer.

Event Timeline

Sounds like Blender is rebuilding the dependency graph (depsgraph) every time an object is added.
Since Viewers have no need to do this, they are faster.

Someone more familiar with glTF internals will have to weigh in here.

Julien DUROURE (julien) changed the subtype of this task from "Report" to "Known Issue".


I confirm that the long time comes from dependency graph rebuilding each time an object is added.
Based on the tracker curfew policy, this is not a bug. Solving performance will need either refactoring of the addon (not sure there is something we can do at addon level), or at blender core level.

Closing as Known issue / Architecture limitation

This issue is significant for me. Is there anything I can do to improve the situation? I'm more than happy to do some python profiling on the importer for instance - and I could even refactor the addon if I have some guidance, but I don't know Blender's internals well enough yet to know if that would be useful.

Note that even we can't fix in a short term any dependency graph rebuilding performance, glTF addon still continue to improve performance on directly addon related code.
See, for example, committed yesterday:

I spent some time on this. It's not all just dependency graph rebuilding. I was able to cut down my import time for one of my samples from 261 sec to 132 sec, so about a 50% speedup.
My patch is at (It's not finalized, it has some timing code which you may find useful. Let me know where to submit it if you think it's good.)
The main speedup for my use case comes from using numpy for color_linear_to_srgb and speed-hacking the inner vertex-color loop. I also got some speedups by using import_shading='SMOOTH' because the default import does a dot product on every vertex of every imported poly to see if it should be treated as smooth or flat.
After that, the largest time is spent in adding faces to the mesh. If there's a way to do that would improve things a lot.

After my patch, here's the top lines from the python profiler (which my patch enables):

      154336313 function calls (154336131 primitive calls) in 132.136 seconds

ncalls  tottime  percall  cumtime  percall filename:lineno(function)
   120   55.081    0.459  105.909    0.883 ...io_scene_gltf2\blender\imp\
   120   19.794    0.165   21.836    0.182 ...io_scene_gltf2\blender\imp\

so those would be the next things to attack. Most of add_primitive_to_bmesh is the loop that adds the faces (interestingly, the vertices are fast -- it's the faces that take the time). I couldn't see any obvious way to speed up bmesh_to_mesh once I turned off import_shading='NORMALS'.


Thanks for your suggestions!

Can you please create a PR on the upstream project, here :
This will have a better visibilty by Khronos Team


OK, I'm happy do that. Perhaps you can help me understand the differences though: the last commit in this area in the Blender tree is 06bb353c84, by you: "glTF importer: big perf improvement". But I don't see that commit in the upstream, so I'm not sure how best to apply my patch there. Should I treat the upstream as the "source of truth" and recreate my patch on that (ignoring your changes in 06bb353c84)?

Never mind my prev comment; I didn't understand how the blender submodule stuff was organized. I see those two repos are much closer than I'd thought content-wise (even if the actual commits differ); I should be able to submit this as an upstream patch.
Also I see someone already figured out some of this, which is great!