Announcement

Collapse
No announcement yet.

Dynamic shadows artifacts

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

    Originally posted by NilsonLima View Post
    I got to put my hands in several games not developed with UE and checked if this happens or not... Im still playing them... not doing my job as supposed to... but, up to now didn't find the issues in any of them... lol Im losing money here... -_-
    I've tested in Unity and similar artifacts can be seen with low bias settings, I'm not an engine programmer I'm not sure if this is some sort of a limitation somewhere as to how light and shadows affects surfaces in these engines.

    Comment


      Like I posted earlier in the thread:

      Originally posted by IronicParadox View Post
      There is a whole section about screen space PCF ddx/ddy filtering. It also states that it's a pretty complex operation, meaning it has a non-trivial performance cost. Keep in mind that you can quickly google to find more versions and variations of these types of filtering

      https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx

      The problem lies in properly fitting it into the UE rendering path and doing it in a way that minimizes impact on frame time. There is a lot asynchronicity in the rendering engine and I'm pretty sure that plays a lot into the mix as to why they haven't implemented it already. In that article, it even states "Because this technique is computationally complex, it should be used only when a GPU has compute cycles to spare." The problem is that the UE rendering engine is already pretty optimized in filling up empty cycles.

      You'd have a few options to pick from:
      1)Let it lock up GPU to calculate completely and immediately
      2)Mess around with priorities and "spare cycles," so that this filtering would have a higher priority and finish sooner
      3)Let it constantly update over several frames like DFAO

      #3 would be the best trade off between performance vs quality. It would be made to have an iterative approach where it's filter quality starts out course and progresses into finer and finer accuracy. So it might start out looking a tiny bit like the faceting problem and over a couple frames, it would smooth out to look closer to what the soft shadow filtering looks like.

      Comment


        Originally posted by IronicParadox View Post
        Like I posted earlier in the thread:
        And how the hell are we supposed to do that? I am not an engine guru, I am a small indie dev who now can't publish screenshots of his game project because the shadow artifacts make it look like my game is severely broken.

        Seriously, what is Epic doing? Are they too busy counting money from the PUBG influx?

        Comment


          After 11 pages without single reply, coming into the conclusion that this thread doesn't show up for epic staff. Might have to do with their account or forum settings.
          Artstation
          Join the support channel
          Gumroad Store

          Comment


            Originally posted by Maximum-Dev View Post
            After 11 pages without single reply, coming into the conclusion that this thread doesn't show up for epic staff. Might have to do with their account or forum settings.
            Maybe we should make a new one every day until someone accidently clicks on one?

            Comment


              It is my conclusion that on several games, artists are having the issue and are hidding them with props, because it is clear they make an effort to avoid scenes with those angles at terrain, or they change the illumination, so the light source comes from different directions. I took a look on games quite old, but open world like Lineage2 (UE3), Aion (CryEngine), Blande n Soul(UE3), Far Cry (CryEngine and a modified one for later versions).

              I just think, UE could be "the engine" to look for and get rid of this ridiculous artifacts, granting that Env.Artists get less headache trying to workaround with extra work when it would be greatly simplified by just not existing the issue.

              Im sure they see the thread but they can't do much for this right now. It needs a rethink on several engine aspects, involving a lot of people, and a lot of work hours... no budget for it.

              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
                Im sure they see the thread but they can't do much for this right now.
                Surely they'd be able to post that they don't have a solution instead of ignoring the topic?

                Comment


                  We can send private messages for them, they will not ignore a lot of messages with same subject, we just need to agree the subject, content, and the people to address. What you guys think?
                  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 Maximum-Dev View Post
                    After 11 pages without single reply, coming into the conclusion that this thread doesn't show up for epic staff. Might have to do with their account or forum settings.
                    relax, it's only 4 pages if you've set the forum to show 40 posts per page
                    Follow me on Twitter!
                    Developer of Elium - Prison Escape
                    Local Image-Based Lighting for UE4

                    Comment


                      The fix is so obvious that I have no idea what's going on at Epic. Clearly the normals are being calculated using the camera vector when they should be calculated using the perspective matrix.

                      In simple terms, if your camera is orthographic mode facing forwards (direction vector [1,0,0]), then every single pixel also represents a direction of [1,0,0].
                      But if you're in perspective mode with the camera facing forwards, only the pixel in the center is facing [1,0,0]. Other pixels are facing different directions. Like if your V-FOV is 90, the center-right most pixel would be facing [1/root2,1/root2,0] and the center-left most pixel would be facing [1/root2,-1/root2,0]. That's the correct vector to perform the calculations on.

                      For proof just change your view to ortho. The lighting is perfect because the pixel vector is always equal to the camera vector. When you switch to perspective it's all ****ed up. How much more obvious can it be?

                      Comment


                        Originally posted by Ohriginal View Post
                        The fix is so obvious that I have no idea what's going on at Epic. Clearly the normals are being calculated using the camera vector when they should be calculated using the perspective matrix.

                        In simple terms, if your camera is orthographic mode facing forwards (direction vector [1,0,0]), then every single pixel also represents a direction of [1,0,0].
                        But if you're in perspective mode with the camera facing forwards, only the pixel in the center is facing [1,0,0]. Other pixels are facing different directions. Like if your V-FOV is 90, the center-right most pixel would be facing [1/root2,1/root2,0] and the center-left most pixel would be facing [1/root2,-1/root2,0]. That's the correct vector to perform the calculations on.

                        For proof just change your view to ortho. The lighting is perfect because the pixel vector is always equal to the camera vector. When you switch to perspective it's all ****ed up. How much more obvious can it be?
                        As much as one might want it to be so, the cause of the problem is slightly different.

                        Comment


                          Originally posted by Ohriginal View Post
                          The fix is so obvious that I have no idea what's going on at Epic. Clearly the normals are being calculated using the camera vector when they should be calculated using the perspective matrix.

                          In simple terms, if your camera is orthographic mode facing forwards (direction vector [1,0,0]), then every single pixel also represents a direction of [1,0,0].
                          But if you're in perspective mode with the camera facing forwards, only the pixel in the center is facing [1,0,0]. Other pixels are facing different directions. Like if your V-FOV is 90, the center-right most pixel would be facing [1/root2,1/root2,0] and the center-left most pixel would be facing [1/root2,-1/root2,0]. That's the correct vector to perform the calculations on.

                          For proof just change your view to ortho. The lighting is perfect because the pixel vector is always equal to the camera vector. When you switch to perspective it's all ****ed up. How much more obvious can it be?
                          This is caused by shadows. Shadows don't actually work at all for orthographic cameras, so the problem will not appear.

                          Comment


                            Originally posted by NilsonLima View Post
                            Im sure they see the thread but they can't do much for this right now. It needs a rethink on several engine aspects, involving a lot of people, and a lot of work hours... no budget for it.
                            Work hours and budget has nothing to do with such very, very old issues. It's been years. Sometimes all people need is a simple reply letting them know that they at least know the issue exists. That's all. But the silence only results in more duplicate threads and posts by different people.
                            Last edited by Maximum-Dev; 12-19-2017, 04:29 PM.
                            Artstation
                            Join the support channel
                            Gumroad Store

                            Comment


                              if we keep the thread up maybe they'll end up acknowledging it

                              btw I'm sure I saw this very issue in FortniteBR, I just don't have the evidence
                              Follow me on Twitter!
                              Developer of Elium - Prison Escape
                              Local Image-Based Lighting for UE4

                              Comment


                                Originally posted by Chosker View Post
                                if we keep the thread up maybe they'll end up acknowledging it

                                btw I'm sure I saw this very issue in FortniteBR, I just don't have the evidence
                                If I recall correctly, for the cinematic, they had to replace the heads for higher resolution models, because as there were shots very closely to them, it was necessary increase the details and smooth the surface a lot, maybe was just to avoid this issue. Anyway, you can't do that for gameplay with landscapes... and replacing the areas compromised for high resolution props is a pain...

                                Im not confident on a reaction to this thread... I wish a lot for some acknowledge
                                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