[USER=“4894”]Tim Hobson[/USER]
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
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?
Hey. I’m facing the exactly same issue as **Rawalanche **and can’t get rid of black color below the horizon. There’s an exp. heigh fog actor in the Archviz example that fills up the below horizon area. Its color responds to the color of the sky and gets completely black during the ‘night time’. That’s cool.
However I’am unable to mimic this behaviour in an empty project. Create an empty Map, place a Sun and Sky Actor (leave Height Fog Contribution set to default 1.0 for the SkyAtmosphere Component) and an Exponential Height Fog Actor into it and enable ‘Support Sky Atmosphere Affecting Height Fog’ in Project Settings. The fog retains its bluish inscattering color and totally ignores the sky color.
I’m pretty sure I’m just missing something banal but can’t figure out what that might be…
Is there a way of changing the sun size? I tryied adding an atmopheric fog and reducing “sun disc scale” but it does absolutly nothing. It’s a big problem when you use high bloom values as it makes the sun way too big.
@Haoris
Its based on the “Source Angle” in the directional light.
You can think of it as how close/big the sun is in the sky, the greater the number the larger the apparent area the light is coming from
Is there a way to get some hold of the materials / BP’s for the clouds (as demonstrated in <link> (and <link>)? In the 4.24 release I can find the “M_SkyTimeOfDay” material but it has a heave impact on performance so we’re trying to get clouds that are performing decently…
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.
I did. It allows me to have extremely complicated set of over 40 parameters to control the color below horizon in a way which makes it still almost impossible to set up a specific color. It’s a model for approximation of a fog fading in a distance. It’s not a model to specify solid shaded surface color. I go into great length describing why that is not a solution on the previous page.
I second this as well. Having the Sky Atmosphere renderer actually attached to the scene component gives it inherent positioning properties, such as being able to be properly positioned when rebasing the world origin. I may play with the code later and see if I can get it working.
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: Imgur: The magic of the Internet and this is the issue with skylight: Imgur: The magic of the Internet
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.
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:
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!:
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:
Trying to add custom background as horizon results in precision issues.
Trying to use the new Sky Material mode to customize sky model to include color below horizon results in extremely bad performance.
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:
^ 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…
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?
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 Sky Atmosphere Component Properties in Unreal Engine | Unreal Engine 5.1 Documentation
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 SkyAtmosphere and World Rebasing - Rendering - Epic Developer Community Forums
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:
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:
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.
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.
