Gee that was a really interesting read and an amazing piece of detective work, thanks OP.
It would also explain why those flying out in the middle of nowhere don’t tend to see it. I’ve flown for hours across parts of China, and Australia, and not seen it.
1 Like
Indeed. All I figure out within a mind-mazed confusion is that metropolitan areas in the US and Europe are the weakest points in the chain and have exposure to great airspace classifications which might overlap erroneously. So, London seems to be a pretty good example from this point of view when I stare at a certain direction, fps begins to drop down dramatically. I don’t want to speculate on it further as I am at work. I will try to find it out on Navigraph.
Have you checked vertical dimensions?
The bug we’re talking about here has nothing to with do where you look but where you are.
We should not again mix up all kinds of issues into one isolated topic. This one is about having 1-3fps in very specific areas where it doesn’t matter whe you look, it persists as long as your position is in the affected area.
In the FPS display of developer mode in this case the Manipulators have values over 800ms.
2 Likes
Exactly. Also when disabling Draw in terrain or deleting all default airports fixes it, I would say it has nothing to do with airspaces/
airspace related files.
so tragic… asobo tried to improve the ATC, but they also introduced another major bug. smh
Microsoft needs to hire you immediately. This makes sense - I wonder if the class Bravo airspace in Seattle is the reason for poor performance. Or does it happen with handcrafted airports?
2 Likes
You did way more work than I’d ever have time to do but that same area is where I also experienced a tank of FPS and had to force the sim closed on my flight from New Mexico into the DFW Class B from that same NW quadrant.
Here’s another…
Last night I flew from Tennessee into KCTJ which is just West/NW of the Atlanta Class B boundary. I also had FPS tank as I was approaching KCTJ on final from the North. Pretty similar area to what happens around the DFW Class B. You might want to check out KCTK and points North to see.
This is brilliant work. To add to the list, noticed the same issue on the LEGOZ2 arrival into KCRQ, followed by the RNAV-Z for runway 24. Problems started occuring below 10,000 as I neared the mode C veil, OCN VOR. However problem didn’t go away inside the veil, so perhaps we have solved ‘part’ of the problem here.
Nice work, hopefully this will help the team track down the issues if they aren’t already aware of them through their own detective work. I was wondering, doesn’t this also coincide with the fixes for the terrain spikes problem? Perhaps they are related in some fashion.
The game’s afoot, Holmes! Good show!
1 Like
Wow. Spectacular analysis ! Well done. On my side, there’s “back hole” close to LFLB (come and fly in the Alps area 
). On east part of airport, in a specific zone close to it (downwind leg) , it drops to 1-2 FPS, whatever the plane I use, real or not weather and graphics parameters.
I will try to detect as you the pattern of this black hole.
It’s really really anoying to have this, specifically close to an airport and in manual VFR mode. Impossible to control.
Fred
2 Likes
This is great stuff, and might explain why for instance New Zealand is pretty smooth right now. (Not a lot of airspace areas).
I wonder if there is any correlation to the DEM/terrain mesh level of detail in these areas. For example, does the terrible performance correspond to airspace boundaries in areas that have received a World Update with the more detailed DEMs? Perhaps the “Manipulators” thread is mapping the geometrically defined airspace data from the nav data onto the mesh defined terrain under the aircraft (to create an “are we in this airspace” flag) and having more detailed terrain means more points it has to look at at the edge of each boundary?
For the “non airspace related” part of the performance problem - I saw a post a while back by someone who was fixing the terrain spikes pre-WU3 where that person said they thought there were terrain post-processing algorithms running on our local PCs.
With the cloud driven nature of the sim this made 0 sense to me - why make 2 million users reprocess the same terrain data every time we fly, just process it “in the cloud” so it’s ready for the sim to consume. However, we saw the first glimmer of some of these performance issues after WU3 where they “fixed” the terrain spikes and the “water creeping up the coastline” issues (by making the costlines in many areas look like someone had taken a clay working tool and pulled them back from the coast).
In addition to the airspace related items, maybe the “Manipulators” thread is constantly reprocessing the terrain mesh that is downloaded from the servers to smooth out spikes and “pull back” coastlines. This would also explain why turning off Bing Data and using only the lower LOD terrain mesh on your local HD improves performance. If so…they should really process this data once before it is ingested into the Azure servers, and not make us spend our PC resources to process it on every flight.
Edit: All 3 of the Class C boundaries mentioned by the OP are in the 2m DEM area per the map in [RELEASE] Release Notes (1.11.6.0) World Update II: USA Now Available!
Amazing work! I ran into another reproducible stutter area last night, it was just west of Ikitsuki Bridge. I checked it out in LNM just now
Looks like it’s on the edge of Nagasaki Airport.
I also had some problems between RJDM and RJFS but didn’t pinpoint it, also between RJDA and RJFE while flying over open water, and finally it nearly died from RKPK to RKPS.
Although the last one might have been another bug since it was memory related, went up over 30GB allocated hammering my page file. (The bugged areas don’t consume more memory and actually end up lowering cpu and gpu temps, I notice the fan slowing down when in a bugged area)
3 Likes
Anyone find one that was not top left of the airspace?
1 Like
I really enjoyed reading OPs findings. I second the idea to reward this great effort.
2 Likes
Well done to the OP. This is the sort of investigation that speeds up bug fixes for Asobo. Well done for making the effort rather than creating a generic rant post with vague details that are no help to anyone.
4 Likes
Really brilliant analysis.
Thank you.