Hi,
I have a huge interest in computer graphics & color science and I have developed Enhanced Cloudscapes and Enhanced Skyscapes for X-Plane 11. Most modern flight simulators including MSFS, DCS and X-Plane 12 started to use physically based sky implementations and there has been something about them that was really annoying - overly purple sunsets / sunrises. I have been looking into the issue and I finally came up with a solution.
Firstly, the same issue is shared between so many simulators because they all use the same few papers (most notably Eric Bruneton’s and Sebastien Hillaire’s) as a basis for their implementation, and turns the reference these papers used for some of their parameters had a significant error. The atmosphere is rendered by casting rays and calculating the scattered & absorbed light by physical equations. As different media scatter and absorb light differently, their scattering and absorption behavior is expressed using scattering and absorption coefficients. And the issue lies in how these coefficients are calculated. The physical equations used in atmosphere rendering are normally defined for a spectrum of light, but in computer graphics rendering is not done spectrally but using tristimulus values (such as RGB) due to computing power limitations. This poses an issue as not only the physical equations themselves but the scattering and absorption coefficients as well are defined spectrally (in other words, for a given wavelength) and not for tristimulus values used in rendering. For rendering in RGB, the reference used by these papers picked a single wavelength for red, green and blue as an approximation. The issue is that there isn’t a single wavelength for red, green and blue - 680 nm light is red, but so is 630 nm light and this approach of picking a single wavelength for red, green and blue doesn’t take that into account. Therefore it is a really poor approximation. My solution was developing a way to take all wavelengths into account when calculating the coefficients for red, green and blue. For this, I used CIE 1931 XYZ color matching functions and converted them into sRGB (as the rendering is done in sRGB color space), which means that now I can convert any wavelength I want into sRGB. My approach is simply using these sRGB values as a weight and taking a weighted average of the coefficients. For instance, when calculating the coefficients for red, if a wavelength has a higher amount of red when converted into sRGB than another wavelength, then it will have a higher contribution to the coefficient as well. Using this approach, I managed to significantly improve the accuracy of the sky colors when tested against a spectral implementation of Sebastien Hillaire’s paper and a spectral path tracer.
To validate my approach, I used a root finding algorithm which tried to find the scattering and absorption coefficients which minimized the error between the spectrally rendered reference and also converted a test incoming light and transmitted light into sRGB to solve for the coefficients. In both cases, the expected coefficients almost perfectly matched the coefficients calculated by my approach.
Under the spectrum calculations section, the first line is Rayleigh scattering coefficients and the next line is Ozone absorption coefficients for red, green and blue, calculated using my approach. And the array shown by “x” are the Rayleigh scattering and Ozone absorption coefficients that match the spectrally rendered reference the best, found by the root finding algorithm. You can see that they are in great agreement.
Finally, I can show you the results.
Using the original coefficients:
Using the coefficients from my approach:
As this approach was recently adopted by X-Plane 12, I decided to use it for comparison as well.
Here’s X-Plane 12 with the old coefficients:
And here’s X-Plane 12 with the new coefficients:
So, that’s all. My work is open source and can be accessed from GitHub: GitHub - FarukEroglu2048/ARPC: Atmosphere Rendering Parameter Calculator
Lastly, why did I create this thread? Because I need your help. Meanwhile my work is open source and really easy to implement (it only requires changing 6 parameters in the game engine), it needs to be implemented by the developers of the simulator. And I really don’t know how to contact Asobo developers. In the past the community helped many developers to establish communications with Asobo and I believe that I can have my voice heard by Asobo with the help of you as well. Thank you all in advance.
ARPC is MIT-licensed and even all of it can be included in MSFS without any royalties, which would allow for different skies depending on different conditions. Either case, only the coefficients themselves are enough to finally get rid of the purple skies and they should be fairly easy to change. I’d be more than happy to document anything that’s needed if Asobo team decides to implement any part of ARPC or if they have any questions. I’d also be really happy to give more technical details on how ARPC works if needed.