Thanks for your reply! I’ll see how I can work-around this as you suggested with a sun light, and in the meantime I hope both the spot-light and the sharpening solutions in the future will solve this.
If beam shape spread for area lights will get implemented for eevee, do you think the solution you are talking about for spot-lights could be the same for area lights? I ask because area lights are my main light sources so far.
Yes that would be the plan.
Yes.
The support was delayed. So it is currently unsupported. It is available because the property is now the same for Cycles. Maybe we should have a warning label for that.
Strange shadow behavior ( with planar probe )
At certain angles, the shadow in the reflection either disappears or starts to disappear partially (as if filled with cubes). And at certain angles it looks normal
And if you used plane lightprobe, reflective objects in reflection doesnt have any reflection - (cubemaps too), please fix that
05.06.2024
Jittered shadows doesnt rendered?
Could we perhaps finally look forward to ToonBSDF support in EEVEE-Next?
You don’t need it- you can get far better results with Shader to RGB
I don’t know if people still mention about the frozen I get with eevee next.
I guess it’s so-called “compilation time”.
It’s very disgusting in my case, even switching panel from object property to Render property it froze for a very long time in my old file. I am not even in render/material preview mode yet.
I felt only discouraged and unsafe using eevee next. because I am uncertain if such freeze will keep coming or it will only happen very initially.
what’s really sad to me is that 4.2 seem to remove eevee legacy. for now I still staying on old alpha for more fluent workflow. 
I too am experiencing freezing
I add a new material, frozen for 10 seconds
Do any change in the material, frozen for 10 seconds
And so on
when I check “jittered shadows” some shadows dissapear in the viewport:
They do not disappear, they just have higher bias because they are lower resolution. This was a fix for the issue you were mentioning about a few days earlier where shadows would alias very badly on the face.
See Fix: EEVEE-Next: Shadow acnee during viewport transform · 6ce4e94eb9 - blender - Blender Projects
The issue is that for viewport, the jittered shadows cannot converge properly because of the viewport restriction on shadow render update. So we use a lower approximation. The chosen resolution is going to be the lowest that is requested for this light. So if your light is touching the background, it will have this issue.
Do note that this only affects the viewport and viewport renders. The final renders should be fine.
We do not have a better fix right now. You can workaround this by using spotlights and reducing the cone angle to only light your subject, or reduce the influence distance (globally or per light).
Thank you, I noticed the glitchy shadows didn’t happen anymore and that it was related. I’ll be savvy on the use of area lights for now.
Wow, EEVEE raytracing in realtime + realtime compositor in GPU is a bit of amazing:
Could you give a test run to this?
Builds available here.
Edit: Download the latest daily build instead:
Getting seemingly random crashing on today’s build when switching to rendered/material preview mode, can’t report it because it’s in a scene i cannot publicly share but the scene is relatively heavy (~30 lights and ~80 materials) so it might have to do with that.
This build is significantly faster (with some caveats). I set my core allotment to 16. (I7 13K chip, 16 physical cores)
clipped test RGB.zip.txt (1.3 MB)
Scene attached, here’s a pic:
from fresh launch, no cache:
clipped test took 1:22 min to compile
close blender, relaunch
open scene, switch to render view
the compile repeated, 1:25 mins to finish
close blender, relaunch
open scene, switch to render view
compile time 1-2 seconds
So oddly, the first compile had to be … ‘redone’, or something.
The city scene (have posted before, screenshot not needed) has compiled times dropped from 2:02 mins (regular 4.2 build) to 1:22 min (special build). This compilation speed is not as fast as Eevee Legacy (36 secs), but nonetheless much improved.
I’ve noticed that changing parameters within the nodes still has a significant delay. For example, changing from ADD to MULTIPLY (or anything else) has a nearly 3 second delay for the shader to recompile. This delay is on a per node basis. So, it’s not as if the system compiles ‘mix/add’ once, and then the rest of the session is fast - individual nodes have a 2-3 delay when changing certain values.
Stability was not good, Blender often crashed when a scene is open, and I chose to open a different scene.
And as an aside, i continue to wish the RAYTRACING CHECKBOX in the render properties was NOT ON by default. I have to turn it OFF for everything I open, otherwise scene is filled with reflections and light bouncing that I didn’t ask for.
i have the same situation, i try to use a value there on thickness in the output node to define how thick my mesh was, it kinda works but i wasn`t able to properly dial to look right.
Which brings me to the little question i came to ask,
¿is there a preview of some kind of manual/faq/guide to read about the new eevee?
https://docs.blender.org/manual/en/4.2/render/eevee/render_settings/index.html
There is no 4.2 info yet, even when i was following more or less the development its hard to test and push eevee next without knowing what things does, besides the hints in the ui.
I have a question, I find that the screen space reflection in EEVEE-Next doesn’t look like full resolution, at least I feel it’s more blurry than the old EEVEE.
I don’t know if this is a bug or if the developers designed it this way to minimize performance, but I would prefer to have a full resolution reflection of the screen space available.
By the way, today’s 4.3.0 alpha release seems to fix the lack of shadows in large scenes when objects are too close to large objects, which is fantastic!
Are normal maps tanking EEVEE’s performance always going to be a problem? Or are there optimizations planned eventually? Seems like EEVEE-Next is just as bad as legacy EEVEE
Old behavior is just the same as using Slab thickness mode and plugging a 0 value into the output thickness.
Documentation is going to be updated very soon
You can set the resolution of raytracing to 1:1 for that. The denoising is actually a bit buggy concerning refraction so you can try by turning it off.
This wasn’t part of the EEVEE-Next project. There is solutions to this problem but we need to assess which is best and fit our design.
