Blender 4.2 - EEVEE-Next Feedback

Hello all!

In Blender 4.1 EEVEE has been replaced with EEVEE-Next. EEVEE Next . Currently we are finalizing the last bit and pieces so it will be feature complete with good documentation. We would like to get some feedback on how it is to use EEVEE-Next.

The feedback should be limited to what is essential for Blender 4.1 to have the same feature set as EEVEE in Blender 4.0. We all know that adding for example light linking is a common request. But that would not be added to Blender 4.1 as it requires development and would not lead to a more stable EEVEE-Next release.

Before giving feedback, you can check the list of known issues Issues - blender - Blender Projects to see if the feedback is already known and will be addressed.

So download the latest Blender 4.1 Alpha and start testing and give feedback!


Currently, Eevee Next breaks all of my Eevee shaders, because the Shader to RGB node doesn’t work, so… not great :wink:

Don’t get me wrong, I’m really excited about Eevee Next, but I’m worried that this issue isn’t getting much attention. The vast majority of Eevee users I’m aware of use Shader to RGB nodes in every project.

This issue seems to be known, but I haven’t seen an indication that it will be addressed. The issue hasn’t been commented on by any developers, it’s just been triaged and left to die, as far as can be seen.

I hope this can be fixed soon, it’s far from a “normal bug”, as it’s been triaged, it’s a breaking regression that will affect pretty much every Eevee file and user.

As it stands, Eevee files from any version do not work in 4.1 Eevee Next, so I think this issue can be considered essential for feature parity.


Quoting for agreement. Until this particular bug is resolved, none of my scenes can be used nor tested in Eevee Next.


Shader to RGB Issue is known and will the handled and we also find it essential for Blender 4.1. Just need to be patient until we get to it, there are not so many developers who have the experience to solve it. For clarity we updated the issue to reflect the milestone.

Of course you get it that there are many EEVEE files out there that do work! Only files that use this specific node isn’t working concerning this issue.


On Mac, viewport performance in eevee next when navigating or playing an animation is very bad compared to regular eevee (with shadows disabled about 1/2 the fps, with shadows enabled 1/4 the fps or worse). Is that expected/something that will improve?


@blenderrocket EEVEE-Next is still in alpha and performance will improve in the upcoming months. We are looking to optimizer the current effects and might introduce a quality change when playing back an animation or using older GPUs that aren’t optimized for compute intensive tasks.


Hi, few things off the top of my head:

  • Missing material shadow option. I think disabling shadow per material was a pretty useful feature.
  • I see that EEVEE Next renders point cloud. But it seems incomplete as it does not support material (rather, it just renders world shader) and is rendered as octahedral (same as Workbench, maybe intentional for performance reasons?). Is the proper rendering of point a target for 4.1?
  • The addition of SSGI is fantastic. But I think the denoiser is a bit underwhelming. For example, temporal accumulation option makes indirect light darker, but disabling it makes the scene prone to fireflies and sometimes makes glowy artifact around objects. For now I often disable the denoiser and turns up the scene-wide samples instead, which would not be ideal.

Quite a many confirmed EEVEE Next issues here Issues - blender - Blender Projects didn’t get EEVEE-specific label.


The new point cloud is an experimental option and the data type itself isn’t a target for Blender 4.1 afaik.
See #75717 - New pointcloud object type - blender - Blender Projects for more details about the point cloud type.

Will need to do some research on the other topics as I am not fully familiar with the shadowing pipeline and denoising. @fclem any insights from you side?

Here’s my bit of feedback for EEVEE.
There’s something that always really bothered me about Eevee (this includes Material preview shading mode for Cycles):
Glass/Transmissive shaders do not work by default. They appear as mirrors, which is not what is expected.
The user has to go in and search in the material settings to fix ths. Every time. Also, those particular settings to fix it don’t even appear when Cycles is set as the renderer!
By default, I think, these shaders should work. When there’s no raytracing, such shaders should appear as transparent+Glossy. If there’s raytracing, by default, they should do raytracing as well.

Some UI things:
I believe that material preview and final Eevee Render should have their settings unlinked.
So, for example, if the user has raytracing on for the final render, they might not want it for the material preview too. That shading mode is there just to preview materials.
Material preview does not need elaborate settings. Best to keep it as simple as possible. Just a bunch of essentials the user could toggle within the shading mode settings:

This is especially relevant when Cycles is set as the renderer, as all Eevee-related settings get hidden.
Speaking of which: If there’s a setting that changes how a material looks like for Cycles material preview, it shouldn’t get hidden, when Cycles is set as the renderer. Perhaps they could be in their own panel, in the materials tab, called “Material preview display”.

Another thing: The “Use nodes” checkbox for Materials has always been completely useless and should go.

Edit: Oh sorry, I missed the line “The feedback should be limited to…”.


The Raytracing feature needs some additional work. First off, the option to turn it off is hidden inside the menu unlike other settings like Shadows, so it isn’t clear if it is active or not from a UX perspective. Also, it doesn’t seem like it is possible to actually turn it completely off. Because of this it can become very hard to see changes on the canvas with specific settings for Raytracing, even with Denoising being chosen.



I also noticed square artefacts on the canvas when I opened up this current file across the entire canvas caused by Raytracing, but I can’t replicate the issue to take a screenshot as of now.

High Quality Normals when combined with Raytracing and Temporal Reprojection can give ugly normal artefacts while moving the camera:

Some parts of the object can sometimes get black artefacts across the mesh, which is related to Multiscatter GGX:

I sometimes noticed blown out pixels, which I believe is related to SSS (I’m not 100% sure yet, but the issue reminds me of a previous bug with rendering materials with SSS):

Here’s an example of SSS actually creating artefacts when Scale is set to 0:

Shadows in the latest build are looking overall a lot better with less sharp artefacts, but I can still notice a few smaller artefacts in larger shadows:

I am also of the opinion that all types of render options should have more than one setting for either viewport, rendering, or baking (where it makes sense), not just for Sampling, which would apply for both Cycles and EEVEE. For instance, the shadows in EEVEE Next are very resource heavy and slow to render in the viewport, but for a final render in EEVEE Next I would like to bump up those values to max. Right now it is either viewport performance optimisation or final render settings, which is just unnecessary work of having re-adjust the renders to do as I please.

Finally, I want to give some encouraging words. EEVEE Next is showing a lot of potential. It’s a lot more useable now than a few weeks ago. Keep it up!


I love it!

shadow buffer has bugs but there is a patch for it,

I have been trying to understand how to bake a displace from a animation and play it back
(displace / normal / tangent vat) formalizing this workflow will give us a huge boost in speed.

opened a RCS for it.

I also see a need to be able to control the samples per pixel - per effect
(like for SSR / global illumination / shadows etc)

This feedback is misplaced:

Gpu displace is a huge deal
(part of eevee next)

VAT is one of the deliverables from the decision*

Maybe some information in the documentation on eevee_next is required?
(Clement says this should be posible now without any patches)

1 Like

It’s looking great so far but still a ways to go. I’ll touch on reflections as others here have covered some of the other talking points already. I hope reflections end up having a true hybrid raytraced algorithm as to move away from screen space only. Sometimes reflection angles highlight what is not in the original camera’s space and it would be nice to get a truer reflection. Maybe a distance option for reflections (?)

That said basic out of the box current developed EEVEE Next is doing an incredible job with shadow inclusion, compared to OG EEVEE. Still has light leaking at different distances. Distant objects have an issue with being in proximity of each other and possibly losing Ambient Occlusion, meaning distant objects are getting brighter when their edges get too close to each other.

A Reflection Cube Map seems to be needed in the scene to negate the screen space limitation of showing things like the HDRi where a building should be, and helping with some of the light leaking.

Adding a Reflection Plane helps with cleaning up the reflections but doesn’t currently work with a Reflection Cube Map, so you’re back to seeing distant object through walls.

The Reflection Plane is still pretty inaccurate as far as reflections go, i.e angles, point of contact between objects and items tend to disappear at random between renders. Sword, Gun, and shorts are missing in the reflection of the Reflection Plane example below.

I only used an HDRi for lighting the scene.
Machine used: Basic M1 Mac mini
Setting used:

Here are a few examples:

Basic EEVEE Next: HDRi is showing in reflection.

EEVEE Next with Reflection Plane: Missing Items in the reflection. Off center reflections.

EEVEE Next with Reflection Cube Map: Reflections aren’t that great. Overall lighting seems to be closer to Cycles.

Cycles for comparison:

Original EEVEE with baked lighting and Reflection Planes, and every trick I know to get a daylight outdoor scene lit with an HDRi to look good: :slight_smile: And lighting is baked now which isn’t great for animations.

Can’t wait to see what EEVEE Next is capable of in a few months time.


By default, I think, these shaders should work. When there’s no raytracing, such shaders should appear as transparent+Glossy. If there’s raytracing, by default, they should do raytracing as well.

That’s something I’ve considered in the past for performance reasons. The issue is that smooth blending is reserved to Alpha Blend mode (newly Blended render mode) and I don’t think it would make much sense to have very noisy glass material by default. So it would be an option only for this mode to make refractive BSDF cheaper (and working with multiple layer) with these render mode. But this would still require some user input to set the render mode to Blended.

There is nothing in light objects panel. Tested today on blender-4.1.0-alpha+main.67b078aa6f4c build.

First of all, the overall picture quality is greatly improved.

What is stopping me from switching from EEVEE to EEVEE Next:

  • Crashes on older files, when I switch over to EEVEE Next, while the shaders are loading. Haven’t been able to pinpoint on what material/object, would need to do some trial and error.
  • slower than EEVEE. I am not yet able to get enough speed for a good VR session.
  • Very spotty apperance with HDR lighting, especially when moving the viewport around → not (yet) suitable for VR.
  • Materials with partly transparent textures show the HDR background in the transparent areas, instead of the object directly behind. → EDIT: known issue (#114291 - EEVEE Next: Transparency fades to incorrect color on edges. - blender - Blender Projects)

Some small bugs:

1 Like

Another difference with EEVEE legacy I noticed recently.

In EEVEE Next, Wire and Bounds viewport display settings now hide volume materials. In EEVEE legacy the settings didn’t hide volume materials for some reason.

I guess the new behavior is more consistent but personally I find the old behavior more convenient when working with big mesh volumes that span across the scene. Because they don’t get in the way of selecting other objects while properly rendered as volume in the render preview. With the new behavior I have to go back and forth for proper preview and better editability.

EEVEE legacy:


Maybe this is the case that I was using an inconsistent behavior as a feature. :sweat_smile: I’m not sure.


I am quite happy with the current satus. Except for ocassional glitches it works pretty well even on my old laptop (GF 940M). No more Z-fighting when working with planes and alphachannels it seems. That’s awesome!

The one thing that keeps me from using it all the time is that when I have several 3d viewports with eevee in one workspace then edits in sculpt and edit mode will only update in one of them. I have to pan or orbit the other viewport(s) for blender to catch up. I couldn’t find this in the known issues so I don’t know whether it’s a bug or just a known limitation for now.

Currently my main issues with EEVEE-Next are the very noticeably blurry/splotchy world color/material preview and the inability to disable individul effects like AO and SSGI.

Other points of concern are the lack of a per material/object shadow toggle, very strong ghosting at times (which people will still mistake for motion blur like with viewport denoising in EEVEE-Legacy, oh the amount of people i had to explain that to) and shadows freaking out after a few minutes of being in rendered view.