Announcement

Collapse
No announcement yet.

Dynamic shadows artifacts

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

    Originally posted by DamirH View Post
    Well I think this is a bigger and more advantageous change than TAA sharpening.
    Oh surely is, I just commented on it, because it was also something that took time to consider, now probably it will be a rework if not dropped at all, since upsampling would produce similar if not almost like the sharpening.

    Now lets get back to the focus of the thread.
    Nilson Lima
    Technical Director @ Rigel Studios Ltda - twitter: @RigelStudios
    Join us at Discord: https://discord.gg/FUwTvzr

    UE4 Marketplace: Cloudscape Seasons
    supporting: Community FREE Ocean plugin

    Comment


      Originally posted by Kalle_H View Post

      Here you go.

      Sobol:

      Spiral:
      Kalle_H,

      Which is the angle for the light are you using into this scene? Im sure you posted something, but I was unable to find.
      Also, very little angles which would make the shadows even more elongated, would present the same performance? So, both methods are equivalent in performance regardless scene differences, right?
      Nilson Lima
      Technical Director @ Rigel Studios Ltda - twitter: @RigelStudios
      Join us at Discord: https://discord.gg/FUwTvzr

      UE4 Marketplace: Cloudscape Seasons
      supporting: Community FREE Ocean plugin

      Comment


        Originally posted by NilsonLima View Post

        Kalle_H,

        Which is the angle for the light are you using into this scene? Im sure you posted something, but I was unable to find.
        Also, very little angles which would make the shadows even more elongated, would present the same performance? So, both methods are equivalent in performance regardless scene differences, right?
        I use default angle of 1 degree. When angle goes up both methods start to hurt by cache misses quite equally. But I barely see any difference between 0 and degrees.

        I am not really sure should I bundle all my edits to single PR or try to split them small incremental improvements.

        Comment


          Originally posted by Kalle-H View Post

          I use default angle of 1 degree. When angle goes up both methods start to hurt by cache misses quite equally. But I barely see any difference between 0 and degrees.

          I am not really sure should I bundle all my edits to single PR or try to split them small incremental improvements.
          I already bought the idea, seens great. One unique PR with statistics about gains and pictures for the whole set of optimizations is more likely for them to take action faster than separate. Also simplifies the amount of testing they will do.
          Nilson Lima
          Technical Director @ Rigel Studios Ltda - twitter: @RigelStudios
          Join us at Discord: https://discord.gg/FUwTvzr

          UE4 Marketplace: Cloudscape Seasons
          supporting: Community FREE Ocean plugin

          Comment


            Originally posted by Kalle-H View Post
            Found easy fix for this.
            Code:
            FScreenSpaceData ScreenSpaceData = GetScreenSpaceData(ScreenUV);
            float NoL = saturate(dot(ScreenSpaceData.GBuffer.WorldNormal, DeferredLightUniforms.NormalizedLightDirection));
            Settings.TransitionScale = SoftTransitionScale.z * lerp(0.1, 1.0, NoL);
            https://github.com/EpicGames/UnrealEngine/pull/4503Click image for larger version Name:	ScreenShot00032.png Views:	1 Size:	128.2 KB ID:	1429573
            Click image for larger version Name:	ScreenShot00033.png Views:	1 Size:	129.2 KB ID:	1429572
            Hi,

            I tried your code and I see zero difference
            I modified the shader file and pressed Ctrl+Shift+. and the log reports some shaders that changed and re-compiled
            yet the result is exactly the same
            this is how it looks on a scene with a sphere (default scale) and a DirectionalLight (default settings, just set to movable)



            am I missing something here?
            Follow me on Twitter!
            Developer of Elium - Prison Escape
            Local Image-Based Lighting for UE4

            Comment


              Chosker: Do some testing that shader edits are really affecting. Like setting shadows to 0 or something.

              Comment


                setting Shadow = 0; in line 191 makes the entire world shadowed, so the shader edits are really affecting (and I'm really in the correct shader define for PCSS)
                but your changes still make no difference at all


                This is the default unreal sphere scaled to 50, and a directional light with all properties as default but set to movable

                Click image for larger version  Name:	spherescale50.jpg Views:	1 Size:	16.5 KB ID:	1435926
                Last edited by Chosker; 02-28-2018, 07:18 AM.
                Follow me on Twitter!
                Developer of Elium - Prison Escape
                Local Image-Based Lighting for UE4

                Comment


                  Chosker Are you using just the PR 4503? Kalle-H is that result only needing the PR 4503, or does it need anything else?
                  Nilson Lima
                  Technical Director @ Rigel Studios Ltda - twitter: @RigelStudios
                  Join us at Discord: https://discord.gg/FUwTvzr

                  UE4 Marketplace: Cloudscape Seasons
                  supporting: Community FREE Ocean plugin

                  Comment


                    Kalle-H
                    I'm not sure if you should merge everything into one large pull request or separate minor changes. Epic had plans for further PCSS improvements, so they might or might not have something planned/drafted already. At least judging from trello. I'd probably separate performance-only changes from large alterations, like ditching sobol.

                    @Chosker
                    PR 4503 by Kalle-H reduces soft transition threshold depending on the angle between surface and light and pushes acne a bit further into the shadow, but will not cure it completely for large objects. We had a bit of a discussion about this in git comments.

                    Comment


                      [edit]
                      nevermind, I had failed to integrate the PR properly
                      I'll report later with results


                      [edit]

                      ok with a proper implementation I see the result. but yeah Deathrey it's only really relevant for small objects.
                      sadly it doesn't help with what I'm working on (large-scale city builder)
                      Last edited by Chosker; 02-28-2018, 08:50 AM.
                      Follow me on Twitter!
                      Developer of Elium - Prison Escape
                      Local Image-Based Lighting for UE4

                      Comment


                        Results are not 100% same but it's hard to see the difference with that image. My screenshot was using default sphere with scale of 1. Only thing that is different is that my test screenshot was not from PCSS but the default path.
                        Deathray also tested the PR and noticed that it's surely help but does not fix the whole problem.

                        I am currently mainly testing with PCSS shadows and I just ditched DepthBiasPlaneNormal slope biasing because that caused some very nasty visible triangulation and caused severe shadow bleeding. It's also not free. For me sample counts.(40 blocker search and 32 pcf) it's add 182 assembly instructions. From 0.63ms to 0.58ms. Almost 10% of ShadowProjection time.
                        Random rotation is now using 4x4 ordered dithering.

                        There is screenshot of self shadows from real game object. Object size is 2.6 x 2.4 x 5.6m and it's about 7k triangles.Click image for larger version

Name:	ScreenShot00351.png
Views:	70
Size:	579.0 KB
ID:	1435965
                        Click image for larger version

Name:	ScreenShot00352.png
Views:	52
Size:	526.9 KB
ID:	1435966

                        Comment


                          Originally posted by Kalle-H View Post
                          I just ditched DepthBiasPlaneNormal slope biasing because that caused some very nasty visible triangulation and caused severe shadow bleeding.
                          I am totally with you on this. Despite mentioned in almost every paper out there as magical adaptive bias, it breaks on every edge and near terminator line. For large kernels assuming whole surface plannar is still bad, and perhaps as a part of research, it might be feasible to precalculate the bias for several (4 ? ) control points and interpolate between them when comparing samples. But at this point it becomes so bulky, that nobody would ever dare even to think of using it in production. So adaptive RPDB Can be used only in conjunction with other biasing techniques, not as substitute.

                          The issue still stands firm though, and for PCSS with large penumbra sizes, biasing is even more important than for conventional PCF.

                          Comment


                            Originally posted by Deathrey View Post

                            I am totally with you on this. Despite mentioned in almost every paper out there as magical adaptive bias, it breaks on every edge and near terminator line. For large kernels assuming whole surface plannar is still bad, and perhaps as a part of research, it might be feasible to precalculate the bias for several (4 ? ) control points and interpolate between them when comparing samples. But at this point it becomes so bulky, that nobody would ever dare even to think of using it in production. So adaptive RPDB Can be used only in conjunction with other biasing techniques, not as substitute.

                            The issue still stands firm though, and for PCSS with large penumbra sizes, biasing is even more important than for conventional PCF.
                            Ideally Blocker search and pcf filter would need to use cone tracing. I just can't get it to work. Idea is to only account blockers that are actually blocking current pixel and then calculate what percentage of light circle area those blockers are blocking. Currently all blocking samples are weighted equally in visibility calculations but samples that are near in depth cover more area so they should have bigger weight. I think if I can implement this then biasing shouldn't be that big issue.

                            Comment


                              Code:
                              #if SPOT_LIGHT_PCSS
                              {
                                   float CotanOuterCone = DeferredLightUniforms.SpotAngles.x * rsqrt(1. - DeferredLightUniforms.SpotAngles.x * DeferredLightUniforms.SpotAngles.x);
                                  float WorldLightDistance = dot(DeferredLightUniforms.NormalizedLightDirection, DeferredLightUniforms.LightPosition - WorldPosition);
                                   Settings.ProjectedSourceRadius = 0.5 * DeferredLightUniforms.SourceRadius * CotanOuterCone / WorldLightDistance;
                                   Settings.TanLightSourceAngle = 0;
                              }
                              #endif
                              Can someone confirm that extra scaling with 0.5 is wrong? It's seems that code is just confusing diameter and radius. Also CotanOuterCone could be precalculated.

                              Comment


                                Originally posted by Kalle_H View Post
                                Code:
                                #if SPOT_LIGHT_PCSS
                                {
                                float CotanOuterCone = DeferredLightUniforms.SpotAngles.x * rsqrt(1. - DeferredLightUniforms.SpotAngles.x * DeferredLightUniforms.SpotAngles.x);
                                float WorldLightDistance = dot(DeferredLightUniforms.NormalizedLightDirection, DeferredLightUniforms.LightPosition - WorldPosition);
                                Settings.ProjectedSourceRadius = 0.5 * DeferredLightUniforms.SourceRadius * CotanOuterCone / WorldLightDistance;
                                Settings.TanLightSourceAngle = 0;
                                }
                                #endif
                                Can someone confirm that extra scaling with 0.5 is wrong? It's seems that code is just confusing diameter and radius. Also CotanOuterCone could be precalculated.
                                I think the intention is to downscale the CotanOuterCone to a radius form instead of diameter (CotanOuterCone == diameter right?) and multiplication will have precedence over the division and the result must be in radius.

                                PS: thats a hell of a place to put some comments in code >.<
                                Last edited by NilsonLima; 03-01-2018, 10:34 AM.
                                Nilson Lima
                                Technical Director @ Rigel Studios Ltda - twitter: @RigelStudios
                                Join us at Discord: https://discord.gg/FUwTvzr

                                UE4 Marketplace: Cloudscape Seasons
                                supporting: Community FREE Ocean plugin

                                Comment

                                Working...
                                X