This is a weekly video chat meeting for planning and discussion of Blender Eevee/viewport module development. Any contributor (developer, UI/UX designer, writer, …) working on Eevee/viewport in Blender is welcome to join.
For users and other interested parties, we ask to read the meeting notes instead so that the meeting can remain focused.
Next Meeting: August 14, 2023, 11:30 AM to 12:00 PM Amsterdam Time (Your local time: 2023-08-14T09:30:00Z → 2023-08-14T10:00:00Z)
Attendees:
Anthony
Clement
Jeroen
Michael
Omar
Windows/ARM
Microsoft is executing a project that might eventually lead to supporting Windows/ARM as an official platform. After we bumped OpenGL version to 4.3 the developer of that project had some issues to actually support it on Microsoft/ARM devices. Mostly as the drivers only support OpenGL 4.2 with most extensions except the texture extension.
During the meeting we went into several scenarios and see what one would fit. On the short term we will add a work-around to Workbench-next so that the project can continue. Adding support for Eevee-next requires driver compatibility with OpenGL 4.3 or Vulkan 1.2.
Our advice is to focus on vulkan compatibility. Main concern is that hardware manufacturers might not implement full compatibility any time soon. Consequence is that Windows/ARM would not support all features in Blender. Most noteworthy Eevee-next.
Eevee-next
Although we have worked hard and would have wanted Eevee-next to be in Blender 4.0 release it is currently not mature enough. Releasing it in Blender 4.0 would lead to undesired performance regressions, stability and workflow issues. We decided to target Blender 4.1 so we can have a few extra months on polishing Eevee-next features. Eevee-next will still be available on alpha builds as experimental feature.
Polished irradiance caching
Metal-backend
Mostly worked on fixes and Eevee-next compatibility.
Why not postpone 4.0 as a whole? I feel like it won’t be as impactful without Eevee next to warrant such a big number change? Wasn’t 3.0 postponed to wait for Cycles-X? Sorry if it’s a dumb question though, great work, devs.
I kinda agree. It doesn’t make much sense to adhere such a significant release to the regular 4 month release cycle. The strict release cycle is a bit of an artifact of commercial software, where the company has to report some quarterly earnings, which often need to be inflated to look good. But Blender has a luxury of being open source project, so why not take advantage of that luxury at least once in a while? Sure regular releases are great, but why rush an important one if there’s no true deadline forcing it?
Some feature of eevee next are still not ready and just working their ass off to just have something “stable” (not performant) i don’t think is good for anyone.
It’s better if they give themselves extra extra time so the eevee that come out is feature complete + have some more work done on performance.
saying goals that make escaping 3.7 are not going to be in 4.0 make the cycle release modification from 4 to 3 release pointless in this first challenge so , I’m with postponing this release until having at least 95% of goals are realized. I propose to delay 4.0 the release to February or March then 4.1 and finally 4.2 at the end o the year, to mention Grease pencil rewrite also needs this delay so. here is like mixing 2 time release into one release. if 4.0 had no eevee-next or Grease pencil V3 or supporting Complex script like india or arabic as text object to be used in geometry nodes or in grease pencil as example… what the big thing that make 4.0 really exciting to change 3.x to 4.x ? or don’t escape 3.7 release happens, bring it back… sorry
From what I understand the major releases are not meant as primarily “big shiny feature” thing but more as also a means of progressing with breaking changes in the code and existing features all around. I am not sure if waiting for a feautre to progress the software as a whole is a good idea even if it’s sad for some people who waited for it. “Wait for feature X to be ready before release” can be a moving target and postpone releases indefinitely in the worst case.
I mean - I’m not a developer so I may be wrong here but I think it’s still absolutely fine to progress with major releases as a means of saying: “it’s potentially feature breaking - beware if you upgrade beyond this point.” Yet it also gives the opportunity to grow in more places than just big feature milestones. Also nobody here can guarantee that all those features will really be ready if BI postpones the release another 6 months or so.
Really, as a community that’s what we have been saying frequently: PLease make the core of Blender better before you add stuff on top. Bring in the long neglected core features and make it stable, fast and improve UX. And the way I understand it that is what the Major releases are meant to progress more than “Feature X”.
But that’s just my understanding. I may be totally wrong here
Thanks for the feedback you all. Postponing a release is much more than adding a few weeks/months to the release date. Blender (uses an open source development model) where many independent projects run at the same time and other development are already planned/scheduled with the next release date in mind so it can land early on in BCon1. It is harder to slow down a running train than to catch the next one. From user perspective we don’t want to post-pone light linking (or any other feature) that many artists are also waiting for.
Cycles landed in the first week that BCon1 was open. The release was postponed in BCon3/4 when some breaking issues where detected (that can always happen). Eevee-next should have landed early in BCon1 in the first place, but as we are nearing BCon2 it is just not realistic and adds to much uncertainty to the release overall.
In software development this is quite normal to do as postponing a release is from user point of view almost the same as targeting for the next version and all other developments and teams can just continue with less impact.
IMO a release number is just a number. Although personally I would not have skipped to 4.0 as that communicates an incorrect message, but that is not my decision to make. 4.0 is just the same as any other release after an LTS. Developers are allowed to remove (legacy/dormant) features and make some breaking changes in order to smooth further development.
But isn’t there a problem that after 4.0, which is a big breaking change for a lot of features, we will have 4.1 which is gonna be even bigger breaking change for Eevee and Grease Pencil? Having breaking changes that frequent isn’t good for users at all. I’d rather wait for one release, manage everything for transition and know that I won’t have to do that for a while now. Opening 4.0 and seeing my shaders changed because there’s new color management, adjusting it only to openi t again in 4.1 and see it changed again because there’s new render engine is less than ideal.
Seeing how light linking also needs serious UI/UX fixes, dyntopo isn’t merged, Principled V2 might also not be ready, it just, from my users point of view, seems like pointless to upgrade to 4.0 and might prefer to stay at 3.6. Light linking is great, but I’d rather not risk such a breaking jump just for it to happen 4 months later again. Right now it feels like 4.0 doesn’t justify being a breaking version
It’s not about naming for me if 3.7 will still be a breaking change. What I’m concerned about is having two breaking changes happen back-to-back. I’d rather either wait for 4.0 bit longer to have 1 major breaking release, or have 3.7 (or 4.0) be a smaller release with every breaking change moved into next one together
I 100% agree. Imo, LTS releases should be round numbers (4.0, 5.0, etc.) and non-LTS should be point releases, such as 4.1, 4.6, 5.3, 5.10, 5.12, etc.). For many new or non-advanced users, it’s confusing that a float number is the “safe”/“stable” download and a whole number is not.
Indeed calling it 3.7 feels much more adequate then.
At work will be much easier to explain that Blender 4.0 has a new Eevee than explaining why renders don’t look the same from 4.0 to 4.1.
Both LTS and non-LTS are safe and stable. The distinction doesn’t matter unless you’re using a pipeline specific enough that you rely on the API and exact features staying unchanged, and/or you’re managing a long-running production
