Blender viewport playback in Eevee is slow—are hardware upgrades worth it?

Hi everyone,

I’m working on an animation in Blender and have already optimized my scene as much as possible in terms of software (Simplify, hiding objects, reducing subdivisions, etc.). However, I want to focus on hardware solutions to improve my viewport playback in Eevee.

Here’s what I want to achieve:

  • Smooth playback in Eevee, with visuals as close to the final render as possible.
  • A significant FPS improvement for real-time animation playback.

Current Specs:

  • CPU: AMD Ryzen 9 5950X
  • GPU: NVIDIA GeForce RTX 3080
  • RAM: 32GB DDR4
  • Storage: 1TB NVMe SSD

Scene Details:

  • Using Eevee for real-time playback.
  • High-poly scene (~2 million polygons).
  • Heavy use of materials, particles, and high-res textures (4K and 8K).
  • Goal is to have smooth viewport playback close to rendered quality (25–30 FPS).

Questions:

  1. Would upgrading to a higher-end GPU (e.g., RTX 4080/4090) or adding more VRAM help with Eevee performance in this scenario?
  2. Is my CPU holding me back in any way? If so, would an upgrade (e.g., Ryzen 9 7950X or Intel i9-13900K) make a noticeable difference for Eevee viewport performance?
  3. Is 32GB of RAM enough for this type of workload, or would 64GB provide any significant improvement?
  4. Are these upgrades worth it for real-time animation playback, or will I hit diminishing returns given Blender’s current limitations?

I’m looking for advice on specific hardware upgrades and whether they’re worth the investment. Thanks in advance!

Have you checked the CPU+GPU+RAM usage?
It seems necessary to check whether it is a performance problem or a data bottleneck.

I don’t think there will be a dramatic reversal of new hardware performance unless there is a very significant difference in performance. :thinking:

Hi !
You’re expecting too much. Animators everywhere make playblasts to view their shot in realtime, Blender is no exception. Set your render engine to workbench and hit render animation (ctrl+f12), you can then scrub through it freely using DJV or some other review program (I use DJV, it’s great).

3 Likes

There’s no circumstance in which you need 8K textures. As @Hadriscus said, you’re asking the wrong questions here, you need to learn more about how this process works

3 Likes

You aren’t supposed to be able to get a full realtime playback out of Eevee, especially not in a complete scene like this, it’s just not intended for it.

Are you getting good performance in solid mode though? If you don’t, Eevee isn’t the problem.

Animation would usually be done in solid mode, with only the necessary objects visible. You should disable as many modifiers as you can on everything that is visible, modifiers are re-calculated every frame and are a major source of playback slowness. If you are getting slowness in solid mode, modifiers are likely the cause.

My main question from this post is: why do you even need this? Maybe there is an other way?

I hope I don’t come off too much as a rambling old guy, but I am guessing you are a relatively new to 3D art? You probably haven’t known the era before viewport render previews were a thing. I say rendered viewport is nice to have, but you don’t need it to get a good result.

  • Solid mode is enough to fully understand the movement of an animation.
  • You don’t need realtime playback to adjust lighting and rendering.
  • You don’t need to see everything or have realtime playback to sculpt or texture an object.

So I don’t know what you could possibly be doing that requires realtime render.

3 Likes

I am relatively new to 3D art. I’ve only been doing it for 4 years, but I’m at a level where I’ve incorporated so many elements into my videos that I need to boost my performance for faster feedback. I’m using green screened png sequences of myself and inserting it into 3D worlds with 6+ animated characters at a time. Not only am I focused on the animation, but I’m focused on the camera work, the lighting, and various other animated elements all at once.

Here’s an example of my work so you can get the gist of what I mean:
Video Link

Solid view limits what I can see in the grand scheme of things. I like seeing as much as possible, all at once, before the rendering process.


I’m not a traditional 3D animator, so I understand that this question is probably useless anyway. I just wanted to know if I could throw extra hardware at the problem and get better results. Looks like that is not the case.

Thanks anyways.

Everyone does, but it’s not always possible. Blender isn’t fully designed to be realtime like a game engine. If you want fast playback, you may need to temporarily disable some stuff when animating.

You would likely get better results, but don’t expect perfection, especially considering your current hardware is by no means bad. Hardware is half the solution, knowing what causes bad performance and how to avoid it is the other half. I am thinking your scenes and render settings are likely in need of some optimizations, though it’s hard to tell what is needed without having seen the files.

If you consistently make videos of this scope, I would say having good hardware is totally justified in your case, so do get it if you can. Just don’t use it as a crutch to brute force bad practices.

Vram doesn’t really help with performance, it’s all about how big of a scene you can render. You can render a scene as long as its memory consumption fits your VRAM. If it exceeds it, the render will crash and you won’t be able to render the scene because it’s too big.

Rendering barely uses the CPU. Maybe you would have faster build times before the rendering starts if you had a better CPU.

Since Blender 4.2, the new Eevee can use multiple CPU cores to built shaders faster, so that’s probably the place it would help most.

If your scene still fits your VRAM, it’s still far from maxing out your RAM (your RAM is bigger than your VRAM). You most likely have never run out of RAM in Blender, not even close. I have an older computer with 16 GB and have never run out of RAM, even on rather heavy scenes.

I am going to make a guess on what the performance problems might be based on the video you linked.

  • In that video, you are using a lot of light sources. Eevee’s shadows are done by basically re-rendering the scene from the viewpoint of each light and shadowing what’s hidden from view. So, using a large number of lights in Eevee causes a direct and predictable performance hit, because it’s like the scene needs to be rendered multiple times, once for each light that’s visible to the camera.

  • I see volumetric fog. That has a performance hit. Maybe you could first set it up, then temporarily disable it in the viewport while doing the animation? Or at least temporarily lower the volume resolution in the render settings (ex. use 1:8 instead of 1:2).

  • You are talking about high polygon counts. Eevee is sensitive to that. Eevee is a rasterizer, a renderer that works by drawing each polygon on screen one by one. This is faster than raytracing at low polygon counts, but the render’s cost is directly linked to the polygon count in a way raytracing isn’t. And it gets even worse if you have lots of lights, because each one has to shadow the high polygon scene too. If you are using subdivision modifiers, lower all of their “viewport levels” and you will gain back some performance.

  • Multiple characters. Each character is skinned to an armature and that’s a modifier, it has a performance cost. It might not be possible to get perfect performance with multiple characters. You may need to disable one when working on an other.

You know what might avoid a lot of those problems? Using Cycles. This may sound a bit weird, but with the hardware you have and the type of scene you render, the Cycles viewport preview might very well be faster or at least more responsive than the Eevee preview, though it would be noisy instead of being slow. I am not certain this will be the case, you will have to try.

  • You have an RTX card, which can use raytracing acceleration.

  • Cycles doesn’t suffer as much from high polygon counts, because it doesn’t draw each polygon individually, rays of light only need to know about what they hit.

  • Cycles doesn’t individually shadow every light. Instead, it splits the effort between lights, causing noise instead of taking longer to complete each sample. If you are using hundreds of lights, Cycles will probably have a better viewport preview as Eevee is crippled but Cycles isn’t.

The volume fog is very heavy in both renderers, so you would have to disable it in Cycles too for a fast preview.

4 Likes

Obviously, there could be performance improvements, but I don’t know how much of that performance improvement is worth investing in.

If it’s for rendering, it definitely works, but if it’s for previews, it might not make much sense. :thinking:

From my experience, performance bottleneck in animation playback is not Eevee’s GPU rendering, but Blender editor processes, such as mesh modifiers. Mainly Armature and custom Geometry Nodes stuff.
One Eevee-specific performance tip though: avoid (or temporarily disable) normal and bump maps, as well as any custom shaders that involve Tangent input. Blender is really slow at computing mesh tangents, so disabling everything tangent related speeds up Armature modifier significantly. Often helped me achieve target FPS during playback. You can also try a workaround for faster normal maps, though with significantly worse quality: Way Faster Normal Map Node (for realtime animation playback with tangent space normals)

Also, for every vertex group you have on the mesh, Armature modifier will have to iterate through every vertex of the model additional time. So in theory, splitting a mesh into several pieces, each of them only having vertex groups that directly affect it (for example, head shouldn’t have arm and leg related vgroups on it), can boost Armature-based character performance

3 Likes

While that is true for rendering a still frame, it isn’t the case the animation playback in the viewport. For anything moving or being affected/changed by modifiers, the CPU is then having to process the data for each frame. In some cases the more cores won’t actually make much if any difference.

It is possible that faster single core performance will speed up viewport FPS, but that still has limits and at the end of the day, outside of a sudden leap in technology, there’s little one can do to truly speed things up.

2 Likes

Probably the best way forward is caching modifiers (including armature), I believe the animation module is aware of that possibility. But it’s a big project and I don’t see it happening before other more essential aspects are worked on (layered animation, etc).

1 Like