Can you maybe add a link to the OP to point to the ‘conclusion’ post?

This one POI Very Late Rendering/Draw/Pop-In *SOLUTION FOR ASOBO TO FIX IN THIS THREAD* - #28 by DronkeyKlong

Please dont mark it as a solution!


Hope moderators can elevate this to Asobo.


First post updated

1 Like

Just throwing this out there, but would it be possible to convert the modelLib.bgl file to xml, add the LOD code where it’s missing, then convert the xml file back to the bgl file?

Just asking…

For an individual model you can do it, but this is an overall issue.

BTW, the LOD entry thing was a red herring. Read the whole thread for my progression on the analysis.

1 Like

Congratulations to all in this topic nailing this one down!

Your comment about stop rendering then starting again reminds me something I’ve posted in the forum and Zendesk some time ago. I’ve observed the same pattern with Trees where as you get closer, they disappear then reapear:

[08OCT2020] Trees draw distance is different per-species AND per-Trees LOD setting
[16OCT2020] Some trees are disappearing then reappearing
[25OCT2020] LOD Problems - Distances revisited

Ironically, in searching these links in my activity history I’ve stumbled on:

(1) LIve Q&A - October 28, 2020:

Answering to:

Good God. Seb Wloch just asked for examples of the loss of LOD bug they introduced cos they can’t find it.

Live Q & A via Twitch - #49 by CptLucky8

(2) Live Q&A - January 27, 2021:


Being one among others documenting the exact problems with LOD and Trees for months, I was indeed quite puzzled they were answering as if they were just discovering there could be an issue with LOD and Trees. It is especially even more troubling to me that IIRC, in a previous Q&A the same topic was brought to their attention with the same reaction.

Discussion: Live dev Q&A January - #57 by CptLucky8

I believe the question of LOD bugs can’t just be ignored again in the next Q&A and it is important this is officially acknowledged and being worked on once for all. We’re counting on you! :heart:

In Zendek:


I agree with ALL! This would not have possible with the excellent and quick feedback from others (especially without external ‘noise’). The hints all made it possible, I just connected the dots and created a faithful repro of the issue :smiley:


Yes, I have the same problem at least since the World Update USA (Devil’s Tower, Crazy Horse Memorial, etc.). Reported it to the Zendesk back on December 5, 2020. Apparently no one cares to fix this glaring issue in almost 3 months.

For reference for the support:

Ticket ID: #81848


That’s strange thinking. A ticket that is submitted may be overlooked, but a ticket that is not submitted at all, can most definitely never be seen by anybody.

Please, submit it! The more people report an issue, the higher the chance it DOES get noticed (and fixed).


Begs the question then what is the point of these forums if not for submitting bugs?!

Regardless this is - yet another - Prime example of something that shouldn’ve been clearly picked up in testing and reported and fixed.
How long has the USA update been out now? The person putting in these POIs surely tested them in game themselves so would know the draw distance is incorrect, the beta testers surely have “LODs” as a very basic checklist item.
This sort of issue (alongside many others) needs to be rectified before patches/world updates are released, quite why they’re not is extremely disappointing.

Anyone is free to Report this to Zendesk, personally I’m just very tired of seeing the same simple mistakes happen time & time again and at the end of the day I’m not here to be a Beta Tester reporting everything I see, that should be something that is properly conducted in the first place.

(None of that is aimed at you personally)


How awful!

Totally agree. At this point, most of my reports aren’t fixed, or acknowledge. And filling a zendesk report takes too much time to being ignored.


What is even more peculiar to me is that these POI are showing up without this bug in their promotional videos. Which poses the question whether are they really shooting the videos with the same version they are shipping, even if they were saying otherwise in a Q&A when the rumor they didn’t was growing in the forums. Because obviously, this kind of bug as no other way but showing up during the video shoot.

In turn, this might help them pinpoint and cure what is causing this bug, and many others: if they are only using a “release candidate” version which is different than the shipping one we are using, there might be some differences between the RC and the Release code base at the source of these many bugs. They might need to diff these to ensure their RC is the same as the release version, every bit of it.


In addition to the POI rendering too late in view, I’m wondering if the GLTF loader not honoring the model scaling factors is not at the root cause of the other bug in VR, where cockpit size seem either too big or too small depending on the aircraft:

[FEATURE REQUEST] Cockpit Size and World Scale in VR
VR World Scale

1 Like

What you might be seeing is tester’s bias where yes, the first time the plane approaches the object you see the lack of detail but once it’s loaded it gets cached and stays in the scenery. The next times you do a test it appears to work fine. The tester is looking at the big picture instead of the details or they weren’t paying attention to the object the first time they approached it or, even worse they merely began their test right next to it. Major POI’s need to be created with different LOD levels. We as users though need to understand that the more information a scene we’re flying into contains, the longer the load times are going to be for that scene. Seeing Devil’s Tower as a nice little bump from 10 miles away also means that the scenery directly around us at that 10 mile point needs to also contain some detail of a far away object. Hopefully Asobo will continue to add detail and stay honest with us about all of this.

1 Like

My guess is the promotional videos were made with multiple flights over the same POI to get it right. Once an object is loaded, I believe it stays loaded or at least resides in cache regardless of LOD factor.


I’ve tried different Cache Options and it’s always the same with these POI, they do not Render in until you’re on top of them. So no it’s not Tester Bias.


In my tests over London I noticed that crappy looking buildings got better after multiple flights over the same place even after I flew away from them and back. Objects that are loaded late do seem to remain so I assumed that was a cache thing. I’m just guessing here. Ultimately we need multiple LOD objects for major POI’s. All I’m talking about is how this may have got past the QA stage. Let’s say as a tester you have 30 objects to check off and some very short time frame to get done because your company has bragged about the release. The tester’s bias would be slewing very close to your object to begin your test instead of flying to it from 10 miles off which doing so over 30 objects would take up a huge amount of your time. If it remains in memory or cache it would cloud the results even if you flew away and back. I’m not excusing it. You should see how detailed the QA department of our software company gets. It almost seems ridiculous at times. Our product is extremely high quality but then again we aren’t selling to an audience of impatient gamers either. lol

Any tip on how to do this ourselves? Great work!

I have this issue on only one of my own imported objects. All other imported objects show up just fine, but one only pops in when I’m practically divebombing the building.

My xml only shows this:

?xml version=“1.0” ?
ModelInfo guid="{df4edded-554a-4880-4805-15f27a714f00}" version=“1.1”/>

It’s the big round building in the middle that draws only when close

I’ve reported this bug month ago both on forums and to zendesk and nothing was done about it. Not just that, but some POI’s have issue with shifting up and down depending on LOD.

Finally more people notice this issue, but Asobo doesn’t care to revisit all the landmarks to actaully fix them.

I’ve lost all hope that this will ever get addressed. It’s the main reason why I didn’t buy any in game addons and haven’t played MSFS in weeks.

It just takes away all the fun from exploring when suddenly landmarks (that are used for VFR flying btw), don’t load until you nearly crash into them.

I was gonna buy CRJ too just to have a nice plane to explore the world… now? Not so much. Asobo fixes the issue, I return and buy all the addons I want and they get profit along with third party devs… Asobo ignores this issue and I won’t bother with MSFS anymore. Simple.

@Jummivana Please do something. This bug has been plaguing the game since USA world update, and the more world updates they push, the more POI’s will release as broken, and the more they will have to revisit each World Update. They are going to stack each and every World Update with this bug until there’s thousands POI’s that are BROKEN. The more POI’s there are to fix, the more time they have to spend fixing them. It’s best to fix this bug now instead of letting it fester.

This is bad to ignore now because it will get WORSE.