Biology

Yes, but then you move away from the spectrally rendered ground truth. I think it's better to fix multiple scattering instead of tweaking the parameters without any physical basis. Even though the boost to the multiple scattering doesn't exactly have a physical basis either, at least the inaccuracy comes from the model's limitation itself and not due to inaccurate parameters being entered to the model. In other words, it's a better approach to tweak the model to look right when accurate parameters are used than tweaking the parameters to compensate for the inaccurate model. This way it can also be more easily tweaked by cross-referencing it to CIE standard skies.

Yes, that seems to be caused by multiple scattering not being enough. It's especially true for Bruneton's paper (which is used in MSFS) but even in XP12 which uses Hillaire's paper LR had to artificially boost the multiple scattering. So the multiple scattering amount needs to be artificially increased during sunset / sunrise like in XP12, which will turn the green tint into yellow / orange and make the sunsets / sunrises much brighter just like real life.

As I mentioned in the other thread I really don't recommend it as it indeed might cause issues with updates and even if it doesn't, any update will revert the mod and the offsets will be no longer valid. It is only intended to be a proof-of-concept to show how it would look in MSFS.

I have an HP Reverb G2, which is considered to be the highest resolution (common customer) option available, but even that doesn't look sharp at all and it's not even bright with colors being really muted, it also feels like looking through binoculars. Overall, I really don't like VR that much, despite the feeling of depth.

Was there even a horizon line issue in P3D? I only have v4 and v5 so maybe it was fixed, but I don't remember seeing anything like that. Regarding people saying that it's carried over from FSX / P3D - I think it's simply because when the bugs look similar people will naturally assume that they are caused by the same thing, but the way MSFS and FSX / legacy P3D (v5 and v6 moved into a physically based sky as well) skies work is completely different. FSX / legacy P3D used actual photos of the sky to render the sky, which had the advantage of looking exactly like real life and as they literally are photos from real life. It also allowed for lots of variation as the developers could simply add more photos of the sky taken at different conditions. However such an approach doesn't work well in an environment where everything else is physically based, as there is no way to get the actual brightness values from a photo, so the lighting calculations can't take the contribution from the sky into account. There not being a straightforward way to calculate aerial perspective was another major issue. Because of these issues, flight simulators, including MSFS, have all moved into physically based implementations. They might lack the variation of literal photos of the sky, but they are really consistent with the environment and they yield accurate brightness values. The horizon line issue in MSFS is an artifact in Bruneton's model and there isn't a straightforward way to fix it. There is a recommended solution in the paper, but it didn't work for me in Enhanced Skyscapes and it seems like it didn't work for Asobo either. I'm sure Asobo would've gotten rid of it already if they had found a straightforward way.

Yup, purple sunsets are certainly a thing IRL. It's just that they require specific conditions such as the sunlight constantly bouncing between clouds around the ozone layer or being interrupted by clouds at a long distance even before reaching the surrounding area. But most of the time blue sunsets dominate as the required conditions for a purple sunset are somewhat rare. Either case the MSFS and other simulators having purple sunsets was partly just a coincidence rather than an intentional art choice.

On good news - I finally got the Member status and created a wishlist thread: https://forums.flightsimulator.com/t/replace-the-atmosphere-parameters-with-more-accurate-ones-from-arpc/607603 Sadly I can't edit the main thread to include it so I hope it doesn't get lost.

This is not the first time he does this, the best thing to do is to not give him any attention. He's creating a story about what happened by (likely intentionally) mixing completely unrelated things. As Enhanced Cloudscapes was my first ever OpenGL project, I had decided to make it is a freeware product and like most other freeware projects in existence, I had a donation link up for it. After releasing initial versions of EC was out my computer died in a spectacular way (PSU failure) and I mentioned that the development was halted indefinitely as I didn't know the extent of the damage and whether the drive containing the code was damaged or not. There were a few people who offered donations, but I said that I don't need any and I can afford the replacement PC myself. Indeed I paid for the replacement parts myself and continued working for EC for a long while, without having the idea of developing a payware product long after EC development was finished. And I never said that I'm in poverty and I'm not even in Eastern Europe, so I have no idea where he is getting that from. Long after releasing EC, I decided to create a new volumetric cloud rendering add-on with a physically based sky from scratch and Enhanced Skyscapes was born. As I was now a lot more experienced in computer graphics, I decided to make this new project payware. And mind you, when I made EC, I didn't even have the idea of making a new payware add-on, again it was long after EC development was finished. Despite me having no moral requirement to make ES a freeware as well as it was a new project I developed from scratch, despite me giving free copies of Enhanced Skyscapes to everyone who donated to Enhanced Cloudscapes and despite removing the donation links before ES was released, he seems to have an issue with me making ES a payware project. At first I thought he was just misunderstanding, but his behavior is really bordering on deliberate. Either case, I'd be really appreciated if he doesn't turn this thread into a drama thread as my other work for other simulators are completely irrelevant here.

Nope, currently all simulators assume that the atmospheric parameters don't change with temperature. For now LR only implemented the coefficients from ARPC, but maybe in the future they might integrate the full code base which allows for calculating the coefficients for given atmospheric conditions. If you mean the color temperature adjustment ("Mexico filter") that was implemented to adjust for the lighting condition changes, it was not physically based and looked completely wrong in many cases - so that a lot of developers, including me, asked LR to remove it in the developer Slack, so currently it has very little to no effect.

The good thing about physically based rendering is that as long as the equations are physically correct, the results will be the same regardless of where and how they're implemented. Similarly, the coefficients are derived from first principles, therefore they work the same way regardless of where they're implemented and the implementation details. Both MSFS and XP12 use physically based rendering for the atmosphere, so my coefficients should work the exact same way in MSFS that they do in XP12 now, so I'm really optimistic about it being implemented. For instance, the first set of comparisons are from a ShaderToy implementation of Hillaire's paper and the second set is from X-Plane 12, and yet they look the same. The same will very likely be the case for MSFS as well. The main thing that matters is the coefficients being accurate to the real atmosphere, which is what this approach aims to accomplish.

It was really surprising to me that both papers got it wrong as well, but turns out it's because they both used the same paper as a reference when picking these coefficients (which is what I mentioned as the reference in the thread post), additionally Hillaire's paper cite Bruneton's paper for the coefficients anyway, so I believe they just used the coefficients from Bruneton's paper believing they were accurate. Indeed it is a really easy fix to implement so I really hope Asobo decides to implement it. The script is MIT-licensed so if they want they can integrate the entire script (instead of just the coefficients) to the simulator as well, which would let them do things like dynamically changing coefficients according to air conditions. Either case, I love sunset / sunrise flying and I really hope we can have this in MSFS.

Thank you. I actually thought of using the DevSupport channel but it's for developers asking questions about the MSFS SDK, meanwhile mine is a feature request for the base simulator, so I wasn't sure if it was suitable.

Anything made by Raul / FSReborn is an instant purchase for me.

Luckily X-Plane 12 had it exposed for debugging reasons, in the form of art controls, which is how I made the change. Yes that's pretty much what this approach does, instead of increasing the spectral resolution, it calculates the best possible approximation for a given amount of spectral samples. Sadly it's not identical to rendering spectrally, because as the light gets attenuated some colors will shift outside the sRGB gamut, but it's still a pretty close approximation. Indeed X-Plane 12 was also using the wrong coefficients from Hillaire's paper until very recently, but I contacted them about this approach, which very recently got integrated into the simulator.

Hi, I actually didn't get any screenshots in MSFS as I can't change the coefficients, they are hidden behind the game engine. Instead I used a ShaderToy implementation of Hillaire's paper for the comparison screenshots. Currently there is nothing an user can do to get this work in MSFS as these coefficients are typically never exposed to an user.

It can run on any simulator that uses physically based atmosphere calculations, which is the case for MSFS. Only the parameters that are entered to the atmosphere model needs to be changed, and I made sure that the coefficients generated by the Python script are compatible with both Bruneton's paper (which is what MSFS uses) and Hillaire's paper (which is what X-Plane 12 uses), so it should be fairly easy to implement.

Hi, no, the good thing about the scattering and absorption coefficients is that they only depend on the composition of the medium and nothing else, so even if MSFS doesn't model ozone density it shouldn't be an issue as an average / standard value can be used. For instance X-Plane 12 doesn't model ozone density either.

Hi, Firstly thank you everyone for your supportive comments! I love MSFS and really hope that this can be adopted by them as well, as it would make sunsets / sunrises so much better. I registered in MSFS forums but I still haven't received a confirmation email so I can't use my account, I sent another confirmation email which also didn't arrive, so I don't know what to do. Until now, I can anaswer your questions. Edit: I finally got in but seems like I have to wait for a while to become an "approved" user to be able to post, so I'm currently waiting for that.

I will post there as well, I wanted to start with AVSIM as the community here has been traditionally successful at drawing attention to a wishlist item.

Hi, I have a huge interest in computer graphics & color science and I have developed Enhanced Cloudscapes and Enhanced Skyscapes for X-Plane. 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: https://github.com/FarukEroglu2048/ARPC 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.

Most volumetric cloud implementations already do that - I don't know if it's the case for X-Plane 12 as well or not, but it likely is. For instance, in ES and EC I change the cloud density as a function of altitude to get more flat bottoms and softer tops. Similarly, some implementations fade from a wispy noise (Perlin or inverted Worley) to a caluliflower-like noise (Worley) as the altitude increases. But these methods are quite limited due to a few reasons. The raymarcher doesn't know where a specific cloud is, so it has to apply the effect either to all clouds or a specific region, but there is no guarantee that the specific region will definitely have clouds because even if the coverage map indicates a non-zero coverage, it doesn't necessarily translate to an actual cloud actually being there due to the cloud noise having its own empty spaces. So these effects have to apply everywhere in a symmetric way, usually depending in just altitude. And this is simply not enough to "carve" realistic shapes into the noise.

Basically, yes. The hardware of today simply doesn't allow for it.

Honestly this is a compromise of volumetric clouds that we all might end up having to accept. All volumetric cloud implementations, be it MSFS, DCS, X-Plane and even xEnviro lack detail when the clouds are viewed from up close. It's simply because the clouds are made from low-resolution noise and the raymarching for both rendering and lighting has to be done with so little samples. Increasing the noise resolution is not possible due to memory contraints, and increasing samples for raymarching is not possible due to speed constraints. Not only that, as the clouds are constructed from simple noise, the resulting large-scale structures often don't look realistic but only somewhat resemble clouds, So until GPUs are around 5-10x faster than today with around 5-10x more memory, having realistic volumetric clouds won't be possible. Legacy 2D billboards have a lot more detail and their shapes are accurate because they are literally pictures of clouds, but they also have unrealistic lighting and suffer from artifacts when moving through them. So it's a compromise. But I feel you and I'm going to be honest, despite having made 2 volumetric cloud implementations myself, I still sometimes ask myself if the better lighting etc. were worth giving up the detail and accurate shapes of 2D billboards, but I believe that it was, despite the downsides. Volumetric clouds simply integrate much better with a physically based atmosphere, they look much nicer (even though they have less accurate shapes), they have much nicer lighting and they don't suffer from artifacts when moving through them.

Hi, that's actually a really nice question. Indeed the rendering is still done in RGB, not spectrally. However instead of trying to pick 3 wavelengths for red, green and blue, which is equivalent to rendering with only 3 spectral samples, this approach takes the entire visual spectrum into account when calculating the red, green and blue coefficients. For each color channel, instead of picking a single wavelength for the coefficient, a weighted average of the coefficients for all wavelengths is taken. The weights are directly based on how much all wavelengths contribute to the color channel. For instance, 650 nm is a brighter red than 680 nm, so the coefficient for 650 nm has more weight than the coefficient for 680 nm. This approach gives the most accurate coefficients possible for rendering in RGB, though in the end it is still an approximation and fully spectral rendering would be more accurate. However spectral rendering has its own disadvantage, namely performance impact, and based on my experiments the difference between spectral rendering and rendering in RGB using the coefficients from this approach is not that different. But who knows, maybe LR will switch to spectral rendering in 12.07, given that they mention more atmospheric scattering improvements in the roadmap.

TL;DR: You are mostly correct, but the issue is a bit more complicated than other simulators not modelling it. Basically almost all of atmospheric scattering implementations in any flight simulator (both first-party and third-party), even my own Enhanced Skyscapes, with the exception of xEnviro and FlightGear are based on either Sebastien Hillaire's or Eric Bruneton's papers which have a mistake on their coefficients, resulting in wrong colors during sunset and sunrise. For those who are interested, here is the long story: In order to model atmospheric scattering, scattering and absorption coefficients are used to describe the medium in which the light scatters and gets absorbed. As both scattering and absorption is wavelength dependent, both scattering and absorption coefficients are defined for all wavelengths in the visual spectrum. However, in most games, including X-Plane 12, rendering is done in RGB (more specifically sRGB color space), which poses an issue - somehow the coefficients for all wavelengths need to be converted into coefficients for just red, green and blue components. As a solution, a paper way back in early 2000s decided to simply arbitrarily pick 3 wavelengths for the red, green and blue components - 680 nm, 550 nm and 440 nm respectively. Both Hillaire's and Bruneton's papers used the same wavelengths without any modification, and this is where the issue starts. The early 2000s paper I mentioned only modelled Rayleigh and Mie scattering caused by the major constituents of the air (oxygen, nitrogen and aerosols), and their arbitrary wavelength choice was likely tuned for their model. However, there is one more constituent of the atmosphere which has a significant effect in the sky colors during sunset and sunrise - it's ozone. Ozone absorbs a lot of red and green light, and it is what causes the blue hour. In order to simulate blue hour, both Hillaire's and Bruneton's papers introduced ozone absorption into their models. However as they didn't change the wavelengths from the early 2000s paper, which wasn't tuned for ozone, the results were inaccurate, more specifically, the sunsets and sunrises looked too purple. And this brings us to the main issue - there isn't a single wavelength for red, green and blue - 680 nm is red, but so is 650 nm, 550 nm is green, but so is 580 nm, 440 nm is blue, but so is 460 nm. So a lot of tuning is required to pick the "right" wavelengths for a given atmosphere model. However, there is an alternative solution, which is what was used in X-Plane 12: What if instead of picking a single wavelength for red, green and blue, we managed to find a way to calculate the contribution of all wavelengths? Turns out this is possible, by using CIE 1931 XYZ color matching functions. By converting the CIE 1931 XYZ color matching functions to sRGB "color matching functions" using the transformation matrix from the official sRGB specification, what you get is sRGB color space representations of all wavelenghts, in a way showing the contribution of all wavelengths into red, green and blue. By taking a weighted average of the scattering and absorption coefficients where the weights are set to the sRGB "color matching functions", it is possible to consider the contribution of all wavelengths for red, green and blue, resulting in much more accurate coefficients. You can try my open source Python implementation here if you want to learn more about how it works, it includes visualizations and helpful comments as well: https://github.com/FarukEroglu2048/ARPC