Laggy / slow / unresponsive UI with heavy scenes & instancing

Pablo in Blender Today Live asked me to make a task for this, but I’m not familiar with developer.blender.org (additionally Blender ID still doesn’t work for that)

In 3.0 beta the UI is still super laggy with heavy scenes, especially with instancing. Here is a simple example:

  • make over the UI layout to show just the geo node and property editors (so no live/realtime viewport rendering)
  • in the default cube create Instance on Points node and connect it’s output to the Geometry output (Group Output)
  • create a Grid node with few thousand by few thousand resolution and connect it to the instancer’s Points input

Now just try to select any node and grab it, or tweak any irrelevant value, like the render resolution, time range etc. As the instancer point count gets higher, the UI tends to be more and more unsresponsive/laggy.

Thus, there is a very basic problem with the code, because something unnecessary iterates as the result of the instanced points. Millions of useless instructions per second. Actually there shouldn’t be any geometry related calculations at all if there is no demand for that, like the 3d viewport, geo spreadsheet, live rendering or whatsoever…

There is a room for optimization, and such problems makes Blender quite unattractive for people who use so-called industry standard software (don’t want to name them here, following the Blender etiquette :wink:) … and I’m aware of some other users’ similar experiences.
3 Likes

I agree.

This isn’t anything new though, working with nodes in the shader editor has always been extremely slow in heavy scenes.

Not sure why, even moving an unconnected node is laggy and painful. Flagged it a couple times over the years but never really got an answer why this might be or if it’s even being looked at.

1 Like

Thank you guys for sharing your experiences.

I edited my first post because I named the wrong instancer node (the simple Instancer name would be better for this node, instead of the actual long & very similar to the other one), so now it’s ok if you tried to recreate.

Investigating in the meantime, my findings so far:

  • Workaround 1.:


That CUTOFF is a Switch node, is switched on and final geometry connected to the False. I collapsed, colored, moved close for better visual representation. In this way, if you mute this node (M), it calculates as before, but hitting the M on this node again disables the whole branch. So this is like a cook switch in other software.

  • Toggle Fullscreen Area makes the situation a bit better: selecting and moving the nodes are not laggy, but tweaking the - even unconnected - nodes’ any parameter is a pain, additionally there is a momentary but huge memory consumption peak. This info could help to catch the culprit in the code, as exiting this fullscreen mode yields the node selection/move operations very slow again.