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?
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.”.
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?
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
.
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.
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.
Good idea. Maybe we could just add it to the viewport “Compling Shaders” message.
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.
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.
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
Blender arent fully closed if you use Shader Compilation Subprocesses #122973 - Shader Subprocesses aren't closed if Blender crashes - blender - Blender Projects
I’ve tested it in one of my scenes:
MSCS set to 0 - 63 seconds
MSCS set to 12 - 21 seconds
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.
The final version will be linked inside the release notes.
https://developer.blender.org/docs/release_notes/4.2/eevee_migration/
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.
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.
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.
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…
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.
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 1BLENDER_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?
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.
Refraction gives weird result unless thickness is increased under Ray Tracing settings to around 5m. Intended?