sundog

I'd keep a copy of the installer someplace safe, just in case.

Andy, I think your issue is different from Tom's. I did try flying around Detroit this morning and things looked OK to me, so whatever was happening to you may have been specific to the METAR conditions in place last night. If it happens again, please post your log.txt and your metar.rwx files and we can investigate more deeply. I have a hunch that another fix I just made based on another report may help, though.

Just to follow up, I took the time today to reproduce your exact scenario. It was more complex than I assumed; basically the weather stations around Juneau were reporting conditions that were all over the map, creating many cumulus cloud layers at widely different altitudes intersecting the stratus layers at widely different altitudes. It was a very tough set of conditions for RWC to make sense of. I've coded up some changes that will handle something like this better in our next update, though.

OK, I see what's going on here. METAR cloud heights are specified as AGL (above ground level,) but in X-Plane we need to draw them in MSL (above mean sea level.) To convert between the two, SMP 3.2 tests the height of the terrain underneath you to figure out where "ground level" is. Problem is, if you're flying over mountainous terrain or over islands, ground level changes frequently, and that's what's leading to the cirrus cloud moving like it does. Coding up a fix now.

Thanks. I'll take a flight in your region and see if I can get it to happen and see what's going on. EDIT: Yup, I see it here as well - the cirrus cloud keeps changing altitude. Looking into it.

It would certainly help if you could provide your log.txt file after experiencing this. I'm not real sure what you're running into, to be honest. But the log file may shed some light on it. There's a chance the free 3.2 upgrade, which is available now, could help too - it's worth a shot, anyhow.

It's kinda technical, but Ben Supnik describes it here: http://developer.x-plane.com/2016/04/actually-you-can-be-told-what-the-matrix-is/ In short, 10.50 exposes information to plugins that we can use to avoid stalling the graphics pipeline.

If you removed RWC, you'll need to download the latest version of it and re-install it as well. If the real world weather option is missing in the SMP config menu, it means RWC is not properly installed (or there is some sort of license authentication issue going on.)

It'll represent the overcast cloud with puff particles instead of as a solid slab, but it's the only way to completely avoid these sorts of intersections for the time being.

I think it's probably specific to where you were flying and the weather conditions there at the time, so there's a good chance it will just clear itself up. But switching to one of the older cirrus textures (4-6) and setting the overcast representation to "dense particles" will probably work around most of what was going on there for now.

Your log confirms it's associated with crossing tile boundaries, combined with impossible cloud layer altitudes in the METAR data that RWC struggled to compensate for. You must have been flying across the corners of adjacent tiles for it to happen that often. Thanks for the data; it gives me something to work with. Cute dog.

I think you are crossing 1-degree tile boundaries in X-Plane. When this happens, X-Plane changes its internal coordinate system, which invalidates the placement of our clouds. In SMP 3.1.x + RWC, we simply made the old clouds disappear entirely and faded in new, repositioned ones when this happened. In 3.2, instead we do our best to reposition the existing clouds we have into the new coordinate system. But sometimes, there are changes in altitude that result, and I think that's what you're seeing. It's the lesser of two evils, however. Clouds disappearing and reappearing entirely was even more distracting, and had a much larger performance and memory impact when it happened. What you're seeing in your video seems a lot more extreme than what I saw in my own testing, however. Can you tell me what location you are at?

Yes, it's intersecting cloud layers in the METAR data. SMP tries to prevent this by moving them around if necessary; I think what happened is that by increasing the cloud draw area, it caused SMP to produce larger cloud puffs, and so it actually needed to move them more than before to avoid this sort of thing. It should be a fairly rare occurrence and specific to certain cloud draw area settings and weather conditions, but in the meantime switching SMP's overcast representation setting to sparse or dense particles should avoid this anomaly entirely. I will make a change for SMP 3.2.1 however to avoid this case better regardless of settings. Thanks for including your log.txt; it made this very easy to pinpoint.

Did you turn up the cloud draw area really high by any chance? Toggling "always" will make RWC get new weather and recreate all the clouds around you. If you draw area is large and there are lots of clouds in the area, this can take several seconds, and X-Plane will seem unresponsive during that time. If you're tight on VRAM, then you probably need to lower the cloud draw area setting. If memory is swapping, it could take even more than several seconds for that to complete (if it can at all) I don't remember the VRAM usage at max settings in the currently released version of SMP, but I want to say it's around 500MB if you turn everything up all the way and fly into heavy cloud cover. There are some changes in the upcoming 3.2 update to reduce that figure further. As for what's eating your VRAM even with SMP disabled and stock scenery - could be lots of things. A really high display resolution; high texture resolution settings; HDR mode's extra buffers; a demanding third-party aircraft... could even be some other application you have open in the background.

If you turned up the cloud draw area, that can demand extra memory from your system that might not be available if you're running with lots of custom scenery. By deleting settings.dat, you restored it to its default setting, which may have allowed you to stay within your system's memory capabilities.

SMP needs SilverLining and Gizmo; and PluginAdmin comes with X-Plane and is harmless. I don't know if the IXEG needs those other two plugins (Cameron?)

The one other time I saw something like this from a customer, it turned out to be related to a defective video card that had been recalled by Apple. Your model is much newer than that one, though. There are plenty of people using SMP and the IXEG together successfully on Macs, so I don't think there's a general incompatibility there. Do you have any other add-ons installed? If something were invalidating OpenGL textures under the hood, it would explain this sort of thing. If there's a workaround to be had other than disabling other plugins, Cameron's right in that HDR is likely to make a difference. It is worth trying.

Updating your video drivers, and/or resetting your video driver settings, may also be worth a shot.

What I'll need is the METAR.rwx file and the location you were at.

Please refer to the documentation for SkyMaxx Pro and RWC; you're probably running out of VRAM and it outlines steps you can take. The first thing to try is reducing the "cloud draw area" in SMP if you had turned it up previously.

Did you try my initial advice of changing the overcast representation to dense or sparse particles?

It really comes down to tradeoffs between visual quality and performance. These particular cloud types are especially demanding on today's GPU's. Remember our clouds are truly 3D and volumetric, so you can't really compare them to the flatter representations other sims use for these clouds. You're right that these clouds don't really get quite that close to the ground in nature (usually); the intent is to approximate the "virga" you see underneath a heavy thunderstorm which does reach the ground and obscures visibility beneath the cloud. The cloud size, although not as huge as I'd like in a perfect world, is still realistic - they range from 5000 to 7000 meters tall when created by RWC (16,000 - 22,000 feet.) A big challenge for us is that there are many different kinds of cumulonimbus clouds that can be in a wide range of development, and METAR data doesn't really give us any insight into which one is "correct" for a given location. Our thunderstorms may look great to someone in Florida who sees fully-developed monsters every day, but not so much to someone in Europe where the conditions are different. Anyhow I agree it's something we can keep iterating on and making better in future versions, especially as video cards keep getting faster over time.

You can't go by what X-Plane's rendering options menu says for VRAM. That only counts textures used by X-Plane. SMP's control panel says you only have 433 MB of VRAM available, which is more accurate. However, that should be enough. I suppose it's possible that your new nav data triggered an ATC error exposed by some existing scenery you had installed. If you post your log.txt file after experiencing a crash, it might tell us more about what happened.

It sounds like you're out of video memory. Did you start flying over some new custom scenery, or start flying with a new plane, just before the problem started?

SMP takes steps to prevent solid overcast layers from intersecting with cumulonimbus clouds, because that looks unnatural. You're probably seeing the effects of that. You might try changing your overcast representation setting in SMP to something else to get different results. The sparse and dense particle settings won't be affected by this particular behavior (but they also won't honor a crazy request for a 30,000 foot thick cloud layer in order to preserve performance!)