I found a use case where geometry nodes’ performance deteriorates drastically, and I don’t understand why.
If I put a heavily subdivided Icosphere (vertices ~1M) and connect a geometry nodes modifier to it, I merely have to add a Scene Time node (unconnected!) and my fps falls to 20. Muting the node does nothing. I’ve tried a few other input nodes, and it seems that this only happens with Scene Time. This effect exacerbates even more when I connect a Set Position node in between the geometry input and output, whereas with Transform Geometry the fps stays the same.
An unconnected node, in theory, should not be evaluated and thus not affect performance.
Even if Scene Time was connected, its value does not change per vertex/edge/face/etc and can be hoisted outside of any loop. Whether you use Set Position or Transform Geometry should not matter.
To me it seems like Scene Time is nog being optimized properly, but I’m not sure. Does anyone have any insights? For my current project Scene Time’s performance is crucial.
Tested on Blender 4.3.0 for MacOS.
I found a recent commit by JacquesLucke which might be relevant. It’s not in 4.3.2 yet though so I cannot test it without having to build Blender myself.
Unfortunatly nodes get evaluated even if they are not connected. I submitted a similar bug report not too long ago and it got merged into a 6 year old bug report about the modifier stack evaluation.
Apparently it has something to do with the depsgraph but I don’t understand what:
I don’t understand why “unconnected mode is evaluating” = “disabled modifier is evaluating.”
Perhaps there’s a great reason, but a cursory glance of both discussions didn’t make anything pop out. I mean… Unconnected nodes shouldn’t eval, full stop. This does not even seem to be a weird logic loop to resolve…?
But if course, I don’t code such things. Seems like a weird foundational oversight, though.
I’ll also submit that the dev discussion on “but what if the user has keyframed the visibility of the modifier”… It feels like an edge case to me. I don’t keyframe modifier visibility. If anything, I keyframe the parameters within the modifier.
Yeah same. No idea why these two problems are connected. I feel like I had it explained to me by a developer at some time and somewhere but unfortunately my memory is like a sieve.
Well, for whatever it’s worth - I’ve now learned that I shouldn’t have all those unconnected nodes in all the things I make, left in there just in case I need them at some future point.
ETA: does muting the unconnected scene time node bring back performance?
Your example is even more interesting. Even if you subdivide within the geometry node, Scene Time gets evaluated at the inner-most loop. For something that stays constant for each vertex, that seems very unnecessary…
By the way I found that this also applies to the Simulation node, this function is probably relevant. The commit I mentioned before refactors it.
I guess it detects time-dependency and then the node tree is optimized differently. More understandable for Simulation nodes, but Scene Time? Even if we assume that unconnected nodes are evaluated, time should not be a bottleneck — it’s just a global variable.
Granted I’m not familiar with Blender’s internals…
Yes I ran into that issue a while ago, there is probably a logical answer to why it’s so… But yeah as long as you add the scene time node the graph is evaluated for every frames even if the node is unconnected…
They might just want to avoid introducing hacks to add complexity to the code and make it less future prone, especially when the solution is about the depsgraph rather than GN…
Anyway, if you start to add this node on your tree it’s probably that you want the graph to be evaluated for each frames…
The only thing where detecting if the node is connected is to allow a switch behavior, like a static / fast mode, and a slow / animation mode…
But it looks like very particular usages… And at least we can now bake the tree which should probably make things run faster.
In fact it might be hard / slow to detect if the node is really needed without evaluating the whole tree…
The only weird things here is the surprise that the scene starts to get slow as soon as you add the node, which is confusing… But I’m not sure that fixing that bug would make our life that better …
Yes indeed, but on the overall I find that more confusing than problematic…
Unless you are in cases where you add that node by mistake, if you need
the scene time node you need per frame evaluation… I can only think of corner cases where you would need a switch that turns this node on or off… I think most of the time it’s either your tree is about animation or it’s about static stuff …
But sure GeoScatter could be a great example where you want to turn animation on or off on grass for instance…
I’m not saying that it’s ideal as it is, it’s confusing indeed but in practice , given you know what you are doing it’s IMO quite rare that you need both behavior : static / fast , animated / slow…
