I have a hunch if you’re deciding to change which version of a software you use mid-production, you’re being most unprofessional and have zero grounds for blaming anybody other than your own incompetence (it is of utmost importance to note I use the word you in an editorial sense here).
greetings, Kologe
The issue was more in the way of the unprofessional way the BF handled disagreement with their plans for Eevee, giving the impression at the time that they saw users as more of an annoyance who should be flagged rather than intelligent individuals who just want Blender to grow and prosper.
Fortunately, we have not seen such a situation since. If it became a pattern, it would’ve been the best way for an entity as big as the Blender Foundation to end up facing the day it has to close its doors.
Your hunch isn’t correct for all productions. Some projects take months or years, and may be at a stage that changing versions is (normally) perfectly fine.
I’ve changed versions 5 times while using blender, and it hasn’t been until 4.2 that I had to slam on the breaks because Eevee Next was released too soon, AND as an LTS.
So all the other modules’ bug fixes that have come along, that wouldn’t break my production in the least - too bad, can’t use them.
Some of us aren’t even sure if 4.1 will be the last version we ever use for production.
Well, you had an answer from a main developer in the second link, they’ll keep optimizing it obviously, could take a while though…
That’s a strange way to put it, they’re in charge of development, it’s obviously their choice and it would be very difficult if they had to ask permission whenever they have a choice to make. In the meantime, development is open and everyone which is interested can join the discussions and make their point. However this forum isn’t an effective place for that.
Well, those studios know that switching software during production is a big no-go. No-one do that without 1/ very good reasons, 2/ doing a lot of tests to evaluate how much trouble it’s going to be, 3/ investing some time to fix anything that might come in the way.
And most of the time people don’t do that at all. A project is build on a particular version, it should be possible to finish it without resorting to new features.
Well, I bet that if they removed legacy it was for good reasons, it’s hard to maintain two engines as they are so deeply part of the core of blender. Obviously they didn’t removed legacy to annoy people. Especially when back then next was still very much in development. It’s easy to say what people should do when we have very little info of what they are doing and why…
Sure they forget about the number one rule in life : do everything perfect… Why they do mistakes since it’s obvious that it’s not a good choice, right ?
I think it’s like commenting on a basketball match, it’s pretty easy to comment on bad decisions, genuinely thinking because we like basket, we saw 100 of match, we used to play in college that we have some kind of expertise on what they do, and for sure we obviously know better what they should have done. I’m always baffled when some intelligent people fall into those bias. Most of us here do complex work, we have clients, we have difficult decisions to make, we should be able to easily put ourselves into their shoes…
Difficult decisions are part of the job. The best way to avoid them is to do nothing.
Anyway in this case I’m not even sure it’s a bad decision after all, it’s just that since development took more than expected we all though it would be simple to switch to next, that it would be only cool new stuff in a fraction of the rendering time it was before. And it turns out that it’s a bit more mitigated, just like in real life. Those discussion about blender append since the switch from 2.49 to 2.5 … And eventually things settles, who wants to go back to 2.49 UI ? Because at that time a bunch of people where angry about 2.5 and wanted to stick to 2.49 forever…
That’s not fair, @Kologe. As @thorn points out, some productions take years. Some critical aspects of Blender were very buggy; notably Overrides. You had to upgrade, and this strategy worked fine. The upgrades delivered improvements without any drawbacks.
It’s only with 4.1 that we hit a road block, because they ripped out the old real-time renderer and replaced it with one that is much slower. Who could have seen that coming?
From the developer forum:
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).**
That’s like Ford surprising everyone my announcing their new model cars have a maximum speed of 22 mph, and declaring it End of Discussion. Imagine the hit on their shares.
If I did anything “unprofessional”, by definition, it was choosing Blender instead of Maya or Unreal. But until 4.2, choosing Blender had paid off. And 4.1 is solid release, so it’s still paying off. My concern is if EEVEE-Next doesn’t improve performance, 4.1 is my last Blender release. That’s not at threat: It’s just a practical reality. I need a fast renderer, because fast rendering makes a huge difference to production time and expense. Do you acknowledge that as a legitimate concern?
Which is true if the software you’re using is itself mature, but Blender wasn’t. You said that yourself of proxies and overrides.
Exactly!
Herein is the difference between Blender and commercial software development. In commercial development, the goal is to meet the needs of your users. There are requirements gathering and consultation phases for this. The users and developers reach agreement as to what is needed, and then move forward. So it’s certainly not a case of “if they had to ask permission whenever they have a choice to make…” because at that stage the requirements are (technical term): frozen. A commercial software developer who follows their own fancy at the expense of users would not be tolerated.
But Blender devs do what is interesting to them, which is understandable if you’re a volunteer. Less understandable when you’re salaried, but that’s how BF works.
If EEVEE NEXT had a proper requirements gathering phase, one of the first would have been “Must not be slower than EEVEE Legacy”. Take that from someone who used to write requirements.
No. Development is not open. First you have to be a C++ coder with graphics experience. And even if you are it’s a lot of work. Can’t take a year off to do Blender dev while your own production is put on hold. I looked at doing Override development for Blender. wow. It’s complicated sprawling code. I couldn’t justify taking all that time off. So development is open the same way anyone can be their country’s leader: Yes , in theory, but practical limits are very strong.
Which forum? You can’t “join the discussions” on Devtalk, because they shut it down. Talking on BA is shooting the breeze, because developers are as rare as hen’s teeth here and don’t come for ideas or feedback. And same with RCS: look at the lack of engagement on overrides, or even this very issue https://blender.community/c/rightclickselect/B8AN/?sorting=hot . Even Ton, when I did consider reaching out to him (he complained re the VFX platform that studios never did), I couldn’t find a way to reach him. So, there are no channels.
Do agree thought it is what it is and regardless of what we say here, the current situation won’t change. I’ll stick with 4.1 as long as I can.
PS. Fool that I am, I did just notice @https://blender.community/breakingspell/ on https://blender.community/c/rightclickselect/B8AN/?sorting=hot talking about fixing this. I’ll reach out to him!
Hey everyone! I’m glad this is having some discussion again, and thanks for the ping. Sorry for the wall of text, but it’s probably best to consolidate the talk here. I’ve caught up as best as I can on this thread.
I’m a long-term power user of Blender, and a big fan of the project. I’m also ready to return from a sojourn working with Blender, but it’s simply depressing now, even opening the stable 4.1.
With full respect to the development team, this change was truly disappointing. Functionally, it was out of touch with the NPR/toony features that EEVEE catered to uniquely well, despite it’s known bugs. This also broke compatibility in a sweeping manner on an LTS release. I do think both versions could have been retained, Legacy as a fully frozen feature, with Next being the new default.
Obviously, not all changes are bad! I recall being quite miffed at first when learning that the Blender Internal renderer from 2.7 was replaced by the then-new EEVEE in 2.8, as all of my styled assets depended on the former’s texture slots. However, the migration path was clear to replicate the same effect in EEVEE using the BSDF node, and I fell in love with the new engine’s flexiblity.
Inversely, the Pose Library was slowly deprecated throughout 3.x for the new Pose Asset system. That one did lose quite a few features (many features are still conspicuously missing including list view…), so I held onto the feature by building Blender from source and re-adding the poselib C libray, until that stopped working around 4.0. At that point it was easier to simply port to a python addon than to task my machine every time a 3.6 LTS update would hit.
It been said though, this is a real regression, to a much greater extent than those examples. EEVEE Next is simply not fundamentally able to replace Legacy. It’s apples to oranges. 99% of my work was in EEVEE Legacy, for the sole purpose of vivid smooth colors and avoiding the realistic ray-traced effect. If I desired ray-tracing and properly-calculated shadows, I would set up a Cycles scene!
Let’s get to the point though, can EEVEE Legacy can be made to coexist with EEVEE Next?
Both entries were present in the 4.2 alpha, where EEVEE Next was an additional entry to the array of choices, and Legacy retained the old eevee namespace. This allowed old files saved with the old format to open properly. This didn’t last very long though, and I haven’t sat down to pin down precisely which commit this entered and left in to try and reuse those entry points.
At our current point in time (4.5 alpha), Next is taking over all references of the old EEVEE namespace. Simply swapping them out isn’t possible as there are new API calls that would be incompatible with the older version, now that they’ve been coded to assume the newer one. Not to mention the changes to Bloom/Compositor outside of this code tree.
Due to this, it may actually be easier to re-introduce Legacy much like Next was first introduced, as a new additional entry to the array of renderers with a new namespace (eevee_legacy). This could also potentially leverage version checking on .blend to handle old files saved with the old namespace.
That’s as far as my brainstorm has gotten. I do hope to contribute as much as I can, but I’m certainly not ready to take on responsibility for a full fork. I know little to nothing about the actual renderer code beyond studying commits, and making small changes to EEVEE render snapshot behaviors in 3.x era (hard-coded pose asset thumbnails).
A bit off-topic to EEVEE, but this addon is how I handled the poselib removal mentioned earlier, by porting the removed C functions into a python addon, rather than maintaining a full build/fork of the C library. Just simply isn’t applicable in this scenario, as much as I wish it were.
OK, well, so I guess in this case it’s a matter of choosing one evil over the other: Sticking with whichever version the production started in and suffering what was problematic there, or suffering the EEVEE next performance problems.
I can see where this notion comes from.
On the other hand, the thread you linked to above in post #1055 was opened on October 2, 2023. And after almost a whole year it was closed on August 8, 2024.
I think it is fair if they are handling things a bit differently than here on BA, where certain popular threads get piled on for years and years (prominent examples being Cycles Dev thread, Sculptmode thread, GeoNodes thread) and nobody can ever hope to find anything in particular therein anymore after the fact.
greetings, Kologe
This sound like a completely unprofessional way of running a project.
If you’re responsible for technical decision on that project, it’s your choice to pick blender, and all the problems you ran into is your responsibility.
You could have stick with proxies, or use another software.
Of course it’s possible to update at some point, but if you don’t evaluate the risk you’re basically playing with your project’s money and the people working with you. It’s way easier to blame blender than the decisions you took.
That was from 2023 in the override thread :
Indeed, if Maya was a better tool in your opinion it’s very weird to choose something else…
Well in commercial development things can go wrong too and it occurs that they release something buggy, or not on par with the initial requirements. Development of eevee-next was much more complicated than expected, it’s release was postponed from 2/3 versions. If you followed the development that should gave you an indication of what to expect. Beside that , you can also read what people think when testing the beta software, or even better test it for yourself with your own production scenes. You make it sounds like this was a complete unexpected surprise for you but you had a lot of ways and opportunities, especially if you’re in charge of a complex project that’s basically your job and responsibility.
I wasn’t talking about writing code. You can test the software while it’s being developed, follow the development meeting, discuss on devtalk or project.blender.org. That doesn’t mean they should listen even if you have good points. Anyway, you can give feedback while it’s being developed and also you can test things there as well.
@sozap, I can’t respond to that. It’s incoherent. You’re not talking about the points I raised.
I posted a lot of links. Which one in particular? The salient one which terminated the discussion was this one on Aug 8, 2024:
Haven’t I been clear on that? 4.1 - which has EEVEE Legacy - is a good release. I’ll stick with for the rest of the current production. But 4.1 is getting old, so It’d be crazy to start a new production with 4.1, but EEVEE NEXT is too slow to take over from EEVEE Legacy. For a commercial production, time is money. Slow renders cost you! i.e. $$$$. Things like Overrides clunkiness you can live with, but not slow renders! Obviously you can’t use 4.1 forever, so the options become (1) use Blender for modeling, but Unreal for animation and rendering, or (2) Add EEVEE Legacy back to Blender, until such time if ever that (3) EEVEE NEXT becomes as fast as EEVEE Legacy.
That’s pretty simple really? Yes? That’s reasonable isn’t it? I think even Ton would look at that and say “Yeah! Can’t argue with that!”
Anyway, welcome @ breakingspell! I’ve posted many a wall of text myself, and I agree with yours, and this one-liner premise:
I’m in a similar boat. I have a lot of C++ graphics experience. I have explored the Blender source. It’s huge and sprawling and intimidating… like every other piece of software. 
I don’t want to take responsibility for a full fork either - obviously staying together is stronger - but something needs to give, and that may involve talks with BF at the top. Whatever. Cross that bridge when we come to it! For now: I’m interested in restoring EEVEE Legacy to 4.5+.
EEVEE NEXT can stay there. But we need EEVEE Legacy back.
Well, let’s focus on this instead of going back-and-forth. You and @breakingspell seem to have the experience to say- what will it take to get a custom fork of 5.0 (a more realistic target, I’d say, than 4.5) with Eevee Legacy to happen? Is it possible? How much work would it take? How many developers and how many manhours? I know for sure there are a lot of people that want to see this happen, myself included.
Since the changes that brought Eevee Next permeates all of the graphics code in Blender, you may as well consult with Tiles on finally making B4artists a hard fork with its own roadmap, feature set, branding, and community completely independent from the Blender Foundation.
Eevee Legacy coming back is not just going to be a matter of porting.
Just my guess here, but the reason legacy and next aren’t in the same release version is not spending the extra time supporting both of them going forward. Rip off bandaid, seems like it could have happened a few versions down the road based on feedback, and get feature parity along the way.
Seems like a thing that happens with Blender development. Only update to a new version after testing things for your needs, rather extensively on the side. Then be prepared to go back if you missed something. Not perfect, but that seems like the prudent thing to do. Not getting the latest Blender version doesn’t really seem like much of a problem if it is working for you. Not racking up mileage, no oil changes or engine rebuilds are going to be needed.
It’s a little biased and selfish of me, but I wish they’d chill with the version bumps. Once a year, if that, with subversion updates when needed. Kinda like Linux constantly updating things, just gets annoying after a while. I do not care about the latest thing all that much.
I have no interest in B4Artists. I’m asking exclusively about adding Eevee Legacy back
I’m aware of the drastically increased compilation times, but what other EEVEE next shortcomings are absolute deal-breakers for you?
It seems like fixing the problems with the new eevee might be a better solution than necroing the old eevee.
I am lucky that my use case works pretty well in Eevee next. Though if I had to say, the main problems are:
From a technical standpoint I’m sure it’s possible. Simplifying, but we would need to:
engines/eevee tree as engines/eevee_legacy in latest master (4.5 alpha). This is all contained in one large merge request, convenient as it were.We’d need to test every EEVEE Next change and make sure the EEVEE Next portions only talk to EEVEE Next, and restore any missing EEVEE Legacy code, only to be called by EEVEE Legacy. I imagine the vast majority would be sticking the new code and old code behind if checks.
If a commit is missed, it would likely result in a new bug, so we would need to be thorough. I haven’t checked Blender’s automation/ci/cd tests but we would certainly leverage those. Future additions to EEVEE Next would need to be monitored and accounted for, but could be handled similarly to step 4.
It would be a massive undertaking, and i’ve only scouted out commits for this so far. However, Blender does have great build automation (from my experience with poselib), and attempting at least the first 3-4 steps would be a weekend project for one or two hobby devs. We’d at least get an idea of how feasible the rest of the work is.
This is probably a fallacy of some kind, but a half-baked ray-tracing engine, made from scratch and billed as a rewrite, knocked off the best free NPR/toony engine. It’s not one specific hang-up, but a whole fistful of them. The shortcomings are all well-documented (lighting/shadows/toony shader).
The engines shouldn’t have even shared names to be honest. The new engine should have been called Jolteon (because it makes PCs spike).
The new one can continue development and get faster, but it likely will never be able to fully replicate a render from EEVEE Legacy 1:1 feature-wise (shadows, lighting, bloom). The NPR fork/gooengine will have it’s own approach, and hopefully a migration path from 4.1, but would prefer not to be locked in for that long.
There’s also an issue I haven’t put to paper yet, where Render Region and Crop to Render Region behave differently in Next, but I intend to just inspect that and put it behind an option flag (this one may be proposable upstream even).
Great question. @etn249 summed it up well, so let me just add, I have a library of NPR methods and shaders that I’ve spent the last five years making. They don’t work consistently in Eevee Next, and I don’t have time to spend months playing with them trying to get them to work. Nor do I have months to port everything over to the NPR editor, which is experimental and unstable anyway. I need stability and I need my stuff to work, the way I expect it to, fast.
I don’t have spare time to deal with glitches, regressions, lag, or crashes. I work two jobs, have a family, church responsibilities, a long commute… My Blender time is measured by the second, literally speaking. I’ll happily stay on 4.1 forever if need be, I can’t afford the time to mess around with performance regressions and glitches
Does anyone have good recommendations for some tutorials that explains eevee-next settings and how to setup a render ?
I saw that blenderguru did one, are there others that you would suggest ?
Currently I’m looking into an old scene of mine which was too long to render with cycles and didn’t looked good with eevee, and my first tests with eevee-next looks promising…
However I have to admit that some stuff feels a bit slow but it might also be my scene that is quite hard to handle no matter what engine I use.
So maybe the first step is to learn about the engine and see if I can improve things visually while doing a few optimizations here and there…
Right now, Blenderguru’s is the only good tutorial for Eevee next I am aware of. He got some info that no one else got and covers most features.
Though, that tutorial doesn’t really go deep into optimization.
Ok thanks a lot @etn249 ! Sounds like a good way to start and maybe that would be enough to understand how to speed up my scene !