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.