Tree Draw Distance / LOD Issues

while claiming trees are now back to release state, which is strange, since patches after after release alowed it to show them way further. WHY the restriction besides claiming “engine optimisations”?

There is one thing that is so obviously showing: FLOATING lights.
showing tree coverage on a washy stream AND in front of a mountain range sadly is very unconvincing.


THIS is what the community wants i guess: before 1.14.5.0 trees visible until the farthest mountains.

2 Likes

Stunning picture with the Cessna!

1 Like

Where are these screenshots taken from?
Can you try measuring the LOD in a place near the equator?

NB: there is bug where LOD is changing with COS(LAT)…

Hopefully Asobo will see this problem now when they are working on the Nordic update. Much of Scandinavia is flat woodland and it looks terrible right now.

I believe the draw distance depends on how tall the trees are. Possibly in subtropical and tropical areas trees are taller, hence the draw distance is larger.

You are wrong. If I edit the trees in the Nordics to be 1000 feet tall, the draw distance is still less than 4 nautical miles in the Nordics.

Well, I will report this bug every day to the Zendesk to boost up the fix, I hope.

2 Likes

It used to work that way. That is why the tree draw distance mods worked, they just set a really really small chance of encountering very tall trees so the sim would draw further all species of trees that were set up that way.

NOTE: This is a bug that needs attention right now before World Update 5 comes out. I will report this BUG every day until it’s fixed. The community has been waiting for months and months for this to be fixed. I know Asobo is soon finishing optimizations to make the trees draw further, BUT I’m pretty sure this is a different BUG that will remain after Asobo’s optimizations.

https://www.flightsimulator.blog/wp-content/uploads/2020/12/msfs_trees_lod_default.jpg

Image 1 above shows how awful the World Update 5 will look in the Nordics (ICAO: EFOP) if the Update still doesn’t include any change on trees’ draw distance. The trees draw distance in the Nordics by default is less than 4 nautical miles nor 10 nautical miles like Asobo stated on the latest Dev Q&A. The Equator in Colombia gave me a draw distance of 8 nautical miles with TLOD 125. Meanwhile, in Finland, less than 4 nautical miles only.

Image 2 below is the same location (ICAO: EFOP) with the FSBlog’s tree mod before Sim Update 3 broke it. The draw distance was 8 nautical miles with TLOD 125 and 10 nautical miles with TLOD 200. This is what the community wants EVERYWHERE on the Planet.

https://www.flightsimulator.blog/wp-content/uploads/2020/12/msfs_trees_lod_fix.jpg

The BUG is: The trees draw distance decreases on the way from the Equator (10 nautical miles) towards the North/South Poles (less than 4 nautical miles), meaning the trees draw distance bug is somehow related to latitude. This bug needs more attention and a patch before World Update 5 is released.

9 Likes

It might be good to set this up so it can be voted on. It certainly looks like something weird is going on.

Asobo keeps denying the tree draw distance trimmed away since release, when in fact most simmers, including myself, think otherwise.

Asobo’s Seb also claims that they reduced the tree sizes, probably true, and increased the density of the tree coverage by adding more number of smaller trees, which I hardly think so, It’s just another reason why most of the areas now seem way more sparse than previous builds.

3 Likes

I was flying in Finland yesterday and found that the bad drawdistance was not only impacting trees, but buildings as well. Can someone confirm this? I run a RTX 3090 on an i9 9900k with 32gb 3200mhz RAM.

2 Likes

Anything terrain related seems to be affected, I was told this is to prevent the majority from struggling.

1 Like

Video illustrating what I see. It’s crazy how the building just pop in and out.

3 Likes

how is this thread with 349 votes neither in the “top wishes” nor “top bugs” list?

2 Likes

Reports to Zendesk.

Probably because there are already two items on the snapshot regarding tree LOD and density. There are five separate tree threads with 250+ votes each, if they all appeared on the snapshot then it wouldn’t allow for other unique bugs to be answered.

I think the moderators should merge all these threads into the top voted one, and ask users to cast their vote again if they haven’t already done so.

6 Likes

It seems in the Nordics update the developers have once again reduced tree draw LOD/distance, with trees now having sharp cutoff lines and popping in horribly.

This absolutely ruins immersion of the game, please stop reducing the LOD of objects/trees with every update.

It seems the PC is not allowed to perform better than the XBox.

Could this maybe modded somehow?

Karl

This obsession with XBOX is total nonsense.

I guarantee that the new generation of consoles are more powerful than at least 60% of the PC’s that people are playing this game on. The irony of people moaning about the new consoles but then proclaiming they play on a laptop can’t be obvious to me only, surely?!

The tree (and building) LODs are a joke and desperately need sorting out. If the tree LOD has genuinely reduced again with this update then there must be another reason for it.

IMHO it is extremely unlikely that it’s down to the XBOX release.

2 Likes

To moderators: this is a factual description of what appears to be a bug and this shouldn’t be merged with other “LOD” discussions otherwise this valuable information for the developers might be lost in the noise.

This is my third post about the LOD questions:
LOD: settings and suggestions
LOD problems - Trees Fix Revisited
Facts and illustrated comparison between previous versions and v1.9.3 (SFO Feb 2020 vs Oct 2020)
Facts and illustrated comparison between previous versions and v1.9.3 (KOAK LOD Experiment)

Hi,

This is my next installment about the LOD problems in the simulator which I’m trying to rationalize in order to both help Asobo finding the root causes faster, if any, as well as to avoid judgements based on perception alone.

First let me try to explain what it is about: the simulator is dividing the aircraft surroundings in concentric circles and the farther away from the center, the less resolution and objects are drawing. This is a normal optimization. However if the rings are too close to the aircraft, the visual appearance gets degraded, because the rendered object or texture doesn’t match the optimal size/resolution it could display at. The possible visual defects could be:

  • Melted buildings with photogrammetry, because they are displaying closer to the aircraft a level of details supposed to be rendering farther away.
  • Low resolution ground textures when seen from above, because again they are displaying closer with a level of details supposed to be rendering farther away.
  • Low definition 3D models, again for the same reasons.
  • etc…

Usually the distance between a ring and the next is double the distance of the previous one (exponential), which makes sense I guess because of Pythagoras:

| 0m  LOD0  D m |  LOD1  2xD m |  LOD2  4xD m | LOD3 8xD m | etc...

In this post, I’m trying to measure what are the various LOD ring distance in order to find whether they could be too small and tightly packed, therefore causing visuals degradations too close to the aircraft. And I think I’ve found a problem with the LOD ring distance calculation.

First let’s start with the screenshots. There are 2 series of screenshots measuring from drone view the distance to the ground until the texture changes to the lower LOD.

Using Terrain LOD 100%:




Using Terrain LOD 200%:




Comparing the LOD distances:

LOD 100%: | 0m LOD0 75 m | LOD1 150 m | LOD2 300 m | LOD3 600 m | etc...
LOD 200%: | 0m LOD0 105 m | LOD1 210 m | LOD2 420 m | LOD3 858 m | etc...

Analysis:

On one hand, FS2020 is using the exponential LOD distances like I’ve explained above, this is ok.

However on the other hand, FS2020 is using LOD distances which are not reflecting the Terrain LOD multiplier, and I believe there is an error there: when using Terrain LOD 200% I’d expect LOD0 distance to be 150m, LOD1 300m, LOD2 600m etc… effectively doubling the distance from Terrain LOD 100%.

Now if you look closely to the number and make abstraction for imprecise measurement given the tooling, you find out:

Terrain LOD 200% = 1.4 x Terrain LOD 100%

as a reminder: 1.41 is the square root of 2...

Conclusion:

  • I believe there is a bug in the FS2020 code using the Terrain LOD % slider not as a percentage, but as a square root of the percentage which is unexpected.
  • It is possible this error is spread out to some or all other code using the Terrain LOD value.
  • I can’t compare with pre-release LOD distances because I’ve never measured them.

If this is a programming error, this could explain:

In addition, I believe even at Terrain LOD 100% the distances rings are too close to the aircraft and are reducing the rendering quality very fast a few meters away.

I’d recommend instead using the current (Terrain LOD 100% x 2) as the actual LOD 100% at a minimum. This would give more pleasant details immediately while also supporting zooming in a little without degradations. It won’t introduce any rendering performance problems either because users can still lower the LOD settings with the slider in order to make it the same as it is today (in this case we’ll use 50%).

If the chosen LOD ring distances are a chosen to accommodate the XBox version because the XBox hardware is measured as less performant than most PC simmers are using, then I’d suggest you use 2 different set of values: one for XBox and a different one for PC. If however XBox is proving in your test being superior to most PC simmers are using, then it won’t change anything because we can still reduce the slider if needed (but we can’t raise it past 200%… which really is 141% today)

Please vote this topic so that it gets higher chances being in Asobo’s radar as quickly as possible

I’m filling a Zendesk in the meantime and I hope this will be of any help!

[update] filled as: Request #70848 Terrain LOD distance is using the square root of its value.

[update2] for those wondering why Asobo is taking so much time with bug fixes, you have to realize they are receiving a lot of Zendesk and this takes time just triaging. In looking at my last 2 reports (68719 Oct 16 14:32 and 70848 Oct 25 14:15) you can deduce they have received 2129 request during this time. If they were treating all of them over the 5 working days in this time span, there are about 426 request per day to read, analyse, answer or dispatch!! If they’re working 8h a day, this is nearly 1 request per minute… This should put some of these numbers in perspective.


[UPDATE 14FEB2021]

I’ve posted a new series of screenshots showing further showcasing how LOD distance might be wrongly computed with a 1.41 factor (square root of 2)