Page MenuHome

Eevee: Shadow map refactor
ClosedPublic

Authored by Clément Foucault (fclem) on Mon, Sep 2, 5:14 PM.
Tags
None
Tokens
"Love" token, awarded by ogonek."Love" token, awarded by blueprintrandom."Love" token, awarded by johantri."Love" token, awarded by Dabi."Love" token, awarded by pablovazquez."Party Time" token, awarded by filibis."Love" token, awarded by duarteframos."Love" token, awarded by Frozen_Death_Knight."Yellow Medal" token, awarded by kioku."Love" token, awarded by amonpaike.

Details

Summary

SSS:

  • This refactor reduce the Memory overhead of SSS and enables us to always use separate albedo. Previously we used 128bits/px for SSS data and 32bits/px for albedo. Now we use 112bits/px for SSS data & separate albedo altogether.
  • Then we separate the translucency evaluation to be outside of surface eval. This as the benefit to reduce code complexity and remove the need for shadow map (non-test) sampler in the shading pass. One big change is that bsdf intensity is multiplied and stored with the albedo color instead of the sss irradiance. This is in order to apply it to both the translucency and the sss diffusion. This change the look of mixed SSS shaders which is now closer to cycles.

Shadows:

  • Add shadow bias state to DRW manager to have hardware depth bias. It is set to the minimum needed to avoid shadow acne using bilinear filtered shadowmaps. The bias parameter is now only doing an extra (user defined) offset in world space to avoid aliasing artifact.
  • Replace ESM and VSM by PCF shadow mapping. PCF shadowmaps are less prone to light leaking and are faster to render (no prefilter).
  • Make sun clip distances automatic: This simplify sun lights setup and matches more cycles behavior.
  • Speedup: Use only 2 sample for cascaded shadowmap
  • Add subpixel jitter to improve low res shadowmap accuracy. This option is only enabled if soft shadows are enabled.
  • Improve contact shadows: Contact shadows now follow the shadowmap direction. This means it matches the shadowmap blur that is proportional to the light radius. Moreover this adds a more efficient bias for most contact shadows.
  • Speedup: Only render shadow cube face needed This reduce the number of face to render to 5 in the case of area lights and 5 or 1 for spotlights.

Compatibility:

  • I removed the shadow method option, the exponent and bleed bias, and softness parameter for both contact shadows and shadowmaps. However, all DNA is left (and tagged with DNA_DEPRECATED) to ensure forward Compatibility (avoid crash of 2.80).

During the developpment of this I tried some techniques that failed:

  • Receiver Plane Depth Bias: it was supposed to allow arbitrary wide filter without having self shadowing at the cost of some light leak. In practice, it removes shadowing from almost all surfaces perpendicular to the light vector. I tried putting a maximum bias value but it was very difficult to set the right value. Also the code was a bit heavy.
  • samplerCubeShadowArray: Is a failure, we need to add a one texel border to each face and use a custom sampling method in order to have correct interpolation at face borders (when using hardware bilinear shadow test). So it defeats the purpose of using them to simplify the code.

Diff Detail

Repository
rB Blender

Event Timeline

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.

Clément Foucault (fclem) retitled this revision from This patch refactor shadows and some of the SSS render path (needed for shadow). to Eevee: Shadow map refactor.Mon, Sep 2, 6:10 PM

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.

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.

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.

Clément Foucault (fclem) planned changes to this revision.EditedTue, Sep 3, 2:33 AM

There is a warning with DNA_DEPRECATED.
SSS on transmission + SSRefract is broken.
And bump mapping. (not broken from this patch)

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.

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.

  • EEVEE: Fix broken refraction material
  • Cleanup: EEVEE: Remove unused code
  • EEVEE: Fix contact shadows masking translucency BSDF
  • EEVEE: Fix Translucent BSDF indirect lighting and bent normal

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

source/blender/makesdna/DNA_light_types.h
64

See note no warnings.

90

See note on warnings.

This revision was not accepted when it landed; it landed in state Needs Review.
This revision was automatically updated to reflect the committed changes.

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:


(It doesn't look like it's making a preview).

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.

Clément Foucault (fclem) marked 2 inline comments as done.Thu, Sep 5, 11:58 PM

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!

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.

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?.

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).

  1. 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.

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?.

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!

YAFU (YAFU) added a subscriber: YAFU (YAFU).EditedSat, Sep 14, 8:27 PM

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.