Yes, your response has me inclined to believe this is a LOD issue because you seem so sure it is not, and yet that is the source of almost all airport and ground (not air) stuttering. So you likely haven’t even tried to adjust the key sliders and your settings are too high.
Terrain and Object LOD… and traffic. Those graphics settings, in spite of your skepticism, are limited by your CPU, not your GPU.
Look, you get close to an airport and suddenly you have extra objects and traffic that your CPU must handle. This causes a spike in your CPU use and causes stutters as you get near the airport.
And even though you have your theories about how multi core CPUs work, one core would typically handle a specific task… like LOD. So your computer gets limited by the speed of a single core. And once one core gets maxed out, the rest of the computer gets throttled, as the other cores must stay in sync with the slowest core or that would cause huge problems.
This issue is so well known, we have some math we can run to get optimal settings.
And really, no amount of optimization by Asobo can prevent user error. If a user sets their graphics settings too high, their computer will always slow down.
I am happy to help walk you through this if you need it. Start with terrain and object LOD, and traffic. Drop them all to 50 and see if your FPS doesn’t bounce right back on the tarmac. Then we can look to bumping those settings back up as far as they can go before maxing out a core.
Well, the thing is you are trying to find a workaround while I’m trying to find the root cause of the problem.
The workaround of reducing LOD to get more FPS on ground does work but that is not the root cause of why we have low fps on ground but much more fps at eg. 300 feet.
I made a video with RTSS, DevMode and Task Manager open. I spawn at JFK, active Pause mode, show the settings I have (even though these do not matter), activate slew mode and slew upwards.
The root cause is that even though I see the least amount of terrain and objects when on ground I have the least fps. At 400 feet I see much more of terrain and objects but my fps are higher. And I’m not talking about “yeah but the level of detail is lower, thus you have less vertices to calculate (CPU) and draw (GPU)”. The level of detail stays the same for a given distance and beside of that you massively increase the amount of vertices the system has to calculate and draw so even if the level of details is lower, there is much more geometry to process. Yet the fps are higher.
And that is the problem Asobo needs to fix and not “your LOD setting is too high”.
Why? Well because if I lower my LOD I get, lets say 60 fps on ground (instead of 30) and 120 fps in the air (instead of 60). The root cause is still there.
Yes, this is how the CPU gets used in MSFS and it hits hardest when you get nearest to an airport. Especially large airports like LAX, JFK, and Heathrow.
LOD is a setting I am intimately familiar with because I fly on a laptop. My CPU clocks at about half the MHz you run at. No room in a laptop to keep the CPU cool at faster clock speeds.
I am not ready to delve into your Asobo conspiracy here. You described a common issue that gets discussed in countless threads here on this forum. The CPU gets taxed most at airports. All the tugs, and people walking around… airplane models, car traffic, fire engines… etc. they come to life when you are at an airport and they go away when you leave an airport. And they all run thanks to a single CPU core because you don’t split a singe, real time task between multiple cores or it causes syncing issues (and I am not about to write a novel-sized post explaining why… it is just how software and CPUs work).
From where I sit, you were running the LOD/Traffic settings too high for smooth performance at JFK. And JFK is a notorious CPU killer in MSFS.
You said yourself yours is, “Not the best CPU.” So, you probably shouldn’t expect the Ultra settings for CPU reliant details like LOD and Traffic to work on your, “Not the best CPU.” Ultra settings are only for the best CPUs. I think your CPU would handle High LOD and Traffic settings just fine… but Ultra is taxing your CPU beyond its limit. Especially at the biggest, busiest airports, surrounded by the biggest, busiest cities.
It took me a long time to discover a simple optimization step. Optimize for FPS on the ground, at an airport, not in the air… as the CPU gets taxed most on (or near) the ground at an airport. And a CPU core getting maxed out causes stuttering. A maxed GPU doesn’t cause stuttering nearly as bad as a maxed CPU. A maxed GPU results in lower FPS while a maxed CPU will cause the whole sim to pause while the computer thinks. Those pauses cause the sim to stutter intermittently. And stutters are immersion breakers.
Ok @WellREDBarron, I give you the benefit of the doubt and don’t assume you’re arrogant but that you genuinely want to help.
Thank you for your kind offer to help but I’m more than capable of finding good settings for my PC.
Over the past decades I also gained a lot of experience regarding how computer games and especially computer graphics are handled by the CPU, the operating system as well as the GPU.
Again, you are talking about a workaround aka. “how to get good fps with the current state of the game”. This is absolutely fine, however since we are in the Bug Reports section I’m talking about the underlying problem.
It is not a conspiracy I talk about. It is a acknowledged problem. Acknowledged by Asobo. And it is absolutely fine that the CPU gets taxed much more at airports. However it is not fine that the GPU barely does anything just because that one core that tells the GPU what to render is busy with placing tugs, people, AI traffic and what not.
If you don’t want to split that task to multiple threads then just move it to a different one. That would solve the issue.
Currently the GPU is “idling” at 33% load just because the mainThread cannot send more data to the GPU because the mainThread is busy doing the AI stuff. Yes, lowering LOD will lower the amount of work for the mainThread so that it can send more data to the GPU but it doesn’t solve the underlying problem. Remember, we are in the Bug Reports section, not in “Smalltalk” or “Workarounds”.
If however the AI tasks run in a different thread than the mainThread then this thread would have enough resources to send more than enough data to the GPU so that it would be nearly fully utilized.
I created a new, much shorter video which disproves some of your statements:
As you can see, the fps on ground are 30 - 32 fps. But at 300 feet the fps are at 39 - 40 fps even though you can see the same amount of AI objects. And at 500 feet we’re at 42 - 44 fps and we still can see the same amount of AI objects.
What would you say, how many AI objects aren’t shown or calculated anymore just because I moved 300 feet up? Since I gained nearly 33% fps at least 15 % should be “taken out of the equation”, right?
@an3k Please don’t confuse my need to convince you that you were wrong (which needed to be done in this case in order to get you to solve the easily solvable issue you are currently facing) with arrogance. Arrogance (by its very definition) would be say, ignoring my helpful advice in spite of it working exactly as I claimed, just because it would require one to admit their initial theory was incorrect, even after posting their extremely common optimization issue in this very thread and being told exactly how to fix it by multiple people…
Consider me wry, smug, snarky, even rude if you must… but please, do not project arrogance upon me.
I have given you a couple hours of my time today so I am here for you, with a common goal. I want to help fix your CPU spike. I know telling someone they are wrong is not a great approach… especially on the internet. But in this case, since you must do your own configuration, we both have to be on the same page in order for ME to HELP YOU. And in this case, that involved convincing you your initial theory was incorrect. Awkward… but it is what it is. Focus less on perceived slights because you may not like my tone, and more on the fact that I am bending over backwards, writing detailed posts specifically for you, pertaining to exactly how one solves your specific issue. Please remember, by following my advice you have begun to see your issue get quelled. I’d say, in spite of what you may perceive in my tone, the proof is in the pudding. I am helping you fix your problem… and your complaints have to do with how you perceive my tone, not with the quality of my advice… and said advice is quite literally and verifiably how one solves your specific issue in MSFS, at least in its current state.
Considering you have been skeptical from the start, and I knew that because I can read, I have had to try and break through that skepticism in order to help you fix your issue, and that continuing hurdle has caused me to drop some niceties and pleasantries as we continue to chat, because, I dunno… a little gratitude would have gone a long way by now.
The thread linked below is a gold mine for optimizing your system when it is CPU limited. Before I read it, I really thought things worked the same way you seemed to think they work.
For 60 FPS, things work the same as described in the linked thread, but you want to tune for around 15 ms instead of 30.
By following the steps in this and subsequent posts, I now get smoother performance than I ever did before, and my PC is a potato compared to yours!
With your setup, you might not even notice the lower fidelity, as the sim looks beautiful and often enough, photo real well before LOD settings get maxed out.
Here is a link to the key post, but the whole thread is full of gold.
Even with Traffic and photogrammetry disabled (including all other “online” data) the fps get a huge hit once TERRAIN LOD is increased.
I ran some further tests and these show that the real mainThread cloggers are TERRAIN LOD as well as GROUND AIRCRAFT DENSITY. Every other setting is barely touching mainThread or the GPU Load and thus the resulting fps.
In this screenshot the only change I made was setting TERRAIN LOD back to it’s lowest possible value:
TL;DR: Only GRAPHICS > TERRAIN LOD and TRAFFIC > GROUND AIRCRAFT DENSITY is massively tanking your fps, partly because these settings clog up the mainThread.
Setting GROUND AIRCRAFT DENSITY from 0 to 100 will cost you at least 49 fps.
Setting TERRAIN LOD from 10 to 200 will cost you at least 75 fps.
Excellent testing! I get similar results on my potato. Terrain and airplanes tax me the most at airports.
Now, I highly suggest you lock your FPS to 60 hZ. That variation you mentioned jumping from 30-60 FPS or 60-120 FPS is avoidable, and if you are not going to hit 120 all the time, best to lock it at 60 all the time. If you can get a locked 60 FPS at JFK, it will hit a locked 60 FPS everywhere. And that is performance worth bragging about!
Or bump the details to where you get a locked 30. You might get the best, most stable, highest fidelity experience at 30 FPS. I’d suggest trying both 30 and 60 and seeing which is the best for you.
You are never going to hit 120 locked FPS with your system, at least not without a drastic reduction in your graphical settings, so it is better to have the overhead of a locked, lower FPS. Keeps things cooler, and more steady. And things control better, or at least they feel better when the FPS is steady. Things feel squirrelly when the FPS boosts or drops significantly while you are maneuvering.
Yeah, 120 is better than 60, but this isn’t shooter or race car simulation, and the sensation of speed is minimal when miles above ground. 60 FPS is fine. Both XBOX versions lock at 30. I have to lock my laptop at 20… so color me jealous. Flight sims… they really don’t heed high FPS, and they have been pushing the limits of home computers since their first commercial release.
Be sure to follow the advice in the thread I linked above. Look for around 15 ms per frame for GPU and CPU for 60 FPS, and make sure the GPU is still the main bottleneck at JFK, not the CPU. That should quell all CPU related stutters.
And remember, the FPS you see in Dev Mode in the options screen (like your photos) is not an accurate reading. You have to leave the options menu and be in or outside your plane in real time to get an accurate reading. The options menu tends to run a bit faster because things are paused.
My best guess from years of racing sims is the taxiing model eats CPU, and it either gets shut off, or de-prioritized as your plane takes flight. You need to have both a ground and flight model at work while taxiing and during takeoff or landing, but once in the air, the ground model is no longer needed. As you approach an airport (or the ground) it likely pre-loads or roses in priority (causing a CPU spike) so it is ready to go before the wheels hit the tarmac.
But that is part of the game engine so we cannot adjust it. We can adjust the most CPU taxing graphical settings.
An annoying thing about multi core processors and gaming… since games progress in a linear, real time, and not pre-rendered way, it can make for inefficient use of all cores. You often end up with one core managing all the heavy things like flight engine, taxi engine, and terrain detail because all these seemingly unrelated things are governed by where the plane is currently heading and therefore, these things must all happen together on one core to keep everything linear and in sync. That’s a gross oversimplification and my example may not even be true… but time and again, in real time applications, one core tends to get taxed more than all others, and when pre-rendering things (which can be a non-linear process) more CPU cores can be fully utilized. Alas, if we pre-rendered our flights, we wouldn’t get to fly them.
DirectX 12 might help with this but not in its current state, and still, even once out of beta, I wouldn’t expect miracles. One core tends to do the bulk of the work in linear games and sims.
TLDR: Taxxiing your airplane on the ground requires more CPU than just flying, as the entire ground modeling engine must run and it likely doesn’t need to run while you are in the air. Your sim appears to be operating as expected. For whatever reasons,LOD, taxiing, traffic, whatever… airports (especially the large ones) tax the CPU more than anything else in sim. That is true among all users. The fix to your CPU issue is covered in detail in the above posts and link. Or you can leave things as they are and know there will be occasional but predictable CPU spikes during the critical time of takeoff or landing.
Your analysis of the root cause is based on what YOU see assuming MSFS is seeing and processing identical to what you see. However, MSFS sees things like Superman’s x-ray vision. If one parks their aircraft against a wall at a busy airport so the only object being visible is the wall, if rendering is based on what we see, the FPS should be very high because only the wall is rendered. But if we look at the wall with x-ray vision, the number of object we see is huge and these objects are being rendered. The result is FPS that has cratered. Asobo and others continue to fill hand-crafted airports with lots of objects with lots of detail. Looks good but performs badly. Maybe this is poor design of the graphics processing. I don’t know…. But poor design is not a bug even though it is a problem.
As far as seeing more objects at higher altitudes, we shouldn’t be seeing the same level of detail the higher we go. It is possible to read warning stickers plastered on aircraft when we are on the ground. At 400 ft above ground we shouldn’t be able to read those stickers and MSFS should not be creating graphics for those objects that include the detail of those stickers. Yes, more objects are in the field of view at altitude but the detail being rendered should decrease with increasing distance. This is why FPS is higher at altitude than on the ground and why FPS drops during approaches at larger airports.
to be honest, I have no clue if the issue has been solved in the meantime (I haven’t read the thread that far).
But I guess, I can come up with a solution for a lot of you guys cuz I’ve had to cope with that issue as well.
And in my case I figured out that switching off the Photogrammetry (option/general option/data) solved my problem with poor/bad performance on ground (take off/landing)…since that…smooth in all condition again.
Hope that this will help to get rid of frustration for some of you.
It starts with 24 FPS, with Take off it goes to 2 or 3 FPS: Stuttering Ground.
When I have the small airplane in the air FPS goes slowly to 32 FPS.
Landing is impossible: 2 or 3 FPS and Crash.
It worked nice until SU7. Troubles with SU8.
Sorry, Was out of my comp - screen in Dv mode is below. LOD (terrain) = 200; LOD (objects) = 100. I’m a bit confused about photorammetry - how/where can it be activated/disabled??
Time has passed, so I repeat my config: i7 9700 RTX2070 Super 32Gb.
“The workaround of reducing LOD to get more FPS on ground does work but that is not the root cause of why we have low fps on ground but much more fps at eg. 300 feet.”
This IS the root cause (apart from defect mods). I think everyone has to get his understand of LODs right: They give a distance after which certain objects/textures are not rendered anymore or rendered in a lower resoution. In the air the distance is not only horizontally, but also vertically. Let’s make an example: Immagine you are at one end of Paris on the ground, and the distance to the other end of paris is 2 miles. Your LOD setting of lets say 200 does render objects and textures for exactly 2 miles. So in this case in your location it will render any building exactly until the other end of Paris. That’s MANY buildings.
Now imagine you’d be up in the air above the same location at an altitude of 5280 feet, that is exactly one mile. Now what will happen is, that Paris is not being rendered anymore until the other end of the city, but only up until the middle. Why? Because your LOD covers 2 miles distance and you already “spent” one mile vertically, so it will only have one mile left horizontally. So what happens in this case? A lot less buildings have to be modelled and therefore FPS will be much better.
That’s why on the ground LOD will be much heavier on your CPU/GPU load, just because there are many more buildings and textures that are within the LOD distance, because distance is all horizontally on the ground.
What MSFS really needs is a dynamic LOD that decreases on the ground and increases in the air the higher you go. But that’s a tough thing to do.
The problem with performance is that there are many variables that can have impact. After many, many hours tweaking I was quite happy with performance. Dialed down lod a fair bit, upped graphics settings to find a good balance between a busy GPU while not being CPU bound.
Then I started having stuttering on the ground and while on final. Again a lot of tweaking but did not help.
When I needed to reinstall the sim I noticed that the download speed was really slow. After reading some other threads I noticed that my network settings had changed and managed to get speeds back up to normal. Since then I haven’t seen this poor behavior so must have been a download problem.
Well, as I wrote, reducing the LOD is not the root cause. The root cause is what you described. The LOD is like a bubble and when you’re on the ground it reaches the furthest horizontally, thus the game renders MUCH more buildings and terrain then when you’re higher in the air.
Fun Fact: If LOD 50 in the air is too low for you, on the ground it will be too much for you, simply because you cannot see all those buildings.
So if your LOD is 200 the “on the ground LOD” should be 20 or so. This may negatively effect a few areas where you can see 200 miles even when on the ground but I don’t think “being able to see or being not able so see” a small mountain in the far distance is really important.
Exactly. But luckily it isn’t tough. You only need to know how far you can see at what height and then you have a nice formula to dynamically adjust the LOD internally based on the user selected LOD value. And if then the user still struggles with poor fps near ground, then yes, he’s at fault for setting a too high LOD.