On this week animation I’m back to super heavy stuff, with crowds and such and EEVEE is just going trough it as if it was nothing.
2048x2048 rendering at 18 seconds per frame in completely sharp details. Cycles to be this sharp would take at least 10 minutes per frame… or more because I’m also using volumetrics.
I had to save the file, and re-open it because the ram does increase after we work on the file, from 4Gb of VRam in a fresh opened file to almost 8Gb of Vram on a file that had some work made (which crashed when attempting rendering).
Now I’m rendering at stable 11.9Gb of Vram from my 12Gb from the RTX3060. But it’s like 6Gb for the render and 6Gb of having the file open If it continued failing I would try to lunch it by terminal… but is working, so all good
Thanks for all your efforts friends!
Edit:
However the render frozens at each camera switch again
I have no way to share the file and didn’t happen with the simple file with a cube. But yeah… at each camera switch frozens the render and never jumps to the other frame.
Edit2:
Yup! If I start the render again one frame after the cut then it renders again.
But then again is not always, now it switched fine
Edit3:
All right, new discoveries, it’s only when switches to one of the cameras specifically.
Okay. I just downloaded the new build. It only happens when Blender crashes, and for the last 50 or 70 sessions it crashed only 2 times (when I switched from shaded to material preview). In other words, it might take a while.
Once shaders have built, possibly try setting Max Shaders Compilation back to 0 (zero) for lower RAM usage? Blender will need to be restarted after setting change.
Firstly, big thank you for fixing the blender_<random string> folders issue.
Blue sky thinking:
In the future, except for current Blender restart after setting change, could Max Shaders Compilation setting be dynamically allocated, increasing when shaders need to be compiled, then returning to lower setting for reduced RAM usage?
Crashing as a whole seems to be a major issue for me and a few people I know. Certain heavier files just tend to crash seemingly randomly when you enter rendered view.
Specially today I’m also having many crashes… while animating a high-poly character, even changing from solid to wireframe is crashing blender often. Also some crashes while rendering at 2048x2048 that I then rendered fine in Legacy.
Thank you for your suggestion, adding a thickness value did remove the bleed. I had to play around with the value before it fixed all of the different angles, 100 seems to do the trick.
In this case I can’t point what is causing the crashes… so falls in the category “if you can’t replicate it then is not a bug”.
…It happens… but I don’t know why. Can be the file that is just too messed up! But then again works on Legacy
This might not be EEVEE related, as solid->wireframe doesn’t use EEVEE. There has been a refactor how meshes are extracted on the CPU side and uploaded to the GPU. It could be related to that. Best to report so we can check on it. It is better to let more people look at it via a bug report.
I’ve been playing around with Eevee Next a bit, and Eevee Next is actually unusable so far. Rendering takes about 6 to 10 times longer than Eevee Legacy, and the shading viewport is almost unusable. Cycles is much faster.
This is not project specific, I have even tested with completely new projects in Eevee Next and old projects.
At least the whole MacOS system is no longer stalling (always needed to forcequit)
If it continued failing I would try to lunch it by terminal… but is working, so all good 
