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)
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.
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:
| 0m LOD0 75 m | LOD1 150 m | LOD2 300 m | LOD3 600 m | etc...
| 0m LOD0 105 m | LOD1 210 m | LOD2 420 m | LOD3 858 m | etc...
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...
- 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:
- Why many are finding the draw distance is shorter than pre-release.
- Why some trees are disappearing then reappearing .
- Why trees draw distance is different per-species AND per-Trees LOD setting like I’ve also demonstrated.
- Eventually why trees size affects trees draw distance too abruptly.
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.
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)