Announcement

Collapse
No announcement yet.

New Sky/Atmosphere model in 4.24

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

  • replied
    Arkiras Hello
    Yes this is possible to achieve dense height fog without that HeightFog component.See ExpxonentialHeightFog section from https://docs.unrealengine.com/en-US/...ere/index.html

    I prefer to use the sky atmosphere as opposed tot he height fog: more consistent lighting. But it needs a bit of setup because by default this component is made for large scale participating media. This is what you should do:
    • You need first to make sure that r.SkyAtmosphere.AerialPerspective.StartDepth is very small. By default it is 0.1 meaning 100 meters: aerial perspective will never be applied before that. This is done because typically aerial perspective is not super strong and it is a good optimization to skip computation on close up pixels using hardware depth test and depth bounds test.
    • I recommend you play with Mie scattering only. You will need to increase scattering or absorption density to a high value (I was using 20 or more IIRC). Keep in mind that those density can go above the slider range: the sliders are just there to represent typical range but you can go above.
    • If you use the default setup you might want to bring the aerial perspective volume texture world depth from 96km to a range that makes sense for you (maybe 5 km) to get more accuracy from each depth slices (using r.SkyAtmosphere.AerialPerspectiveLUT.Depth 5)
    • optional: you can also reduce the Mie height distribution for the fog to sit closer to the ground.
    • optional: you can also play with aerial perspective scale from the art direction section
    Positioning will become easier when you also get the atmosphere transform in 4.25.

    Leave a comment:


  • replied
    Originally posted by SebHillaire View Post
    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).
    Is it possible to get very dense fog (100m visibility) without the aid of another height fog?

    Even at 700m, objects are still easily visible with mie scattering set to max. Which really doesn't seem like enough for most games in my opinion, where environments are intentionally made more compact than real life

    Leave a comment:


  • replied
    Originally posted by SebHillaire View Post
    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...
    That fixed my issue, thanks again SebHillaire!

    Leave a comment:


  • replied
    Originally posted by SebHillaire View Post
    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...
    Cool just found those in P4. Thank you!!!

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


  • replied
    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:	744
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:	726
Size:	227.7 KB
ID:	1707884

    Any ideas?

    Thanks!

    Jesse

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:

Working...
X