The current issue we face and a possible solution?

[AnonymousUser68]

Yeah look I'll be honest regarding the current situation...

- The 3.1 update defiantly made me rethink purchasing RWC (as I imagine it did for a lot of other people). Although the performance problem was quickly resolved it resulted in a loss of confidence, I probably would have bought RWC blindly otherwise. :')

- These recent events have highlighted the issue that the performance hit for maximum cloud range is unacceptable! I have a GTX770 and I can also run with max cloud range as Sundog suggests in another thread at an acceptable frame rate. However, the compromises I have to make with the rest of my rendering settings in order to achieve this makes it unreasonable and undesirable. This is not a solution!

In my mind the solution is to have two separate adjustable cloud draw distance ranges. One for low level flight, (approx below 15,000) and one for high level flight (approx above 15,000 feet) There are several reasons for this:

- My current (and seemingly very small) draw distance range of 2,000-4,000 square km looks brilliant on the ground and for GA flying up to about 10,000 feet. When sitting at an airport due to the nature of your elevation it's basically as far as the eye can see. The clouds fade away smoothly into the distance. There's no need to have maximum cloud draw distance at theses low altitudes as it just makes the sim unresponsive and you can't tell the difference. However this value is useless when I am flying an airliner at 30,000 and makes RWC completely pointless. (hence why no purchase as of yet)

- Once I am up off the ground and transitioning to high level flight (lets say around 15,000 feet) I am no longer drawing all the stuff on the ground, have lots of system resources available and to put things simply, am running at 60 to 80 fps. Only now do I have the resources to draw clouds at the maximum range of SkyMaxx allowing me to enjoy all the possible benefits of RWC (a product I was very much looking forward to). This is where I would have my high level slider maxed out, reducing my framerate but back to an acceptable level as I am of course at altitude.

- As a side note, I believe this should be combined with better implementation of the 'imposter' clouds. To be honest I'd like to see a gradual reduction in LOD as distance increases. In my humble opinion the 100% detail clouds extend out to far (hurting performance) and the imposters are to easy to spot and too much of step down. There must be a solution in between!

Put simply...

I have my system set up (as I imagine many others do) so I sit on the ground at the most resource hungry airport + city combination, with the same payware aircraft (Jar's A320neo), the same weather conditions (clear skies, 25NM visability), and the same camera orientation (so I am pointing at the centre of the city) and sit at a solid 35 FPS. This worse case scenario allows me to account for all conditions and 5-10 FPS for the variable that is weather. While a cloud draw distance of 2,500 square km looks brilliant on the ground and results in a loss of about about 5 FPS (as is fair and to be expected) this negates the purpose of RWC! At the same time, drawing clouds to the maximum range on the ground looks basically no different and drops the performance to below 19FPS. I am not prepared (as I imagine many others) to reduce eye candy in the rendering settings just to inefficiently draw an abundance of clouds while I'm flying circuits at 1000ft AGL... Two sliders I believe would provide the best of both worlds!

Thanks,

Andy

I'd like to think this isn't just seen as whiny rant but is fairly solution driven  

I've been a long time advocator of SMP and I'm confident in what John and Sundog are capable of.

Check my original rant :') that led to SMP v2. 

And not only that but the positive end to that thread and the evident improvement!

 

Edited April 18, 2016 by X-Plane Australia

[ONDR4.cz]

Well written, I noticed that too. But rather than having two sliders, I'm sure a better solution would be to program it in a way that your max. cloud draw distance is always your maximum, but the actual cloud draw distance is based on the relative height between the plane and the clouds (or something like that). 

[Cameron]

This is indeed very well written, and I do love the idea.

The one issue I see with it is:

1. I can see a difference between the values you've used as an example on the ground. But, with a user preference as you've stated this would be okay for any one person.

The bigger issue is:

2. When you increase or decrease cloud draw you cause SkyMaxx Pro to redraw the entire scene. X-Plane actually does the same thing when you adjust cloud % in the rendering settings. I don't think many people would like this, and there's a technical challenge that we may not be able to get around.

Do this: go into sim, open your SkyMaxx Pro window, adjust the cloud draw distance and click apply. That's what would happen during this transition phase you're speaking of.

The last thing I'll say here is in regards to your lack of confidence statement between 3.1 and 3.1.1. I can respect your position on this, but considering our turnaround to correct the situation best we could VERY quickly I find the statement a little insulting. That's just personal, so whatever. But, the bigger part is the misconception of "a lot of people". I'm not allowed to talk about sales numbers here, but what you see on forums is not even 1% of what we see in emails or even representative of buyers. I'll say this much: RWC outsold our biggest release ever by a pretty good margin. Forums are naturally full of more complainers than positive vibe people because it's a place to be vocal. It is in no way representative of what's really going on! Not even close, actually. That said, we are definitely listening even to that small bunch which are "complaining". We want everyone to enjoy our products, so at least making the effort is worthy, even if ultimately not possible. When you start dealing with thousands of customers using a product you sometimes have to accept (for your own sanity) that you can't please everyone. You can only try!

[Havner]

11 minutes ago, Cameron said:

2. When you increase or decrease cloud draw you cause SkyMaxx Pro to redraw the entire scene. X-Plane actually does the same thing when you adjust cloud % in the rendering settings. I don't think many people would like this, and there's a technical challenge that we may not be able to get around.

Do this: go into sim, open your SkyMaxx Pro window, adjust the cloud draw distance and click apply. That's what would happen during this transition phase you're speaking of.

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.

Edited April 18, 2016 by Havner

[Morrigan]

I am not sure if it's even possible, since I am rather a computer nooblet, but what about LOD? If clouds are rendered, then maybe it's possible to implement, let say, five transition levels of LOD that will progressively improve the quality of the cloud once you get closer. Nothing too drastic but something that would do the job. Or even just one LOD that just changes at certain distance (let say 5,000 feet). 

That would decrease the visible "popping" scenario. 

(Now, that I write this, I assume it's not such a good idea as I thought )

[gcharrie]

hi,

with the same idea, would it be possible to fade more the distant clouds (the ones that are at the limit of the visible range) ?

I mean, the clouds coverage stops abrutbly at, says 50 kms (limit of the cloud coverage), which is not very nice looking. Beyond that we have no clouds. (this is normal otherwise our GPU will burn :-) )

Do you think that making the clouds at the edge of the cloud coverage , more 'tranparent' would be nice (and technically possible) ?

For example, clouds (or cells) from 0 km to 50 would be drawn as today, the ones from 50km to 60km, a bit more transparent (or having more color from distant fog or colors), and the ones at the edge, says  75km, more transparent....

 

(hope my question is clear :-) )

 

 

 

[AnonymousUser68]

Thanks for the responses all!

Good to see lots of positivity and yes, there very well could be a technical limitation as I imagine we have all experienced the 2-3 second wait after applying a change of settings. This is where it might be useful for John or Sundog to chime in as I imagine they understand the underlying intracies to a much higher standard than the rest of us haha!

Great point from Havner which aligns with my basic understanding of programming and suggests that it's much safer for SMP to redraw the whole scene even if it's not paticulary required! As we fly along SMP is drawing clouds in the distance and dropping clouds behind us (obviously assuming they aren't being driven by some 300kt tailwind...) without any noticeable frame dip, and although this is on a smaller scale, it does suggest that it could be very well possible.

In practice there should be absolutely no problem techincally in descent? In my mind as the set 'transition altitude' is crossed the clouds that are presently around you and within your lower level cloud range would be left as is and the clouds outside of this range would be removed from the scene. SMP would just cease to draw them! (and hopefully due to the nature of your lower altitude this drop in cloud range basically can't be seen)

The technical issues with a simple redraw obviously arise on ascent... While I don't believe a full redraw is necessary and it should be possible to achieve the transition to extended range without a noticeable slowdown, some thought has to be placed into this aspect as it's inevitably going to be more taxing on the system to draw more clouds in the scene.

A possible solution would be to have the SMP recognise when the 'transition altitude' is crossed while ascending and leave the clouds in the small range/radius as is, then over 10-20 second period it would slowly begin to draw clouds into the scene that are further and further out, just as if they were being drawn in as a result of the planes movement. I mean I currently run SMP with NOAA resulting in abrupt changes in weather, I only experience a 2-3 second slowdown when SMP removes all 3 cloud layers and replaces them with 3 new ones. It could be very possible to avoid this when only drawing in the next 50km or so of clouds, leaving the ones in your immediate vicinity as is and doing this slowly over even a 30 second period. (I have no idea of the validity, but I do appreciate this would be no small feat haha, would be intrested to hear from someone in the dev team?

Finally, sorry if you were somewhat offended by my comments Cameron. As a fellow X-Plane user who wants to see progress in the sim, it's in my interests to have products like these thrive, be purchased and drive future development. After a while away from the sim I came back to the forums after receiving an email regarding this product. I saw the overly negative vibe on the forums and was concerned for the product. As I now know, the views of the forums definitely do not reflect a majority of the user base and this makes sense, why go looking for the support forum when you're in the sim enjoying the product and having fun?! I admit there have been many times when the tables have been turned and I see users trying to blame their poor and usually unrelated performance issues on a product which I am using without problem, yet I never feel the need to comment, defend the developer and represent the 'majority' of the user base. However, as with the last time I brought something up, I do feel as though there is definite room for improvement here! Either way, congrats on your biggest release! Exciting times ahead!

Andy

Please excuse any typos, this was typed while on a train on my phone haha...

[sundog]

gcharrie - it should already be doing that, if you're not flying with Real Weather Connector. With RWC, we need to "tile" cloud layers together so that gets more tricky.

Thanks for the other thoughts, folks. I will noodle on them. My experiments in the past with more complicated level of detail schemes is that they caused more problems than they solved - even more memory consumption, or stutters as clouds switch between different representations. The main challenge I'm facing is really one of memory management; in order to avoid "stutters" caused by creating new clouds while you're flying, I must pre-create everything you might need at startup. Most performance issues being reported are from people who were on the edge of running out of memory, and got pushed over that edge by SMP pre-allocating its clouds for large cloud draw areas set by the user.

So - adjusting the draw area as a function of altitude wouldn't really help, because under the hood all those clouds are still there, waiting to go, and consuming memory some customers don't have. The only reason it works doing it by hand is because when you adjust the draw area slider, I throw away all of the clouds we had and recreate them for the area you specified, which does change the amount of memory they consume. But we can't do that at runtime without introducing massive "stutters".

Anyhow, it's complicated! But I'm always looking at ways to improve the product. Thanks for the ideas.

 

 

[AnonymousUser68]

10 minutes ago, sundog said:

gcharrie - it should already be doing that, if you're not flying with Real Weather Connector. With RWC, we need to "tile" cloud layers together so that gets more tricky.

Thanks for the other thoughts, folks. I will noodle on them. My experiments in the past with more complicated level of detail schemes is that they caused more problems than they solved - even more memory consumption, or stutters as clouds switch between different representations. The main challenge I'm facing is really one of memory management; in order to avoid "stutters" caused by creating new clouds while you're flying, I must pre-create everything you might need at startup. Most performance issues being reported are from people who were on the edge of running out of memory, and got pushed over that edge by SMP pre-allocating its clouds for large cloud draw areas set by the user.

So - adjusting the draw area as a function of altitude wouldn't really help, because under the hood all those clouds are still there, waiting to go, and consuming memory some customers don't have. The only reason it works doing it by hand is because when you adjust the draw area slider, I throw away all of the clouds we had and recreate them for the area you specified, which does change the amount of memory they consume. But we can't do that at runtime without introducing massive "stutters".

Anyhow, it's complicated! But I'm always looking at ways to improve the product. Thanks for the ideas.

 

 

So all those clouds are sitting there, consuming ram or vram?

I ask as I have an abundance of ram but my 4GB of vram is restricting... (I imagine this is the situation most people are more likely to be in)

And they'll obviously be killing FPS for those who are at their ram or vram limit, but if not at this point, they're not being drawn into the scene and should have no net effect on FPS!

Edited April 19, 2016 by X-Plane Australia

[sundog]

24 minutes ago, X-Plane Australia said:

So all those clouds are sitting there, consuming ram or vram?

I ask as I have an abundance of ram but my 4GB of vram is restricting... (I imagine this is the situation most people are more likely to be in)

And they'll obviously be killing FPS for those who are at their ram or vram limit, but if not at this point, they're not being drawn into the scene and should have no net effect on FPS!

That's right. At default settings, our clouds' memory consumption is minimal, but it gets into hundreds of megabytes if you crank up the draw area all the way. Normally a 4GB card is sufficient even then, but if you start adding in stuff like HD mesh, memory-hungry third party planes, photoscenery, etc., you can eat it up quickly, leaving nothing left over for our clouds.

Our existing imposter scheme keeps the cost of actually drawing the clouds pretty low, regardless of the draw distance. When your driver starts swapping memory is when performance goes someplace bad, and when customers start complaining really loudly. That's the main challenge we face right now. We're damned if we do, and damned if we don't - if we dynamically allocate clouds to minimize memory use, we get stutters. If we don't dynamically allocate clouds to minimize stutters, we use more memory, pushing some customers over the edge. Right now we're going with the lesser of two evils - every customer suffers from stutters in the former approach, but only the relatively few customers who were running right on the edge of their cards' memory and aren't willing to lower their settings have issues in the latter.

[Muskoka]

51 minutes ago, sundog said:

That's right. At default settings, our clouds' memory consumption is minimal, but it gets into hundreds of megabytes if you crank up the draw area all the way. Normally a 4GB card is sufficient even then, but if you start adding in stuff like HD mesh, memory-hungry third party planes, photoscenery, etc., you can eat it up quickly, leaving nothing left over for our clouds.

Our existing imposter scheme keeps the cost of actually drawing the clouds pretty low, regardless of the draw distance. When your driver starts swapping memory is when performance goes someplace bad, and when customers start complaining really loudly. That's the main challenge we face right now. We're damned if we do, and damned if we don't - if we dynamically allocate clouds to minimize memory use, we get stutters. If we don't dynamically allocate clouds to minimize stutters, we use more memory, pushing some customers over the edge. Right now we're going with the lesser of two evils - every customer suffers from stutters in the former approach, but only the relatively few customers who were running right on the edge of their cards' memory and aren't willing to lower their settings have issues in the latter.

Well said. I actually run 2 totally independent versions of XP10. One is for low and slow, the other for high and fast. It's too much of a bother adjusting everything from flight to flight. I find it much easier just choosing what I feel like flying, and starting that version of the sim. Low and slow has all the eye candy, 3d mesh and the like, with fairly high in sim settings. High and fast has stock everything, with settings mid to low. It's a lot more critical to me to have fluid movement when you have a few hundred people sitting behind you, more important than forests full of trees, and roads full of cars. I have no problem finding a "compromise" with my SMP/RWC cloud settings, you just need to be creative.