No announcement yet.

New Sky/Atmosphere model in 4.24

  • Filter
  • Time
  • Show
Clear All
new posts

    Yeah apparently the new sky isn't really integrated with close in fog/volumetric scattering yet, which seems to be targeted for 4.25. So I wouldn't count on getting the new sky to totally work for a bit.


      Hey everyone, (Rawalanche The_Distiller)

      I'm posting on behalf of Sebastien Hillaire since he's had some account trouble we're sorting out. He's our rendering engineer who worked on the SkyAtmosphere system in 4.24.



      Thanks for all the feedback, it is great to see dedicated artists like you all trying the SkyAtmosphere component.
      When the documentation will be available, the parameterisation and a few questions I see here should be clarified. So take it easy in the meantime.

      Still, here are some details:
      - The black area below the horizon: that is not for the sky to simulate/render/fill up. You should put your world/landscape there, use SkyLight bottom color, or control it via skydome shader.
      - Some steps such as "Support XXX" and "Support YYY" are required for performance and for not affecting other projects not using this component (for instance: transparent need to sample the aerial perspective when enabled or to get cheaper height fog).
      - Setup/Use of the properties: all the exposed parameters are required for full control and fine-tuning (and simply to represent an atmosphere). There is a TODO to provide a small blueprint simplified controller similar to Hosek/Wilkie but no ETA.
      - HeightFog: once enabled you need to set the color on height fog (in-scattered and color) to 0 because those are additive and can hide the sun contribution (we keep them here in case you want to tweak things). The sun adds its contribution on top of that. Otherwise, Height fog is not required, you should be able to play with the Mie scattering component and get the same result even better because it will be react to sun light more correctly (to some extent as it will still be limited by the resolution of the aerial perspective LUT). Your choice.
      - Planet rendering and fog pop: yes because by default we use special LUTs that are optimised to render a view on ground level (typical use case). For Game/level using the ground to space view transitions with a planet mesh, you want to disable "r.SkyAtmosphere.AerialPerspectiveLUT.FastApplyOnOpaque 0" (and maybe r.SkyAtmosphere.FastSkyLUT). Then more expensive raymarching will be used for the sky and aerial perspective on opaque, then the transition should be smooth. Sample count is then controlled via r.SkyAtmosphere.XX. Please note that this path not using LUTs has not shipped in any application yet.
      - As of today: limited to only one planet that is not movable

      I hope this helps."

      Tim Hobson | Learning Resources | Epic Games
      UE4 Documentation


        Originally posted by Tim Hobson View Post
        - The black area below the horizon: that is not for the sky to simulate/render/fill up. You should put your world/landscape there, use SkyLight bottom color, or control it via skydome shader.
        This is an inadequate answer unfortunately. Placing geometry large enough to not cause any gap between it at the horizon line can result in level issues and precision errors. Such geometry would have to be way too giant to cover distance approximating infinity. Specifying color below the horizon using SkyLight bottom color is also inadequate for 2 reasons:
        1, This will completely override anything below the horizon, so if there is any kind of height fog atmosphere present, which is affected by scene lighting, such contribution will be missing from the SkyLight capture below the horizon.
        2, This change will only affect illumination from the SkyLight, not actual directly visible representation of the Sky atmosphere.

        Almost all the Sky atmosphere environment models in both realtime (Unity, Godot) and offline (Vray, Corona, Arnold) renderers have non-black representation of the color under the horizon. It's that way for a reason.


          I would like to comment on this....

          First, thank you Tim Hobson and Sebastien Hillaire for greatly improving the environment options available on UE4. I've personal have been using linear workflows, HDRIs, and advanced exposure controls in architectural animations for about 15 years in 3ds Max and I completely understand the challenges. What you've done in 4.24 is a huge improvement and it appears to only be the beginning.

          Second, a lot of people are complaining about black bottoms under the horizon. Welcome to what happens when you have zero geometry in empty space. This is very common especially with professional HDRI scenes without geometry. I've personally create landscapes that expended out to 100 miles of real world accurate geometry. Or created infinity oceans. Although I haven't used the new features allowing you to view your site from space, as the new SunSky system appears to allow you to do, but I imagine the best solutions are having geometry at the edge of your scene to fill in the black area. But what they have done so far deserves a thanks, not criticism.

          Again, thanks Epic!!!
          Eldridge Felder

          Animation/Visualization Manager
          WorthGroup Architects


            Exactly what I worried was going to happen happened. The new atmosphere model made it all the way to the final 4.24 release without ability to specify below horizon color, despite several preview releases. I'd expect this kind of development from Autodesk, but definitely not Epic :/


              Tim Hobson
              Thanks for the info
              Additionally, is it possible to allow this component to work with world origin shifting, Currently the atmosphere gets shifted where ever you rebase the world origin.
              My HLSL knowledge is rudimentary so to my untrained eye this section of code in the shader seems to be responsible for the position of the atmo in the world
              float3 GetCameraPlanetPos()
              { return GetCameraWorldPos()*CM_TO_SKY_UNIT + float3(0, 0, Atmosphere.BottomRadius);
              It seems that its grabing the player cameras position and a fixed world 0 position rather than the components position or a predefined one thus causing it to move back to world 0 when ever you shift the origin.
              I was going to have a crack at changing it or if you have any better suggestions, anyone else know about HLSL and what is available for a actors position in a shader?
              Last edited by Rareden; 12-10-2019, 11:56 PM.