@Juan_Romero > based on comments and feedback it seems like 4.2 even though is LTS will be a testbed for a mature and âcompleteâ Eevee Next in 4.3. I donât think this has been a bad decission necesarily, sometimes technology progress demands risk taking and Eevee in 4.2 is fully usable and produces great results in general, but yes, itâs a landing a bit too rough.
@Juan_Romero > Itâs a new toy that we have to learn and tinker with, the rough part comes when we expect the new toy to work the same as the old toy.
If youâre a hobbyist or just doing it for fun, risk taking is fine. If it goes bad you lose nothing.
But if youâre using Blender professionally, then your livelihood - as in income, repayments, rent, food - is at stake. For users working with larger scenes, 4.2 is not fully usable - Itâs performance is substantially worse to the point I canât use it - and the results arenât significantly better enough to offset that. A 1500% drop in performance is mind-blowing.
What bothers me was I had no idea this was coming. The âEEVEE migration from older versions to Blender 4.2 LTSâ guide only made one reference to performance which, even if you follow the tip, is still far short of EEVEE Legacy performance. There were many Youtubers who posted videos experimenting with EEVEE Next, but they were comparing it to Cycles and Unreal Lumen, and nearly all of those videos worked with simple static examples. It didnât occur to any of them to compare it to EEVEE-Legacy (nor to me, I just assumed NEXT would be better, not worse), and the videos that did mention performance told me it was âfasterâ and I believed them. It took me a week of head-scratching before it occurred to me not to take their word for it and benchmark the two:
My own tests showed EEVEE-Legacy 5.75 sec vs EEVEE-Next 89 sec. Looking for comparisons on Youtube there are no head-to-head but these are alarming none-the-less:
- Rigged character in simple room: Youtube âCycle vs Eevee Next vs Lumenâ: Unreal Lumen 5 min vs EEVEE-Next 30 min vs Cycles 2 hours
- Rigged character in simple room: Youtube âComparison of render quality in UE5, Blender Eevee and Blender Cycleâ Unreal 0.4 vs EEVEE-Legacy 1.54 sec vs Cycles 4.75 sec
- Static furniture scene: Youtube âLumen vs Eevee Next vs Easy Raytraceâ: Unreal Lumen 8 sec vs EEVEE-Next 14 sec
- Moving Car: Youtube âBlender Vs Unreal Engine 5 I render comparisonâ: Unreal Lumen 5 min vs Cycles 4 hours
(One commenter quipped: âLumen: frames per second. Blender: seconds per frame.â 
Based on those, seems EEVEE-Legacy was competitive with Lumen, but EEVEE-Next has really taken a big step backwards. Itâs now competitive with Cycles. 
This next Youtube was interesting, so I re-ran it myself (times are first run (which may include caching), then subsequent re-runs)
The Blender Junk Shop Splash Scene: Youtube âEEVEE Next is horribly slow! (Cycles at 2:28)â (poster said he reported it):
- Cycles(4.2): 1 min 42 sec, 1 min 41 sec, 1 min 41 sec
- EEVEE-Next(4.2): 2 min 01 sec(!!!), 54 seconds, 52 seconds, 51 seconds, 53 seconds
- EEVEE-Legacy(4.1): 49.37 sec. 19.40 sec, 19.42 seconds, 19.53 seconds, 19.40 seconds
At even lower sample rates (16 instead of 64), EEVEE-Legacy is still much faster (6.82 seconds, 6.75 seconds) than EEVEE-Next (15.66, 15.83 seconds).
Yes, EEVEE-Next is taking twice as long or worse than EEVEE-Legacy. (For my scenes, which are larger than the Blender demo scenes, it is much worse).
Cost me a week to sort through all this, so thatâs a week I wonât get back. But what worries me more is Iâm now stuck on 4.1.1. With those sort of performance differences, switching to EEVEE-Next would be like replacing my nVidia 3xxxx with an nVidia 1xxx, and paying a bigger electricity bill too. Yeah, EEVEE-Next is prettier than Legacy (but not that much prettier), but the performance is more like Cycles than Lumen.
@Steve_K2400 > To be honest, I would be happier if we would have Eevee Legacy & Eevee Next both present in 4.2 and in the upcoming versions. The transition (for us) would be smoother.
@Steve_K2400 > Blender supports multiple renderer and so it might have been possible to keep the legacy renderer and only make the necessary changes on the materials. Sure, that would be also more work but I think that would have been a wiser choice.
Yes, absolutely! EEVEE-Next clearly isnât ready for prime time, and eliminating EEVEE-Legacy before EEVEE-Next was ready has put a lot of us in a bad place.
@Lawrence_Teng > Eevee has matured nicely through these years andâŚnow Next is going through the same needed growing pains.
But those growing pains are not needed: If EEVEE-Legacy was still available, no one would have a problem with this. We could transition when EEVEE-Next was ready to take our weight. The problem is this was forced on us prematurely, wasting time while we try and deal with it, causing stress and FUD. Management does not like any of those things.
@Illasera > I do not know how the engine implementation works BUT, they probably wish to avoid maintaining double the code which can results in more bugs and time spent; i can understand that.
I can understand that from their POV, but from a customer POV itâs not a good outcome. Software Engineers always want their code in production as quickly as possible, but companies rely on QA and management to make sure that doesnât happen until itâs of sufficient quality and the customers are ready for it.
And, no. They donât need to keep debugging EEVEE-Legacy. Thatâs mature software thatâs been debugged for years (See Things You Should Never Do, Part I â Joel on Software ). They only needed it as an alternative while they debugged/optimized EEVEE-Next.
@Steve_K2400 > This is exactly the problem why our workflow in the studio brakes down with 4.2. We achieved a visual quality with Eevee legacy that beats VRED on lower end hardware for real time visualization of very large car datasets (some files are over 2 GB in size without packed textures) . A discontinuity in presentation quality due to software changes is not accepted by the leadership so we have to be careful how we proceed. There is also internal competition from other software that makes such a change in Blender even more uncomfortable for our Blender team.
A businessâ biggest nightmare is they wake up one morning and find themselves imperiled because of a change in software they had no control over. Recent changes to BF pushed through, like this and Auto-smooth, are worrying. It makes Blender a much harder sell to management, because it becomes unpredictable.
By its momentum, Blenderâs future as a DCC is safe for now. But as a renderer, not so much. Thereâs now a good business case for doing your animation and rendering in Unreal. Those Lumen frame rates are impressive.
Suggestions:
1. First are foremost: BF need to commit to improving EEVEE-Next to EEVEE-Legacy performance levels, or better (or if thatâs not possible, restore EEVEE-Legacy as an alternative) Weâre assuming they will do that, but have BF accepted this is a problem that urgently needs to be fixed? If not, weâre in trouble.
- BF should be testing new versions on more scenes. The demo scenes are a good place to start: Demo Files â blender.org If your new renderer is half-the-speed of the old one, maybe itâs not ready yet?
Also I suspect as more people are using Blender professionally, they are using larger scenes than BF is aware of. We need to get representative scenes such as this into the BF test suite. IP is a real pain here (and I donât blame BF for not signing NDAs), but we need to make an effort here. I donât mind putting the effort in to make a sample cityscape (which EEVEE-Legacy handles brilliantly) if BF will use it.
- BF needs to be mindful that professionals using Blender need stability. A broken toy is one thing. A broken livelihood is another.