Indeed, it looks like full 1:1 resolution with noise reduction turned off, and a little blurrier with noise reduction turned on.
There’s also the question of how much detail is blurred out by the noise reduction, I don’t know if that’s a good thing or not, but it looks rather… It doesn’t look good.
Still, this seems like a too small improvement. I have the same processor and speed-ups are much larger.
Could you share the file?
Yes, this compiles multiple shaders in parallel, so if one of the material passes takes 3 seconds to compile, we can’t really speed that up.
At least this method doesn’t block the UI, so it should be a bit less annoying.
Yes, this is just how it works. We generate the shader source code from the nodes and send that to the driver. There’s no option to tell the driver “this is like this other one, but we changed this”, the whole thing has to be recompiled every time.
Could you share your crash reports? They should be in your %tmp% folder.
Here are a few different occurrences of the crashing, done just now -
geonode fail.crash.txt (54.5 KB)
blender_debug_output.txt (8.8 KB)
blender_system_info.txt (26.7 KB)
SkylineBase_v1-Painted_GE41.crash.txt (56.2 KB)
I’m not able to share the city file itself, but can say it has 85 materials, the majority (70-85%, at least) of which are of the Diffuse/Shader-to-RGB variety.
Thanks!
Those crashes seem unrelated to the shader compilation.
One happens in blender::bke::object_has_geometry_set_instances and another one when deleting a blender::nodes::geo_eval_log::GeoModifierLog::LocalData.
If you can’t reproduce them on the latest daily build, they may have been fixed already.
Otherwise, open a bug report, please.
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.
Subject: No Volumetric Shadows in Eevee Next Render - Build b73b66330905SHA
//—//
I am unable to get volumetrics and his shadows to work in Eevee Next using Blender beta version b73b66330905, released on June 7th at 01:59 for x64. I have enabled volumetrics for my lights and set the world environment to use volumetric scattering.
While I can see the volumetric effects in the viewport with Eevee Next render engine selected, they completely disappear upon rendering an image sequence or single frame. The render appears as if there are no volumetrics at all, even though they are visible in the viewport.
I have tested this with both simple and complex scenes, and the result is the same. I am unsure if this is a bug or if I am missing a setting. with Cycles rendering just works so ı am sure it’s about eevee next
this is with viewport render image from view panel - same with just render too :d
Thank you for your time and consideration.
I am trying to do some investigation of my broken NPR file.
Meanwhile I found this issue of shader to RGB and “Shadow” setting on.
Another thing I want to mention,
while I didn’t measure if compilation time improved with newest subprocess change.
If you load factory setting to reproduce some bugs, the subprocess will be set to 0.
I am afraid it will cause unhappy experience in bug reporting process.
Is it possible to improve it?
Hi @pragma37,
Possible to simplify Max Shaders Compilation preference setting, by borrowing some Cycles CPU Performance > Threads UI code?
GIMP mock-up.
Hi Clem,
Appreciate you are busy, when you have a moment, how did your discussion go? Be helpful to match EEVEE Legacy, visualising DoF Jitter camera in the Viewport.
Out of interest, would they help reduce shader compilation times?
Thank you for your time, dedication, and consideration.
Kindest regards.
There’s another issue I find about shadow intersection area.
I recall people already mentioned issue about missing contract shadow.
eevee above, eevee-next below
I tried to tweak settings, but unfortunately I can’t find anyway using eevee-next to achieve old eevee looking by any means.
We’ve been asked to report a bug for issues like this
@Gerstmann_Bradley
It’s hard to tell from just looking at the images.
Your second image might be a soft shadow tracing issue.
On your first image, I’m not even sure what you’re referring to. If it’s the noisiness, it could be soft shadow tracing or AO.
For such simple scenes, it’s best if you link the files so we can check (also tell specifically what issue you’re referring to).
We want to add a command line option to set the number of subprocesses at startup.
The problem is that auto-detecting the optimal number of subprocesses is harder than it may seem.
It depends on how many physical cores your processor has, how many of them are “performance” vs “efficiency” cores, how the graphics driver handles compilation, how it handles multiple processes, how much RAM you want to allocate to shader compilation…
It’s best to test it yourself, at least until we receive more feedback about the feature.
I misunderstood the issue. After looking over some other test files, I figured out there was indeed a problem. I mitigated it with this commit (more precision in the commit description): Fix: EEVEE-Next: Shadow: Very low resolution shadow in viewport · fb7d5e49d3 - blender - Blender Projects
Anyway, the behavior should be much improved starting from next build.
As I can’t upload file and many other reasons, I turned it into a report: #122921 - Eevee-Next: Weird Shadow Artifact At Close Shot of Where Lights Intersecting - blender - Blender Projects
A relevant topic I want to mention is that I feel “Shadow” should be turned off for all NPR file because it’s noisy and so on. However I am also afraid that turning it off will lose certain features that were available brainlessly in eevee legacy (?).
Also if I understand it correctly, even if RayTracing is off, Shadow itself still requires RayTracing to function and thus the noise.
If this is the situation, If find it very confusing.
I don’t think disabling shadows is a reasonable solution.
To disable soft shadow tracing you have to enable jittered shadows:
And also enable them on the viewport:
That should make shadows behave pretty much as EEVEE Legacy.
I agree with this. At the same time, I don’t think adding even more features to the Raytracing toggle is a good idea. We may need a better solution.
Not sure if this comment will be correct to the current situation, as Next is constantly evolving - but from an artist perspective, I do not expect to find various settings of dealing with Shadow quality and features to be within a tab that deals with Raytracing settings.
It would be like having to go into the color management tab, to deal with turning an alpha channel on and off, because the alpha channel itself is the fourth color channel.
I am not sure if it’s the right place, but can I ask if there is a roadmap somewhere for the Eevee development? I’ve played with it a little and I still find the Eevee ssgi hack having better quality (which still isn’t enough to not consider moving to UE). It would be good to know if there are planned quality improvements in the next half/one year or it’ll be just bugfixing and performance upgrades for a while.
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
Here is a recreation of your scene using the first Beta Ver of Eevee-Next. I don’t know what happened in your particular situation to end up with results like that, but so far in all of my own tests, Eevee-Next is doing NPR some real justice atm. The shadows, along with ShadertoRGB have been working really well for me since the Alpha and only seem to be improving.
Edit: I’ve experienced crashing when going into camera view, but only while in material or render mode.
I‘ve attached bug report earlier #122921 - Eevee-Next: Weird Shadow Artifact At Close Shot of Where Lights Intersecting - blender - Blender Projects. which you can read and the real issues is usually more complex and various than simple cell shading. That’s why the investigation is always still ongoing while I only have limited time.
As I am investigating, I started to notice that the reason it makes shadow difference,
is that the shadow settings has been transferred from “material setting” to “object setting”.
nevertheless often a geometry node tree/generator holds different objects of different materials,
and sometimes the shadow settings may vary within these materials.
These differences can’t be converted properly and thus is making the differences.
Indeed, there are workarounds to resolve it. but it also changes workflow in a negative way in my opinion.
Unfortunately, even if this can be improved, I guess we are already in BCON3 and file saved in 4.2 beta may just be broken with no rescue? (glad I am in alpha anyway)
Thank you for your time and insightful reply.
Apologies if a silly question…
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?
Edit:
Just noticed, bug to report?..
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.
Thank you again.
