If you say it’s Screen Space technique then it should be under “Screen Tracing”. But it still feels like renderer from 90’s, containing tons of parameters users should not be expected to care about.
Why not:
Remove Horizon Scan precision and use Screen Tracing precision to drive it. That will give us “Overall GI Quality” slider.
Remove Horizon Scan thickness and use Screen Tracing Thickness * 2 value to drive it.
Move Horizon Scan bias in Screen Tracing under Max Roughness.
Yes, one could probably make argument that there will be some corner case where careful tweaking of 6 interdependent float values into some perfect constellation could yield slightly better quality/performance ratio, but I don’t think it’s worth the hit to have Eevee NEXT with the UX of 90’s renderers full of Bulgarian constants to tweak.
True… I’d just rearrange the nesting of the settings a bit to imply that Global Illumination can work when raytracing method is set to none. But it still makes sense to have just one set of global illumination quality parameters.
I would just merge both Screen Tracing and Horizon Scan into one Global Illumination panel, where there are 2 subpanels:
This would clearly imply GI is always active, and you can enable ray tracing to improve GI accuracy. It’s also a bit weird that Ray Tracing can be enabled using panel checkbox but Method can be set to none. Either, method should be removed if we have only Screen Tracing so far, or method should stay but the panel checkbox should go away, because it does the same thing as “None” method.
None method still uses the raytracing denoising pipeline and just uses lightprobes to find ray hit color.
Disabling the Raytracing module means that we only rely on prefilter probes without any ray generation or denoising. Maybe we should rename it “Probe only” instead.
The former can still be wanted for lookdev or asset work as it offers more accurate BSDFs representation than the prefiltered probes.
The later is a crude optimized path, aimed at low end hardware support or noiseless output.
Shadow look so much better now! In a full production scene they now look Better than on Eevee-Legacy.
At lunch will test how they animate.
Edit: Nope, no dice on the animation side yet… gives a new shadow at each frame.
Edit2: Render times aren’t bad… the same thing (a full scene with depth volumes, particles, geometry nodes, many assets, etc) on Eevee-Legacy takes 8 seconds per frame and on Eevee-Next 10 seconds per frame, this with GPU compositor enabled for both. On Eevee-Next looks much better tho.
I’ve rendered a bit more frames of animation just to be sure and each frame a new shadow is confirmed. I only have a sun lamp for the sun and 2 point lamps (without shadows) to give ambience.
EEVEE-Next renders world volume different compared to EEVEE-Classic. EEVEE-Classic renders the world volume taking the camera/view clipping in mind. EEVEE-Next takes the same approach as Cycles where the world volume is considered to be infinite and the world light itself not visible.
The reason why it is an operator is that when done as versioning code the mesh could be added to a collection you don’t want and scene data is being changed without you noticing it. Perhaps you did want to behavior of cycles, but forgot to switch the render engine back before saving the last time. World could also be linked and would not be saved when changed.
Although these are development oriented logical decisions I would like to know if there can be a consensus on doing this automatically versus as an operator from a user point of view.
Another option might be to detect this when loading a file and show a popup. Which might be annoying if you’re not interesting in it at that moment.
Having an infinite volume and not being able to see the background is not often useful, and so using a volume with the world in Cycles usually requires lots of extra steps. It makes technical sense for it to be that way, but as an artist I find it annoying more often than not. A much more useful solution would be to add a control to limit the volume distance in the world in both Eevee Next and Cycles, decoupled from the view clipping, so that the artist can choose whether or not it’s infinite. While that’s more work on the rendering side, it would be an amazing workflow improvement. Is that possible?
If one try to render by the 3D viewport in View → Viewport Render Animation. Every frame gets on top of the previous one or something like that looks like a big blur in motion. I tried with both motion Blur on and off and looks the same. From the normal render it doesn’t show up.
What is the difference of having that on the world shader and applying such shader to a sphere? It doesnt make sense to do that on the world since it is supposed to be a global (and infinite) shader, you can already do what you are describing by doing on a geometry`s shader.
And if you insist on doing so on the world shader, you can also do it already.
Like so:
In a new download of the build (so, no existing shader cache), this scene on first open takes approximately 30 seconds to go from shaded to preview in Eevee Next.
I’ve read the previous comments on compilation time, but nonetheless this seems very excessive. In the very same build, Eevee Legacy compiled and displayed the rendered view after a mere 2-3 seconds. (IE, fast enough that I didn’t find it troubling.)
I was going to bug report it (this was mentioned a week or two ago), but at present it sounds like this behavior is completely expected and acceptable.
It doesn’t sound bad that Eevee Next compiles a first run up to 10x slower than Eevee?
And that’s not a theoretical or funny number I’m just throwing out there for impact - I counted the seconds.
I just tried it with another scene (the one I’ve used above for many examples). Eevee was basically instant, under 2 seconds. Eevee Next was nearly 10 seconds.
Another test, just performed / first time load:
Eevee compile time: :41 seconds
Eevee Next compile time: 3:04
Few days ago I did some tests and in 1 minute on my PC (3600X/GTX1660) Blender (4.2) compiles ~116 simple shaders for the EEVEE-Next, while UE5 (5.4) compiles ~1100 complex shaders.
