Autogen issues on long flights: additional observations

[AnkH 2,233]

Again: this "issue" is already fixed. Simply accept that also with a 9900K you have to balance your settings properly. Since I locked my FPS to 30, set FFTF to 0.33 (default value) and accepted that "high" is the best my rig can get along with for autogen drawing distance, this "issue" is almost not visible anymore for me. On top, add suitable visibility settings in ActiveSky and all is OK.

Edited January 6, 2019 by AnkH

[LRBS 943]

4 hours ago, AnkH said:

Again: this "issue" is already fixed.

this "issue" is almost not visible anymore for me. 

 

I'm sorry but I don't get it, how can it be fixed while is almost not visible.

We don't need to add suitable visibility settings to hide the problem, it's not all OK.

Many of us tried to "balance the settings", unfortunately, whatever is broken the way is programmed (code) is still there and it will be there unless properly fixed, adjusted by P3D LM.

[Bob Scott 7,715]

36 minutes ago, killthespam said:

I'm sorry but I don't get it, how can it be fixed while is almost not visible.

We don't need to add suitable visibility settings to hide the problem, it's not all OK.

Many of us tried to "balance the settings", unfortunately, whatever is broken the way is programmed (code) is still there and it will be there unless properly fixed, adjusted by P3D LM.

I don't consider reducing the visibility to reasonable distances as hiding a problem, but rather adjusting performance to operate within the hardware and software limits of the system.

I use TFR unlimited with frame rates limited instead by VSync to a 30Hz display.  I also use FFTF Dynamic to gradually reduce the FFTF setting as you descend (0.01 at the surface, 0.40 at/above 3000 ft AGL).  This preserves enough CPU headroom (on a 5.3GHz hexacore 8086K) to avoid load-shedding the spawning of autogen.  I do also keep my visibility capped at moderate values in ASP4, as much (most) of my real-world flying was in visibility limited by haze if not by anything else.  CAVOK conditions only require a minimum of 6nm vis, so setting 10-15 nm is still enough to see the immediate surface environment while masking the sight of autogen spawning off in the distance beyond the vis limits.  I know that if I set vis to effectively unlimited (40nm+) it's going to make the generation of buildings and trees visible.  The choice seems clear enough...we can lament that we can't have our cake and eat it too, but we do at least get to make a choice.

Regards

[honanhal 1,420]

7 minutes ago, w6kd said:

I use TFR unlimited with frame rates limited instead by VSync to a 30Hz display.  I also use FFTF Dynamic to gradually reduce the FFTF setting (0.01 at the surface, 0.40 at/above 3000 ft AGL).  This preserves enough CPU headroom (on a 5.3GHz hexacore 8086K) to avoid load-shedding the spawning of autogen.  I do also keep my visibility set to moderate values... setting 10-15 nm is still enough to see the immediate surface environment while masking the sight of autogen spawning off in the distance beyond the vis limits.

Wow, you couldn’t come up with a clearer case that this is a code problem, could you? 5.3 GHz and you have to limit visibility to 10-15 nm (!) to avoid popping...

This is the kind of tradeoff we’ve become used to with FSX/P3D that just doesn’t make any sense. I’m done making excuses (“maybe if we can get to 6.0 GHz we can have autogen that works as well as FS2004!”).

James

[Bob Scott 7,715]

13 minutes ago, honanhal said:

Wow, you couldn’t come up with a clearer case that this is a code problem, could you? 5.3 GHz and you have to limit visibility to 10-15 nm (!) to avoid popping...

This is the kind of tradeoff we’ve become used to with FSX/P3D that just doesn’t make any sense. I’m done making excuses (“maybe if we can get to 6.0 GHz we can have autogen that works as well as FS2004!”).

James

I choose to limit visibility but with fairly high autogen density settings.  Of course the other possibility is to reduce density and increase visibility.  But keeping in mind that the area covered by autogen increases with the square of the distance, I'd rather have it fairly dense out to a reasonable distance than have a much less dense field out further.  And it's not unexpected to find that there are still limits other than the VAS limits that used to be the real brick wall.  As Rob observed upthread, all of the sim platforms are limited when it comes to autogen buildings and vegetation.

My memory of FS9 isn't nearly as rosy as yours, I guess...I think the quality/density of the autogen is still far better in P3D, on balance, than it ever was in FS9 and any of the FSX variants, and of course at the same time we have all sorts of IQ improvements with shadows, lighting, and such that we didn't have before.

 

[LRBS 943]

Bob,

I want you to understand that I'm not looking to an unproductive discussion with you.

As soon as there are other "simulators" out there that don't suffer from this magnitude like P3D LM where autogen pops up and ground textures are delayed in loading in big squares at big distances and there is no smooth transition in these situations we should be able to conclude that there is a problem.

On the other hand, I would like to recall that the other versions prior V4.0 did not suffer from this.

On https://www.prepar3d.com/system-requirements/  lists the minimum requirements, with your system (that exceeds all the requirements) you should not be in need adjusting performance to operate within the hardware and software limits of the system especially reducing visibility to alleviate (if you don't like the term of hiding a problem)  poping or ground textures loading in patches (squares) in distance,  (being a pilot you know very well that many times is crystal clear outside and unlimited visibility, it's not Delhi or Mumbai where when you descend below 10,000 is haze) or having all the other tweaks listed in your config system. 

This software IMHO is good (that's why I have it) but having in view that there are many of us having this issue we should not disregard and advocate that this issue is OK and not ask for a fix.

Same as you when you finish a flight and find something to be wrong or not working properly you put it on MX log to be fixed, not pretend that is ok or I didn't notice it 🙂. 

[Guest]

27 minutes ago, killthespam said:

you should not be in need adjusting performance to operate within the hardware and software limits

Are you saying performance is not related to your graphics settings and add-ons and that min spec should provide 16ms frametime render guarantee regardless of graphic settings or add-ons used?  If those are your expectations, then Flight Simulation is probably not for you ... even AF2 with it's limited scope will pause to load AG in the distance, so does XP11 (and both of these platforms don't render as much unique AG as P3D nor as far).  It sounds like the experience you expect is more related to AA 3D shooter titles ... sorry but that's not going to happen for a Global Flight Simulator that has to render 1000 times more unique objects than you seen in your average 3D shooter at a distance well beyond (150nm) you see in your average 3D shooter (which has a "dynamic" visibility range of about 1-3 miles max).

You also have to understand the entire globe/planet is loaded, it has to be because it supports a global view (do a top down and zoom out, you'll see the entire planet) from anywhere.

LM could simply do what LR/XP and/or AF2 do and just NOT make certain graphics settings available period (not letting users shoot themselves in the foot) ... I think you'll find a lot of users would NOT like that option/restriction.

"Fix it" is NOT a productive discussion.  You'll either have to compromise settings and add-ons, or look elsewhere for something that meets your requirements.  I outlined the solution to avoid the problem, but it sounds like you are unwilling to simply go from "Unlimited" to setting a lower TFR value (couple of clicks in the P3D graphics UI) which your hardware can handle for your graphic settings and add-ons?  With the "Default" graphics settings that LM provide I have none of these issues, well into 100+ FPS range.  If I increase those graphics settings my FPS drops, that's "normal", it's not a bug that needs "fixing".

Cheers, Rob.

Edited January 6, 2019 by Guest

[LRBS 943]

Rob,

I'm sorry if there is any misunderstanding here.

What I said  I hoped that is very clear, in versions prior 4.0 this pop up autogen and ground textures delayed loading in squares in a fair close distance in reference to the airplane was not happening so bad even the entire globe/planet was loaded.

I have no problem at all with LM make certain graphics settings available, I actually welcome their and your  efforts in this respect to be able to do some adjustments.

Yes, I and many others have a problem with something that happens after V 4.0 regarding autogen popping and delayed texture loading in squares problems that we didn't have before.

At the same time claiming that everything is OK I wonder why there are so many videos trying to fix this autogen and other things.

Yes, to have it  fixed is a very productive discussion, it's the same situation as when you have a problem with your car or something else when is broken, you take it to the service to have fixed. Not to create a problem or a heated discussion, same applies here.

I don't think for a second that is unreasonable to ask for a fix when so many other people have these issues.  

Also to be noted that you tried to help sim community many times with many videos on YouTube (which everybody is grateful) , the last one that I remember was related to autogen popping  up and provided us with a wealth of information and tweaks that for some helped and others unfortunately not.

So I don't understand why would you reject that it might be a problem.

Regarding "unwilling to simply go from "Unlimited" it's not true, I tried and with some airplanes and I get stutters (ex PMDG, BA 146....) , I'm open to any suggestions and adjustments but I reject completely the idea to go at "Default" settings when my PC exceeds the LM requirements.

I9-9900k at 5.0, GPU NVIDIA GeFotce RTX 2080 Ti 32 GB DDR4 at 3000 on a Dell P4317Q 3840 x 2160 set at 30 HZ and only LEVEL OF DETAIL RADIUS, SCENERY COMPLEXITY AND AUTOGEN AND SCENERY DRAW DISTANCE are at max, everything else is normal and no traffic.

If you have anything that can help at least with the stuttering when I'm limiting my FPS to 30 or 31 I'm open to any suggestions but I reject the idea to be at Default settings with my PC.

I hope you understand my position and don't take it in the wrong way.

 

[honanhal 1,420]

Rob, I wonder if you have any thoughts on w6kd’s situation. Would you expect running autogen on “high” at 5.3 GHz not to provide provide headroom to not have pop-in? Why might that be happening?

James

[honanhal 1,420]

3 hours ago, w6kd said:

My memory of FS9 isn't nearly as rosy as yours, I guess...I think the quality/density of the autogen is still far better in P3D, on balance, than it ever was in FS9 and any of the FSX variants, and of course at the same time we have all sorts of IQ improvements with shadows, lighting, and such that we didn't have before.

 

No question that things have mostly moved forward, but so too has hardware — dramatically. I think it’s fair to occasionally reflect on the fact that other engines (not just shooters) have come a much longer way than ESP in that time, to be honest. That said, I am very grateful for the advances LM have made recently.

James

[Mace 1,902]

3 hours ago, honanhal said:

Wow, you couldn’t come up with a clearer case that this is a code problem, could you? 5.3 GHz and you have to limit visibility to 10-15 nm (!) to avoid popping...

This is the kind of tradeoff we’ve become used to with FSX/P3D that just doesn’t make any sense. I’m done making excuses (“maybe if we can get to 6.0 GHz we can have autogen that works as well as FS2004!”).

James

I don't have any autogen popping in my P3D, or at least I haven't noticed any with P3D in a long time (since 4.0).

I thought that was a thing of the past.

[Guest]

6 hours ago, honanhal said:

Would you expect running autogen on “high” at 5.3 GHz not to provide provide headroom to not have pop-in? Why might that be happening?

Depends what add-ons are being used, how those add-ons are configured and your location ... for example the area around EGLL with add-ons increases CPU load significantly.  I'm not aware of any CPU/GPU/RAM combo that can't be brought down to single digit FPS numbers with the right set of add-ons and graphic settings and some nasty weather ... so P3D can easily bring my 5.4Ghz 9900K with two 2080Ti's to it's knees, so can XP11 ... AF2 is the only one that can keep FPS high but it's got issues of it's own and limited depth (no weather, no AI traffic, no road traffic, no dynamic lights, no season support, no ...).  So sorry a 9900K at 5.4Ghz with a couople of 2080Ti's still isn't enough ... in fact,  you'll need to see 3X (300%) performance gain of the best hardware of today IF you wanted to max everything out with a bunch of add-ons all configured to their max also and in 4K.

What other engine is better that can match ESP feature for feature?  Hard to really say this is still ESP considering ESP wasn't 64bit and didn't have all the new features that have been added by LM such as PBR, DR, DL, increased AG density/distances, 1024 terrain tile support, etc. etc. ... what we have today is more like ESP++.

Anyway, with that said, there are always ways to optimize ... DX12 does a better job at using single instances to generate slight variants so I'm sure adjustments to the AG batching system with DX12 support might help improve AG performance.  There are also other Multi-GPU modes that DX12 support which could leverage multiple GPU's better than they currently are being used.  LM could also reduce the uniqueness of content in the AG libraries which would reduce draw calls at the cost of having AG tending to repeat more.   But to be clear, even if LM moved to DX12 with better multi-GPU support and adjusted the AG batching system and reduced the size of the AG library of unique models you'll still not see 300% FPS improvement, absolutely best case maybe 90% and that's pure speculation based on what I've seen of other products.  If we get future Ray Tracing support it will definitely NOT make P3D run faster, just the opposite, but it will make P3D look better. 

I've seen A LOT of engines, and when I actually start to pull them apart on a feature by feature compare they all start to fall the way side of "can't do that".  Now, maybe some users don't want all that is to offer in a very complex engine like ESP++ ... they want a more simple simulator ... if so, those mystery group of users don't appear to be enough as more simple products never really took a foothold such as AF2 and/or FSW.  I supported those products with my wallet, but that wasn't enough.

So the only solutions to your hardware being overloaded is with the suggestions I've made in the video combined with a 30Hz monitor (or method to operate at 30hz) will provide for many an enjoyable experience ... I do agree with you it's a compromise and it will always be that way.

Cheers, Rob.

 

Edited January 7, 2019 by Guest

[fluffyflops 1,845]

I'm also experiencing horrendous stutters with 4.4. 

So if I use a 30hz monitor I try using the  fiber frame tweak. 

Question 1.What fiber for frames locked at 30?

Question 2. What fiber for frames unlimited 

I see so many different posts ranging from 0.01,   0.10,  0.33   etc etc

Thanks 

 

 

 

Edited January 7, 2019 by tooting

[Gabe777 132]

.

[Gabe777 132]

Apparently, the lowet the FFT number the less cpu time is devoted to terrain/AG loading, but improves fps instead.

A higher (0.33 or higher), devotes more to terrain/AGen, at the expenses of FPS.

The choice depends on scenery density and altitude.

The dynamic fft software, actually sounds interesting, although I am cynical as to how cfg entries can be changed on the fly.

May be worth a look, as I have only just noticed delayed autogen loading on descent, since v4.5

 

This is an official statement for FSX operation:

On multi-core machines in SP1, we moved many fiber jobs off of the primary thread and onto secondary threads. Since FIBER_FRAME_TIME_FRACTION only affects scheduling of jobs on the primary thread, it will have less of an impact on the performance of Flight Sim on multi-core machines. In fact, we moved so many jobs off of the primary thread that there probably isn’t enough fiber work left to soak up the full time allowed by the default value of 0.33.

Therefore, on multi-core machines, there’s very little reason to tweak the fraction because it really only impacts performance of single core machines.

Edited May 10, 2019 by Gabe777