Announcement

Collapse
No announcement yet.

Dynamic shadows artifacts

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • replied
    Originally posted by II_ADN_II View Post
    Any news on fixing the current implementation of the shadow slope bias?
    Not yet, I am waiting for the full 4.23 release to see if anything new has been done to solve this problem. Fingers crossed lol

    Leave a comment:


  • replied
    Any news on fixing the current implementation of the shadow slope bias?

    Leave a comment:


  • replied
    Originally posted by II_ADN_II View Post
    Testing the slope solution in the 23 preview, and the results are very inconsistent. The slope bias helps a little, but it needs a huge value for close up distances, and this makes it broken in the distance. Looks like the bias is waay strong in distant cascades.

    Overall doesnt do much to me, when I solve the acne issue in close ups it broke in the distance and viceversa. Anyone has tested it? What are the better values?
    Ah ****, I was already expecting this. I am waiting for the full 2.23 release to see if the dynamic shadow issues have at least partially been fixed, but it seems it won't..

    Leave a comment:


  • replied
    Testing the slope solution in the 23 preview, and the results are very inconsistent. The slope bias helps a little, but it needs a huge value for close up distances, and this makes it broken in the distance. Looks like the bias is waay strong in distant cascades.

    Overall doesnt do much to me, when I solve the acne issue in close ups it broke in the distance and viceversa. Anyone has tested it? What are the better values?

    Leave a comment:


  • replied
    Originally posted by Deathrey View Post
    Could that be fixed by calculating geometric normal using DDX/DDY and only use vertex normal when that fails.
    DDX/DDY is another alternative. This one would require a beefy fullscreen pass in order to gather at least 5 nearby pixels for normal reconstruction, and still would fail from time to time on some very thin / small geometry / alpha masked fences etc. Also performance overhead would be problematic for certain use cases like VR or mobile and force users to re-tweak bias parameters for those.

    Originally posted by Deathrey View Post
    Thanks, looks like something worth looking into.

    Leave a comment:


  • replied
    Originally posted by Krzysztof.N View Post
    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.



    Originally posted by Krzysztof.N View Post

    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 ?


    Originally posted by Kalle_H View Post

    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.
    Last edited by Deathrey; 05-13-2019, 04:37 AM.

    Leave a comment:


  • replied
    Originally posted by Deathrey View Post
    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.

    Leave a comment:


  • replied
    Originally posted by Deathrey View Post
    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?

    Originally posted by Deathrey View Post
    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.

    Leave a comment:


  • replied
    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).
    Last edited by Deathrey; 05-12-2019, 05:31 AM.

    Leave a comment:


  • replied


    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)

    Leave a comment:


  • replied
    This is unrelated to lightmaps - dynamic lighting only.

    Leave a comment:


  • replied
    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.

    Leave a comment:


  • replied
    I think this is the commit:

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

    Leave a comment:


  • replied
    Originally posted by Charles.D2 View Post
    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.

    Leave a comment:


  • replied
    Originally posted by The_Distiller View Post
    @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.

    Leave a comment:

Working...
X