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.
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.
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.
It seems that the issues mentioned will be resolved soon.
Much better! Thanks for the heads up and the link!
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.
First Eevee also was a bit rough⌠in reality if we compare this Eevee to the 2.8 Eevee, this one is less faulty.
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.
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.
When the camera angle changes, occlusion seems to work much more stably in Eevee Legacy. Eevee Next definitely makes it harder to control occlusion.
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.
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.
Thanks for the explanation.
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.
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.
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.
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.
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.
Makes sense because the scene does take about 2 minutes to render! Thanks for the explanation, will report the bug right next!
Done: