Optimizing EEVEE GI

There isn’t, but the memory use per polygon in Blender should be consistent. I just tried subdividing and duplicating the default cube to see how much memory that would take. At 40 million triangles, my memory peaked at 3.4 GB during render.

But, even an empty scene took about half a GB to render, so that would mean very roughly 40 million tris = 3 GB Vram use. The only way you are going to reach that kind of polygon count by accident is if you aren’t careful with subdivision modifiers.

Keep in mind this is only for the polygons without textures. If you use image textures, you also need to count them, as they will use some memory. I tried adding a single 4096x4096 image texture to a plane to see how much memory it takes at render and it took 64 MB. This really isn’t that much, but you have to be careful if you have dozens of materials each with color, roughness and bump textures.

If you double the resolution of a texture, the number of pixels increases by 4x. This means that the cost of textures rises increasingly faster with resolution. This also means that if a texture is in the background and you don’t need as much resolution, you can save 3/4 of its weight by dividing its resolution in half.

What happens if we exceed the amount of memory we have in VRAM?
in the viewport and in the render?

Thanks

Then your normal RAM takes over- at the cost of serious slowdowns

1 Like

Why is the amount of VRAM used in the viewport greater than in the render?

Because running the viewport, running Blender itself needs to use some Vram. When you do a render, all of that can be temporarily deactivated and only the data needed for the render is used.

So can I leave the viewport at : rendered when rendering?
or is it necessary to change the viewport to wireframe when rendering?

I just tried it and it seems that the viewport will be stopped in Eevee, but will keep rendering in the background in Cycles.

So you should go out of rendered mode if you render in Cycles.

What are the video card processors for?

When we have procedural maps in a material, are they calculated during compilation by the processor cores?

Is there a way for nodes on the left of a material tree not to need to be calculated when we edit nodes on the right of the tree?

Thanks

Unless you are rendering in Cycles on the CPU, the video card does most of the rendering process. The main thing it doesn’t do is the pre-render process, the scene getting loaded and prepared before the actual rendering starts.

Procedural textures are not calculated during compilation, they are calculated on the fly during render.

During compilation, a procedural texture is stored only as maths equations. There is no texture that is pre-calculated and stored, only instructions that will serve to re-create it for each pixel on screen one by one.

Each time a pixel of the object is rendered, those equations/instructions are calculated for that one pixel to figure out which color should be on that spot.

Each procedural texture is stored only as a few lines of code, so it needs almost no storage space. But, this slows down the render, because nothing is cached or stored, the maths need to be calculated for each pixel on screen one by one and each pixel in the render is created without any texture having ever been stored.

Sadly no. The developpers had discussed a plan to improve nodes and texturing at some point. That plan would have included the ability to bake parts of your node tree that are final so they don’t need to be calculated each time. But this hasn’t led to anything real yet.

Right now, there are a few manual ways to deal with this:

  • Temporarily disconnect parts of your node tree if you aren’t working on them and don’t need them for now.

  • Turn down the “detail” level of procedural textures if it doesn’t need to be that high. That setting can be quite performance heavy depending on what you are doing.

  • If there is a big branch of you material you know is final, you could bake just that branch to an image texture in advance. You can then disconnect that entire section of the procedural material and replace it with a single image texture node that does the same thing. Even if the rest of the material isn’t complete, you can keep adding more procedural stuff over it afterward and then bake it again.

  • If you have multiple procedural materials visible at once, hide the ones you aren’t actively working on, they take performance to display even if you aren’t changing them actively.

how do I do this?

2 Likes

On many of the different procedural textures (noise, voronoi, etc.), there is a slider called “detail”. If you are doing complex shaders, I am assuming you are likely using it.

Does this addon really work?
Is it similar to NANITE?
Is it also good with EEVEE?

Thanks

If I understand what’s written on the page, this works using instancing.

“Instancing” means that you can make a single displaced object and tell Blender to reuse it multiple times at little cost. That is something you can already do without an addon, this addon just adds a bit of convenience.

It is not like Nanite, which works more like the decimate modifier.

Instances are objects that reuse the same mesh. That means that the object can be stored into memory only once even though it’s present multiple times in the scene. If you have multiple objects in your scene that will be completely indentical, you can make them into instances to save memory. Instead of duplicating them using shift+d, you use alt+d. When you do this, you will see the polygon count of your scene doesn’t increase, as you have reused the same polygons for 2 objects.

This is great for making large scenes. You can make a few high detail objects and instance them to build a large scene for less cost than it would have taken if they were full copies. However, this only works if the objects being instanced don’t have modifiers on them. Modifiers force each object to be counted separately and this prevent the reuse.

There is an other way to make an instance, which does work with modifiers. You can put an object into a collection, then instance that collection (right click on the collection in the outliner, the option will be there). Anything that is inside this collection will be duplicated and reused. This way can instance pretty much anything (even entire rigged characters), but is slightly more restrictive in what you can do with the copies.

Particle systems and geometry nodes also use instancing, if you use them to scatter objects on a surface.

Instancing does work with Eevee, but the performance gains aren’t as good as they are with Cycles. Instances save on memory, which allows a bigger max size for your scene, but Eevee still needs to render all those polygons, so it will still increase the render times.

Cycles’ performance is less affected, because it doesn’t render every polygon 1 by 1 like Eevee does, it renders only what each light ray touches.

Here is an example of instances. It’s done using the collection instance method. Only one cube is real, the others reuse the mesh at no extra memory cost.
displacement_instances.blend (1.1 MB)

1 Like

In the Infinite Displacement addon that I mentioned: the guy can instantiate a brick and splice the edges of the mesh.

how is this done?

he quotes: It’s amazing because most of the memory is used to tessellate a single tile, while all of the other tiles are copies of this one and this makes the whole process much faster and efficient for your GPU to handle.

thanks

Are the edges really merged together though? If the texture used is perfectly seamless, the edges between the instances should match perfectly and look fine even if the vertices aren’t merged.

Also, I notice that in the video, the addon is making a floor out of cubes, not planes. This would allow the floor to tolerate small cracks if the texture is not perfectly matched (you would see through a plane if there was a gap between the instances, but cubes solve this).

Looking at the video, I think that’s what it is. I can see the cracks between the instances. It’s just displaced cubes that rely on the texture matching well.

cracks

3 Likes