Announcement

Collapse
No announcement yet.

New Sky/Atmosphere model in 4.24

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

    #31
    I'm trying to get a skin shader working with the new light model, but I find that unless I disable skylight, the skin and eyes look "milky". Has anyone else eperienced this, and / or know what I should be doing to prevent it? shader: https://imgur.com/a/4KACT5d and this is the issue with skylight: https://imgur.com/a/zV54DRr

    Comment


      #32
      I have a number of questions about the SunSky and the changes I have to make to use it. First, is there a technical guide on how to use it?

      Second, my particles systems now are black. I had a blood spray emitter upon hit that was red, Now it is black...

      thoughts?

      Originally posted by pf_breton View Post
      Hi,

      I need to give you some background on this prior to answer individual points below.

      The SunSky positionner is a plugin that was added in Unreal in 4.21. It lacked of proper shading technology (physical sky). In this release, this has been added to it in the form of extra components that can be used individually. The main use case is for Architecture where maintaining a notion of physically correct values for lighting, camera EVs and material parameters is a recommended practice.

      From the comments i read below it seems that you are starting from a project template that isn't right for that type of use case and hit all the roadblocks that are solved by the Architectural Visualization project templates. I'll get to that below.



      In project settings, enable the following options:

      Enable Extend default luminance range in Auto Exposure = true
      Apply Pre-Exposure before writing to scene color = true

      That will allow lights to go from low to very high ranges.



      The lower part of the sky hemisphere is usually done by an exponential height fog that should be added separately to the scene which isn't part of the Sun Positioner plugin.



      This is not the Hosek & Wilkie but still physical. Its using a derived version of the Bruneton sky which has several advantages over the Hosek & Wilkie. Its not something that was defined arbitrarily as you imply. The parameters are different (and more extensive) but it doesn't means is physically incorrect because of that.



      We have hidden the Sun Positionner plugin in Unreal by default but enabled it when using the project templates dedicated to Architectural Vis. However you don't need to use that plugin to use the new Sky shader. Just add a Sky Atmosphere actor from the Visual Effects category and you have it.

      Comment


        #33
        I found that using Apply Pre-Exposure before writing to scene color = true, creates problems with sub-surface scattering materials, like skin and eye materials. And that this setting should be turned off.

        You can test this with the "DigitalHuman" sample project. I found that the skylight is causing this "milky" effect, however I find skylight important and so, turning off the above setting worked best. I took the Digital Human project and got rid of everything except the bust model, and added the SunSky blueprint to the scene, default settings. Had to get rid of the post processing material as well, and re-introduce a new one with default settings, just to isolate the issue as much as I could.

        Originally posted by pf_breton View Post
        Hi,

        I need to give you some background on this prior to answer individual points below.

        The SunSky positionner is a plugin that was added in Unreal in 4.21. It lacked of proper shading technology (physical sky). In this release, this has been added to it in the form of extra components that can be used individually. The main use case is for Architecture where maintaining a notion of physically correct values for lighting, camera EVs and material parameters is a recommended practice.

        From the comments i read below it seems that you are starting from a project template that isn't right for that type of use case and hit all the roadblocks that are solved by the Architectural Visualization project templates. I'll get to that below.



        In project settings, enable the following options:

        Enable Extend default luminance range in Auto Exposure = true
        Apply Pre-Exposure before writing to scene color = true

        That will allow lights to go from low to very high ranges.



        The lower part of the sky hemisphere is usually done by an exponential height fog that should be added separately to the scene which isn't part of the Sun Positioner plugin.



        This is not the Hosek & Wilkie but still physical. Its using a derived version of the Bruneton sky which has several advantages over the Hosek & Wilkie. Its not something that was defined arbitrarily as you imply. The parameters are different (and more extensive) but it doesn't means is physically incorrect because of that.



        We have hidden the Sun Positionner plugin in Unreal by default but enabled it when using the project templates dedicated to Architectural Vis. However you don't need to use that plugin to use the new Sky shader. Just add a Sky Atmosphere actor from the Visual Effects category and you have it.
        Last edited by vbs; 12-20-2019, 03:41 PM.

        Comment


          #34
          I was surprised to find that this Sky Atmosphere doesnt support world rebasing, is there future plans to implement this?

          Comment


            #35
            Alright, so the new Sky Atmosphere woes continue. Exactly the issues I was saying were going to happen happened. Atmosphere model with pick black below the horizon is completely unusable.

            If you try to create your own ground using a shader, you will run into a geometry precision issues along the horizon, exactly as I predicted:
            Click image for larger version  Name:	Horizon.jpg Views:	0 Size:	110.4 KB ID:	1704930
            This is just with a simple shader for material below the horizon:
            Click image for larger version  Name:	Shader.jpg Views:	0 Size:	92.9 KB ID:	1704931
            Now the idea probably is to use new Sky Material nodes, but those are not usable either, due to extreme overhead they cause in HZB. I mean check this out, the time of day template knocks even the GTX1080Ti below the max framerate in completely empty level!:
            Click image for larger version  Name:	HZB.jpg Views:	0 Size:	162.5 KB ID:	1704932
            In fact, even using just a single sky material node has extreme impact on performance:
            Click image for larger version  Name:	skymat.jpg Views:	0 Size:	69.3 KB ID:	1704933
            Click image for larger version  Name:	SkyMatPerf.jpg Views:	0 Size:	150.5 KB ID:	1704934
            And this is with the SkyDomeMesh object disabled in the time of day template:
            Click image for larger version  Name:	meshOff.jpg Views:	0 Size:	170.1 KB ID:	1704935

            So in a nutshell, there's no reasonable way to use the new sky model. It's useless with pitch black below the horizon, and:
            1. Trying to add custom background as horizon results in precision issues.
            2. Trying to use the new Sky Material mode to customize sky model to include color below horizon results in extremely bad performance.
            3. Trying to utilize height fog to cover the are below the horizon as suggested by pf_breton above changes the look of the atmosphere to such a degree using sky atmosphere becomes completely pointless:
            Click image for larger version  Name:	heightfog.jpg Views:	0 Size:	119.7 KB ID:	1704936^ This is how much inclusion of height fog changes appearance of the sky model. What's the point of using physically based sky model if the "suggested way" to make the ground non black is compromising the model to this kind of degree is beyond me...
            Last edited by Rawalanche; 01-06-2020, 06:55 AM.
            https://www.artstation.com/artist/rawalanche

            Comment


              #36
              Originally posted by pf_breton View Post
              In project settings, enable the following options:

              Enable Extend default luminance range in Auto Exposure = true
              Apply Pre-Exposure before writing to scene color = true

              That will allow lights to go from low to very high ranges.
              What if we don't want to use auto exposure (for VR for example)?

              What are the correct settings to use then? We haven't found any good ones yet with this new feature.

              Also, I've read that the sun is 32000 lux, but previously, setting 32000 lux on a directional light didn't have good results. I don't see a lux value for this new sun. If it is "physically correct", does it also have a physically correct lux?

              Comment


                #37
                Thanks everyone for opinions and feedback. I will try to answer by focusing on a few topics.

                Height-fog lighting: this feature is very basic and only here to bridge a gap if anyone still want to use the height fog. It is just an option and of course it will change the look, just up to you to use it or not. The Mie scattering component of the atmosphere is already a height fog by itself (and a better one because it does self shadow and reacts to the other participating media properties globally).

                Color on the ground: the SkyAtmosphere component is an atmosphere rendering component. Not a planet rendering component. As of today there is no plan to add virtual planet ground color as a hard-coded feature. As said before, the best option for anyone is to add a planet mesh for space view or a landscape for ground world view (as in Fortnite).
                I agree with Teriander : when using a physically based representation of an atmosphere, you need to work with it and populate your world accordingly.
                For anything else, you can use the Sky shader as in the TimeOfDay_default level sky dome shader template available in 4.24. There you can add virtual planet colorization yourself and even composite it the way you want with the aerial perspective, sun disk, etc. I hope you will be able to do what you are after with that.
                The reference documentation for those nodes is https://docs.unrealengine.com/en-US/...nce/index.html

                Performance issues: thanks for pointing this one out! However, I am afraid those are the GPU timer reporting wrong values. In my case I am seeing a cost of 15ms in another timer on a 2080. When doing a GPU capture, this cost is nowhere to be seen. Also we have shipped this tech in Fortnite from PC to mobile using the sky dome shader and such performance would have been unacceptable. I will discuss with the team here see what is happening with the timers.
                FYI: the sky dome is rendered as part of the BasePass so that is where you should see the cost going.
                ==> In summary: it is safe for you to use the sky dome shader, it is fast. Sorry for the timer reporting wrong values (that is an orthogonal issue). In the meantime, try using the performance vis tool [CTRL+SHIFT+,] it seems to not be affected by this issue.

                Rebasing: agreed, this is useful and it is on the TODO list to be fixed (I already have a CL). Not ETA but hopefully sooner rather than later. When this is supported, you will also be able to lower the planet and have scattering happening below the level 0 if that is needed (behavior of previous AtmosphericFog). Please see this post https://forums.unrealengine.com/deve...world-rebasing

                Exposure: please see https://forums.unrealengine.com/deve...ystem-exposure

                Keep in mind that this is the first version of an in development tech...
                Thanks

                Comment


                  #38
                  Originally posted by SebHillaire View Post
                  Color on the ground: the SkyAtmosphere component is an atmosphere rendering component. Not a planet rendering component. As of today there is no plan to add virtual planet ground color as a hard-coded feature. As said before, the best option for anyone is to add a planet mesh for space view or a landscape for ground world view (as in Fortnite).
                  I agree with Teriander : when using a physically based representation of an atmosphere, you need to work with it and populate your world accordingly.
                  For anything else, you can use the Sky shader as in the TimeOfDay_default level sky dome shader template available in 4.24. There you can add virtual planet colorization yourself and even composite it the way you want with the aerial perspective, sun disk, etc. I hope you will be able to do what you are after with that.
                  The reference documentation for those nodes is https://docs.unrealengine.com/en-US/...nce/index.html

                  Performance issues: thanks for pointing this one out! However, I am afraid those are the GPU timer reporting wrong values. In my case I am seeing a cost of 15ms in another timer on a 2080. When doing a GPU capture, this cost is nowhere to be seen. Also we have shipped this tech in Fortnite from PC to mobile using the sky dome shader and such performance would have been unacceptable. I will discuss with the team here see what is happening with the timers.
                  FYI: the sky dome is rendered as part of the BasePass so that is where you should see the cost going.
                  ==> In summary: it is safe for you to use the sky dome shader, it is fast. Sorry for the timer reporting wrong values (that is an orthogonal issue). In the meantime, try using the performance vis tool [CTRL+SHIFT+,] it seems to not be affected by this issue.

                  Thanks
                  Hi,

                  I can assure you those numbers are not wrong reporting. The presense of the TimeOfDay sky dome reduces performance in an empty scene to just 50-ish FPS when fullscreened on 1440p screen on GTX1080Ti:
                  Click image for larger version  Name:	editor.jpg Views:	0 Size:	67.0 KB ID:	1705826
                  And worse yet, in standalone build, in fullscreen, it goes as low as 35FPS... Yes, on GTX1080Ti in completely empty level:
                  Click image for larger version  Name:	standalone.jpg Views:	0 Size:	75.4 KB ID:	1705827 That is not wrong reporting. I can clearly feel the super low framerate aside from seeing the low FPS counter.

                  I also could not see the same cost in performance vis tool, but I still experience it both in editor and in build. Strangely, this time it's not HZB though:
                  Click image for larger version

Name:	gpucost.jpg
Views:	489
Size:	108.2 KB
ID:	1705830

                  As for the determination to not have anything below the horizon. Why does the old Atmosphere Fog actor have regular color below horizon?
                  Click image for larger version  Name:	atmospherefog.jpg Views:	0 Size:	133.8 KB ID:	1705828 The new Atmosphere Sky is supposed to simulate the exact same thing, just more accurately. What if I for example would want to simulate a gas giant planet, with no solid surface? The new Sky Atmosphere actor just creates hollow cutout for a solid planet surface which may, or may not be there. There's absolutely nothing physically based about that. It's not an accuracy decision, it's a completely arbitrary decision which is now severely affecting usability of the new Atmosphere Sky in a negative way. If it behaved the same way as old Atmosphere Fog actor, nothing would change. Users would still be able to put in their landscape, or their geometry sphere for a planet surface, but if there wasn't one, the result would not be a pitch black nothingness, which is arguably a lot less physically accurate then continuing the gaseous atmosphere volume all the way throughout the atmosphere.
                  Last edited by Rawalanche; 01-08-2020, 06:12 AM.
                  https://www.artstation.com/artist/rawalanche

                  Comment


                    #39
                    Ok There was indeed a performance issue (only in editor, not visible in GPU perf capture so must be CPU, that is why timers might have been weird also).
                    Explanation: when enabling a SkyDome with a sky shader, we render in the background some editor text to warn artists when the sky dome is not covering/initializing the color buffer. This text is rendered using Canva and was costing more than expected for some reason (investigation will be conducted). The fix is in (not using the canvas) but it will only be available in 4.25 because it involves shader changes which are now prohibited in 4.24 updates.
                    However, the next 4.24 update will have a new command I have added to disable that text rendering pass: Use r.SkyAtmosphere.DebugText 0. That should help in the meantime.
                    Thanks for your report!

                    Planet: The decision was made to simulate telluric planets with a ground that cast shadow in the atmosphere (visual feature deemed important). That is why we have the ground radius for a virtual planet. Not a gaseous planet. Also, even if we add a color to the ground that will still create a sharp edge at the horizon (because you are close to the ground).
                    The goal was not to reproduce what the AtmosphericFog was doing because it has many issues, fudge factors and more (for instance the camera was forced high up in the air).

                    That being said, in 4.25 you will be able to transform the Atmosphere around the component and position the planet anywhere. Then you can use the current component properties to reduce its radius and increase the participating media density to simulate a gaseous planet bottom with smooth horizon. That should do what you want.

                    Comment


                      #40
                      Originally posted by SebHillaire View Post
                      That being said, in 4.25 you will be able to transform the Atmosphere around the component and position the planet anywhere.
                      Very excited for this

                      Comment


                        #41
                        Originally posted by GTJC View Post
                        In my example Earth is at the Origin in 4.24 with the Sky Atmosphere. Moon in front of Earth and the atmosphere renders in front of the Moon.
                        Wondering if I'm missing something.
                        Hi Seb,
                        Just curious if you know of something I'm missing with the atmosphere of Earth rendering in front of the Moon?

                        Thank you,
                        John

                        Comment


                          #42
                          Originally posted by SebHillaire View Post
                          Ok There was indeed a performance issue (only in editor, not visible in GPU perf capture so must be CPU, that is why timers might have been weird also).
                          Explanation: when enabling a SkyDome with a sky shader, we render in the background some editor text to warn artists when the sky dome is not covering/initializing the color buffer. This text is rendered using Canva and was costing more than expected for some reason (investigation will be conducted). The fix is in (not using the canvas) but it will only be available in 4.25 because it involves shader changes which are now prohibited in 4.24 updates.
                          However, the next 4.24 update will have a new command I have added to disable that text rendering pass: Use r.SkyAtmosphere.DebugText 0. That should help in the meantime.
                          Thanks for your report!

                          Planet: The decision was made to simulate telluric planets with a ground that cast shadow in the atmosphere (visual feature deemed important). That is why we have the ground radius for a virtual planet. Not a gaseous planet. Also, even if we add a color to the ground that will still create a sharp edge at the horizon (because you are close to the ground).
                          The goal was not to reproduce what the AtmosphericFog was doing because it has many issues, fudge factors and more (for instance the camera was forced high up in the air).

                          That being said, in 4.25 you will be able to transform the Atmosphere around the component and position the planet anywhere. Then you can use the current component properties to reduce its radius and increase the participating media density to simulate a gaseous planet bottom with smooth horizon. That should do what you want.
                          Hey Seb,

                          It seems like I can't get SkyAtmosphere to respect the world geometry, it just renders the horizon line on top of everything:

                          Click image for larger version

Name:	SkyAtmosphere.jpg
Views:	433
Size:	233.3 KB
ID:	1707883

                          Compare this to AtmosphericFog which smoothly cascades over the mountains (aside from the wonky colors):

                          Click image for larger version

Name:	AtmosphericFog.jpg
Views:	420
Size:	227.7 KB
ID:	1707884

                          Any ideas?

                          Thanks!

                          Jesse

                          Comment


                            #43
                            GTJC Sorry I missed it. It seems that there was a bug in the atmosphere composition shader for space view. I fixed it this morning and it will be available in 4.25. Thanks for your feedback!
                            (if you have source code and can build the editor locally, here is the CL you need to integrate https://github.com/EpicGames/UnrealE...6218e95cc3a651)

                            jrapczak Not sure. It seems that this could be due to several things. Is it with all the default parameters? What is the scale of your world? Some guesses:
                            - Your world is under level 0? that will not help unfortunately. For now, put it at a higher position along Z or wait for the transform update coming in 4.25.
                            - Are you using a strong atmospheric distance scale?

                            Comment


                              #44
                              Originally posted by SebHillaire View Post
                              GTJC Sorry I missed it. It seems that there was a bug in the atmosphere composition shader for space view. I fixed it this morning and it will be available in 4.25. Thanks for your feedback!
                              (if you have source code and can build the editor locally, here is the CL you need to integrate https://github.com/EpicGames/UnrealE...6218e95cc3a651)

                              jrapczak Not sure. It seems that this could be due to several things. Is it with all the default parameters? What is the scale of your world? Some guesses:
                              - Your world is under level 0? that will not help unfortunately. For now, put it at a higher position along Z or wait for the transform update coming in 4.25.
                              - Are you using a strong atmospheric distance scale?
                              Ah, I'm sure it's that parts of the world are below 0. Is the transform update something I can grab from git or Perforce in the mean time?

                              Comment


                                #45
                                jrapczak If you want it, I would recommend you should grab those CLs (in order of integration):

                                1- Transform CL https://github.com/EpicGames/UnrealE...2f3f186ff625d5
                                2- Some renaming https://github.com/EpicGames/UnrealE...0df3eb90db078b
                                3- Some bug fixing https://github.com/EpicGames/UnrealE...795da3afb6d3f7

                                Note: I may have dome other work in between those CLs...

                                Comment

                                Working...
                                X