Dynamic shadows artifacts

[II_ADN_II]

slope bias option?? where??? in the 4.22????????????

https://github.com/EpicGames/UnrealE...8e79a5cc281d83

Those are the changes necessary to integrate the slope bias. Ill give it a try as soon as I have some free time.

[Charles.D2]

Hi,

Sorry for a long delay and lack of responses in this thread.

During the past weeks, we tried to address a few concerns raised in this thread regarding self-shadowing/shadow-acne. We added two simple mechanisms for that: slope bias (during shadow map rendering), and receiver bias (during the shadow-map fetching). The slope bias is directly controllable per light, and is proportional to the constant bias. With these two parameters in hand (constant bias + slope bias), you should be able to reduce some of the artifacts mentioned in this thread. Receiver bias is setup globally per light types. All types of bias (constant, slope, and receiver) are controllable through global variable per type of lights. These shadow improvements are in final stage of development and will be released with UE4.23

The well-criticized sphere should now appear smoother:





This should also allow to bring a bit more contact without introducing acne (with manual tweaking).



Please bare in mind, these improvements will help but won't solve all your shadowing issues. Shadow maps are hard unfortunately.

[II_ADN_II]

Hi,

Sorry for a long delay and lack of responses in this thread.

During the past weeks, we tried to address a few concerns raised in this thread regarding self-shadowing/shadow-acne. We added two simple mechanisms for that: slope bias (during shadow map rendering), and receiver bias (during the shadow-map fetching). The slope bias is directly controllable per light, and is proportional to the constant bias. With these two parameters in hand (constant bias + slope bias), you should be able to reduce some of the artifacts mentioned in this thread. Receiver bias is setup globally per light types. All types of bias (constant, slope, and receiver) are controllable through global variable per type of lights. These shadow improvements are in final stage of development and will be released with UE4.23

The well-criticized sphere should now appear smoother:

{"alt":"Click image for larger version Name:\t1.png Views:\t2 Size:\t184.0 KB ID:\t1616438","data-align":"none","data-attachmentid":"1616438","data-size":"full"}

{"alt":"Click image for larger version Name:\t2.png Views:\t1 Size:\t383.8 KB ID:\t1616436","data-align":"none","data-attachmentid":"1616436","data-size":"full"}

This should also allow to bring a bit more contact without introducing acne (with manual tweaking).

{"alt":"Click image for larger version Name:\t3.png Views:\t3 Size:\t284.5 KB ID:\t1616440","data-align":"none","data-attachmentid":"1616440","data-size":"medium"}

Please bare in mind, these improvements will help but won't solve all your shadowing issues. Shadow maps are hard unfortunately.

Thank god this will be in 2.23 T_T Thank you very much, this problem was killing the usability of realtime shadows. Cant wait to test it on 2.23, hope it work as good as other engines

PD: the difference in first image(ground specially) says it all

[The_Distiller]

@Charles.D2: Will the new parameters help to improve landscape slopes as well?

[XilenceX]

Hi,

Sorry for a long delay and lack of responses in this thread.

During the past weeks, we tried to address a few concerns raised in this thread regarding self-shadowing/shadow-acne. We added two simple mechanisms for that: slope bias (during shadow map rendering), and receiver bias (during the shadow-map fetching). The slope bias is directly controllable per light, and is proportional to the constant bias. With these two parameters in hand (constant bias + slope bias), you should be able to reduce some of the artifacts mentioned in this thread. Receiver bias is setup globally per light types. All types of bias (constant, slope, and receiver) are controllable through global variable per type of lights. These shadow improvements are in final stage of development and will be released with UE4.23

The well-criticized sphere should now appear smoother:





This should also allow to bring a bit more contact without introducing acne (with manual tweaking).



Please bare in mind, these improvements will help but won't solve all your shadowing issues. Shadow maps are hard unfortunately.

I must be dreaming. Epic actually fixed self-shadowing/shadow-acne for dynamic shadows?!?
I've been hoping for more work being done on that since the Beta. So that finally actually happening in UE4.23 seems almost surreal.
Ofc. it won't be perfect, but finally having dynamic shadows that at least look "good enough" would be a very big deal.
For high end PCs we might switch to RTX eventually, but the regular dynamic shadows will be the fallback for low end machines for a long time.

[II_ADN_II]

@Charles.D2: Will the new parameters help to improve landscape slopes as well?

Theorically yes. It will remove slope shadow acne on any object, including landscape.

[jonimake]

Hi,

Sorry for a long delay and lack of responses in this thread.

During the past weeks, we tried to address a few concerns raised in this thread regarding self-shadowing/shadow-acne. We added two simple mechanisms for that: slope bias (during shadow map rendering), and receiver bias (during the shadow-map fetching). The slope bias is directly controllable per light, and is proportional to the constant bias. With these two parameters in hand (constant bias + slope bias), you should be able to reduce some of the artifacts mentioned in this thread. Receiver bias is setup globally per light types. All types of bias (constant, slope, and receiver) are controllable through global variable per type of lights. These shadow improvements are in final stage of development and will be released with UE4.23

The well-criticized sphere should now appear smoother:

This should also allow to bring a bit more contact without introducing acne (with manual tweaking).

Please bare in mind, these improvements will help but won't solve all your shadowing issues. Shadow maps are hard unfortunately.

Thanks for taking the time to reply and great job on the improvements.

[muchcharles]

I think this is the commit:

https://github.com/EpicGames/UnrealE...d6b0f156cf4df2

[spacegojira]

I am sorry if I misunderstand something, but is this fix going to help with completely dynamic lighting or is it only viable for lightmaps? The explanation of ShadowMaps in the Wiki isn't very clear on this.

[StrangerGwenn]

This is unrelated to lightmaps - dynamic lighting only.

[Chosker]

seriously thanks for finally looking into this.
it's been long due but it's highly appreciated that you don't totally forget about standard techniques in favor of the not-yet-standard future ones (raytracing)

[Deathrey]

Well, good to see it being addressed. While the changes are not finalized, I'll leave a bit of a feedback.

The biasing is flawless now, but another related issue, discussed in the very same thread is still here, which is inability to adjust biasing for each cascade in directional light CSMs individually.

Without it, there is still a problem, where one cascade is underbiasing while the next one overbiases, resulting in noticeable transition between cascades, which is greatly exaggerated by receiver bias.

Finding sweet spot, where transitions are less noticeable, while also getting rid of most acne is still hard to impossible.

I think considering letting user set up biases per split would be an overall good move. @Charles.D2
Adding to that, It would be interesting to know just for the sake of satisfying curiosity, why light dot vertex normal is used for slope, instead of SlopeScaledDepthBias. I mean technically, it would break biasing to some degree on anything with edited normals (eg. quite often, foliage).

[Krzysztof.N]

I think considering letting user set up biases per split would be an overall good move

UE4 adjusts depth bias automatically per cascade, based on texel ratio between cascades. Setting manually bias per cascade may be a bit too complex, maybe something like cascade bias "bias" would be easier to set. Anyway, can you point as to problematic cases in this thread?

Adding to that, It would be interesting to know just for the sake of satisfying curiosity, why light dot vertex normal is used for slope, instead of SlopeScaledDepthBias. I mean technically, it would break biasing to some degree on anything with edited normals (eg. quite often, foliage).

Yes, but depth bias render state is a bit problematic, as it's included inside a PSO and would multiply number of existing PSOs by number of different bias settings. It's a good choice for a single game engine where one can hardcode biases, but in case of UE4 with its flexibility - bias per light, multiple shadow shaders, material graph etc. this can lead to issues with too many PSOs.

[Kalle_H]

It would be interesting to know just for the sake of satisfying curiosity, why light dot vertex normal is used for slope, instead of SlopeScaledDepthBias. I mean technically, it would break biasing to some degree on anything with edited normals (eg. quite often, foliage).

Could that be fixed by calculating geometric normal using DDX/DDY and only use vertex normal when that fails.

[Deathrey]

Yes, but depth bias render state is a bit problematic, as it's included inside a PSO and would multiply number of existing PSOs by number of different bias settings. It's a good choice for a single game engine where one can hardcode biases, but in case of UE4 with its flexibility - bias per light, multiple shadow shaders, material graph etc. this can lead to issues with too many PSOs.

Cheers for clarifying the reasoning.

UE4 adjusts depth bias automatically per cascade, based on texel ratio between cascades. Setting manually bias per cascade may be a bit too complex, maybe something like cascade bias "bias" would be easier to set. Anyway, can you point as to problematic cases in this thread?

One
Two
Three

Closest cascade is underbiasing, while furthest is overbiasing. Applying enough bias to get rid of acne in closest cascade overbiases furthest cascade.

There is also a scene and setup dependent factor in it, since when kernel becomes larger than most geometrical details, you can naturally get off with less bias.

Maybe exposing scaling factor instead of fully independent per cascade bias would be better ?

Could that be fixed by calculating geometric normal using DDX/DDY and only use vertex normal when that fails.

I don't think this is viable for depth rendering at all.
Biasing errors on geometry discontinuities, worse overall slope representation and a strain on pixel shader, that should not be there for depth rendering.