sundog

MacOS actually deals with low VRAM surprisingly well. If your performance seems OK, just hit the "never show this again" button on the dialog that warns you about running out of VRAM, and carry on.

Yes, I've seen that video you're talking about has reared its ugly head again on YouTube and is making the rounds again on social media. It represents a very specific problem with certain METAR reports that we've already fixed, but it has nothing to do with what you're seeing. Like Cameron said, I think you'll be happier with "dense particles". In your first shot, I think the visibility is just so low that you can't really see the bottoms of the clouds above you. But dense particles should make them more visible.

This particular thing has nothing to do with VRAM. But as mentioned above we have a fix that's going into testing soon.

Well, I don't want to tip my hand too much as to what we have planned for the future! But I do think that's a good idea, and I can think of a couple of ways to do it.

I think it should (fix it) but we'll be sure to give that extra attention in beta testing.

In the meantime, you might try experimenting with different cirrus texture selections in the SMP configuration screen. It's much less noticeable if you choose a cirrus texture that doesn't have many clouds near the plane's location.

This should only happen if you change the time of day while flying and pan the camera around. Once you fly for a few seconds it should clear itself up. It's a side effect of an optimization to maintain fluid framerates when the lighting conditions suddenly change. However, there is a fix for this slated for our next release.

I've asked Ben (author of Gizmo) to have a look at that error message. I don't know if it indicates an actual problem or not. As for the dark layer - that's a "broken stratiform" layer as seen from below. You'll see it in RWC if the entire surrounding area is reporting overcast conditions at roughly the same altitude, and you have "broken stratiform" set as your "overcast representation" in SMP's configuration screen. If you don't like it, try different settings for "overcast representation." It's pretty unusual for overcast clouds to appear at such a high altitude. My guess would be that the overcast layer was intersecting with the broken cumulus layers below you, and got pushed up to avoid intersecting. If your log.txt says anything about moving stratus layers to avoid a collision, that's what happened there - and our next version will handle that case better. But if your log.txt doesn't mention that, we're just doing what the METAR reports tell us.

I'll have to defer to the community here as I don't use EFASS. I know some EFASS users hang out on the XPD group on Facebook as well who would be happy to help. However - as long as you have the latest SMP and X-Plane installed, the NOAA weather server drama should be resolved. And word has it that the newest NVidia driver that just came out may address the Windows 10 framerate issues. Keep in mind that if you set RWC to "always" it will be getting METAR directly from NOAA's servers (not the NOAA plugin) and using that to position the clouds. So if you're using an external weather add-on, there could be discrepancies if we're using different source data. But that is still the recommended setup when using external weather engines other than FSGRW. One other recent development in X-Plane weather is that a lot of people seem to like the new "Ventura Sky" package; you may want to look that up.

Just tested using your METAR.rwx file at KILM here, and overcast clouds did appear. Try jujub's suggestion, or it may be that you're not using the latest SkyMaxx Pro version. Make sure you have version 3.3.2 installed; there was one earlier version that didn't work with FSGRW. FSGRW has also had some updates recently that you'll want to be sure to have as well.

The METAR file you attached actually doesn't show OVC at 16,000 feet. Here's what it says for KPIA: KPIA 060849Z 02006KT 3SM R13/5500VP6000FT TSRA BR FEW005 BKN023 OVC075 18/18 A3004 RMK AO2 LTG DSNT ALQDS RAB04 TSB12 P0054 According to that, OVC should be at 7500 feet, FEW at 500, and BKN at 2300. Which is totally different from the weather display you're showing. But it would seem that X-Plane's internal weather system believes there is an overcast layer at 16,000 feet - but based on what's in your METAR.rwx, I can't see where that would be coming from. In this case, I think we're right and X-Plane is wrong. This results in precipitation being inconsistent with the clouds you see, but we're working on that problem separately.

No, not yet.

There have been a couple of bug fixes related to imposters since 3.3.2 was released. I think you'll find our next update improves things.

Thanks for providing all those details. You've hit upon an edge case and gave me the info needed to track it down. Short answer: if you switch the overcast representation in SMP's configuration to "sparse particles" or "dense particles", you should at least see clouds on the ground to represent the ground fog in this case. And the reason your ground fog layer wasn't on the ground in this case will be fixed in our next update. Long answer: So here's what was happening under the hood... I'm explaining this mostly to emphasize that this only happens under a very specific set of conditions. The entire surrounding area of PAWI was reporting fog in some way. RWC saw that you wanted our "solid stratiform" overcast representation, and went ahead and created a solid stratiform layer just above the ground across the entire scene as it should. However, a few surrounding weather stations were also reporting scattered clouds at low altitudes. I'm guessing their intent was to indicate broken fog, but RWC takes the report literally and tries to create some scattered cumulus clouds near the ground in response to these reports, over the stations that are reporting them. The way SMP draws solid stratiform clouds does not interact well with cumulus clouds when they intersect. You can end up seeing the tops or bottom of cumulus clouds sticking out of the top or bottom of the stratiform cloud, which looks weird. So to prevent this from happening, SMP goes through all of the cloud layers in the scene, and moves the stratus layer up or down to prevent such intersections. In this particular case, it moved the stratus layer up to around 5000 meters in order to avoid it intersecting with those scattered cloud areas nearby. So, your fog bank was there - but it got pushed up to around 15,000 feet! The "broken particles" and "solid particles" options for overcast layers play nicer with scattered or broken cloud layers, and so this shuffling of layer heights to avoid intersections doesn't happen when you have either of those options selected. That's why solid or broken particles works around this particular issue. For our next update, I've changed the way RWC handles stratus / cumulus layer collisions by simply removing the offending cumulus layers. That way, the stratus layer remains where it should be, and the reported cumulus clouds that would be inside that fog bank are just discarded. I think this keeps the scene closer to reality. Again, thanks for providing your metar.rwx file so I could track this down and fix it.

I really appreciate your posting this. Glad your performance is back up!

There is no option to disable imposters at present.

Unless the entire surrounding area is reporting OVC at roughly the same level, SMP/RWC will represent smaller areas of OVC clouds as either "sparse" or "dense" particles. You might want to set SMP to dense particles to ensure maximum coverage.

I think that's a 3GB video card, which means you're running pretty close to being out of VRAM there. Once memory starts swapping, performance is done. Your large display resolution is eating some of that, but as for what's consuming the rest - that depends on the add-ons you have installed. Basically you installed something that tipped your VRAM usage over the edge, I think.

My guess would be that they are sampling the sky colors based only on the solar azimuth angle, and not the actual time of day.

Alright, I have to take a stand on this one. It's perfectly reasonable for customers to expect to find system compatibility information for a product before they purchase it. We need to fix this. How long does it take to put a message on the checkout page warning users that Linux is not supported?

Well, X-Plane 10.50 uses a bit more resources than 10.45 I imagine. So if you were running on the edge of your available memory, VRAM, and/or CPU power, perhaps 10.50 just pushed you over the edge. Your system should be more than capable of handling it, so I'm betting you have a bunch of other add-ons installed that may just be too much now. If you want further guidance, post your log.txt file and we can give some advice on what might be eating up your resources.

SMP/RWC runs fine with 10.50. If you're running into performance problems, I'd suggest resetting your SMP configuration settings to start from a known good configuration, and then turn up the cloud draw area while you're in stormy conditions until performance is no longer acceptable in order to find the sweet spot for your system.

No, this crash is unrelated to SMP/RWC. Your log is inconclusive about the actual cause, but I can tell for sure it's not the same issue discussed in this thread. There is circumstantial evidence that your "dataref tool" plugin may be to blame. Did you install that recently?

Some great shots! Thanks for posting.

Alrighty, the fix for this new case (METAR reports where fog is indicated, but no cloud cover or vertical visibility is indicated) has been coded up and tested. Here we are looking back at UMMG using the METAR.rwx file you provided: This will be included in our next update. Thanks again for the detailed information.