EDIT: @DShot92 has shared a script that accomplish the case presented bellow:
In my current project, I noticed a peculiar thing.
Let’s say we have just one workstation with 64Gb of main ram, a GPU that has 12Gb of ram and one animation to render with the following specifications:
900 frames long;
Uses 4 Gb of video ram;
takes 30 seconds to render each frame.
Now, what surprised me, to begin with, was the very low resources I was using to render it. Most of the PC wasn’t doing much and didn’t feel particularly tired.
So I experimented with opening a second Blender with the very same file loaded.
Blender A → renders frames from 0 to 450
Blender B → renders frames from 450 to 900
Was expecting a major slow down in both Blenders…
But such did not happen, it kept rendering each session at 30 seconds by frame! So I had just reduced the rendering times to half.
What do we do when such a thing happens!? We open a 3rd Blender of course!
Blender A → renders frames from 0 to 300
Blender B → renders frames from 300 to 600
Blender C → renders frames from 600 to 900
And guess what, because it still has available video ram 4*3 is effectively 12Gb… it kept rendering all 3 sessions at 30 seconds by frame!
I’ve therefore reduced to 1/3 my animation render time!
Now the obvious question is:
Wouldn’t be possible to automate this in the same blender session, like using some kind of virtual sessions, so that instead of taking 30 seconds by frame it would take only 10 seconds by frame?
This would use the same video ram, the full potential of the graphic card, but would save the CPU ram of the need of having 3 Blender windows open.
Makes any sense!?
As long there’s free memory why doesn’t Eevee load more than one frame at a time on an animation!? Seems that it could load 3 just fine in my case!
Hummm! Thanks! But ain’t this for multiple machines!?
I’m using the very same workstation, just with 3 Blender open at the same time on it.
… My description wasn’t clear, sorry! I’ve improved it a bit now!
Just on a side note -when- rendering one scene on multiple machines…
Blender does NOT lock a blend file within the OS, so a accidental file save with a change on one of the many machines will be possible. ‘Normally’ a app and OS will lock the file, so accidental changes cannot happen when a file is opened twice or more.
It is a interesting find indeed.
With CPU rendering, Blender would use all available cores and RAM if possible, so a second Blender would be dog slow to render.
Not sure how Eevee is dealing with this on GPU level, but it looks like the VRAM and GPU rendering has ‘room to spare’ to render all three at once on the GPU.
Yeah, seems that it’s exactly that! As long it has Vram it will render…
…but why has the graphic card room for processing all 3 and keeping the same render speed!?
This means that the graphic card (in my case an Nvidia RTX 3060) has a lot of parallel processing power that ain’t be used most of the graphic card during a single Eevee render seems to be sleeping what a waste!
Yeah, the current Eevee is more of a minimal viable product than a final version. Don’t get me wrong, it’s incredible, I’m a huge fan of Eevee. It just has never officially been “finished”. I don’t remember the whole story of why Eevee took a back seat to geometry nodes, other than “everything nodes” is a huge priority for the foundation, but luckily Eevee Next is being actively worked on right now
Eevee wastes a lot of resources and this has been discussed before as well as running multiple instances of Blender to get around this problem. It should be done in some dirty way before Eevee Next to be able to run multiple rendering instances within Blender project with a single click. I think it should be fairly easy to do such an addon. Unfortunately I am not a coder.
For Eevee Next for PC you will have to wait for a very long time. Mac users are probably in a slightly better situation, because Apple is involved in Blender Cycles/Eevee development. Anyway in a meantime multiple instances rendering should be build into current Blender version.
AFAIK, EEVEE never took a backseat, it just that bugfixing issues like the OP mentioned requires a full rewrite, due to the nature of GPU rendering itself. Also fixing and/or adding certain features will require some modern GPU’s, and thus, EEVEE next will not be limited to openGL 3.x anymore. Also notice that no render engine of any kind will ever be a finished work, since research is ongoing for several features people want/needs for production use.
GeoNodes, by their nature, is orders of magnitude easier to code than a physically based GPU render engine, so it’s not surprising that more developers are on board on this project. Render engines (GPU or not) requires certain knowledge of math, physics, optics and image processing that not every developer has, and for GPU rendering, also requires quite a lot of knowledge of GPU tech, and it’s limitations. That’s probably why there’s only one developer working on EEVEE.
By the way, no need to set different frame ranges in the different Blender instances. At least I assume thats what Format64 was talking about above. Just uncheck Overwrite and check Placeholder. That way before a frame starts rendering, the (empty) output image is created. Once rendering completes, the (finished) rendered frame replaces the empty file. Since Overwrite isn’t activated, the other Blender instances will skip each frame that’s already being rendered by another instance.
At least that’s how I understand it (and how other software does it)
It is indeed! I’ve used it before for one of the companies I worked for.
We rendered in a render farm of 6 computers if I remember correctly, and that would do exactly what you describe… the thing is that if one frame fails, you’ll then have an empty image file.
We had a lot of frames failing, so we often ended up with a lot of empty files that we had to delete by hand That’s why I don’t enjoy that option very much!