Ever since 2.8 came around, I’ve been having alot of problems with armature posing being incredibly slow (to the tune of a 5+ second delay on every little input, sometimes even freezing the program completely for 15-20 seconds).
I’ve been experimenting and I’m fairly sure the problem is that all the items that are ‘Disabled In Viewport’ are still being calculated and lagging the posing. The reason I believe this is that modifying the visible objects the armature affects seems to do nothing (removing subsurf seems to make it even slower for some reason…), while deleting groups of disabled objects (such as scenery) gradually reduces the lag the more I remove. (even things that are not tied to the armature in any way seem to be slowing it down)
Maybe I’m just understanding this wrong, but I was under the impression that the ‘Disable In Viewports’ option was supposed to make blender ignore something completely - is it not?
Do I just have too much stuff in one file for which disabling unused assets is not enough, or is there actually something not working as intended?
Also, any other random tips/possibilties for speeding posing up would be greatly appreciated~
Disabled in viewports doesn’t make Blender ignore something entirely, no. (It would be nice if there was a way to do that.)
If an object is dependent on another object, that other object will be calculated, even if it’s disabled in viewports. And even if a modifier is disabled-- muted, don’t display in viewports, whatever-- it still creates a dependency. Constraints probably work the same way. Dependencies are per-file, not per-frame, so nothing keyframable changes dependencies.
Another way that a large file can create slowdown is by using more memory than you have and thus going to swap drive, or autosaving / undo saving large files. Check memory usage, check for file system usage.
If you want super fast posing, faster than you’d ever need, make your actions in a different file containing only the armature, to eliminate any dependencies, and if you need visuals, bone parent some cubes and cylinders and whatever else to that armature. Bone parented stuff is lightning fast compared to armatures. If you need other stuff in there as references, import only what you need, no more.
Ah, I see. I’ll just have to try to clean up as much unecessary stuff as possible then.
Still don’t understand how something that’s not at all linked to the armature slows it down anyway though…definitely not a memory issue, as I have plenty of both system memory & vram left over.
I can see how it might affect performance graphically if there was alot going on - but i’m pretty sure disabling in viewports is designed to stop at least that, right?
Disabling in viewports will disable the overhead of transforming those verts (world space to view space) and drawing those faces. That can be significant. But it’s easy to end up with a long chain of dependencies you didn’t consider, from modifier targets, constraint targets, etc. Usually, it’s the modifiers, and recalculation of those modifiers, that end up causing major slowdown. If you don’t have any dependencies, those modifiers only get recalculated when you change settings, not when you manipulate bones, and Blender runs pretty quickly.
So I’d suspect that you just have some dependencies of which you’re not aware. Of course, I can’t say that for certain without looking at the file, and looking at a simplified file wouldn’t help-- you’d probably be deleting away the dependencies.
Note that autosaves don’t depend on memory. If you have a big file, and you have autosaves set to every minute, you’re going to get slowdown every minute as suddenly Blender is waiting for your hard drive.
It’s pretty easy to “simply the scene”-- just open a new instance, copy paste your armature, and possibly delete everything that gets copied that’s irrelevant to your posing. (Those are the dependencies, btw.) When you’re done making the action, you can copy paste the armature back and you’ll be importing the action, which will be compatible with your original file’s armature.