I already replied to you bug report but I’m re-posting here so that everybody knows.
It interacts with volume if you add a lightprobe volume and bake it. The behavior without probe is expected.
I already replied to you bug report but I’m re-posting here so that everybody knows.
It interacts with volume if you add a lightprobe volume and bake it. The behavior without probe is expected.
I didn’t know this! thank you!
I know compilation speed is on the radar, but… the past few builds are scary slow in most every way. Early 4.2 builds were rather zippy, but now it feels like speeds we dealt with back in the 90s.
On heavy scenes it does struggles… Eevee-Legacy still can handle more complexity than Eevee-Next.
Up to today I wasn’t able to replace Eevee-Legacy at work.
It’s so slow for me in the past 1-2 weeks, that I can’t even really test anything. 3, 7, 10 seconds to change a thing and see what happens… or open a particular scene, and wait minutes.
Real example: color added to shadow pass recently, A/B feedback wanted on which way to go. I tried for several minutes to start working with it, see what the different results were, and try to form an opinion. It was so slow to work with I finally just gave up and closed the program.
So definitely no chance I’m switching from Legacy at this point. (Nor would i ever advise with any alpha, though. Alpha = if it breaks your scene, better have an alt plan… not responsible for damages, lost time, or sudden fire.)
I use 4.2 at work and feels as stable as 4.1… this in Eevee-Legacy and this way I get the speed increase of the GPU compositor (Once go GPU compositor one really doesn’t want to go back to the old one).
But I make everything in Eevee-legacy and then switch to Next for trials. Once Next get’s to Legacy level I’ll use it.
When it regards software l like to live dangerously
…I’m such a daredevil that I even use one of those new Linux Kernels.
If you’re using Linux for anything, your whole computing life is already Daredevil.
You lost me on that one … I work all days with the workstation at maximum and it’s rock solid stable… my last windows was XP since then I started using Ubuntu distros. I only use the workstation for work tho.
Are separate dedicated options for “Cast” and “Receive” shadows per material or object planned to be introduced?
I did a couple more tests, only with Suzanne on an empty stage. As a result, I found that the problem with the lighting was due to the HDRI card format. When using the EXR format, lighting in EEVEE NEXT doesn’t work correctly.
If the license permits it, could you please share the HDRIs?
There will definitely be differences between legacy EEVEE and EEVEE Next as we don’t store the lighting the same way. The lighting is also clamped to 10 by default for HDRI. You can change that using the indirect light clamping in the render setting > clamping
panel.
I’d like to discuss the EEVEE-Next screen. (The following opinions are my own)
Let’s start with ambient occlusion: I’ve been following this new-age renderer since November 2023, and earlier I noticed that the renderer’s ambient occlusion calculations didn’t look as good as the previous EEVEE, which was very bland, didn’t go dark where it should have, and didn’t fit in with the overall look. But I don’t know when EEVEE-Next updated the calculation of ambient occlusion, it looks much better, but in my personal opinion it still hasn’t reached the “layered” and “clear feeling” of the previous EEVEE. (Maybe I’m not used to the new way of calculating, or maybe it just doesn’t look as good as it used to) Anyway, it’s just that clean and clear feeling, black and deep where it should be, with a little bit of stylization XD.
Then there’s raytracing: I’ve been longing for an EEVEE with raytracing for a long, long time, until I discovered EEVEE-Next. I was surprised when I first experienced this renderer because the raytracing interacts with the HDRI textures, it’s like a mini-Cycles renderer integrated into EEVEE. But as time went on, I realized a few things that I personally don’t think are very good. For example, the noise reduction makes lighttracing results rendered at 1:1 resolution look blurry, as if a layer of oil had been applied to the image, or the “roughness” slider, which in my opinion is used to adjust the ratio of level scanning to raytracing. But there are advantages and disadvantages to both calculations, and I’m having a hard time finding a balance.
Advantages and disadvantages of horizontal scanning: the image is clean and tidy, but the overall look can be a bit strange. No “ray tracing”.
Pros and cons of ray tracing: The image is blurry, but it’s really ray traced. However, the intensity of the effect is not as aggressive as horizontal scanning (probably due to the fact that it mimics light bouncing off of it many times, and it looks faint in places where the light is hard to penetrate, or where it should be obscured by ambient light).
This makes the image look a bit bad XD. Also, I feel like the spatial reflection of the screen in EEVEE-Next is not as clear as in EEVEE?
Lastly, the overall graphics: I’m a bit curious as to which way the overall feel of EEVEE-Next is going to be when it’s being made, such as going in the same direction as Cycles, or maybe going more in the direction of UE5’s feel? Going in the direction of Cycles would probably be better for blender, as it would make all three renderers (EEVEE, EEVEE-Next, Cycles) look exactly the same, but my personal opinion is that I’d prefer to go in the direction of UE5, which is a less ray-tracing-sampled renderer, but still has a perfect overall look and feel. It combines the advantages and disadvantages of global raytracing and spatial raytracing, and it feels perfect. By the way, I found a modified version of EEVEE (SSGI version of EEVEE) in the community, I feel that this effect is quite good, not only retains the advantages of EEVEE, but also has the ray tracing of EEVEE-Next. It’s a shame that the shadows are not raytraced.
Pros and cons of SSGI’s EEVEE: It retains EEVEE’s slightly stylized, but very layered and clean image, and the raytraced samples are not too blurry, but are relatively clear. Retained EEVEE’s glow and volume (I think EEVEE in the two do better), and performance overhead feel completely no (I use the RTX4090, feel that rendering 1080P screen is only than the usual increase in rendering time of about 0.2s), reflections are also very clear. The downside is that it doesn’t have the ray-traced shadows and ray-traced refractions of EEVEE-Next, and the algorithm for estimating thickness doesn’t seem to be quite the same as EEVEE-Next, which can make a difference underneath, say, some cars.
SSGI’s EEVEE link “SSGI’s EEVEE”.
EEVEE-Next brings us a new option for real-time renderers, I am happy with this great achievement and hope EEVEE-Next will be better and better in the future!
After I did some tests I felt that there is not much difference between the two, but when I usually play it I can always feel the difference between the two XP, mainly in the overall picture rendering and ray tracing effect / ambient light shielding effect.
What I still feel is that Viewport Motion Blur and Render Montion Blur should have options to be activated separately.
Viewport is never playing on real time on my shots, so viewport motion blur is just one more thing to have things even slower And so far looks really bad, nothing close of what one expects from Motion Blur.
From camera view it’s better… but on 3D viewport with a scene full of particles it’s just a big smudgy thing.
Ok, this is totally off-topic, so admins feel free to delete it but I just wanted to thank @fclem for the huge effort he is making, I can imagine the level of hard work he’s putting in and reading the comments of what should be improved, that must feel discouraging at times, but Clement never has a bad word for anybody and is working his ass off.
Bravo Clement, we are so lucky to have you behind EEVEE.
You are the man.
That’s right.
The reason I use blender is because of EEVEE.
The developers are the best.
Bcon2 is days away, how is EEVEE-Next looking for the release?
Launching a fresh 4.2 install this morning, opened simple test scene with 5 shaders and 1 light. Scene opened in solid view. I changed 3d view to “rendered” and waited approx 30 seconds for Blender to process the command.
I’ve also noted that after this first long delay, opening other scenes feels someone faster than previous builds. Compilation speed is cripplingly slow. So… definitely not there yet. But, improvements are happening.
The output looks nice overall, though, far better than the builds earlier this year.
Sorry if others reported, I skimmed the thread and didn’t see them, but I might have missed something.
Sampling / Shadows / Normal Bias - This was set to 0.02 on my system, which caused strange artifacts that would appear or disappear depending on how close to the geometry my viewport “camera” was. I lowered it to the lowest setting (0.001) and the artifacts seem gone. I don’t recall tweaking this paramater, so if it’s defaulting to 0.02, that might not be good, or maybe this feature is incomplete? (Also, I don’t understand why I want to slide shadows along normals on a surface as a render setting at all, whether this works or not?)
Sun Lamp Angle Degrees - This does seem to affect the softness of the shadows a little bit, but not nearly as much as it should. I have sharp shadows cast from small objects quite far away from the shadow receiver. If I lower the angle to 0 degrees, the shadow appears very sharp, and the larger I make it, the more of a “shadow halo” appears (kind of like bloom, but in reverse? could this be the penumbra?), but there’s still a sharp/clear shadow that should not be that clear given the angular appearance of the sun lamp in question. It seems there may be a new parameter about shadow penumbra that might be buggy? Or maybe the penumbra is working while the main shadow is not? Can’t quite tell.
Sun Lamp Shadows - Might be related to the previous, but there are times where I can see the shadow of a further object whose shadow should be occluded by a closer object. (Imagine a chain of objects, Light > A > B > C… I can see A’s shadow on C even though B’s shadow should keep it from being visible) EDIT: I think this is related to the previous. The “shadow behind another shadow” effect increases as I increase the sun lamp’s angular appearance. If the shadows were properly softened, I don’t think I would see any shadow overlapping.
If these aren’t trivially reproduced I can try to set up a simple .blend for any of these situations. On Mac M2 if that matters.
This sounds crazy TBH. Indirect lighting clamping should be used for secondary bounces to reduce fireflies or variance in interpolated techniques, but illumination from HDRI/Sky should be considered a direct light or a first bounce.
The implementation of proper environment/sky lighting in both Eevee and Eevee Next has kept getting postponed for so long (several years) that we are now getting into these ridiculous issues where HDRI illumination looks absolutely nothing like it should. I don’t mean just slightly wrong or moderately wrong, but illumination that is essentially completely unrelated to the data in the HDRI map.
This really needs to be addressed since now, in the third decade of 21st century, HDRI/Sky environment lighting is base of illuminating nearly every scene. There’s no justification for a renderer in 3D DCC package to get it wrong when even game engines get it right these days.