Blender 4.2 - EEVEE-Next Feedback

[Sunova]

I have been using the “plane in front of light” for Eevee (and an Emmision shader with Image Texture for Cycles) for gobo projection in BlenderDMX. How can i do this with Eevee Next, anyone?

[etti]

There should at least be a way to communicate to the user that they can speed up compilation time, because at the current state users will most likely struggle with slow compilation until explicitly told (if at all).
Cycles struggles with a similar issue, where I see MANY users not turn on their respective render device under preferences (or have it reset between versions without knowing), and complain about slow render times. Greyed out Device doesn’t seem to be enough, so i think an explicit warning like such is necessary.

For EEVEE, maybe have a warning under the viewport shader compilation message? “Warning: Max Shader Compilation Subprocesses set to 0, shader compilation may be very slow.”.

[thorn-neverwake]

4.1 Sun shadows - not as clean as I’d like, but the best I could get from Eevee.

4.2 Sun shadows - grainy, blurry, dirty, not even cohesive.

What settings should i be exploring and tweaking for the 4.2 shadows to be clean?

[pragma37]

@josephhansen

To add some clarity, I think it should be said that “NPR” in these discussions usually means cel-shading, which requires hard, smooth shadows with a precise non-gradiented shadow line. For this context, noise or dithering are not acceptable, and I think that’s what is being asked

I don’t think that’s the case here (?), since the user is using really large light angles (67.8º).

For sharp shadows like in @Patting_Pawz image, just set the light Radius/Angle and the Resolution Limit to 0, and disable the Absolute Resolution Limit.

@David_Black

As per the mock-up image, would using the same Cycles CPU threads allocation logic be a good starting point, and more performant, even if an overallocation. Also helpful for Load Factory Settings as an artist friendly default?

Nope, as mentioned, this is more complex than that.
For example, I have a cheap AMD laptop (Ryzen 3, 4 cores, integrated graphics, 8GB RAM), where enabling this is only ~33% faster (in the best cases), so eating up to 1GB of RAM for that little speed-up doesn’t worth it at all.

@David_Black

With Max Shaders Compilation preferences setting > 0, should /tmp blender_... and BLENDER_SHADER_CACHE folders be automatically deleted when Blender is closed? Currently, more and more folders are created each time a scene is loaded.

Not a bug, the point of the shader cache is that we can load an already compiled shader from the disk the next time you use it (instead of having to compile it again).
Those blender_<random string> folders are not related to shader compilation.

@etti

There should at least be a way to communicate to the user that they can speed up compilation time, because at the current state users will most likely struggle with slow compilation until explicitly told (if at all).

Good idea. Maybe we could just add it to the viewport “Compling Shaders” message.

[David_Black]

@pragma37

Not a bug, the point of the shader cache is that we can load an already compiled shader from the disk the next time you use it (instead of having to compile it again).
Those blender_<random string> folders are not related to shader compilation.

Appreciate the need for a cache, as with ‘mesa_shader_cache’.

Since the blender_<random string> folders are only generated if Max Shaders Compilation is enabled. With them having a random string, and loading the same blend file appears to create extra random string folders, rather than reusing the same ones, how do they function as a cache?

Question not a complaint.

Thank you for your wonderful programming skills, time, and helping me understand.

[pragma37]

@David_Black

Since the blender_<random string> folders are only generated if Max Shaders Compilation is enabled.

No, this is not true. As I mentioned, these are not related to the shader cache.
You can easily check it by opening Blender 4.1 or any previous version, that will also create a new folder for that session cache.

[josephhansen]

@pragma37

I don’t think that’s the case here (?), since the user is using really large light angles (67.8º).

It is the case here, as demonstrated by the post above your reply from @thorn-neverwake expressing that the shadows are not clean and sharp enough

[Kuznetsov]

Blender arent fully closed if you use Shader Compilation Subprocesses #122973 - Shader Subprocesses aren't closed if Blender crashes - blender - Blender Projects

[Kuznetsov]

@fclem The light probes look a little bit broken

EEVEE-Next: Area and spot light artifact in reflection plane probe

EEVEE-Next: Environment reflections missing in plane probe

[JohnDow]

@pragma37

BTW, all the parallel shader compilation changes have been merged into the beta and alpha branches, so it should be possible to test them from the daily builds starting tomorrow.

I’ve tested it in one of my scenes:

MSCS set to 0 - 63 seconds
MSCS set to 12 - 21 seconds

[fclem]

I have compiled a migration checklist. There might be some oversight but the biggest changes should already be there. The links to the manual are broken because the pages don’t exists yet. They will be updated in the following days.

blender-developer-docs/eevee_migration.md at main

The final version will be linked inside the release notes.
https://developer.blender.org/docs/release_notes/4.2/eevee_migration/

[fclem]

I think there is a bug where jittered soft shadows have a minimum size. I think I saw it in this thread with the microwave test image. This should be reported and fixed.

[thorn-neverwake]

Coolness, reported.

[Draise]

Refraction

Refraction to Shader to RGB (issue)

Right now I can’t migrate 2 years of a project with another 2 years of production slated due to the heavy reliance on Shader to RGB with refraction from EEVEE-Legacy.

In EEVEE Next, this feature hasn’t been implemented yet. This is a core feature I will need to proceed into the future.

I won’t be able to use the LTS nor can’t use LTS (even if it 4.2 had EEVEE-Legacy) due to ongoing development with a custom fork of Blender used for the production optimization the next coming 2 years based on main trunk to future proof.

Examples of use:

The color highlights behind the character uses Refraction to RGB, and this is a fundamental feature of my future work and the style of the project.

Alpha Clip

Another issue, I was using Alpha Clip on shaders for performance reasons, but due to needing dithered (hashed) alpha, there seems to be a performance cap and this optimization is now lost. From what I know, the math to get a similar result with a greater than or less than can be used in shaders directly, but inherently it’s still using the dithered system with no inherent optimization. From initial migration, this has proven troublesome already.

Thanks for the great work into the future, I hope the overlap and feature parity with EEVEE-Legacy shader to RGB node is on par for official release in the coming month.

[fclem]

Right now I can’t migrate 2 years of a project with another 2 years of production slated due to the heavy reliance on Shader to RGB with refraction from EEVEE-Legacy.

I created this task to keep track of the issue, but there is no way this will make it into 4.2 unfortunately. #123020 - EEVEE: Add back screen space refraction for Shader To RGB material - blender - Blender Projects

Another issue, I was using Alpha Clip on shaders for performance reasons, but due to needing dithered (hashed) alpha, there seems to be a performance cap and this optimization is now lost.

In our testing, it didn’t made much of a difference. The performance drop might be caused by other things (more complex material code). If you can reproduce the performance issue in a simple file, please create a bug report.

As for the porting procedure, it is outlined here EEVEE migration from older versions to 4.2 - Blender Developer Documentation. I am sure this can be automated by python script. We just don’t have the resources to create one for now.

[Draise]

Is there a way to roll-back the pull of EEVEE-Legacy till feature parity in EEVEE-Next is 100% reached for Blender 4.2? Being an LTS, this seems like this is a bit of an oversight to replace something with something that is still a work in progress…

I would rather wait and extend the time for the new and polished in a main build, than not be able to proceed production without using dated versions…

EDIT: One more official release with Legacy might smooth the transition…

EDIT2: I know the commits to roll back legacy are various and multiple in between, so might be an overhead, so understandable (was planning to pull it back). But with this case of no refraction to shader to rgb would be the first time I’ve needed to skip a version to proceed in over half a decade…

[fclem]

I don’t remember if that was mentioned in this thread already, but there are technical reasons why releasing both engine side by side was never an option.

EEVEE-Next was planned for 4.0 and supposed to be breaking compatibility either way. So we cannot version files and expect them to work in both engine. There are way too many changes to keep both side by side. Moreover, it was really time consuming for the development of EEVEE-Next to have both engine side by side (we had to keep some legacy internal API and workarounds). The more we keep EEVEE-Legacy around the more we have to make sure it doesn’t break because of additional feature (i.e: Geometry nodes, sculpt changes, etc…). So all in all, this takes away dev time we could put to better use.

[David_Black]

@pragma37

@David_Black

Since the blender_<random string> folders are only generated if Max Shaders Compilation is enabled.

No, this is not true. As I mentioned, these are not related to the shader cache.
You can easily check it by opening Blender 4.1 or any previous version, that will also create a new folder for that session cache.

Hi,
Apologies. Late last night, realised what I wrote was incorrect, and didn’t explain well what I was trying to say.

Try again…

Max Shaders Compilation = 0

• When Blender is launched - one /tmp blender_<random string> folder is created
• As Blender is closed, that blender_<random string> folder is deleted

Max Shaders Compilation = 8

• When Blender is launched - one /tmp blender_<random string> folder is created
• Switching Viewport shading to Material Preview / EEVEE Rendered creates 8 extra /tmp blender_<random string> folders, and 1 BLENDER_SHADER_CACHE folder
• As Blender is closed, only the original blender_<random string> folder is deleted

/tmp begins to fill with the undeleted empty blender_<random string> folders, not so much of an issue for Linux (since /tmp is cleared when the PC is restarted), possible issue for Windows /temp?

[slowk1d]

It’s quite understandable that both engines can’t be kept for a release, but I feel that for what regards feature parity between Legacy and Next, NPR workflows have been left a little bit behind.
Not that they are not possible at all, but Shader to RGB still doesn’t have “parity” in terms of usage, and in my case, sharp shadows are lower in resolution compared to what I can currently achieve in Legacy. Also reflections with Light Probes Planes (which I’m also relying quite a bit for my NPR project), are still not possible, but I know that it is being investigated.

[etti]

Refraction gives weird result unless thickness is increased under Ray Tracing settings to around 5m. Intended?