sundog

Try lowering your cloud draw distance setting to about 3/4 and it should eliminate that tearing when reflections are on. We'll fix that for the 1.3 release. Thanks for the feedback on the other two points!

Sounds like a pretty awesome setup, Rolf. I don't have an easy way to test this here, but I do know the underlying cloud engine used by SkyMaxx Pro is used all the time in professional multi-channel training simulators - and in principle, I know the line of code to add that should make the clouds line up in SkyMaxx Pro as well. I will add that in for the SkyMaxx Pro 1.3 release for you, which we're already working on.

It has to be 3D Studio - you have to export a VRML file with spheres that represent the cloud puffs, and our VRML parser is only written to handle the way 3D Studio writes it out. Glad you're enjoying SkyMaxx!

3saul, it's not a XPX limitation, it's just how we model the clouds. There is a slider in the SkyMaxx configuration for the cloud sizes, which controls the maximum size the cumulus congestus clouds can reach. This ranges from 500 meters to 5000 meters, so cranking that up should result in larger, thicker clouds. The cloud sizes follow an exponential distribution (as they do in real life,) so it may be rare to get a really big one even with the slider all the way up. You asked specifically about cumulonimbus clouds - these are the "thunderheads" we sprinkle in the scene when X-Plane tells us thunderstorms are present. These are hard-coded to be 5KM across and 7KM tall (we really should add some randomness to that to make them a little more visually interesting - I think I'll do that now). But, these are anvil-shaped clouds and not the sort of towering cumulus cloud in your screenshot. Providing more variety in our cumulonimbus cloud shapes is something we can look at for future revisions. It's actually possible to model your own cumulonimbus cloud shapes if you have 3D Studio Max - any adventurous souls interested in trying it out should PM me for details.

Ah yes. The solution to those sharp cloud/ground intersections is a technique called "soft particles," but we would need access to X-Plane's internal depth texture in order to do that. We should lobby Laminar to expose that through the XPLMGetTexture function, and other useful textures such as the reflection texture.

It will be switchable in the SkyMaxx configuration, flydav. It's already coded up.

Yeah, if you spread that load out over multiple frames you could build up a larger / higher resolution area without hurting performance too much. Do those terrain probes give you any bathymetry, or do you always get a height of 0 when testing above the ocean? Mostly I'm wondering if there's an easy way to detect the shallow water near coastlines. Effects like breaking waves and blending water with terrain would need that information.

Does anyone know of a specific built-in airport or aircraft in X-Plane that exhibits this problem?

Ben, are you basically constructing a height map of the surrounding area using a ton of intersection tests? How long does it take to generate that?

I only asked about real weather because that would cause SkyMaxx to create new cloud layers and remove the old ones whenever you fly into new conditions. So if there was a leak associated with the underlying cloud layers, it might explain this. However, I just ran some tests in SilverLining where I created and deleted a large cumulus cloud layer repeatedly and measured memory at each step - and there is no evidence of a leak there. I am also not really seeing the slow leak Ben reported when running X-Plane with SkyMaxx installed. Looking at the chart bunchy put together more closely, the case without SkyMaxx also reaches a peak memory usage just before reaching the point where memory was exhausted. It seems that the case with SkyMaxx is following the same general memory usage pattern as the default weather case, it just consumes more memory in general than default - which is expected, given the additional detail we provide. To me, it doesn't look like a memory leak so much - it looks more like a system that was running on the edge of memory usage to begin with, and SkyMaxx just pushed it over that edge. The best way to reduce SkyMaxx's memory usage is to reduce the cloud draw distance setting in the SkyMaxx configuration. But, I'll step aside and let the pro's (Cameron / John / Ben) weigh in.

bunchy, does this only happen when you are running with real weather on?

Make sure your visibility setting is high in your weather settings. Clouds will fade out at your visibility setting, or the cloud distance set in the SkyMaxx configuration - whichever comes first. Thunderstorms are placed randomly within the cloud drawing distance, so it is somewhat luck of the draw whether they appear near or far from the camera. As Cameron pointed out, X-Plane does not give plugins any localized weather information - all it tells plugins about storms is "there are storms around you, and on a scale of 1 to 10, here's the overall intensity of them." SkyMaxx interprets that intensity as the number of randomly placed storm clouds it creates in response to that message. It would take a more sophisticated weather injector that can pass more information to SkyMaxx, or an update to X-Plane, to do something more precise.

Yes, the underlying cloud system (SIlverLining) does have a real-time cloud growth feature. That could help spread it out, and it might even look pretty cool to see the clouds form in front of you. We're working on testing out a smaller patch release right now, but I'll have a look at this when we're looking at new features for a version 2.0 down the road.

Thanks for the suggestions! When the weather conditions change, what's really taking all the time is "growing" new cumulus clouds. SilverLining creates each cloud shape using a cellular automata technique, which ensures no two clouds look the same. They already share VBO's, it's this simulation of cloud growth that takes some CPU cycles. The way we usually get around that is to create a single cumulus cloud layer at 100% coverage when loading, and then just enable and disable individual clouds at runtime to achieve the desired coverage. I'm hesitant to do that in SkyMaxx Pro, however, since we would need to have three of these 100% coverage layers around in case we need them, and they would each consume quite a few GPU resources even if sitting there unused. Since a lot of users are already on the verge of running out of GPU memory with high resolution scenery etc., this seems like a risky thing to do. However, it could be something we could expose as an option for users who have graphics cards with large amounts of GPU memory. As for clouds forming in front of the plane - check your visibility setting in the weather dialog. Clouds will fade out at the specified visibility distance, so if this is set too low you will see clouds forming close to the camera even if you have a high draw distance set.

Short answer: it is always safe to let the X-Plane updater overwrite core files with SkyMaxx Pro installed. Longer answer: When the SkyMAXX Pro plugin is activated when you launch X-Plane, it copies the sky_color_*.png files inside \\Resources\\bitmaps\\skycolors\\ into \\Resources\\plugins\\SilverLining\\skyColors\\Default Sky Colors\\, and will copy any custom sky colors you've specified in their place. If you've left SkyMaxx's sky color setting at its default, it just copies the default sky colors back in, and nothing actually changes in your X-Plane core files other than their creation dates. However, that can trigger a warning when upgrading, and it is safe to let the updater overwrite them. So, \\Resources\\bitmaps\\skycolors\\ is the only directory we mess with in normal circumstances. There is also a rare case (in fact I'm not sure it ever happens at all in practice) where if our attempt to disable X-Plane's built in clouds fail, we will temporarily back up the contents of Resources\\bitmaps\\world\\clouds\\ into \\Resources\\plugins\\SilverLining\\savedClouds\\, replace them with 100% transparent textures, and then restore the original contents when the plugin shuts down. Hope this helps.

In that scene, I think the sun is below the horizon, and there is very little moonlight. Clouds can get weirdly dark in that situation (see http://pictures.4ever.eu/data/674xX/aviation/aircraft/boeing-kc-135-stratotanker,-afganistan,-clouds,-twilight,-airport-161467.jpg for an example.)

In case you're curious why those two folders are empty - they exist for hand-modeled cloud shapes. Only cumulonimbus are hand-modeled, since they have a very specific anvil shape to them. The other cloud types are "grown" procedurally using a cellular automata technique, which ensures no two clouds look the same. If no model files are found for a given cloud type, the procedural approach is used instead - and that's what we want for cumulus congestus and cumulus mediocris.

Ben, I noticed that the offending code makes use of STL vectors (or some other STL container.) Could it be an issue with different STL libraries used between the various plugins involved? That would especially be a concern if STL structures are somehow passed between the plugins and X-Plane. Also, commenting out this code will basically leave you with empty vectors for gizmo_XPSceneryProbeResult, gizmo_DrawResult, etc. It's possible that the issue is triggered where these vectors are later processed, and not where they are populated. That all said, this code does allocate a bunch of memory. It's certainly possible that it just exposes some sort of invalid memory access in XSB. If you've run your plugin with a Visual Studio debugger attached to it with all the exception handling options on, and it doesn't pick anything up, I'd say that clears Gizmo of wrongdoing. Another possible workaround would be to see if INSIGHT_PROBE_STORAGE_SIZE can be reduced somehow to limit the memory allocated, or to come up with some way of processing smaller subsets of this data instead of all at once. Also I assume all of those new's are balanced with delete's somewhere...