Just leaving my impressions after 4.2’s release:
EEVEE legacy’s AO and SSR were very useful modeling companions, very simple to switch on/off with reasonable parity to current-day game engine equivalents.
Things must evolve of course but to me the new raytracing features are missing a little practicality for modeling in comparison. The new AO is smeary and approximates much more intensively, messing with the impression of forms a lot more.
I completely understand the drive to reach parity with Cycles and admire the direction EEVEE is taking, I just find myself missing the old AO/SSR implementations for their practicality in modeling and staying on 4.1 as a result. Could just be bias from using the old implementations for so long though.
5 Likes
Quickly regarding AO…
Multipass viewport compositing (currently EEVEE only) recently landed in 4.3, which means that you can use the AO pass in the viewport, which some of you may find more satisfactory as a direct 4.1 replacement.
7 Likes
If they port it back to 4.2 LTS, that might help people moving their projects…
That’s not possible, LTS releases can only receive fixes, and this is a major feature.
And here I go again saying it, but introducing New Eevee in 4.2 LTS is - imho - not the correct decision.
Now people with running projects in 4.1 cannot properly move to the latest LTS version, and have to jump to another non LTS release to use that new feature, to get more or less back to where they were feature wise?
For me a LTS means to freeze all new feature introduction for that release, and have support on “showstopper bugs” for X amount of time. But hey… That’s me… 
6 Likes
Or perhaps 4.2 could have been delayed until other closely related features that were nearly ready to commit, were present.
Eevee Next itself was not ready, so making 4.2 an LTS …
4 Likes
It sure looks to me like AO needs to be added to Eevee-next. It is needed for very close surfaces where the raytracing fails. It should also be available when raytracing is turned off, since it is almost free. The reason it can’t be a compositing step is that the amount and algorithim may depend on other settings such as whether raytracing is enabled, ideally it exactly complements failures in the ray tracing. A slider where 1.0 means “the amount the authors think is correct” and that can multiply AO or completely fade it out would be nice to.
6 Likes
I have to wonder if Eevee next was tested on any other hardware. I have a pretty basic computer. An AMD Ryzen 7 5700, and an RTX3070 with windows 11. Not the best parts in the world. But a modern and capable machine. And Eevee next runs terribly for me. Fuzzy artifacts appearing in light when shadows are enabled. Jagged aliased edges to shadows when rendered. Slow shader compilation, even after turning the sub process to the highest my machine can go. Turning raytrace on and off causes long delays. Changing shadow steps causes long delays. Essentially, anything that affects shadows seems to cause a long delay.
I might be able to overlook the slowness. However the fuzzy artifacts really makes eevee next unusable. I have to stick with 4.1 until that’s fixed. And I’m not sure if it’s being fixed. I downloaded the 4.2.1 release candidate, and the same problem still persisted. I looked around this site, and I haven’t seen any posts saying it’s resolved. Just a couple posts saying they can’t reproduce the problem. So I’m guessing no developer truly knows the cause? And so it probably won’t be fixed for the foreseeable future?
Attached are renders that show the difference between 4.1.0 and 4.2.0. I didn’t use the same file for both renders. I recreated the same environment in separate files. Just to avoid any possible conversion issues. 4.2’s version is noticeably grainier. It’s almost ignorable as a stylistic thing. But when I try toon shading, the fuzz remains, making ugly splotches over the otherwise clean cel shaded surface.
5 Likes
A lot of this is currently known about/expected.
EEVEE-Next shaders are expected to take longer to compile, but they take extra long on NVIDIA GPU systems due to a issue with how it compiles specific parts of EEVEE-Next.
Most of these will be shader compilation for the specific setting you just changed.
The fuzzy artifacts probably come from the many stocastic systems in EEVEE Next. Shadow tracing (making shadows of lights with a non 0 size fuzzy), ray traced screen space reflections, bounce lighting, stocastic material sampling, etc.
As for your other issues (E.g. jagged shadows), it’s scene and settings dependant so we can’t comment on it unless we have a file.
Hopefully this is fixed soon, as discrete graphics these days is not cheap, and we would not want people to think they need to spend 1K or more on a high-end GPU just to get the same performance as in 4.1.
Nowadays, it should be the responsibility of software makers in general to stop relying on Moore’s Law to keep their apps usable and instead have more of a focus on optimization to help people stay on their current hardware for longer periods. The devs. are doing a good job optimizing many other areas to where it feels like a free upgrade, it is just that the same was expected for the big upgrade to Eevee as well if you wanted equivalent results to the original version.
3 Likes
It definitely takes a noticeable time with my RTX 4090 & Ryzen 7700x. It was way worse before twitter was flooded by people showing the existence of the Max Shader Compilation Subprocesses property, but i still have times when I prefer previewing on Cycles just to skip the initial waiting period. I hope this gets better rapidly 
I’m also surprised that this property is set to zero by default. Blender seems to already be able to tell how many threads a machine can have since it’s already automatically detecting and setting up Cycle’s threads in its performance panel, so why not do it here as well to avoid unnecessary setting up and unexpected poor performances?
4 Likes
Shaders are compiled on the CPU, a high-end GPU won’t get you faster compile times.
We have implemented multithreaded shader compilation, so if you enable it on the preferences you should get better compile times than in 4.1.
Compiling a single material is still slow, though (since we can’t parallelize it). Shaders are compiled by the GPU driver, so if the compiler is slow there’s not too much we can do on our side (Vulkan should give us more tools to improve this, though).
We did put a lot of effort into improving this as best as we could (see #120100 and #121925).
I don’t think is fair to say we’re just relying on users purchasing more expensive hardware.
The main reason is that this was implemented relatively close to the release and, since OpenGL doesn’t really support multithreaded compilation, the implementation is pretty complex. So enabling it by default seemed too risky.
In the end things have gone quite smoothly, so we may change the default for 4.3.
18 Likes
Downloading this user’s file…
…I get such results:
I didn’t change anything about their file. I simply opened it up in 4.1 and hit F12. Then opened it up in 4.2 and hit F12. These are the render results.
5 Likes
Testing with the file provided, I can confirm that if no settings are changed, you get results like the ones shown.
But if settings are changed (E.g. You select the light and disable the Absolute resolution limit setting in Light Properties -> Shadow), then the shadow quality drastically improves.
3 Likes
Performance Hit on EEVEE Next:
I’m currently migrating an animation project that’s been running for a year from 4.1.1 EEVEE Legacy to 4.2 EEVEE Next.
The scenes in this project are large (a city block with 5 rigged characters), but EEVEE Legacy has been handling them comfortably: Well under than 10 seconds per frame with good quality renders.
Been doing some performance benchmarks during the migration and found we’re taking a severe performance hit in EEVEE Next: An identical scene (i.e. same blend file) rendered on an nVidia 3060Ti delivered an average 5.75 seconds per frame on 4.1.1 EEVEE Legacy, but is an average 89 seconds on 4.2 EEVEE Next. Tweaking EEVEE Next’s settings hasn’t been able to improve on that, though it’s early days.
I’ve found you don’t notice the performance on very small scenes, but when scaling up to a larger scene, you really feel it.
6 Likes
Yes it’s scene specific. Usually involving large complex backgrounds, at least for us. We suppose larger scene are more complex and will have increase in render time but compared to legacy the increase is exponential.
Our studio has machines with 4090 and 128 ram, which are "monsters’ compared to my old clunker at home, so we have ruled out the outdated graphics card or something. Next is basically a totally different renderer so there must be some esoteric setting / scene setup that we still have yet to figure out, but after all the helpful tips on this thread we have not really achieved too much improvement in render speed. Also it can get noisy in some instances where we had to play with settings that add even more to render time.
If we have a character with white background (ie. character tests), then the render speed is not so drastic (in fact we even managed to get a few that rendered faster). But once we put the character into our background scenes, then the waiting game begins. Any improvement we got visually does not justify the exponential increase in render time for our use case. We are on a waiting game with Eevee Next, and things will get better but we are bypassing it for now.
3 Likes
Thanks, @Lawrence_Teng! That explains a lot. I though I was missing something!
For the time being I’ve regressed to 4.1.1. A 1500% performance penalty is just too much. None of the Youtubers trumpetting 4.2 and EEVEE NEXT mentioned any of this.
It’s a real pleasure to be back at Blender 4.1.1 rendering at ~5 seconds a frame once again, and although EEVEE Next has some big improvements, in the scenes I’m generating, hard pressed to notice the difference. But the idea of being stuck in 4.1.1 worries me. I really hope these performance issues can be fixed, otherwise it’s a step backwards, and invites a schism.
A few issues:
-
Something making the transition to 4.2 hard is changes in shadows/transparency requiring changes to the materials shaders, which in turn, are incompatible with 4.1.1. Would have much preferred it if those changes were internal and silent, because once you write those changes back to the .blend file, there’s no going back. Also really complicates maintaining asset libraries. Makes migrating from 4.1.1 to 4.2 all or nothing.
-
When BF tests changes, do they have a test suite featuring large models? Would facilitate early detection of performance problems such as this if they did.
-
EEVEE Legacy gave really useful information on the console which let you identify bottleneck assets and monitor performance. This was worth it’s weight in gold: Let you get the most out of your PCs without redlining them into thrashing behavior, but in testing EEEVEE Next found nothing like this:
...
Fra:455 Mem:15890.18M (Peak 16115.11M) | Time:00:00.58 | Syncing abc
Fra:455 Mem:15916.83M (Peak 16115.11M) | Time:00:00.61 | Syncing CAM01
Fra:455 Mem:15916.65M (Peak 16115.11M) | Time:00:00.61 | Rendering 1 / 17 samples
Fra:455 Mem:15866.48M (Peak 16115.11M) | Time:00:05.58 | Rendering 16 / 16 samples
Saved: 'z:\PRJ039\frameout\S01E03A04B01 v99.CAM01.0455.png'
Time: 00:06.13 (Saving: 00:00.25)
-
Curiosity: When I batch rendered with EEVEE Legacy, my PC is responsive, so I can do other things. But with EEVEE Next, it gets really staggering slow, stuttering, so I can’t type. You could argue I need to upgrade my hardware ($$$$), but point is, it’s fine under EEVEE Legacy, for similar output.
-
Really hope these performance issues are resolved, because being stuck on an old version of Blender isn’t good. (Can no longer contribute to bug reports, and obviously addons start breaking.) So if not, please consider, as others discussed before, keeping the EEVEE Legacy as a render engine alongside EEVEE Next and Cycles, so artists developing productions with large scenes aren’t shut out.
2 Likes
I can’t comment on most of your questions as I do not have the knownledge to do so, but I will comment on what I can.
There are performance tests run automatically for both EEVEE and Cycles. The results for which can be found here:
Linux
macOS
From the looks of it, the EEVEE testing is only run on macOS, and the scenes they use are probably not as complex as the scenes you’re using.
Developers probably also run their own personal tests when trying to optimize a piece of code, but I can not comment on how often, which scenes, which hardware, or what they considered acceptable performance as I do not know this information.
This information missing from 4.2 was a oversight. It has been re added and should be avaliable in 4.3 Alpha right now, and possibly 4.2.1 or 4.2.2 in the future.
1 Like
#123904 - Eevee Next Performance regression - blender - Blender Projects is the bug I’ve opened that’s probably related. I also get massive slow-downs on Eevee Next.
Maybe you could get the scene attached to that bug and report on the bug if you can repro that 4.1.1 is better than 4.2.0 for you?
1 Like