I’ve been experimenting with geo nodes & build some warehouse racking.
The components are all very simple - however, something is really slowing this down… all components seen are made up of simply cubes.
Since I haven’t used nodes much, I’m not sure where the bottlenecks occur.
stats:
Any help appreciated!
Hm, there’s nothing there that jumps out as particularly inefficient. What are your system specs?
There is a timing overlay you can use for debugging:
Thanks -
I’ve never heard of the timing overlay. How do we enable that?
System is"
Win 10
AMD Ryzen 9 5900X 12-Core Processor, 3701 Mhz, 12 Core(s), 24 Logical Processor(s)
TUF GAMING X570-PRO (WI-FI)
RAM 32.0 GB
NVIDIA GeForce RTX 3080
if you click on the overlay button on the top right you can find the overlays
Indeed with timing overlay you should get a clue of what’s going on…
Nothing seems particularly complicated… Maybe the slowdown comes from many nested instances.
You can try, even if that counter intuitive , to put a few realize instances node at some point in the tree and see if you get any speedup…
You need to test what is the right balance, so you keep some instancing, that is good , but avoid too many instance of instances of instances…
But maybe the issue is elsewhere …
Ok, well, this is strange, but I think maybe I’m not understanding timings.
I actually tried this a bit earlier but didn’t find anything that worked.
However, after you mentioned it, I tried again, figuring that I’d start at the end and work my way to the beginning.
First place I put one increased the timing to 11ms, but I can make LOTS of copies and everything is really fast and smooth…
hmmm…
Ok that’s weird, but at least, if it works …
But wait … your issue was not in the execution time of the nodes… do you mean that before it was less than 11ms , but your issue was more on the viewport that was getting laggy ?
If that’s it, then it’s the way that instances are drawn that is not as fast as it could be. Especially because you had nested instances this makes the refresh a lot slower.
With the realize instance nodes, you convert instances to geometry, and that may makes the tree execution slower, but the viewport refresh may become faster.
The tree is only updated once ( unless you animate value), I think now that’s totally fine, 11ms is great !
Obviously that depends on the case , in general it’s better to keep instances …
So yeah, to sum up, the timing of the node is only about how much time it takes to create the geometry. not something like viewport fps. But of course , if the tree is animated , then the tree needs to be computed every frame.
But then , once the tree is executed in 11ms the geometry + instances are send to the viewport , and it’s the viewport ( workbench, eevee, cycles) that is in charge of rendering all that geometry as fast as possible. And with many instances that part can get slow.
Yes - previously it said <.01 ms, but the display was REALLY laggy. I’m able to navigate the view very smoothly now, even with lots more objects on-screen.
Ok awesome !
blender does tend to slow down in viewport with more objects, I wonder if there is a similar slowdown with multiple internal objects inside of geonodes.
There are over 3600 objects all being instanced, and since the objects are just cubes, you aren’t gaining much performance by instancing them. The nested instantiation is probably causing some issues as well, since blender should be pretty performant with 3600 instances, but they are complex, branching instances, so that could be part of the problem.
