How do I get Mie scattering to produce an effect on the atmosphere visuals? Does the SkyAtmosphere need to have certain settings within specific ranges? I don’t see much in the tooltips about those either, at least in version 4.24.3.
Thanks, I will give it a shot and see how it goes! 
I checked Google as well as the linked PDF, and if I understand it correctly, then when the sun reaches zenith, the ratio of sun to sky illuminance seems to be very close to 5:1. So am I correct to assume that if my sun intensity is set to 5x the intensity of skylight, I should get quite close to average lighting conditions on earth during sunny day?
1 Like
So I tried the tiny planet thick atmosphere trick, but there is just no combination of parameters that makes the horizon and area under it look acceptable. To me it still appears this model works for actual spherical planets, but is not very useful as a means of physical sky system for ground level illumination, at least on its own. Even the time of day level template needs to employ some spherical mesh around the scene to actually render something useful.
In comparison, the legacy atmospheric fog provides nice gradient with non pitch black color under the horizon. If there wasn’t a drawback of sun color not being correctly modified by sun angle, it’d remain a superior solution.
I am aware the new one can be combined with height fog, but that’s just unnecessary waste of performance and additional shader permutation on top.
Yes, the model may have been used in some high profile project, but in most of them people most likely had to spend some extra effort to get it looking right, while physical sky atmosphere model is not something that requires considerable amount of effort to get looking right in most other renderers. Vray, Corona, Blender Cycles, all got new physically based sky models, none of them ends with pitch black below the horizon. Heck even Unity got it right in HDRP.
Unreal currently has this weird schizophrenia, where it has two different models, both of which do some things right while other things wrong. It’s quite unsettling situation.
I’d just use the legacy one but now I am worried it will be removed soon 
Thinking about it more, I think the main issue here is that the new sky atmosphere model has been made with modeling actual spherical planet atmospheres in mind, while most of the game scenarios usually unfold on surfaces of the planets. It’s good to have both options, but the new one defaults to way less common scenario, and therefore adds significant amount of workaround filled efforts to make it look suitable for the more common scenario of modeling atmosphere viewed from planet surface, as well as resulting in poor performance out of the box due to calculating effects invisible from the planet surface, such as shadowing of the atmosphere by the planet itself.
So I think the right solution would be to not deprecate the Atmospheric fog, but update it with the tech from the new Sky Atmosphere, but keep it as the model more suited for modeling sky atmosphere as seen from the planet surface, which includes horizon. That way, we no longer need to employ random, arbitrary, workaround using all sorts of sky sphere background meshes to achieve basic, nice looking results such as:
https://s3.amazonaws.com/markets-rails/uploads/1570818172164-1570818172164.gif
Ability to model planet atmosphere and ability to display non pitch black content under the horizon of the atmosphere model are not two mutually exclusive things.
I’d kinda get it if the model is meant for a research paper, but since this has been added into the engine, then I assume it’s made for us, end users. Therefore user friendly setup (good results out of the box) makes sense.
The AtmosphericFog is also made to render terrestrial planet and has a ground (it is Bruneton model from 2008 but broken). It just put you at a 1km or so altitude without you knowing it and prevents you to go at level 0 while clamping the LUTs.
AtmosphericFog is hacked in some ways and suffers from some artifact due to the luts. It is not possible to also update atmospheric properties at runtime, it can only happen in editor (could be implemented and I did it before but it would be costly and with lag).
AtmosphericFog also is not configurable, does not have ozone to render realistic earth and does not support beautiful space view.
Also it looks very hazy by default, I wonder if the Mie scattering is not fudged somewhere to be higher than earth…
It also is not future proof for volumetric shadows (can be done but needs hack) and what is coming with clouds.
I came up with a new set of luts that allows all that to happen in real time from PC to mobile, with dynamic atmospheric properties supported, and with nice performance (and more could even be squeezed out I am sure).
==> The paper came out after when seeing it was a nice improvement over the existing state of the art algorithm. So I am not sure what you are trying to say here. The new sky is fast and can even run on mobile at shippable performance (Fortnite). AtmosphericFog is going away in UE5.
“but in most of them people most likely had to spend some extra effort to get it looking right, while physical sky atmosphere model is not something that requires considerable amount of effort to get looking right in most other renderers”
Now I think you are inventing things: I am sure other renderers are good but I have been involved and talked to all artists while in the process of the demo I mentioned and everything went well.
Also the system seems easy to use so far: for instance a dumb programmer like me made the bottom screenshots in just a bit more than 5 minutes.
Also Unreal is not here to copy paste what others are doing, we are here to push new and better tools (at least try when it makes sense).
Skydome: it is not something you have to use, just another possibility. It is required for the best performance on mobile architecture for instance. It often is the fastest option for anyone who want to compose sky in a custom fashion.
Heightfog: this is not wasting permutation and performance since you have to enable it per project for it to work (it then updates all shaders, no extra permutation, no default cost when not enabled).
“non pitch black color under the horizon” on your screenshot you put some water there so the horizon and bottom darker ground should not be visible anyway.
All those screenshots are possible to achieve with the current system (showing some screenshots here with a mirror surface at altitude 0, daytime, sunset and some others I tried to match and get close to yours, basically playing a bit with Mie and Rayleight scattering, mainly increasing them, I am sure an artist would make them look even better)
(small bug in ssr on this image it seems not sure what it is yet, to be investigated)
I have reproduce a similar setup to the AtmosphericFog with the sky atmosphere: (you can see below I have only changed 3 parameters, this is what AtmosphericFog was basically doing it as explained abobve and as I remember, I will not dive again in that code.)
You say you want physically based light ratio on ground, but you also want a color under your feet that matches some scattering while being on the ground. None of those are possible at the same time (considering ground level and a sane algorithm).
I know the SkyAtmosphere is not perfect: there are use cases not handled and things here and there to improve. But, at this stage on this particular topic, I do not know what else to say because everything is working and the AtmosphericFog setup is also reproducible with SkyAtmosphere. I’ll stop answering on that particular topic since we just seem to have divergent opinions.
@presto423 Hello, not sure what you mean since the SkyAtmospehre component has an entire section called Atmosphere - Mie and I think tooltip were there in back 4.24. I could remember wrong though, sorry if they are missing
Simply increasing the MieScattering Scale should increase the particles in the air and the impact should be easy to see. Please check this page for some visual exemples with sliders https://docs.unrealengine.com/en-US/…tmospheremodel.
I hope this helps.
@SebHillaire Thanks, now I have better clue which parameters to look for. The renders with the water planes were actually not made by me. What I am worried most about is the suggestion to actually use some ground plane. That generally requires some giant geometry extending far away enough so that there’s no visible gap between it and the super sharp transition between sky and black. That’s also often more tricky if your scene is kind of “below sea level”. What I just generally expect to be able to do is to employ just the sky atmosphere on its own, without need for additional geometry, and still get smooth gradient around the horizon so that the sharp transition is not so distracting.
To better illustrate:
If I start with the default sky atmosphere and have some terrain, everything is fine:
So the first suggestion I usually hear is “Add the ground”. So fine, let’s add a giant plane:
Well, the horizon problem is solved now, but obviously I can’t have the plane running through my level, so let’s lower the plane:
Then, when I lower the plane, the gap starts to show. I can obviously make plane excessively large but I am always worried about running into some sort of precision issue.
That being said…
Your explanation of the correct setup helped a lot. Now I am able to get pretty much what I need. I did not need to go nearly as high with the Mie Scattering scale, and I also touched the Mie scattering anisotropy to compensate down the increased glow around the sun disc caused by increasing scattering scale:
Now I feel that we’re not in a territory of insufficiency of the model, but rather odd defaults. Perhaps they could be tweaked to get something better looking out of the box. To most people who are used to working with physically based sky models coming from other software, encountering one with pitch black color under horizon by default is quite jarring experience 
PS: When you wrote “for instance a dumb programmer like me”, I hope that wasn’t reference to something I’ve written. I hope I didn’t write anything that even indirectly implied I consider you dumb. Quite the contrary. I’ve been crying for physically based sky model in Unreal for years, so I am really grateful we finally have one. I just tend to nag a lot as I want it to be the best one it can be, and it seems that is the case, apart from combination of my lack of understanding of it combined with perhaps questionable defaults
For what’s it worth, for me it clearly sounded like a habit of self-sarcastic (or just modest?) person used to say things like “I did this, but this not perfect, sorry, I’m just dumb programmer clicking into things, artist would make it properly” 
I see many questions on Reddit or Unreal Slacker how to handle such cases, so better defaults/documentation would definitely help many people. (just don’t hide this in video live stream)
Can you guys please make it so that the AthmosphericLightVector parameter is also available to the vertex side of things?
[SM5] /Engine/Generated/Material.ush(2082,19-70): error X3017: ‘MaterialExpressionAtmosphericLightVector’: cannot implicitly convert from ‘struct FMaterialVertexParameters’ to ‘struct FMaterialPixelParameters’
I’m not sure why, but having to create an actor bp to keep a MPC updated just to make a sun flower kind of follow the sun is pretty tedious when the vector is already there for the pixel shader…
@SebHillaire One question: I saw your change of min radius for planets and atmosphere (to 1km and 0.1km) in branch dev-rendering… maybe it is possible to change radius to 0.1km or less ? I’m trying to do some very small Mario Galaxy type planets and would greatly appreciate using the SkyAtmosphere (and clouds) there as well
@SebHillaire @Rawalanche So how is exponential height fog supposed to be used with atmosphere? In a typical foggy day case, I can’t seem to get the result with height fog alone, as it appears to scatter a lot less than it should. Tweaking mie is not an option, for fog needs to be dynamic.
Also, both fog and sky atmosphere are causing double fogging with single layer water rendering. This really needs curing.
[USER=“3140864”]MostHost LA[/USER] That will be fixed in 4.26.
@sh0day 4.26 will have those reduced even more. However we have not tested that extensively so any surprises might happen. If you find something broken, maybe scale your game assets up (but yeah I understand that is also not easy)
@Deathrey See this document:it has a height fog + SkyAtmosphere description. Height fog is an approximation so it will never match the complexity of the atmosphere Mie scattering itself with multiple scattering and self shadowing. Mie scattering is dynamic and can be changed from blueprint so this should not prevent you from using it dynamically. SingleLayerWater: yeah thanks for reporting! we have that already tracked on our side.
That is awesome, thanks, looking forward to 4.26
But as you mentioned, scaling everything up has its own problems and is not that easy…
Awww, thanks. Did not realize that contribution parameter is unclamped and can go beyond 1.
Which brings me to a bit of a follow up:
It is peculiar, that I achieved expected appearance at around 6.28 Sky contribution multiplier to the fog. Coincidence?
Correct me, If am I wrong here, but my expectations would be that volumetric fog with large distance, when set to work with sky inscattering, should not look appreciably different from analytical fog.
That is not the case, and they have significant difference in brightness. And this difference originates from sky inscattering.
I’d also think, that even when volumetric fog is not set to override lights with inscattering, it still should not be vastly different in brightness.
Interestingly, boosting sky inscattering for volumetric fog by 3.14, as well as scaling Sky contribution to fog by 6.28,
makes all 3(Height Fog, Volumetric Fog with Sky Inscatter override and without it) look instantly correct under all sky conditions.
Something is slightly off or is it me?
@Deathrey
Quick answer:
I am not sure what is your expected appearance but heightfog one must be wrong anyway since it is done with simple height distribution and some fake lobe for the directional component and it does not feature multiple scattering. All these techniques (height fog, volumetric fog and SkyAtmospehre) have different ways to represent participating media, do the computation and different features (phase function lobes, altitude distribution, multiple-scattering) so brightness will change across them. Heightfog is a different participating media than the SkyAtmosphere on for instance, and it is flat not round, etc.
HeightFog and VolumetricFog should however get closer because they represent the same flat participating media (although the volumetric fog can represent more from voxelised entities) but they still can look vastly different because a different directional lob (or phase function). Maybe something else is missing also, we are actively trying to test more interactions by adding more test to our test suite also (the interactions matrix is huge).
So that 6.28 is a setup from the flat-earther!
Beg your pardon, that would be a plane earther. Earth is a finite plane.
Comparison image:
https://i.imgur.com/5ymrFB5.jpg
It is not coloration or lack of directional scattering that causes concerns, but darkening.
Volumetric fog, when set to reasonable distance, fades out to height fog. Notice huge difference between two. That already cases issues visually.
Check volumetric fog with inscattering override at defaults. Pitch black. How?
And this is the main symptom I’m referring to. Difference between Height Fog and Volumetric Fog with Inscattering override. I’m positive that there should not be that much difference. Moreover, they seem to be different by exactly a Pi.
That is 4.25.0, for reference.
Yes agreed: I am not saying there is not a problem somewhere but all I am saying is that PI or 2PI is likely not it. (PI is usually a surface shading error, but yeah who knows everything is possible).
So there must be a fundamental problem somewhere else. Maybe something like the skylight captures the height/volumetric-fog into the environment lighting representation that is then used to lit it self again on the main view via the diffuse spherical harmonics. The SkyAtmosphere contribution is separated from that: this contribution is from a *atmosphere light scattering only value * (so this way of doing things for an unshadowed participating medium should be more correct than the skylight feedback loop). And it is separated to avoid that specific feedback loop. So again investigation is required within the wide matrix of all the interactions.
Thanks for those images, and I added all that in the long list of todos…
Not claiming otherwise for sure. Not well-versed with the subject. It is just that difference is quite close to PI or SHAmbientFunction or w.e. which may or may not be a helpful hint.
For the record, images were taken with skylight capturing sky without heightfog in all cases.
It is just that my expectation from height fog with respect to atmosphere would be that inscattering from atmosphere would function more or less reliably without need for manually tweaking additive inscattering color, as well as not causing so noticeable transition to volumetric fog. At least to a point where it would work equivalent to using inscattering cubemap. Right now it is much darker.
Has anyone had any luck with this? I have messed around with just about every setting on the sky atmosphere, the light and exposure but i still cant get anything but a black night sky. (need it to work realtime, not baked, and with time of day change)
So far i can get around that with the old method of adding another skydome, hdri or whatever additional stuff i want, but it would be nice to not have to.
Some posts also mentioned not having to use the height fog any more, as well? That the fog in the sky atmosphere could do all the same up close fog effects (light light rays and cones from nearby spot lights) but no luck there either. Increasing the mie scattering, like some suggested, just darkens everything.
UPDATE: I have had good results by adding a second directional light to act as a moon light (with low brightness and low exposure values).
Still no luck with the sky atmosphere as the only fog, but the height fog is working alright for now.
Haven’t tested in 4.24, but in 4.25 and 4.26 Sky Atmosphere fog is incorrect while in VR: the right eye is off when applying the aerial perspective volume (the sky itself looks correct).
Is there a way to disable this Atmosphere debug text pass in 4.26.1? r.SkyAtmosphere.DebugText 0 doesn’t seem to work or even being recognized by the engine. Please, assist!
Thanks in advance!