Running Out of Memory in Blender?

We have all run into those dreaded out of memory errors. For your graphics card. Your system memory. The music you're listening to starts freezing, stuttering, repeating over and over again, until finally, Blender (or worse, your PC) crashes.

As part of my optimization series, let me share with you the "why" and "how" of memory usage in Blender.

Why Am I Talking About Optimization?

Hardware limitations can feel like every problem is out of your control. I hope this series can give that control back to you, enable you, empower you, to make the most of these problems and still accomplish your creative goals.

And memory is a big one for low-end computers and graphics cards.

As with any optimization tip list, this is going to vary in impact depending on the computer and project.

I try to avoid talking head videos if I can just write it out. If it’s already a video “essay,” why not just write the essay?

Managing Your RAM

RAM (random access memory) is your system's general memory. Every program you have open is sharing this RAM. You can check the programs you have open and see if any are hogging memory using your operating system’s favorite task manager or system monitor.

Blender often uses a lot of memory. What can you do to reduce memory usage? What can you control?

File Size

Keep file sizes small. I have yet to see a project that truly needs a single .blend file over a gigabyte in size (believe me, I’ve troubleshooted quite a few that are).

All the data you need for your .blend file will definitely be loaded into RAM. The bigger the file, the more space it will take in memory. Compressing your .blend file on your hard drive doesn't compress the data while the file is open.

So do what you can to keep files small. Reuse and instance assets (you can even put them in separate files and link them back to your main scene file).

Remember that Blender also manages a lot of data not saved to your file, including:

Undo History

Yep, that setting Blender content creators tell you to just crank up as high as possible? Each undo requires Blender to copy data necessary to go back to that previous state.

Less undo's, less memory usage. And on low-end PCs, this can make the difference between continuing to work, and crashing.

I used to have my undo setting at 128, but I realized that, by the time I needed to undo 128 times, I might as well just go back to an old save. I already save often every five minutes, so why not use them?

I wanted to test how much undo’s affect memory, so I ran a script on the default cube scene (shown below):

import bpy

for i in range(256 // 2):
    bpy.ops.mesh.primitive_cylinder_add(vertices=2048)
    bpy.ops.ed.undo_push(message='Add cylinder')
    bpy.ops.object.delete()
    bpy.ops.ed.undo_push(message='Delete cylinder')

It adds a cylinder, generates an undo, deletes the cylinder, and adds another undo. I intentionally kept it from adding anything to the final result, so any memory increase is in the undo stack, not the complexity of the current scene.

I had global undo enabled and the undo memory limit set to unlimited. I ran the script on Blender 4.2.6 at factory settings twice: once with undo steps set to default 32, then set to the max of 256.

Overall, the memory usage is better than I expected. This is likely due to a Blender code fix of sharing memory data across undos when possible, reducing redundant copies in memory. This seems to be part of Blender 4.1 and onward - all the more reason to stay up to date!

But remember, this is still based on the file’s data size and the complexity of each operation you do. I did this test on the default cube scene, and it was still ~23 more MiB. As you work on your files, see how that memory increases with each operation. The bigger the changes and the bigger your file, the more space undos will take.

So, I lowered my undo steps. While saving to a file is a better use of memory, this depends on your workflow and saving habits. Some other settings you can tweak:

• In the “Save & Load” tab of preferences, you can enable auto save (auto saving may be delayed in some cases, such as while sculpting). These auto-saved files can be accessed from the “File” menu => Recover => “Auto Save…”

• The same “Save & Load” tab also has a “Save Versions” option to increment save. This is where the .blend1 files come from. You can make it create .blend2, .blend3, and so on.

• Try lowering your undo limit in increments. If you begin to lose precious undos, increase the limit. If you need the performance and save often, lower it.

This is a balance in hard drive space and RAM space. Optimizations are all about balance.

Add-ons

Some add-ons store lots of data about Blender files and session in order to work. Including (and especially) asset managers. Add-ons can even too Blender store extra data per datablock, so each object or scene may have extra properties saved to the file, which can stack up.

So, disable any add-ons you are not currently using. Sadly not all add-ons are created equal; some add-ons do not cleanup after themselves well (I do plan to make a video on that). But this can at least prevent extra data from bloating your file.

Rendering

Obviously more memory is required for rendering. To mitigate this, here’s some options:

In Cycles, use tiling and reduce the tile size to reduce memory usage per tile. This is especially effective when rendering dense geometry like hair. It can save you from having to switch from GPU rendering to CPU.

Also check the “Final Render” and “Acceleration Structure” panels (depending on if you render with CPU or GPU), as those allow you to manage BVH usage, including "Use Compact BVH" for CPU users. What is BVH, you ask? In (very short) summary, it stands for bounding volume hierarchy, and it helps accelerate raycast calculations by reorganizing the scene data in memory.

In Eevee, check the performance panel on the memory pools for shadows and light probes. This just means how much memory is expected to be available for these. If you have a graphics card, this will be actually loaded into VRAM, not RAM (more on that below).

And those long shader compilation times? That’s based on the complexity of your shaders. If you can, simplify them.

And finally, render from a terminal or a render manager like Flamenco. Having a separate process render for you gives flexibility to close the Blender user interface, freeing memory for the actual render. I made a video on how to get started rendering from the command line.

Video Editing

For the video sequencer and movie clip editors, you can change the disk and memory cache limits in preferences (“disk” here is referring to hard drive space, not RAM). Caching improves performance in these editors, unless you simply don't have the memory for it.

Modifiers

Modifiers, especially ones like subdivision surface, can add memory usage in the viewport and renders. So disable or reduce modifiers in the viewport and render whenever possible.

This does not necessarily mean to apply modifiers. Applying can reduce some memory usage, but it’s often worth keeping the non-destructive workflow.

VRAM

VRAM (video random access memory) is RAM attached to and specifically reserved for your graphics card.

Note that Blender’s displayed VRAM usage is for your entire system, not just Blender. While you may not be able to discern programs within the VRAM, seeing the overall usage of your whole system can tell you that something else may be hogging that memory. We’ll get to solving that.

Firstly, a couple gotchas. VRAM currently used may not necessarily mean it's actively used. The graphics card often uses VRAM as a cache. And some "used" VRAM is reserved to guarantee your system will not suddenly run out.

Your graphics card also may hold queued tasks for rendering. So the more memory you have available, the more it can be filled up with jobs to render. So having more VRAM may still fill up quickly, even if the file hasn't changed.

So, those things may be out of control. But what can you do to not run out of VRAM?

Within Blender

Reduce data needed for renders. So, some of the principles about RAM should apply here too. Especially render-related settings like tiling for Cycles. But let me add a couple others:

• Simplify geometry and modifiers when reasonable. The less data your graphics card needs to render, the better, especially …

• Texture resolution. Textures take a large amount of memory. While high-res textures add crispness, if you run out of memory, you run out of memory. You may be surprised what you can get away with in terms of texture resolution.

• What about procedural textures? You are trading memory usage for more calculation time. It depends on your use case. But to save myself from just proclaiming extremes, be reasonable in balancing shader complexity and texture size.

• Reduce particles in particle systems and instances. While instancing is far better memory usage than complete duplicates, each instance still needs its own set of information to give to the graphics card. Use culling methods or just remove them manually as needed.

Outside Blender

Let me mention a few tips for optimizing VRAM and GPU usage outside Blender, as these may solve some problems for you without compromising the quality of your render.

• Remove unnecessary display devices the GPU may be calculating for, such as an extra monitor you are not using.

• Close other apps using the graphics card. You can also disable hardware acceleration for those apps. Hardware acceleration means an app can use other parts of your computer hardware to improve performance -- usually, your graphics card. That tends to be the name of the setting to disable in the app. Just know disabling this means your CPU will be handling more processing load for those apps, instead of passing it off to the graphics card.

  • Running apps in the background, without a UI, also helps with this. All the more reason why rendering with Blender from the terminal is a better use of memory.

• Lowering screen resolution and monitor refresh rate. This means less work and memory usage for your card just to display your screen. Not ideal, but can help in some situations.

• Clear shader caches. I'd rarely if ever recommend this. It is often a last resort, as it will lead to stutters as your graphics card rebuilds the cache as it works. But if you have a corrupted or outdated cache, sometimes forcing a full recompile can help.

Hopefully this gives you some insights and better tools to take control of your memory usage in Blender! If you have any questions, corrections, or other insights, let me know.