We might want to enable soft shadows by default now, as the quality of them really depends on this option. This is opened to discussion.

From an artist point I'd prefer to have the subpixel jitter decoupled from soft shadows. Whilst subpixel jitter seems to be a useful addition in most cases, soft shadows often come at high cost and are not used.

I think it's a bold decision to remove ESM and VSM. But if we think of Eevee more as a preview or final frame renderer than a game engine renderer, then it does make sense to go for more accurate results with less parameter tweaking.

In the user interface, the "Soft Shadows" setting should become more prominent, as the top setting in the Shadows panel, since that's going to be used more now.

Probably soft shadows should also be disabled by default in lookdev mode (soon to be renamed to material preview in D5612), since it's quite distracting when texture painting.

In D5659#129663, @Alexander Court (spiegelball) wrote:

From an artist point I'd prefer to have the subpixel jitter decoupled from soft shadows. Whilst subpixel jitter seems to be a useful addition in most cases, soft shadows often come at high cost and are not used.

The subpixel jitter is done in the same way as soft shadows. If you don't want soft shadows, making your lights radius equal to 0 will only jitter the sub pixel position but not the emission point.

That said I considered (and still consider) separating the settings. But I fail to see a real use case where you would like incorrect shadowing.

In D5659#129673, @Brecht Van Lommel (brecht) wrote:

I think it's a bold decision to remove ESM and VSM. But if we think of Eevee more as a preview or final frame renderer than a game engine renderer, then it does make sense to go for more accurate results with less parameter tweaking.

I considered keeping ESM and VSM but it's really too much code to maintain and have really different behavior.
I also considered keeping the shadow softness setting but to do this, we would have to have a variable slope bias that is proportional to the filter size. Also it would add complexity to the sampling and I prefer to have fast shadows that are easy to accumulate and converge quickly than shadows that leaks and are slower (but still faster to converge tho).

In the user interface, the "Soft Shadows" setting should become more prominent, as the top setting in the Shadows panel, since that's going to be used more now.

Agree.

Probably soft shadows should also be disabled by default in lookdev mode (soon to be renamed to material preview in D5612), since it's quite distracting when texture painting.

I also agree.

I tested this new patch with a number archviz scenes.

Soft shadows they look more accurate, but also maybe a little harsher compare to previous version or cycles. Would be possible to add a "Softness Shadow Factor" per light? like other game engines like Unreal or Unity.

The translucent BSDF node is not working correctly.

Now that the shadows are being refactor would be possible to fix the soft shadows having animation flickering and temporal aliasing. See bug T68594 https://developer.blender.org/T68594. More comments at Blender Artist thread.

In D5659#129865, @Eric Klein (eklein) wrote:

Soft shadows they look more accurate, but also maybe a little harsher compare to previous version or cycles. Would be possible to add a "Softness Shadow Factor" per light? like other game engines like Unreal or Unity.

This is what I want to avoid. Keeping this soft parameter adds complexity that I would like to get rid of as adding more blur mean bigger bias. Unreal or Unity have a different architecture and they get away with it more easily.
I could add it back later because I need some other changes first that are in another branch. But honestly I think if you want softer shadows, just bump the number of samples.

The translucent BSDF node is not working correctly.

Thanks for noticing that!

Now that the shadows are being refactor would be possible to fix the soft shadows having animation flickering and temporal aliasing. See bug T68594 https://developer.blender.org/T68594. More comments at Blender Artist thread.

This is a separate issue I will fix it outside of this patch.

Please fix your warnings:

//source/blender/draw/engines/eevee/eevee_materials.c: In function ‘EEVEE_materials_draw_opaque’:
///source/blender/draw/engines/eevee/eevee_materials.c:1748:55: warning: unused parameter ‘sldata’ [-Wunused-parameter]
 void EEVEE_materials_draw_opaque(EEVEE_ViewLayerData *sldata, EEVEE_PassList *psl)
                                                       ^~~~~~

//source/blender/blenkernel/intern/light.c:61:3: warning: ‘bleedexp’ is deprecated [-Wdeprecated-declarations]                                                                                                                                           
   la->bleedexp = 2.5f;                                                                                                                                                                                                                                                                   
   ^~                                                                                                                                                                                                                                                                                     
In file included from //source/blender/blenkernel/intern/light.c:29:0:                                                                                                                                                                                   
//source/blender/makesdna/DNA_light_types.h:64:9: note: declared here                                                                                                                                                                                    
   float bleedexp DNA_DEPRECATED;                                                                    
         ^~~~~~~~                                                                                         
//source/blender/blenkernel/intern/light.c:64:3: warning: ‘soft’ is deprecated [-Wdeprecated-declarations]
   la->soft = 3.0f;                                                                                   
   ^~                                                                                                 
In file included from ///source/blender/blenkernel/intern/light.c:29:0:
///source/blender/makesdna/DNA_light_types.h:62:9: note: declared here
   float soft DNA_DEPRECATED;                                                                     
         ^~~~                                                                                      
//source/blender/blenkernel/intern/light.c:79:3: warning: ‘contact_spread’ is deprecated [-Wdeprecated-declarations]
   la->contact_spread = 0.2f;                                                                             
   ^~                                                                                                            
In file included from //source/blender/blenkernel/intern/light.c:29:0:   
//source/blender/makesdna/DNA_light_types.h:90:9: note: declared here       
   float contact_spread DNA_DEPRECATED;                                                                 
         ^~~~~~~~~~~~~~

If you mark something as DNA_DEPRECATED, you should also cleanup the code

Thanks for these improvements! Shadows are now perfectly accurate, it even seems "contact shadows" are no more necessary.

This is what I want to avoid. Keeping this soft parameter adds complexity that I would like to get rid of as adding more blur mean bigger bias.

This is a bit sad to drop soft shadows though... Yes they bring bias and shadow leaking, which is a pain, especially for animation. However it's perfectly fine for some cases, for example still images which don't require accurate shadowing.
Ideally it would have been nice to keep one of the two other mode (ESM?), but that's understandable it's also more work to maintain...

For NPR, control over shadows is really helpful. The softness parameter was useful because it made it possible to tweak shadows without introducing a sampling issue.
Here's the current soft shadow in Blender 2.81. The shader should guarantee that everything is either black or white, but shades of gray appear as samples accumulate. This occurs in Blender 2.80, also, but filtering shadows makes it possible to get this softness without the averaging of several samples. This is sometimes desired, though, since it produces really nice soft shadows and gradients that are hard to get from shaders alone.

Here's Blender 2.80, using the shadow softness parameter:

I'm not saying we need to keep the softness parameter, but this is the use case for me.

I've also noticed that SSS translucency isn't being preserved by Shader-To-RGB node anymore. I think the changes to SSS in this commit are responsible for this. Even though SSS wasn't producing great results with Shader-To-RGB before (being the same as diffuse), having the translucency was nice because it was possible to use it as a mask for back-scattering. It's really hard to fake that effect, so the old behavior is what I prefer. EEVEE is really great for NPR, and I hope this is one of the goals for the renderer, especially since this is something Cycles can't really do yet.

Sad that shadow_buffer_soft got removed, It was actually very useful for faking global illumination and ambient occlusion, and could really reduce the number of samples needed to get a decent image.

In D5659#130689, @Joseph Brandenburg (TheAngerSpecialist) wrote:

I've also noticed that SSS translucency isn't being preserved by Shader-To-RGB node anymore. I think the changes to SSS in this commit are responsible for this.

Ha right! This is because translucency is now done as a separate pass in post and is not computed before the shader to RGB. I will have to add it as a limitation.

For NPR, control over shadows is really helpful. The softness parameter was useful because it made it possible to tweak shadows without introducing a sampling issue.

I understand the issue. If you want really crisp shadow you can always make the shadow size 0 and bump the shadow-map size up to the maximum.
Unfortunately NPR requirements are not really specific when it comes to lighting and making a system that works in all cases is a big headache.
This is why I would rather give full control over the shading and shadowing with a shader script node than trying to alienate EEVEE into something that is half usable for both NPR and PBR.

This is why I would rather give full control over the shading and shadowing with a shader script node than trying to alienate EEVEE into something that is half usable for both NPR and PBR

A shader script node would probably more than make up the difference, and I think in the long term it's better for EEVEE to focus on PBR and matching Cycles. A more dedicated NPR system (like LANPR) might be the best thing to do.
Is there anywhere on devtalk or developer.blender.org that NPR is being roadmapped or discussed specifically? I'd like to list out some of the scenarios I use EEVEE for, now, and the limitations they have. Maybe I could also make an RCS proposal, like the one Marius Oberholster did a few years back.
Thanks for the reply and for all the work you do!

In D5659#130724, @Joseph Brandenburg (TheAngerSpecialist) wrote:

This is why I would rather give full control over the shading and shadowing with a shader script node than trying to alienate EEVEE into something that is half usable for both NPR and PBR

A shader script node would probably more than make up the difference, and I think in the long term it's better for EEVEE to focus on PBR and matching Cycles. A more dedicated NPR system (like LANPR) might be the best thing to do.
Is there anywhere on devtalk or developer.blender.org that NPR is being roadmapped or discussed specifically? I'd like to list out some of the scenarios I use EEVEE for, now, and the limitations they have. Maybe I could also make an RCS proposal, like the one Marius Oberholster did a few years back.
Thanks for the reply and for all the work you do!

Not that I'm aware. If you find or create a devtalk thread, please tag me there so I can follow the conversation.

In D5659#130715, @Clément Foucault (fclem) wrote:

Unfortunately NPR requirements are not really specific when it comes to lighting and making a system that works in all cases is a big headache.

Basically NPR requires control over separate passes, full-blown shaders are not very useful unless they are build specifically for NPR, the best would be to have input nodes to raw lighting data like shadow pass node not already multiplied by lights, light pass not already multiplied by shadows so artists can do whatever they want with them, also outlines but that's already being worked out right?.

In D5659#130715, @Clément Foucault (fclem) wrote:

This is why I would rather give full control over the shading and shadowing with a shader script node than trying to alienate EEVEE into something that is half usable for both NPR and PBR.

+1 to shader script node, it would be extremely useful for NPR, specially if It had full control over shadowing as you mention, but learning GLSL might not be practical for all artists, as I said before a good amount of raw input nodes would be easier for people without programming background.

Sad+1, I often used ESM at before. two problem.

1.The PCF seems need more samples to make soft shadow. so the progressive make shadow flicker when I change the view. does it will fix in future. btw, and more soft need more samples, that means I need more time on render, for soft shadow(or clear up leveles in soft shadow).

2. I find can't get soft shadow in opengl render（3d viewport/view/viewport render image）. I often used this to preview my animation, or do some test. it's much quickly than final rendering(F12). currently, only get hard shadow with PCF.

So really hope can keep ESM in new version, thanks.

In D5659#130729, @Jean Da Costa (jeacom256) wrote:

In D5659#130715, @Clément Foucault (fclem) wrote:

Unfortunately NPR requirements are not really specific when it comes to lighting and making a system that works in all cases is a big headache.

Basically NPR requires control over separate passes, full-blown shaders are not very useful unless they are build specifically for NPR, the best would be to have input nodes to raw lighting data like shadow pass node not already multiplied by lights, light pass not already multiplied by shadows so artists can do whatever they want with them, also outlines but that's already being worked out right?.

In D5659#130715, @Clément Foucault (fclem) wrote:

This is why I would rather give full control over the shading and shadowing with a shader script node than trying to alienate EEVEE into something that is half usable for both NPR and PBR.

+1 to shader script node, it would be extremely useful for NPR, specially if It had full control over shadowing as you mention, but learning GLSL might not be practical for all artists, as I said before a good amount of raw input nodes would be easier for people without programming background.

Correct. NPR needs to be able to access every component of an image on its own. Roughly speaking, that means we need to be able to get the following as color in the nodes:

• Shading without contact shadows.
• Contact/occlusion shadows on their own.
• Light color
• World Color and strength
• A decent render pass system (Can currently be done by instancing your objects on different layers with different object index, and using that to factor between different shader nodes. This is annoying to setup and maintain. Would be great if we could get custom props in materials, or some sort of layer/scene property so that we can drive a mix value based on what layer/scene is rendering.)
• A proper toon shader that behaves like the Cycles one. If you use Shader to RGB and ramp regular diffuse to create a toon shader, then your shaded area size changes based on light strength, but the intensity of the shading stays the same. Whereas in the Cycles Toon, the size of the shaded area stays the same as you adjust the light, but the intensity of the shading changes.

Eevee can already do some really great toon workflows. The main things that are missing is that last bullet point. It'd be great if we can get an Eevee version of the existing Cycles toon (but preferably without its current size based brightness distortion). The Light and World color issues could be solved if Eevee world and lights could take their color and power from node groups. Currently these don't work.

Of course there's lots of other nice stuff you need for fancier NPR style like light groups, different models of fake light or specular, etc. But the above covers the essentials and Eevee is so close to being a viable NPR engine as it is. A new engine may be needed for really fancy and deep NPR, but it'd be a real waste to not get some of these features in Eevee as it is already so close.

The new shadows are much simpler to use but really lack quality of the more advanced ESM technique. I'm afraid some people would say that you're deliberately reducing the quality of EEVEE because you've got money from Epic Games ;)

I have tested a number of archviz scenes from realistic archviz the PCF quality is a little more accurate than VSM. The issue is It requires more samples to get it them completed soft a minimum 256 or more. This makes the eevee render take longer time, especially in heavy scenes.

The other problem is now contact shadows it has no softness control. Increasing the render samples does not make it go softer. Thick contact shadows are now dark with aliasing artifacts. Previously I was able to combine the normal VSM soft shadows with the contact shadows softness to make a unify look of both type of shadows together. Now this not possible. For practically purpose only very thin contact shadows are usable.

I like that the new system has less settings.
And it's also very nice that there is almost no light leaking anymore.

My main problem is that the "Softness" setting is gone, as the new system is more jaggy and requires higher resolutions for the shadow maps to look good enough.

Offcourse, we have the "Soft shadows" option which look pretty great. But this won't work real-time.
If you have "Soft shadows" enabled, each time you rotate the view or move something around they have to be re-calculated and that's pretty annoying.
For those who have an older / slower machine, the "Soft shadows" are just to slow use.

If the "Softness" would come back I would be very happy!

Just in case you are not aware. Jagged edges depends on Shadows settings > Cube Size (Cascade Size for Sun lamp). With Soft Shadows enabled, Edge Smoothness depends on lamp size/radius (or Angle for Sun lamp).
It is true that in some cases many render samples are necessary to obtain better soft shadows, which can significantly increase render times. I wonder if it could be implemented some way to configure high samples only for shadow system independently without affecting the rest.

In D5659#133301, @jo vlem (jovlem) wrote:

If you have "Soft shadows" enabled, each time you rotate the view or move something around they have to be re-calculated and that's pretty annoying.

You know what would be nice? If they didn't recalculate when you rotate the view, as nothing is changing and the lights are in the same place.

Btw, will the SSS transluncency line glitch be tackled? It also happened in 2.80 but could be mitigated with a little bit of softness, now its more noticeable.

In D5659#129673, @Brecht Van Lommel (brecht) wrote:

I think it's a bold decision to remove ESM and VSM. But if we think of Eevee more as a preview or final frame renderer than a game engine renderer, then it does make sense to go for more accurate results with less parameter tweaking.

Just wanted to chime in since I recently finished an architectural animation with Eevee, and finally was able to test out the new shadow method which does away with individual softness settings per lamp (leaving softness to be determined solely by the lamp's radius). While this does make sense for simplicity, I find that without individual softness control ALL lamps have to be a moderate size to have soft shadows. In the case of my previous animation, I needed to set radius to 0 on some lamps to minimize having their incorrect X-ray image become visible in mirrors.

Obviously, having a lamp appear IN FRONT of occluders when reflected is a serious issue in itself that needs to be addressed eventually, but without the ability to set radius to 0 and still apply artificial softness, there is no more workaround for this.

You can watch the animation here. This features the previous method of VSM and 0 radius on some lamps with individual softness added to compensate.

Note that the ugly specular blob of all the point lamps (table lamps and the pendant light) would have become clearly visible in the mirror surfaces if I did not use a 0 radius in this animation. And using a 0 radius with this new shadow method, obviously produces shadows that would be too hard-edged. Nevertheless, I would be willing to live even with this new potential limitation, if speed optimizations were in the works for Eevee. The animation I linked to above took approximately 76 hours to render at 128 samples and HD resolution @60 fps, which is a bit long for a 30 second animation in a real-time engine. If I did not apply optimizations to completely turn off the render-ability of one room when it was no longer visible, each frame would have taken 9+ minutes to render. So yes, I could live with the lack of shadow tweaking settings if speed optimizations could be added. :-) And I do greatly appreciate all you guys have done with Blender 2.8. It truly is incredible. The organizational quality of the new outliner and collections system alone made this last project for my client possible (and would have been impossible in 2.79). :-)

Thank you so much!

-Adam Janz

I have a question about the soft shadows function.

This works by Randomize the shadow maps origin to create soft shadows.
Now while rendering in the viewport, they are rendered in specific random order.

Would it be possible to first render the shadow map with the smallest offset and the one with the biggest offset last?
This would make the transition from "hard" shadow to "soft" shadow smoother without less off the annoying flickering until all offset shadow maps are rendered.