Biology

Really nice screenshots! Sorry, it's a bit unrelated but what do you use for the scenery? Is it orthophoto or something like SFD Global? If it's ortho, I'm surprised by how color accurate the terrain looks - if you used some kind of color correction for the tiles I would be really appreciated if you post the settings for it.

You already told the entire story so there's not much left for me to tell. Honestly yeah, given how much research it took I probably should've done what you said. My reasoning was that I really wanted to have it added to both sims as I was really annoyed by the purple skies, and the best chance of achieving that was making it free, open source and easy to implement. In the end as much as I'm a developer I'm also a simmer, and the purple skies were really taking the enjoyment out of the sims.

Are you sure that these are in the right order? These are the exact same values ARPC outputs, just in the wrong order. ARPC outputs 0.00229 for red, 0.00154 for green and 0.0 for blue. In any other order the sky would look completely wrong, so I'm pretty sure it's just the order they're stored in the memory being different, not the order they're used. This means that Asobo used the ARPC values as is (thankfully), and the purpler sunsets / sunrises compared to applying the ARPC values in SU13 is solely caused by the corrections they made to the Rayleigh scattering coefficients and the direct sunlight color.

The issue with the mod is that it only worked because we knew the values to search for - as Asobo used the values from the original paper as is, it was really easy in SU13. Now no one knows the exact values they used, which means it will be much harder to find them.

Sorry for the late response, but indeed I'm pretty happy with the changes. Without seeing the new coefficients it's hard to comment but it appears that they chose something in between the old default values and what ARPC outputs for the ozone absorption coefficients. If I had to guess why, I'd say it's likely because the sunsets / sunrises look too green when using the ARPC coefficients as is without the required changes to the multiple scattering, so they likely had to make a compromise between the accuracy of the coefficients and the greenness of the sunsets / sunrises. Another unexpected but welcome change is the day sky colors. While ozone absorption coefficients affect day sky colors, the effect is minimal, so it seems like they also changed the rayleigh scattering coefficients based on ARPC and not just the ozone absorption coefficients, making the day sky colors have a deeper blue hue with less green, a change that I really appreciate. I would have been even happier if they tried to tweak the multiple scattering so that they could use the ozone absorption coefficients from ARPC as is, but they never said they would do that so I'm not disappointed as I had no expectations in that regard to begin with.

On other good news, the wishlist item for ARPC is now marked as "Fixed (SU_14)", so it sounds like they've finished.

@Drunq sorry for bothering but how does your live memory changing tool works? I run MSFS on Linux so I was trying to make a similar tool that runs natively on Linux, but I couldn't make much progress.

Those are identical to the FSX sky textures and not used, so if I had to guess they were either left there when Asobo was studying FSX code or added for some weird backwards compatibility reasons.

Hi, this is indeed my concern. Hillaire's method assumes that the sky is rather uniform and lacks high-frequency components which is how it can get away with rendering everything at real time at a lower resolution. But it is only true for a clear sky and not a sky with clouds. Thankfully there are potential workarounds for it, like falling back to raymarching for such atmospheric effects, which is why I decided to say "Hillaire's method or something similar" instead of just Hillaire's method as it's hard to know exactly what they're planning without more information - even though it's not straightforward, it's possible that Asobo, who are really skilled in computer graphics, already found a workaround for it or maybe even developed their own Hillaire-like method. But it's also possible that they are going to use Hillaire's method as is and think that compromising some atmospheric effects is worth fixing the horizon line issue and having more accurate multiple scattering, only time will tell. Directly quoting Hillaire's paper: "An important visual effect to reproduce is volumetric shadowing, for example from mountains onto the atmosphere. It is not possible to use epipolar sampling because the atmosphere is not a homogeneous medium. And it is also not possible to use a shadow volume approach from Bruneton et al. because our LUTs do not allow that kind of integral sampling over view ray paths in the atmosphere." As Hillaire's method doesn't have a lookup table like in Bruneton's method to evaluate the atmospheric scattering integrals in any direction, they can't add the effects of other things like clouds or mountains to the sky in a straightforward way, but again this doesn't mean it's completely impossible. In fact Hillaire's paper itself mentions that it's possible to use raymarching and CSMs to achieve light shafts in real time and the results can be seen in Figure 14, but it doesn't go into much detail on how they implemented it.

They will be completely ditching Bruneton's method for Hillaire's method or something similar, so instead of pre-calculating the atmospheric scattering integrals into a lookup table, they will calculate them in real time. This means they no longer will have to deal with the precision issues near the horizon which is what caused the horizon line issue, so it will be gone for good. Another advantage is that Hillaire's method is significantly better at estimating multiple scattering, so the luminance during sunset / sunrise will be much more accurate. Lastly, they talked about an "all new color engine". Given the context of it was that they are going to do more than simply rendering in RGB with more accurate coefficients, it could mean only one thing - ditching RGB rendering altogether and going for full spectral rendering, which means the colors will be even more accurate than what can be achieved with ARPC coefficients.

In case anyone hasn't seen, here are some good news: This week's MSFS development update is out and the wishlist status for ARPC went from "Under Investigation" to "Started (SU_14)" and the wishlist description says "Work is progressing. Looking good for SU_14."

For the case of MSFS, the horizon line is a giveaway artifact in Bruneton-like implementations, and Asobo mentioning the scattering & transmittance LUTs, which is how of Bruneton-like implementations work, alongside with the leftover text in FlightSimulator.exe confirms it. For the case of DCS, their shader code is open, and indeed they use Bruneton's method (in fact I already found a way to have the ARPC coefficients on DCS as well) For the case of XP12, the exposed art datarefs were a giveaway and then I got a confirmation from the developers. For the case of P3D v6, the same reason as DCS, their shader code is open. They also had told in their promotional material that they were using Unreal Engine's sky, which uses Hillaire's method. In fact Sebastien Hillaire works as the principal graphics engineer on Unreal Engine.

I'm sorry that my comment sounded like a lesson on the content of your answers, that wasn't my intention. It was merely an observation about everyone involved in that argument and why your criticisms despite being valid weren't taken well. As said above I agree that VisualXP exceeds everything I've seen, including what can be achieved with ARPC in either of the simulators. It looks simply beautiful. My point was that sadly it's very non-physically-based which means neither LR nor Asobo would be willing to integrate it into the simulator for very valid reasons. With physically based rendering everything works like a clockwork, if a component is not physically based, rest of the components in the chain also become non-physically-based and things quickly turn into a tuning nightmare. My next project is a new custom tonemapper for XP12 called Enhanced Visuals, which replaces the default filmic tonemapper with a more natural hue-preserving one, fixing the cyan tinted sky during day and yellow tinted sky & clouds during sunset / sunrise. I won't get into more detail as it's not a MSFS project and completely off-topic, but it is indeed what I have been spending my time on recently.

For those who are interested, I'm aware that my comments regarding multiple scattering are a bit too technical and don't actually give a feel of how it affects the visuals, so here's a demonstration using XP12: (For debug purposes or not, I love that LR exposes these parameters and I wish Asobo did too) Initial release day XP12: (Before the aforementioned multiple scattering hack and before ARPC coefficients were integrated into the simulator) Current XP12 multiple scattering, but without ARPC coefficients: Initial release day XP12 multiple scattering, but with ARPC coefficients: Current XP12: (After the aforementioned multiple scattering hack and after the ARPC coefficients integrated into the simulator) Currently what we can achieve with this .exe hack is basically akin to the initial release day XP12 multiple scattering, but with ARPC coefficients. When Asobo tweaks the multiple scattering and exposure during sunset / sunrise it should look like current XP12.

As much as I understand your frustration things are not that simple. Both MSFS and XP12 use the exact same physically-based scattering equations, just implemented using different methods. The discrepancies you see are caused by 2 separate issues which need to be addressed separately. 1. Both MSFS and XP12 use autoexposure to have as much dynamic range for a given lighting condition as possible. MSFS underexposes during sunset / sunrise, making everything, including the sky, look too dark. If you switch to the drone camera and manually increase the exposure through its key binding you will see that the sky looks much more realistic with a higher exposure. Not that XP12 is perfect in that regard, it has the opposite problem - it overexposes the sky and causes clipping during sunset / sunrise. 2. The method used by MSFS (Bruneton's method) significantly underestimates multiple scattering. This also causes the sky to be too dark. Even the method used by XP12 (Hillaire's method) underestimates multiple scattering, though to a much lesser degree. Even then, to overcome this XP12 uses a non-physically based hack to artificially boost the multiple scattering amount during the sunset / sunrise. Asobo seems to be really reluctant when it comes to using non-physically based hacks to the degree that we still don't even have accurate visibility, so I'm not surprised that it's not implemented by them. For those who are curious, neither Bruneton's method nor Hillaire's method are superior to each other, they have distinct advantages and disadvantages. For instance Bruneton's method gives you a full LUT for the scattering and transmittance integrals, so you can easily take the the effect of the clouds into the atmosphere into account, which is the case in MSFS. You can see how the aerial perspective / haze on the ground disappears when there is cloud coverage and how the clouds cast light shafts into the sky in MSFS, neither of which are simulated in XP12. It's because it's much harder to implement these effects accurately with Hillaire's method as it doesn't pre-calculate a LUT for the scattering and transmittance integrals but renders a low resolution sky each frame. On the other hand Hillaire's method is much better at calculating multiple scattering, resulting in a much more accurate sky luminance during sunset / sunrise. In the end, it's a compromise. MSFS and DCS use Bruneton's method while XP12 and P3D v6 use Hillaire's method, so both methods are very common and are "state of the art". However based on the last developer Q&A, it appears that Asobo is switching to Hillaire's method for MSFS 2024, which will eliminate both the horizon line issue and the inaccurate multiple scattering. Also you seem to be using a third-party add-on, namely VisualXP, in those screenshots and while I agree that it looks simply beautiful, in fact even better than default XP12 with ARPC coefficients, in the end it's a based on visual references and not physicaly based whatsoever, which is not desired for physically based rendering. So I wouldn't expect a VisualXP-like look from either of the simulators any time soon. What they achieved is insanely beautiful, but it comes with its own compromise. Lastly, I think it's more than fair to compare both simulators, but it's also not surprising that you were met with such a negative response, not because you were criticizing things but due to how you phrased these criticisms. To be more clear, I think it's expected that constantly calling things ugly and making fun of the cameras of people who are offering reference screenshots would annoy people. P.S. Here's XP12 during the time it was newly released, when it wasn't using the non-physically based hack to artificially boost the multiple scattering amount: You can see that it suffered from the exact same issue as MSFS. The hack for the multiple scattering was implemented only relatively recently, and my work on ARPC was integrated to XP12 with 12.06, so literally just a few weeks ago. I pointed out the issue with the coefficients to LR, they were extremely responsive and they quickly implemented it. Now I did the same with Asobo and they said that it will be implemented starting with SU14, so only one SU after I reported it, I don't think it's fair to Asobo to be this negative.