Runway Tears Awareness (Added link to new Bug Report)

I don’t know if this is useful or not, but I had some interesting issues working on an airport in the SDK that mimicked this tearing behavior.

When I placed the runway I must have made some goof adjusting it and it dived into the earth and the terraforming went all whack and made a big hole, kinda like that airport bug in sim everyone thought was so funny but not as extreme.

Well I fixed it after some trial and error setting the runway altitude in gizmo and everything looked normal again.

I saved my work and closed the project to exit, and reset the vew on the C152 I had loaded in on, and my external view was screwed all to hell and I was seeing that hall of mirrors effect through the ground unless I looked more top down on the earth.

Then I noticed a square building behavior around my view that had a delay filling in, trying to draw the surface, and it looked just like the runway tearing we see in game sometimes.

It may be some kind of render bug, it does not establish the true surface of the ground until you look at it more or less. And I think it has something to do with the airport terraforming and/or the difference between airport features altitude and basemap ground altitude.

Just my thoughts. I was doing scenery work and didn’t think to screen record it in time unfortunately.

1 Like

…and it happens again. I land, hit the area where two intersecting runways meet, and flip over on my back… It’s getting aggravating.

I did raise this issue as a topic for the next Dev Q&A so please vote for it if this is an issue that you care about.

1 Like

So, I can say that the tear at my airport, KASH, and I believe you are correct that the airport is at the edge of a photogrammetry area, has nothing to do with the terrain data loading too slowly. It is there as a feature and never goes away. Fortunately, it only exists in the parking area, and just causes a bump while taxiing, no crash, and it does not extend through the runway.

It happened to me as well, in MULTIPLE airports. Haneda Japan, San Francisco, Miami, Orlando, to name a a few, all have bumps on the road

I can understand your frustration … but to give it some “positiv touch”, at least this crash seems to/will ensure that your flight (time) gets logged correctly in the Logbook.

For more details see here:

I think your raise an interesting question:

Does (excessive) local data caching change the behavior?

Because if you have (say) 500 GB of cache … you take off and land at the same airport … and no ground “fractures” are present, then it becomes more likely that progressive data download (and slow connection) is the primary issue.

If the polygon “fractures” are still present than it is clearly a “progressive terrain data creation” issue. The “slow connection” only makes the problem more likely.

I suspect that there are two different “progressive terrain data creation” algorithms in place in the game, as one wants (must) preserve sharp polygon angles in photogrammetry … but in the rest of the world data it gets “smoothed out”. But well … I am just guessing.

Keeps happening all over the place all the time now. Last few patches made that aspect worse even in ‘custom’ airports like SFO, SEA where there should not be such issues.

I was actually under the assumption they just aren’t cleaning up tile joints appropriately in certain situations, and, based on what I’ve read here, that certain situation is when a tile has photgrammetry asssociated with it, it’s at the joint between photogrammetry data and “regular” data, which is what is going on at my airport. So, one tile to the next is close, but not smoothed over for some reason.

Meaning, it’s not a speed of loading/smoothing thing; in my experience, that tile edge is locked in, it never goes away (it’s about an inch or so difference). Now, perhaps it is associated with cache not getting cleared, I could see that. It could be it’s forgetting to smooth the joint because it doesn’t erase the old data. But, I do not believe it has anything to do with speed of update.

Interesting. So based on your assumption (observation?) that would mean that all “fractures” should be reproducible and permanent. So they …

  • (a) clearly should be present even if no network download takes place
  • (b) … and should be visible even if the aircraft is moving very slowly

I typically fly in countries without photogrammetry (which so far is limited to US, EU and JP) … so today I visited an airport where I have seen reports of problems (EDDN) and I did not see any fractures. As it is a small airport with only one runway the check is “easy”.

This leads me to believe that the progressive nature of 3D scenery generation (mainly the upload of geometry to the GPU) + plus the special treatment of photogrammetry 3D data could be a key aspect. At least if I had to debug that issue, that is where I would start testing.

But I will now spend some more time on the “troubled” airports. I find this bug pretty interesting … even when it is “nasty”.

Also that they should be reproducible by others.

See what you get when you go to KASH in Nashua NH. Taxi along the taxiway along the hangars on the west side of the parking aprons, in the vicinity of where taxiway Delta meets the parking apron, go back and forth along there. You might want to try installing my addon which can be found at…

I haven’t checked since the last update, and I don’t remember if it was with and/or without the airport I built. But in the past it was always in the same place, and it caused my plane to bump a bit as I ran over it on my way to R14 from being parked near the tower. You could see the crack running across the apron.

No for (a). The behavior is extremely intermittent. You can land just fine on an affected runway on one flight, and experience the bug on the next. I’ve had the best results by disabling my rolling cache, but it hasn’t been perfect. I still encounter this issue periodically. I’ve experienced it at KSEA, KPDX, KBOS, KATL, KSFO, etc. I’ve experienced it at hand-crafted airports and default airports.

(b) I’ve experienced it in a Cessna 182T (on landing) so I was below 50KIAS when I hit the crevasse.


Hmm … what you have observed sounds a lot like it clearly is not the “raw elevation data” … but what the “progressive extrapolation” does with that data.

If caches make it even worse (more probable) than it sounds like too much level of detail can trigger the problem even easier.

Well … I have no clue which approach Asobo is using … but I suspect that for performance reasons they have to divide the geometry into different tiles and maybe different parts of the code work on different tiles. What @FlyingsCool5650 has written at least suggests that

  • … if the tear shows up
  • … it shows up at a predicable location

So if that is the case … maybe it is some kind of “race condition” where the question is which reference point in the geometry is used first to start the triangle calculation process. And if it picks the “wrong” starting (elevation) point than the two neighboring tiles will not match. In that case the speed of movement (flight) would have no effect … because it is an artifact of the (tiled) progressive geometry creating.

I can imagine that debugging such issues (under high pressure) is not “funny” … but whoever will resolve it will gain some crucial insight into the code base.

1 Like

I will give KASH a try.

You know way more about it than I… I was just guessing, and remarking that it is always in the same place where I’ve experienced, and when I’ve seen it, it never goes away. And it happens when I’m taxiing, and I’ve never seen it extend to the runway. In my addon, however, I did redo the runway for the addon. I don’t know if that has anything to do with my experience, or, maybe created the problem?

And, as the other person said… a) is not necessarily true. I happened to run into an issue with the last update that my login wasn’t being registered, and Bing got turned off, and my scenery was VERRRY different. I did not check to see if the tear was there, but, I don’t think it’s necessarily true that it would still be there with Networking turned off. In fact, since there’s no Photogrammetry, my bet is it would not be.

This crack is very much in the vicinity of the switch from photogrammetry in the surrounding scenery and no photogrammetry. In fact, I’d say it is at the boundary of that.

Well … I have no clue how Asobo is doing what in their code. I would (somehow) enjoy searching for those obscure issues because there is so much one can learn there … but I am just “guessing” based on my (limited) understanding of how 3D scenery tends to work.

I did spend some time cruising around KASH today (with aircraft and drone) … and I was not able to see any “crack” or “fracture” in the ground near taxiway Delta and the parking apron.

I also noticed that all the buildings around the airport are AI generated and not photogrammetry. So if there is (was) an issue at KASH, then it would not fall into the “photogrammetry” bucket … I guess.

I spend some time at …

… and that looks like a perfect example.
West of the airport there is a railroad track and east is a river … both clearly are photogrammetry regions. The airport is right in the middle of photogrammetry elevation data, but only has AI generated buildings and hand made airstrips and taxiways (textures).

One thing that is unclear to me is, if that means that there are (maybe) two elevation data sets for one location … hmm … anyway …

I used the drone to move around, as it allows more radical “maneuvers”. So I can move quickly down the runway … and stop immediately. If you perform “crazy” drone position changes (x-z) than the visual cracks are all over the place. And a clear tile based structure becomes visible.

But … if I stop and wait I can watch the surface “heal” over time (say 2 seconds).

I can see similar artifacts in the river (where it is even easier to see … and very frequent at the river banks and less often in the middle of the river). I guess the underlying problem is identical (river vs runway) … but the runway has more of a “tile based” pattern which the river does not really show.

But if I make a “micro” adjustment of the drone position over the river, then the cracks (in the river) are actually moving! So when I shift back and forth I can make (some) cracks flip too. This is different to the airstrip.

So it is easy to reproduce and not really a “race condition” typ of bug. Which I think is good.

Caching or (slow) data download does not seem to be the key (trigger) … even when it might (will) impact some the tessellation results.

I do not think that it is easy (obvious) how to fix it … but it seems clear where the problem is.

1 Like