Maya2

@MrBitstFlyer this is interesting, I've been looking into the "too much haze" reports and given you've experimented with the turbidity I'm going to have a question: Have you experimented with manual weather by setting the visibility through the weather window? Do you think the manual weather depiction is correct? This is important to me because I want to confirm that the issue with haze is not an inaccuracy with the rendering but what's told to the renderer by the live weather. Also I personally recommend only playing with the turbidity, both single_rat and multi_rat are already set to their physically correct values and they don't change depending on weather conditions. They also control the entire scattering intensity, not just aerosol scattering. Turbidity on the other hand controls aerosols only, which are what's responsible from the visibility. The turbidity dataref defines the Linke turbidity of the atmosphere, aka the ratio between the vertical optical depth of an atmosphere with aerosols and the vertical optical depth of a clean atmosphere. Therefore a Linke turbidity of 1 means clean atmosphere, and aerosol density increases as the turbidity increases. The current table in the simulator that correlates visibility to the Linke turbidity are based on the OPAC dataset: https://journals.ametsoc.org/view/journals/bams/79/5/1520-0477_1998_079_0831_opoaac_2_0_co_2.xml Edit: Looking at your code, you don't have to make a table for the AOD-turbidity conversion, they are directly convertible from one another. Ignoring the complication of water wapor levels, turbidity = (AOD + 0.1) / 0.1, where 0.1 is the approximate vertical optical depth of a clean atmosphere. So you can see that the equation is just the definition of Linke turbidity. Looking at the table, the values you used for turbidity are significantly lower than they should be - an aerosol optical depth of 0.1 corresponds to a turbidity of 2, while in your table it corresponds to a turbidity of 1.11, so it appears that you are overestimating the visibility. How did you calculate the values in the table? Regardless very interesting work, using AOD data for turbidity is something no other Lua scripts I know does, this approach is definitely more physically correct.

I mean the terrain is well known at this point, it's being worked on. The team, including me, has been working on the terrain for quite a while. I have some potential improvements to the star wars type rain. What do you mean with "three colors at night?"

In what way do you think it looks like a cartoon? I'd appreciate more details. The lighting, atmosphere or the terrain?

Did anyone do the experiment I mentioned in my previous post? I still need some input to verify if the rendering part is correct or not. Referring to this. In short, I want to verify that the manually set visibility indeed looks correct.

I wrote the haze rendering code so I believe I can add some input too. As Janov said, currently we believe the issue is not haze rendering but the accuracy of the visibility setting being injected into the sim in live weather. So the sim correctly renders x kilometers of visibility when it's told to render x kilometers of visibility (like when you manually set the visibility in the weather configuration), but the live weather engine tells the sim to render a visibility which doesn't reflect the real visibility. In other words, the live weather believes it's x kilometers of visibility when it's not. At least this is my understanding, however @Janov can correct me if I'm wrong. However I want to be 100% sure that this is the case, so I'm asking for some feedback. Ignore the live weather, just set the clear weather preset, and then adjust the visibility slider to a specific visibility you know how it looks. Does it look accurate to real life when you do so? If not, I'd really appreciate some feedback especially with visual evidence. The aerosol (haze) turbidities were calculated based on OPAC dataset (Optical Properties of Aerosols and Clouds, a dataset for reference atmospheric conditions which is used for everything from building lighting studies to reference radiance transfer simulations / renderers) and based on test approaches I did the visibility setting accurately reflected the visibility in the simulator, but I'd like to be totally sure.

The turbidity control is for the aerosol turbidity, which is only used for depicting visibilities down to 8 km. So lower visibilities (< 8 km) will still be correctly depicted as such visibilities are depicted not using aerosols but using a water "cloud" (fog) layer rather instead.

The single and multi rat are constants of the atmosphere and they never change based on conditions. The turbidity is set by the weather engine, as it controls the haze amount. Overriding turbidity will indeed prevent variations of haze brought by real weather.

Turbidity should never be less than one as it's defined as the ratio of extinction coefficient of the currently being rendered atmosphere to the extinction coefficient of a clean (Rayleigh) atmosphere. So a turbidity of one is the maximum visibility / minimum pollution.

Yup this is my understanding too - it's just developers disclosing their potential conflict of interests, in terms of everything else it's the same as non-commercial member from what I understand.

I mean in terms of lighting there was no change, these changes are post-processing related and as a result the colors might be slightly different, but the lighting code is identical.

What looks different in terms of the lighting? Are you comparing it against b1 or b2? Because while b2 has changed the lighting a lot, b3 didn't change anything. Either case could you please post a screenshot of a case where you think it looks different? So I can look into it.

I personally don't recommend changing it, the current value of it is physically correct and anything else is going to be inaccurate. It was calculated based on the luminance ratio between double scattering and all multiple scattering orders. The reason I don't recommend changing it is because there is a better dataref to change which creates the same effect - scattering/hack_cloud_shadows. This controls the shadowing of the multiple scattering due to the clouds. The correct value for it 0.5 (or slightly below, technically the physically correct value is supposed to be 0, but due to the nature of the approximation we use to calculate the shadowing of the multiple scattering, it often underestimates the brightness levels, and 0.5 sets a limit to the attenuation based on the mathematical worst case scenario. It was not set to 0.5 because the art team felt that even 0.5 is too low in some cases, and they're almost always right on this kind of stuff (massive shoutout to the art team especially to Daniela), so it was decided to be set to its current value until we found a better approximation. This is one of the very few remaining hacks in the lighting model, but thankfully it often doesn't have a major visual impact. We're still working on a better approximation for it. Also I need to add the mandatory disclaimer (for my own safety 😅), editing private art controls is discouraged.

BTW I won't be working much on the cloud formations fix, which is why I couldn't even remember the correct timeframe for it 😅 (In hindsight I should've checked it instead of going by memory, once again I'm sorry about that.) The city lights etc. illuminating clouds are definitely on the roadmap, but with no estimated timeframe right now.

It's planned to be addressed this year, as per the public roadmap. I just misremembered it as 12.3, sorry about that.

Yeah unfortunately cloud formations are still the same as before right now, in other words, pretty hit or miss - this update was to improve the lighting and I believe we managed to do a good job at that, but without the proper formations to "show off" that lighting of course the entire experience is going to be hit or miss too. Depending on the situation sometimes you can get cloud visuals you won't find in any other sim, and in other cases you will get clouds straight out from Minecraft. The cloud formations are going to be addressed in 12.3 as it requires a full redesign of the cloud volume system, the current system unfortunately seems to be a dead-end regardless of the band-aids we apply on top.

Yes, in a perfect world an extra simulation of sun blinding the eyes wouldn't have been needed as it would've been taken care of automatically by the autoexposure, but the 65k nits limit is causing a lot of issues in that regard, as the autoexposure system doesn't even "see" the sun. As a quick experiment, one can set the sky 90 degree up in the sky and slightly move the camera to get the sun in and out of the frame, you will see that the metered EV100 changes very little.

The sun is not in the frame in that screenshot, I assume you confused the overexposed area of the sky (the glow is due to Mie scattering) with the sun? Like I've said in 12.1 and before the cockpits still look dark regardless of whether the sun is in front of the cockpit or not, in fact darker when the sun is behind. Either case I understand, different people have different preferences so it makes sense to make it toggleable. Lastly, other developers are working on the things you mentioned so the work on exposure fusion did not take away any development time from them.

Just a minor correction, you will still be able to blinded by the sun. Like I said above the goal of exposure fusion is not to implement some cheap HDR effect, but to simulate the local brightness response of eyes, with the term "local" meaning different regions of our vision are "exposed" independently, rather than a camera which would expose the whole scene with a single exposure value. So 12.2 is not intentionally making things less accurate to make things look nicer, it's making things more accurate by processing the rendered scene not like a camera but like an eye / brain. Exposure fusion also does not alter anything if the scene can be exposed well with a single exposure value. See the A321 screenshot in sent by @efis007 in page 2 of this thread - I'm pretty sure that's my screenshot, and I had intentionally taken that to demonstrate how the dark cockpits issue was not related to the sun blinding the eyes. The sun is way up in that screenshot, so there is no direct sunlight coming to your eyes whatsoever (which indeed would have been blinding), yet the cockpit is unrealistic to what I see IRL looking from an A320 jumpseat. When there is sun in the view, it will still dominate everything. Though as a fun fact the sun's blinding effect have never been properly simulated in X-Plane 12 to begin with, as we can't fit the sun in its full brightness to the HDR scene buffer (16-bit buffer, maxes out at 65536 nits), when the sun is 1.9 billion nits. However like I said 12.2 does not cripple the sun even further. In fact ironically the cockpits looked darker with the sun was facing up / behind the cockpit than facing the cockpit & camera in 12.1 and before. This would not have been the case if dark cockpits issue was caused by the sun blinding the eyes. With that being said, it's planned to make exposure fusion user toggleable, so if one prefers seeing the scene like how a camera would see like in 12.1 and before, that will still be an option.

Yes but LR team uses all OSes, we have devs who use Windows, Linux and macOS. For instance Sid uses Windows, Ben uses macOS, Daniel uses Linux and so on. In other words, there isn't a case where an OS is a second class citizen. Also this is my personal opinion but I feel like the issue of services on Windows is (slightly) overblown. Yes Windows is notorious for being bloated with services and other stuff, but the OS is not completely clueless and the footprint of them reduce a lot when a game is running. With that being said the story is different when it comes to lower end hardware, where the bloat becomes a lot more significant, and this is one area Linux shines. Lastly I feel like comparing utilization values between different OSes might not always make sense, as different OSes might have different interpretations of utilization. If anyone is wondering what I'm using, I'm using macOS right now. I was a Linux user before, and a Windows user before that. I personally had comparable performance in both Linux and Windows (I can't compare macOS as it wasn't the same hardware) and good stability in all of them (in Linux my stability experience wildly depended on the distro though), though I should mention that I had mid-high end hardware (i5-12400F, 3070 Ti), so Windows' bloat wasn't exactly bottlenecking things as it handles the bloat better when a game is running like I mentioned above. I have spicy opinions on which one I like the most but I'm going to keep that to myself 😅

On the bright side it's over - I know it was a really annoying (sometimes even deal breaking) issue especially if you fly airliners, and the fix took its time for the reasons I mentioned above, so I understand the complaints. As a simmer I was not happy with it either. I even had my fair share of heated arguments trying to explain the issue here before getting hired by LR, but in the end it's finally fixed, so it's time to celebrate.

For sake of clarity I'm that person, I'm still hanging around here (even though not as often). I just created a new account as the other one was not a "Commercial Account" which was causing confusion sometimes. With that being said, a huge part of the credit goes to Daniela, Daniel and Ben too, we worked a lot on fixing the remaining lighting model issues and tuning of exposure fusion (the local exposure model to simulate eyes). Lastly like I've said at the beginning of the thread the issue is fixed in 12.2 update. I am aware it took its time but it was not due to LR not caring about it, it's just that completely reworking a lighting engine is not an easy task. We had to measure several times, and cut once to not make third party developers re-tune things again and again.

Small aircraft and aircraft with light panels had the issue way less yeah, so it's normal that you didn't experience it. The higher the brightness difference between inside and outside, the worse the issue got. As a result Toliss A320 series was one of the worst affected I think, seems like someone even reposted my old Toliss A321 screenshot here, and indeed it could look as bad as that at "right" conditions.

Yes basically, if the dark cockpits issue existed in XP11 it was caused by a fundamentally different issue. The XP12 dark cockpits issue is completely unrelated to it, like you said. However the issue was the opposite - it wasn't caused by mimicking the human eye, it was caused by not mimicking the human eye. I think I had gone into detail long ago here with my other account (@Biology) but in short our eyes do some local brightness processing that was not simulated until now. This was not an issue in XP11 as it was not physically correct, but XP12 with its physically correct lighting meant massive lighting differences between inside and outside, which got processed like a camera rather than an eye. If you remember the photos from old iPhone cameras (from iPhone 3GS era, before phones were capable of doing any processing and just showed the raw capture), they had the same darkness issue.

Hi, Assuming you mean dark cockpits, yes that was one of the main focus areas of the 12.2 update, and it is fixed. The entire lighting system got reworked, and that naturally includes "fix and repair" too.

Yeah I agree but I also feel like at least Quest 3 is nothing to be sneezed at. I had an HP Reverb G2 and I wasn't a big fan of it - I hate fresnel lenses as they are only sharp at a small area and they have a lot of chromatic aberration, at least this was my experience with the G2. Quest 3 with its pancake lens is a massive improvement over the G2. Meanwhile seems like Quest 3S uses a fresnel lens. I know there are much better pancake lens VR headsets but they are also pretty expensive compared to Quest 3, so it's my favorite right now - affordable and (imo) has a better overall clarity than even G2.