Landmarks shifting up and down + Half of them not loading correctly (still not fixed in 1.13.16.0)

[leppie2013]

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

[leppie2013]

Success!

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

Steps:

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)

[hobanagerik]

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

[leppie2013]

@hobanagerik

beginner

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.

@hobanagerik

just a few days

Few hours, on and off.

@hobanagerik

Asobo, please take note of this.

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

[YearlingDeer319]

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…

[MarcG888]

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)

[leppie2013]

@YearlingDeer319

when scaling in 3DS Max, that one should always scale at the vertex level

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

[YearlingDeer319]

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

[YearlingDeer319]

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.

[leppie2013]

@YearlingDeer319

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

[YearlingDeer319]

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”.

[leppie2013]

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

Paging @OlieTsubasa443 for attention

[MarcG888]

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

[leppie2013]

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

This one https://forums.flightsimulator.com/t/poi-very-late-rendering-draw-pop-in-solution-for-asobo-to-fix-in-this-thread/368281/28?u=dronkeyklong

Please dont mark it as a solution!

[StellarRunner]

@DronkeyKlong

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

Steps:

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)

Hope moderators can elevate this to Asobo.

[MarcG888]

First post updated

[CriticalClub72]

@DronkeyKlong

<ModelInfo version="1.1" name="DoverLOD" guid="{424af5ee-7b8d-4eaf-84ec-1593a95f36cb}">
	<LODS>
		<LOD minSize="1" ModelFile="doverlod.gltf" />
	</LODS>
</ModelInfo>

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…

[leppie2013]

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.

[CptLucky8]

@DronkeyKlong

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

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:

Commenting:

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

---

@Jummivana
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!

In Zendek:

• 61475 Photogrammetry, Ground Textures and LOD ring distances
• 66041 Vegetation impostors/objects ring distance algorithm failing in HIGH or ULTRA depending on the species.
• 70848 Terrain LOD distance is using the square root of its value.

[leppie2013]

@CptLucky8

Congratulations to all in this topic nailing this one down!

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