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.
… 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.
Added some more links today in the OP, including a link to the Dev Q&A. I would encourage everybody to vote for this, so we can get this issue acknowledged.
I believe that this issue gets more attention if its moved to the bugs section where it can be voted directly, rather than taking the way through the Q&A.
I agree. I think we need someone to post a great summary with screenshots/links to the issue in the bug forum so we can upvote it. I will give the OP the first opportunity to do so since this post already accomplishes that goal just in the wrong forum.
I will be doing this today. I absolutely had every intention of doing this from the beginning, but my concern was that if I did so without consolidating and bringing awareness to the issue first, then it would gain no traction. I believe I have achieved that first goal, which was to make sure people understood this was not 1000 separate runway issues, but one bigger issue, and to bring visibility to it. Now that is done, I will create a bug report and link various pictures & videos along with this topic. I don’t want to have this topic moved, so will create a separate bug report. I’ll also create a Zendesk report and link both.
Definitely, good work in finding all the separate posts
I encountered the issue only 2-3 times so far but I’m flying the slower TBM 930 only. Now I have a good picture of the overall problem others have with larger and fast aircraft.
… I have one more addition to my previous post from today.
I tried the same “pattern” … rapid drone movement to trigger (tiled) ground cracks … over the city (KBFI, Seattle) in general.
Over airport ground it is easy to trigger the “tile cracks” … even in the grass parts … but cracks tend to heal
Rivers crack from the side into the center … cracks typically are stable
but the rest of the photogrammetry city … hmm … pretty hard to get it “cracking” (I almost got motion sickness far a few minutes when I tried it)
In the end I managed to get some “city” cracks … but only in areas like the train yards. The other parts of the city show progressive surface “morphing” … but no cracks (and I tried hard)
So here is my “enhanced” theory:
I think in the “Bing Partnership” video they mentioned, that they are “fusing” multiple data sources … including OpenStreetMap data for streets and rivers
… in order to flatten the water areas (and to get the sky reflections … which looks buggy in the deserts when the river beds are actually dry sand/rocks)
now I suspect that “terrain flattening” is also happening at airports (and perhaps even train tracks or specific OSM area features)
So IMHO the crakes are the result of
progressive LOD aware terrain creation
especially under the constrains of areas which also apply some “flattening”.
and in flat areas it mainly (only?) happens at tile borders.
Here are some pictures which I took today (all with locally cached data).
This is one showing the “tile nature” of the cracks at the airport (those did heal … but slowly)
So those artifacts are fundamental “features” of the present game engine … and they are not only “not pretty” … but they sadly will crash aircraft. So an “official forum bug” would be a good idea.
… Ok … one more picture because I think it makes sense …
This is the same railroad crack as before … but now the area did “(almost) heal” (most tiles did catch up to a consistent level of detail on texture and geometry)
Yeah, I was confused… what I was thinking, the line is along the line near where photogrammetry ends in Google Earth, not in the game. I’ve been planning on building more accurate hangars using Google earth renditions, or starting there anyway.
But, I assume you didn’t load my airport when you checked it out? I just did check it out again. It’s still there, right at the intersection of Delta and the taxipath that goes by the hangars. It’s very small, maybe an inch or two of difference.
The height difference disappears as you follow it towards the runway by the time you get to Alpha. After that, you can see a color difference in the textures on either side of the line, but there is no height difference, and you can’t see the line in Taxwaypaths or the runway.
You can get my airport at Flightsim.to if you’re interested.
Hey guys I am cautiously optimistic that this latest patch fixed/improved the “tear” issue. So far I have not experienced it once after the new update even in the areas that I normally would see the glitch. Anyone else having success with the new update?
I also can’t confirm they did. I landed wit the 747-800 on
LAX 24 L -> No issues
LAS 26 R -> Issues
ORD 28 R -> Issues
SFO 28 L -> Issues (crashed)
JFK 31 L (Landing Challenge) - > Issues
KATL 09L -> No issues
KMCO 35R -> No issues (complete with a butter landing)
After updating, I made sure that I downloaded the free US Update in the Marketplace. I also deleted my manual and rolling cache. Then, I restarted the sim.
