glTF file loads extremely slowly (5+ min) #72167
Labels
No Label
Interest
Animation & Rigging
Interest
Blender Cloud
Interest
Collada
Interest
Core
Interest
Documentation
Interest
Eevee & Viewport
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
Import and Export
Interest
Modeling
Interest
Modifiers
Interest
Nodes & Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds, Tests & Devices
Interest
Python API
Interest
Rendering & Cycles
Interest
Sculpt, Paint & Texture
Interest
Translations
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Meta
Good First Issue
Meta
Papercut
Module
Add-ons (BF-Blender)
Module
Add-ons (Community)
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
4 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender-addons#72167
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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
modelGroup.glb
file (unzip it first).glb
into a web glTF viewer such as https://gltf-viewer.donmccurdy.com/; 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.
modelGroup.zip
Added subscriber: @garyo
Added subscriber: @StephenSwaney
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.
Added subscriber: @rotoglup
Changed status from 'Needs Triage' to: 'Archived'
Hello,
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.
Hello,
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:
72bee9a11b
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 https://gist.github.com/garyo/e0fe3605d2be7c6308d795c988ec3b4b. (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 usingimport_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
bme.faces.new(array_of_face_data)
that would improve things a lot.After my patch, here's the top lines from the python profiler (which my patch enables):
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 upbmesh_to_mesh
once I turned offimport_shading='NORMALS'
.Hello,
Thanks for your suggestions!
Can you please create a PR on the upstream project, here : https://github.com/KhronosGroup/glTF-Blender-IO
This will have a better visibilty by Khronos Team
Julien
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 in06bb353c84
)?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!
Upstream PR submitted: https://github.com/KhronosGroup/glTF-Blender-IO/pull/922