Havner

RTH's visibility setting are basically setting weather's visibility. Setting this by hand will make X-Plane disable real-weather and fall back to uniform weather. That's because visibility range is tied to weather. It's either automatically updated or set by hand in weather settings. There is an ugly workaround though. Set X-Plane to uniform weather. Set RWC to "always". Then you can set visibility by hand (either in RTH or in X-Plane's weather window). Though with this setting you will only have clouds set from real weather stations (by RWC). You won't have any other weather updates (winds, etc).

And when you're using TrackIR 30 FPS starts to become too low. 45+ minimum to have relatively smooth experience. 60 preferably. Without it 30 is enough.

It's probably programmed to do that regardless of what changed. From a programming point of view this is the safest option. But when you fly and new clouds appear in front of you and old ones disappear the scene is not refreshed everytime that happens. So even now it can add new clouds to the scene and remove some others without a full refresh. Same for weather change.

Pretty much the default, here you have. I don't even think that there is anything in the settings that can change the clouds colors. The screenshot was made at noon and I use RTH, but that doesn't change the clouds colors. Apart from them blending into the sky/ground at the edges.

Hi, In the screenshot look at the distant cloud shadows. Probably the cloud shadows do not take the atmospheric calculations into account. I think they should be more bleak with a distance. They are rendered on a mountains that aren't even visible anymore. I don't know if you can take X-Plane's calculations (or just its data-refs) into an account and I get that Real Terra Haze is not helping here, but maybe an area for a possible improvement in the future? Best regards

I never trivialize anything like that. I know how that stuff works from the inside very well. I'm just very direct and people don't seem to like that (sometimes understandably). But I do talk merit. At least I very much try to. I had this as well. There is a long post here about the issue in 3.1 where you increase the cloud coverage. I hit this limit, but after reading it and understanding what is going on (I too had abrupt and _severe_ drops of FPS without any particular reason) I limited the general X-Plane size of textures from "Extreme" to "Very High" (I have 3GB VRAM) and it helped. It relieved I think 300-500MB of VRAM and now I can fly with 10000 sq. m. area of clouds.

Handling the bitmap itself (whether this is a simple AA or an upscale) is actually trivial. SMP tracking that data might not be. And you said that first and I agreed with you. Here, in the very same post you quoted. You: but think about it, to have any real effect at reducing the saw tooth the cell data tracking is going to go up by a factor of at least four. Me: Yes, this might be an issue. That's why I wrote it might be down to SMP not being able to actually process such a high resolution map. Maybe it would, but with me using words like "upscaling" and "SMP might not be able to handle this" it's actually clearly implied. And I assumed it was clear. Sorry, I was talking to a fellow programmer and I did use word "upscaling". I thought that must have been clear to you. With a bitmap as a simple (not scientific "white paper" style) example. Now, can we sincerely smile and move on? Because it seems we agree on everything and the pictorial you posted actually seems to refer you more. You said twice already you're done talking with me and yet you still argue about a non issue Best regards

What? Upscaling does change the size. That's why it's called upscaling. Of course you will. And that's true as well. You're saying what I said few posts before. Upscaling -> bigger resolution -> not sure SMP can handle that.

This was just an example with an image I found. Should I have scaled the pre-algorithm bitmap down (to its original size) so it would pack one "visible" pixel to one pixel of an array to make you happy? This was a simple conceptual demonstration of what this _upscaling_ algorithm does. Without taking care of any storage data. The images have been rescaled to be visible. Simple as that. You are over interpreting it.

I didn't mean to give an example to increase the data specifically by _four_. I just pointed a general algorithm. I explicitly stated that the data after being treated with something like HQ3X _will_ be at higher resolution. That's the whole point. And I am being treated as a negative here? Wow... Sorry sir, that you are being insulted by telling you about HQ3X in a civilized manner. I did not distort any facts, maybe you misunderstood me. I didn't mean to imply that a simple AA algorithm without increasing the resolution would help. Of course it wouldn't. What I meant is that dealing with an aliasing problem (e.g. that comes from METAR data) by using some specialized algorithm and increasing the grid resolution would. I think that's fairly obvious that HQ3X is not an antialiasing in normal sense. By definition it is an upscaling algorithm. But it obviously deals with an aliasing problem.

Sorry, I missed your post while replaying here. Thank you for your answer. I think that sums up what I wanted to know for now. Hopefully this can be fixed at some point. Will be looking for future releases.

I'm not cherry picking any solutions, just showing that they exist. I wouldn't propose this to anyone as they will do as they please. And seeing how SMP and RWC behave, the "map" of types of clouds do exist and looking at it's not a high resolution. I'm not talking about actually rendering the clouds but telling SMP where to render them. It is similar to upscaling retro games in my opinion. And like we both said, whether SMP can actually handle that it's completely another matter. And it was you that brought retro gaming in the first place :-)

C'mon. HQ3X is used severely in up scaling low resolution games nowadays. Firstly, my screenshot from original post was even a simpler situation. 2 colors (2 cloud types, overcast and lack of anything). Just wanted to show what it does. And here we are also limited to a low number of colors (6+lack of clouds). It would handle well.

In terms of dealing with the edges it actually is. There are very good algorithms to deal with this particular issue. Like HQ3X: (Images courtesy of Wikipedia) Yes, this might be an issue. That's why I wrote it might be down to SMP not being able to actually process such a high resolution map. But I wouldn't call a present state of it realistic. Things like HQ3X actually solve this very well. Of course. Like I said, I just wanted to know whether this will be worked on.

Well, if SMP is just following a grid provided by RWC majority of the performance is eaten by actually rendering the clouds. Anti aliasing a map can be done _very_ rarely (like every few minutes for a new map) and is not a costly operation.