I have a large collection of individual instances +20000 (not sharing the same object data), which are animated using geometry nodes. The issue is that when animating all instances at once, the playback speed becomes extremely slow (between 3-4 FPS) which makes the animation work very difficult. It doesn’t seem to be a hardware issue (since I have a pretty good PC config see below). I’ve read in a forum that playback animation speed and computing geometry nodes is a single-threaded process (so that is why it’s not utilizing my CPU fully I guess). Is it still the case today with the latest blender updates?
One option I found to increase FPS, is to split the main collection into a separate smaller collection and animate the collections using multiple geometry nodes to achieve the same result. What are the reasons behind it and do you have other optimization ideas to increase FPS?
Here are my specs:
13th Intel core i9 - 13900KF
128 gb memory
2x GPU Nvidia RTX 4090
Have you tried realizing the instances at the end of your geometry nodes setup?
Edit: Nevermind. Realizing the instances only works if you are not animating inside Geometry Nodes. If you are animating inside GeoNodes then realizing instances makes it worse.
Thanks for your suggestion. Yes I tried baking with the newest node in Blender 4.2, but it makes it even worse FPS-wise.
Do you know if upgrading my Intel core i9 to an AMD Threadripper 3990X with more cores would help significantly? I’m not sure exactly how blender utilize the CPU cores to process the Geometry nodes and playback animation. And I’m afraid to place a significant budget on a new CPU without any real improvements.
I don’t know if the upgrade would have a signifcant impact.
But perhaps you can post you geo nodes tree and show where you tried the bake node. Because in a test with 20K Instances and a test animation my frame rate goes either from 1 to 8 or from 1 to 25 depending on the setup where i put the bake node.
You’re not stating the OS, but in Windows open up the Task Manager to see what’s going on CPU wise.
And tbh, Blender isn’t that good with massive amounts of data. It’s been a complaint of many since 2.8. You just might have run into the upper limits of playback speeds.
Lane wise it might, as the TR has more bandwith to ‘play with’.
But when Blender ends up as the limiting factor here, this upgrade would not make any sense.
Yes I’m on Windows, here is the task manager when playing the animation, CPU only used at around 10 %. I turned the viewport display to bounds, which helps slightly with the FPS.
I know Blender is not that good when working with large amounts of objects, it just feels to me that it can be optimized the way it computes the geometry. Like when I separate my large 20k collection into smaller groups of 2k and animate them at the same time, blender handles it better (with the exact same result and number of geometry displayed). I think if there is a way to create a node that reads the geometry into smaller clusters, it might work better I guess.
Click on the overlay button on the top right, and check the timer option, so you can see the timing for the nodes.
You might see where the delay is happening.
The first thing you want to do is bake a still frame of you collection (unless these objects themselves are animated of course). This keeps blender from reading the collection each frame.
Then you turn your instances into points for more performant animation
Here you bake again. This time an animation.
You use the "is vieport node to switch between viewport and render
You’re a genius! Thank you so much @Lumpengnom for your help! Just baking a still frame really improved by a lot the playback speed (didn’t know that trick so thank you for bringing that up!!).
It is hard to offer a solution without seeing the complexity of the setups or the meshes. Animating instances and playing them in the viewport could be very slow depending on what you are trying to achieve. Turn your objects into simple bounding boxes and try that way. Don’t do adding the decimate modifier to simply your meshes for better performance, it will do the opposite.