It should be visible till the scaled size of the model is less than minSize. Thats why I say 1 instead of 0 as 0 implies it will always be loaded.

1 Like

The official cliffs seem to stop rendering at around a size of 25, then starts again at 28.

The problem is the initial loading of the model only happens at a size of 250.

You need to be about here for it to trigger the load, followed by a massive stutter.

1 Like

I see this quite a bit, e.g. with the Devils Tower, I was flying along looking for it, then, wham, right in front of me and no way to avoid lol!


I did test to verify what happens to my model without LOD entry to verify the bug. Interestingly when compiled, it automatically add a LOD entry into the BGL.


The question is how was the official BGL compiled and it was not automatically added like it did for me? Is this just a recent addition to the SDK and the official ones were compiled with older versions? I did not see any mention of changes inthe SDK release notes.

Update: I see the official BGL does the same.


I am going to investigate more.

1 Like

This is starting to look like a bug in the 3dsmax exporter.

You will note (slightly cuttoff) in the images that there is a big difference between values in max .

The effect of this, is the calculated bounding box much bigger on my version than the official version. So far this is the only difference I can spot.

Not sure why ModelConvertorX is changing this. It might actually be ‘fixing’ something intentionally, but going to see if I can get the model out without modification.

Update: Figured out why there is a difference. The official applies mesh operations in the gltf, whereas it seems ModelConverterX applies it to the model (like one would in Blender).

There are 4 parts in the model, 3 of them is scaled up by a factor of 45 and the other 78. This is explains the small bounding box. The potential bug here is that MSFS does not consider scaling options in gltf files. I think I have an idea how I can repro this :smiley:



Managed to recreate the issue exactly. It was as I suspected in the update of previous post.


  1. Open my version in Blender
  2. Scale root node to 0.022
  3. Apply the scaling transform in Blender
  4. Scale root node to 45 (back to same size now, but dont apply in Blender)
  5. Export GLTF file

Now both mine and the official model only loads about 1nm from the location.

I am just a Blender beginner, but one of the first things I learnt was when doing any transforms, you ALWAYS apply it as it generally leads to unexpected results.

So basically the people that made these POI’s in 3DSMax just scaled up the model without applying it (as in Blender, not sure what it is in 3DSMax). This was the mistake that exposed the bug.

The bug is that Object LOD ignores the scaling factor when it tries to determine when to load the model. In this case, you need to be 45 times closer to the model than you should be for it to get loaded.

Some other fun facts:

  • Terrain LOD and Object LOD is simply draw distance, it has nothing to do with detail/quality at all.
  • Object LOD has a logarithmic scale. IE if at 100 the object size is 1.0, then at 50 it will be 0.7 and at 200 it is 1.4.

PS: Imagine the OP just silently reported this to Zendesk, the bug would have just gone into the blackhole.

Edit: It should be quite easy to detect all the cases where transforms have not been applied in the BGL files, but unfortunately this is not something we as users can fix. (would if I could)


So you as a beginner worked out the problem with an update in just a few days? Asobo, please take note of this.


The only thing I ever did in Blender was to add animations to the flying goose I did. And that is the extent.

I have been a professional software developer for almost 20 years now, and I love hunting for bugs. :smiley:

Few hours, on and off.

If I could QA for Asobo, they would have a 3000 page document at the end of a week.


I was always told that when scaling in 3DS Max, that one should always scale at the vertex level, having welded where necessary, of course. Stood me in good stead for years.

How do I give you more than 1 like…


That’s awesome many thanks. No I never submitted anything to Zendesk, my fear is it’ll just get lost in the Void anyway. This really needs Urgent Attention by the Devs and not Filed away to be looked at in X number of Weeks/Months.

Are any Devs here to be Tagged perhaps? (he says hopingly)

I guess that is the same as ‘applying the transforms’ in Blender.

They’ll just say they can’t reproduce it on their system.

I think so but I’ve never used it so cannot be sure. Manipulation of polygons will inevitably lead to mesh distortions along with poor rendering performance. I wonder if that affects the LOD and why it’s so poor.

Nothing affects it. The quality is great.

This issue is with MSFS deciding at what point it should load the model. Once it is loaded, you can slew away for a good 10-20nm and still see it. It seems to actually compensate for scaling but only after it loaded the model.

Edit: It disappears a little further than this

My bad, I’m not too familiar with gaming as you can tell.

You can see the white cliffs from the cliff tops opposite in France, so as soon as you get near the border before the Channel they should be visible.

It’s disappointing to see such an iconic view “late”.

Given we have pinpointed the issue and nothing more to add.

Paging @OlieTsubasa443 for attention

1 Like

I’ve changed the thread title to reflect a Fix has been found


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