Zac wrote in Tue Jul 27, 2021 4:06 am: I have also experimented by altering the hazeColor variable in haze.frag and skydome.frag and I can say from experience that purely by editing the values within the current shader framework it will be very hard to achieve any sunset colors that are close to real life. It is tricky to manipulate it this way since this value is very sensitive and so quite hard to fine tune to make it look correct at all angles of the sun. Especially when you start incorporating dynamic variable such as pollution, I could imagine that the colors could "get away" from you very fast and all of a sudden the code is producing colors which were not intended.
Well shaders mean programmability, and if it's possible to define something mathematically it's possible to implement it. Doing another mapping pass is just changing the algorithm. There's nothing stopping changing of the algorithm/approximation based on sun angle - and environment irradiance is added in like that.
With regards to a definition of "realistic", and changing conditions, a quick google gives these articles for effects of sea salt concentration on sunsets and sky/cloud colours after massive storms in coastal areas.
https://www.zmescience.com/other/pieces ... t-14102019 ,
https://www.bbc.com/news/uk-england-46467988 ,
http://ww2010.atmos.uiuc.edu/(Gh)/guides/mtr/opt/air/sun.rxmlBut if the sunset look was hardcoded to always match one of these conditions, what happens when locations/conditions are different?
If it's possible to define the scientific cause of the reddishness you mean, it may be possible to add that in when appropriate - for example taking into account location and weather to put additional aerosol. Advanced weather is done in Nasal and has access to relevant data e.g. terrain and landclass data, and can create needed properties which can be sent to the shader as uniforms.
The way ALS seems to be done is having the math/understanding for a very detailed model, and then creating custom fast expressions to match what's seen on Earth and also include various extra factors that make a large visual difference - like dust/smog aerosol/moisture. There's also lot of code that's easy to miss in the vertex shaders for low sun cases specifically - so adjusting approximations to cover different cases/regimes not a big deal provided the cause is understood and modeled. The vertex shader covers, for each vertex, altitude/normal dependent irradiance from the skydome/haze layer/moonlight including HDR adjustments for surfaces facing away from the sun and shadows (there's a perceptual moonlight part that isn't filled in yet). I don't know what the detailed model behind the current version is, what factors could be refined, what things weren't added due to needing extra core functionality back then, and what factors aren't covered yet etc.
It's better to find what the exact cause of the reddishness is and improve the model if it's worthwhile. For example, to get a red sunset/sunrise colour, it is possible to just hack-in an increase the optical depth of the atmosphere by increasing the atmospheric density at the surface (the density higher up decreases with an exponential curve in the isothermal atmosphere approximation used by O'Niel). The extra density means there are more particles in the path of a ray of sunlight at sunset which goes low through the densest atmosphere. So there would be a redder sunset as the blues and greens get bounced off. But this would mean the colours outside sunset would be wrong as it's essentially depicting a non-terrestrial atmosphere, unless it was done for low angles of the sun and then the dust/smog/haze would need to be changed - and even then the sky might be too thick overhead or the wrong colours away from the sun unless another correction was done. And then there are things like the colours of ice halos, and the cloud lighting by the sun and skydome which also has to look correct. Moonlight has to be factored in, including the regime when the sun/skydome and moonlight compete. So it's better to find the proper cause and adjust the code.
I think the initial O'Neil scattering approximations matched the optical depths fairly well(?) , so there might not be much to improve (although the optical depth does increase really rapidly as the sun nears the horizon). Not sure if the density at the surface based on pressure/temperature to warrant dynamically changing the density, when the code for haze layers probably handles these cases. It's also possible to tweak the exponential curve by changing the scale height if the atmosphere meaningfully deviated from the isothermal model (e.g. the composition of the lower atmosphere and the a dry/wet adiabatic model being more accurate), but I don't think it would be much of a factor (?) at sunset as the light goes through the lowest part of the atmosphere before it thins out. The occasional reddish-ness might be more likely to be related to extra scattering particles combined with perceptual effects, or something.
Zac wrote in Tue Jul 27, 2021 4:06 am: I have also experimented by altering the hazeColor variable in haze.frag and skydome.frag [..] It is much easier to accept the value of hazeColor and use further post processing to tune the colors using something like a tone mapper.
I think the get_hazeColor function includes the spectrum of incoming sunlight, air pollution etc. Changing hazeColor after the function might be like prefiltering it through a layer of atmosphere before hitting our atmosphere or something - there's lots of other factors that are unaccounted for with this approach like calculations that might be tuned for a different sky colour like light contributions from smog/fog layers with different heights, cloud lighting, ice halo lighting, and the skydome/moonlight irradiance for each ground triangle which is calculated in the vertex shader.
Kind regards