Scene management: Tips to keep a large Blender project responsive?

What are some general tips to keep a large Blender project as responsive as possible?

I am wrapping up the largest, most sophisticated Blender project file I’ve done to date. The next time I create a project file with this scope, I want to set up things differently. Right now, depending on which part of the timeline I am in, moving to a different frame is a long, slow, painful process. It’s to the point where it’s like, click on something, go surf the web for about 15 seconds, go back to Blender and click something else.

Since I’m almost done with this project file, I don’t care about optimizing it. However, in the future I don’t want to create another project file with these performance issues.

There’s only three tricks I’m aware of:

  • Link in external low-poly proxy models where possible; replace them with high poly models when rendering.
  • Put models on different layers, so you only see what you absolutely need to see in the viewport when working in the 3D View.
  • Automate the View/Render states of objects you don’t need in the Outliner.

There have to be more tricks than just these. What are they?

I’m using BI for this project, but I also use Cycles for other projects. Tips for either engine are appreciated. Also, I am using BlenRig – a not-lightweight rig – for armatures. (I am using five BlenRig rigs in this particular file.)

1 Like

I know, this is really old, but maybe you’ve got a few tricks to share? I’m stuck with a similar problem in 2021 with a 10+ year old rig, and it’s quite frustrating. Same experience you’ve had - optimise the next one, fight through this one!

Link in as much of the scene as possible. For instance, have a “scenery” blend file linked in your animation file. But frankly, Blender doesn’t scale well at all. We’re awaiting render procedurals and proxies from Kévin : https://wiki.blender.org/wiki/User:KevinDietrich/Reports2021

I’m not sure linking will optimize scene refresh, but anyway it’s still a good habit to have.
One thing that can slowdown file loading is modifiers, if you’ve got a lot of them it can take a lot of time to generate the final geometry. It get even worse if this geometry is forced to be evaluated at every frames :
ex : one mesh with many costly modifiers (subsurf, remesh , bollean, ect…) that is parented to a bone and the rig has one keyframe.
On that situation, even if nothing is moving blender will re-generate the mesh every frame , which will cause a major slowdown.

Other stuff can also be costly : autosmooth on deforming geometry
a scene with many instances ( geo nodes) in blender 2.93 can cause a viewport slowdown (navigating in the viewport)

Anyway, it’s just general rules here, on big projects some time should be spend to optimize assets. While investigating you may find that one or two mesh can half the performance of a whole character … And of course same thing apply to every asset especially if they are animated.
I personally try to find low hanging fruits for optimization, going from assets to assets and try to get more fps I end up having scene that you can work with, but still the projects I’m working on are still light : Boon & Pimento : Cartoon series made with blender - #31 by sozap

2 Likes

Thanks for the replies, guys!

Animation… :sweat_smile: I’m just rendering stills.

What sounds really promising are the proxies… Other than that, the project is rather primitive, archviz with a ton of - seemingly primitive - Blenderkit assets, ultra primitive geometry (BlenderGIS and Archipack Pro), mixed with a couple of particle systems aka trees. Modifiers are almost exclusively Autobooleans with strictly rectangular windows. Of course, there’s a lot of glass involved.

I definitly severely lack experience with such scenes (3 houses in a super primitive city environment), as I’ve only done small projects since 2005, on and off. SO maybe I messed up something basic.

I found particular car models to cause out-of-memory-crashes, even though I was hiding most complicated and invisible geometry completely.
The viewport is actually kind of fast, it’s the “click on - literal - cube building, enter edit mode, WAIT”, select low-ploy street object, WAIT, change camera, WAIT, cancel crashed render, WAAAAAAAAIT, select next Renderset pro slot, WAIT.

I had to massively increase virtual memory, which is but barely being used, as I don’t see the disks filling up. But my 32 GB were being maxed out during render and my rig froze up when RAM hit the ceiling. I can’t rely on the render queue to render over night, as something’s likely, but not always, causing some memory related cancellation of the render or a complete Blender crash. Sometimes Blender crashes upon Auto Save, almost always upon undoing something related to Archipack, so I have to manually undo everything - that’s also because the Archipack part of the project was badly planned and organized from the getgo, so I have massive amounts of parts linked to the wrong reference etc., but I don’t think that should influence the render, or clicking a cube.

Btw @sozap those animations are great :joy:

Ok !
Maybe one issue you have is too many objects, even if they are simple…
Not sure it’s how blender is working, but chances are that when you want to select an object blender needs to go through every objects in the scene to check what is the best candidate for selection. That’s just speculation, but it’s a common issue…

You can try to merge several cubish objects to reduce the overall count.
Maybe some objects are eating far more memory than others, you can try to organize the scene in several collections and disable them in viewport and render then see if it’s going better and finally investigate more on these collections.
I’ll look into the trees and vegetation first, maybe the cars next.

After that there are rendering optimizations that can help, if you’ve got many objects that are the same, you can instance them (Alt-D rather than Shift-D to duplicate) or link the mesh ( select both objects + Ctrl-L → Link object Data) that will save memory.

Start to investigate on what objects are making such a huge slowdown and work on these low hanging fruits ! As always with 3D half the fun is investigating issues and solving problems :smiley:

It’S really tricky - all theplants (blossoming trees…), furniture etc, that should make the difference, don’t. It’s one or two specific cars.
The buildings around are maybe 50 , with a maximum of 24 vertices each, so those can’t be the issue. Though I found their collections have multiple copies, and whenever I delete one, all copies are being removed. I guess those were randomly copied and linked, or what do I know, I’'m sometimes having a hard time dragging collections around, as respnsive as my system has become :sweat_smile:
I did use instancing, but probably only half the time, that won’t happen again either! Also, I’ll, in the future, copy the assets I want to use and like those, so I can use them and alter them according to project.

I’m now doing the view layers dance, takes forever, but looks like I’m getting somewhere. Simplify was gonna be the next step. We’ll see… once I wrapped my head around the magic of rendering view layers properly and compositing them, I’ll be wiser again…

Good luck ! It’s a tedious and long task to optimize but you’ll get your sanity back when your scene will be smoother !
When I’m desperate I turn off all the collections, living nothing in the scene, then I try a render and if everything act normal then I test all the collections alone one by one, then once everything is ok I start adding them back together and do some test render at every step with a low sample count.
I wrote every rendering time and that way it’s easier to see what is causing issues…
It’s a lot of work , it may takes a day to clean the scene but after that it’s way easier to do creative work again, and the result tend to be better because you can iterate way more and you don’t struggle with your scene anymore …

Yes it’s another approach and a great way to render a virtually impossible scene to render, but it doesn’t come without side effects and it could be hard to manage. I’d do this in extreme cases when I’ve got a lot of elements (like a VFX shot) that are very long to render.
By looking at what can be done in realtime render engines, I’m sure it’s doable to make scenes with a lot of detail but still low/medium geometry , that can render in one single renderlayers without compositing cheat. But maybe I’m a dreamer, I’m not really used to heavy scenes.

@Hadriscus I was under the impression that there were only addons for creating LOD’s in Blender. Does this proxy system that is supposedly under development work the same way as Vray proxies? Meaning you save an external file (high poly) that is only displayed on render time, while a user configurable low poly approximation (proxie) is shown in the viewport?

Man, i just watched Cenrtal Panik. I’ll stop whining now. I’ll install Blender 2.93.3 now, cause I’m sure IT’S BLENDERS FAULT I’m failing :joy:
So far, a view layer split has failed to render where a version without layers hasn’t…

1 Like

I’m not sure, but I think this is comparable yes. @KWD would be able to tell you more (apologies for the unsolicited ping)

The proxies made for the Alembic render procedurals are not actual proxies. They are just some boxes that are displayed in the scene to tell that Cycles is taking over the loading of Alembic data. Actually, the memory from the Alembic objects may still be allocated on the Blender side, which is a bit wasteful. This is merely a first step, true proxies and procedurals on the Blender side will be done later (although it is not actively worked on).

Thanks for the explanation! Good to know that it is in the planning or at least on the horizon!

Thanks a lot @Corniger !
It’s a good idea to work with the latest version,
I’m sure if you keep investigating you’ll narrow most of the issues !
And if not you can PM me a link of the .blend file if you’d like me to take a look !
Cheers !

You may try to enable “developper” and “undo legacy” options in blender’s preferences, may help a lot with crash on undo - slower but safer.
Any scene statistic like number of objects / vertices and so on ?
Some grass assets using particles ?

@sozap I will, but you will regret this :joy: Probably would be a good thing to get an analysis by a seasoned Blenderer!

@stephen_leger Thanks for the undo tip, I just set it up.
Statistics: Verts 24.4 Millions, Faces 20 Millions, Tris 31 Millions, 23.5k objects, 21 GB mem, 3.8 VRam. Probably insane, seeing this after enabling in viewport!

23.5k objects is probably the main issue with your scene.

1 Like

Is it the number of objects in general or objects being rendered? Disabling the furniture in shots where it’s not visible has worked before, should I completely exclude it from the render layer? I’ll try and watch the count!
Thanks @stephen_leger !

Edit: the plants alone make more than 20k objects… some 6k+., that must be the culprit

You may disable collections (the [x] beside collection) so objects are ignored.
When count is over 10k things start to seriousely slow down, basically it is an issue with unique names where you have to test against all objects to ensure the name is unique in blender data.
You’ll notice that every time you add / delete / select an object (and don’t even try to rename).
Instancing data, reuse materials and so on may actually help a lot by reducing datablocks definitions, and it is common to see small parts of furnitures as objects, where a simple join would drastically reduce the number of objects.
Beside edit mode initialisation, high poly count should not be an issue for blender, but there still is a cost at render time when the optimisation tree to speed up ray casting is built.
Basically always prefer mid / low poly things unless they are close to the camera and such level of details make sense. Furnitures often are poorly designed and way too heavy poly for common use cases.
[edit] yes vegetation is a nightmare in 3d … hopefully geometry nodes will help a lot in the future.

I don’t know exactly your project (game or movie or else), but for the most part, depending on the shots is that you will decide which assets to make visible or render.

It makes sense to load everything in one file (Ian Hubert style) and have massive scenes that you can reuse in many ways. However the point now is about making optimizations into your workflow.

As for example you have a shot of a face closeup. You only load the actor and a dozen of other background props. You have another shot of a cityscape, you load a scene with low polybuildings and geometry nodes, and so on.

Typically you have all your assets in one blend file (or multiple files), but your shots are different files, and all essential objects are linked (not appended).