Blender 4.2 - EEVEE-Next Feedback

In my view, those are two separate issue, so I would submit two reports. If they are connected in some way, they will figure it out. Bug reports should always be as small/easy as possible.

1 Like

The Max Roughness value determines the maximum roughness that gets processed using the “high quality” ray tracing system. Everything with a roughness above the max roughness uses the “Fast GI” option.

When Max Roughness = 1, it means that all materials are now processed with the “high quality” ray tracing system, and so nothing will be process with the Fast GI system.

1 Like

Thanks for the explanation. This means that the “high quality” raytracer is not calculating any ambient occlusion for whatever reason.
I will file two bug reports as soon as I’m prepared the sample files properly.

1 Like

It seems that the issues mentioned will be resolved soon.

1 Like

Much better! Thanks for the heads up and the link! :smiley:

1 Like

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.

2 Likes

First Eevee also was a bit rough… in reality if we compare this Eevee to the 2.8 Eevee, this one is less faulty.

1 Like

The fact that “High Quality” raytracing doesn’t work at high scale is because the Thickness parameter under screen tracing is becoming just too small for the rays to detect any intersection. If you adjust it to 5000mm, you will see some occlusion.

This is working as expected.

Also it seems that the internal hard coded ray length is too small for this scene (1000 units). This can be fixed. So please create a bug report.

11 Likes

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.

1 Like


When the camera angle changes, occlusion seems to work much more stably in Eevee Legacy. Eevee Next definitely makes it harder to control occlusion.

5 Likes


The occlusion changes significantly depending on the angle.
Of course, I understand that it’s a screen space method, but is there a way to mitigate this?
Additionally, it seems necessary to have a parameter to adjust the strength of the occlusion.

5 Likes

Help, what is this ?
Can’t even do my project. Stuck ! ! !
https://youtu.be/bwvpN3NIuug

It could be the normals? Maybe surface normals? Just a guess here. But we had a similar problem when moving from 3.6 to 4.1 some of our normals need to be reset. I may be wrong but give it a try…

LOL Yes…when legacy came out we thought it was going to go the way of that game engine (I remember Blender had this game engine yes?) and my coworkers keep comparing it to unity/unreal engine but Eevee has matured nicely through these years and…now Next is going through the same needed growing pains.

3 Likes

Thanks for the explanation. :+1:
I filed two bug reports regarding these problems. I hope, my description and the sample files were understandable.

It’s new code so it’s natural that we have to figure out the values and how to use them.

5 Likes

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.
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.

6 Likes

Why does saving in rendering mode takes a million years more compared to solid mode?
In a 1.5Gb file it goes from 3 seconds on solid mode to 3 minutes on render mode.

1 Like

Please report a bug. Usually the render engine is used to render the file thumbnail. It might be that the shader are getting recompiled or something.

3 Likes

Please report it as a bug if that is the case, that is NOT expected behaviour by any means.

I assume its not intentional and is a bug.

I am not trying to repeat what @fclem wrote, i am saying that if it is the case as said, it should be changed to rendering in solid / viewport mode for taking a thumbnail.

very good practice.

Also; 2 bug reports, good contribution, thank you (see, posting the blend file helped).

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.

1 Like

Makes sense because the scene does take about 2 minutes to render! Thanks for the explanation, will report the bug right next!

Done:

1 Like