LOD problems - Trees Fix Revisited

[CptLucky8]

This is my second post about the LOD questions:
Facts and illustrated comparison between previous versions and v1.9.3

Hi,

This is a follow up to: LOD problems - Trees, water. @SlidHydra647449 attracted my attention to Trees specifically and I’ve been doing some experiments I’d like to share.

As reminder, Trees fixes are about reducing the size of trees in the simulator because they generally look taller than reality. I’ve adapted his fix into a set of different community folder fixes so that I can compare what are the different factors affecting Trees and their LOD.

Adjusting tree height requires modifying a file in the fs-base folder. This file defines certain properties per tree-type especially a min and max size. As I understand the file purpose, it is meant to define variations of the same tree types both in terms of appearance (the texture used) and sizes. It seems to me some of these min/max values are chosen so that you get further variation in mixing these in vertical layers (looking at the overlapping min/max ranges).

And here are some unexpected results which might explain why there might be opposite reports about Tree density and rendering distance.

NB: these screenshots are best seen and compared with in their native 4K resolution. The simulator was configured with Tree LOD set to HIGH (not ULTRA).

For reference, here is a screenshot with defaults:

Then I’ve adjusted all sizes, both min and max to 75%:

I immediately noticed not only a reduction in size as expected, but a reduction of draw distance which isn’t!
I’ve been wondering whether the min value could be the main factor in this.

I’ve therefore made another attempt in reducing max by 75% but in keeping min original values:

Surprisingly, some of the tree are now higher, even if the max value didn’t change! However draw distance is still lower than the original file.

I’ve made one more attempt at this in changing just 1 of the deciduous entry, the first one, with original min value and a maximum value of 51 (instead of 14) and here is stunning result:

Not only trees are higher as expected (max = 51), but it looks like changing just the first entry is raising all trees! Furthermore and even more surprising, by raising the maximum tree height it is also raising the tree rendering distance!!

I suspect FS2020 is using a formula to render trees only if their visible size is ‘high enough’ and this is directly affecting draw distance as a side effect. Although it is a sound way of doing it I also believe the implementation is not working as expected because you can see it is removing from view small tree which should be visible even if small in size.

You can download the 2 community fixes to experiment on your systems:

1. Download the file then remove the trailing .pln extension.
2. Unzip in your Community folder.

Fix#1 (75% max 75% min sizes):
Trees-Fix-75pct_max-75pct_min (1.9.3).zip.pln (2.5 KB)

Fix#2 (75% max sizes only):
Trees-Fix-75pct_max (1.9.3).zip.pln (2.4 KB)

PS: for the Skyscraper/Tall Buildings fix:
follow this link for more information and files

.
I believe Tree draw distance should only be dependent on Tree LOD, not Tree size. Even if the trees are displaying over a quad pixel area (2x2 pixels) only, they shouldn’t be removed from view.

[08OCT2020 Update (old link)] [16OCT2020 Update (old link)]

---

[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

[CptLucky8]

reserved post

[SurlierMovie919]

Wow. Great discovery man !

So if i understand this correctly , if i want to have higher tree render, i will have larger trees?

[CptLucky8]

Rather: if you want to have trees farther away, you must have oversized trees.

[SurlierMovie919]

Thats what i meant, sorry for my english.

So all they did in patch 2 was reducing tree size apparently and that caused lower tree lod…

[CptLucky8]

Did they reduce tree size in patch #2? I didn’t notice this information.

In this case I’d guess yes, reducing tree height is also reducing tree LOD and density, and I believe this is bug in their implementation, most likely in the algorithm which is trying to evict trees which are supposed not big enough to be seen.

Unfortunately this experiment is telling me the algorithm is too aggressive and because of this, I wouldn’t be surprised smaller vegetation types (cactus, etc…) have a smaller rendering distance just because they are smaller in size.

[Theodorus]

#2 works well for me.

This makes trees fixed and an other fix fixed the many 5 - 10 story buildings. Now all I need is a lightning fix and my sim word will be good. Thanks to all that worked on fixes for these problems.

[SurlierMovie919]

Hmm, they dont see smaller, but LOD got horrendous

LOD problems - Trees & Water

SBPL testing. If you want to compare yourself steps to align with this. SBPL - runway 13, 12:00 local time, 22. september 2020, clear skies align yourself on middle of starting line facing 132 degrees. now slew up to 1600ft/2500ft, turn to 069 degrees, jump in cockpit, reset camera position and zoom in. [initial position] [SBPL-1600ft-patch1] [SBPL-1600ft-patch2] [SBPL-2500ft-patch1] [SBPL-2500ft-patch2] If someone will be angry again , that the images are not conclusive and they dont see …

[CptLucky8]

Thank you for sharing this. Your screenshots are indeed showing Patch #2 is reducing draw distance but not Tree height, and Tree height alone suffice to change draw distance which is not expected.

[hobanagerik]

That post is from 15 days ago. Is that relevant to this mod? I was hoping you were going to show the results of this mod on your sim.

[CptLucky8]

I believe it is, unless Patch #3 is again doing it differently, because it shows there is a reduction of Trees draw distance introduced since Patch #a320neo

This topic is just for illustrating a major issue in my opinion in the way FS2020 is reducing Trees draw distance (which makes me wondering about the other scenery elements and their own eviction algorithm).

Please understand this post is not meant to criticize Asobo or the simulator, rather it is meant to alert Asobo about a probable deficiency they might not be aware of so that they can investigate once there is enough conclusive reports and I can submit a Zendesk. Otherwise if they are, now we are too.

[hobanagerik]

It does seem to be an odd way to do things. Perhaps it is not intentional, given their surprise at the results of their changes.

[Cygnifick]

Looks like a lod/size bug indeed, nice find. Better report on Zendesk also.

[Mermoz4481]

so can i go back to what it was before patch 1? what value would i need?

[RancidViper6904]

Very interesting find… Hope it’s been reported on Zendesk too.

[Wookie042]

@CptLucky8

(which makes me wondering about the other scenery elements and their own eviction algorithm)

I recently flew into a custom scenery somebody made for Bayport Airport 23N. The creator placed cones and a segmented circle made out of white/red barriers on the field. The segmented circle barriers first got drawn in when I already was over the runway threshold coming in for a landing and the cones, marking taxiways etc. first got drawn in much later.

This at least would give the size=draw distance theory more substance as both object types are rather small.

[CptLucky8]

thank you for your feedback @Wookie042. This is really puzzling indeed.

[Cygnifick]

And it looks like there is a limit set for rendering at half the screen also.

[CptLucky8]

I believe this is what Tree LOD (HIGH in my screenshots) is controlling instead. It just appears with the view angle trees are probably displaying only up to the middle of the screen during my session.

[CptLucky8]

[08OCT2020 Update]

I’m now convinced there is a bug in the FS2020 LOD and Tree Impostor implementation and/or configuration. I’ve spent a few hours modifying various specific values in the 10-asobo_species.xml file in order to isolate the effect of each category of values (min, max, etc…).

Given the XML file key names and the node structure, I’m pretty sure this file is controlling impostor configuration for the trees only. Impostors consist in replacing highly detailed individual trees with pre-rendered textured quad or billboards with a bunch of trees painted over. This saves a lot of draw calls and increases performance without any visual impact if done properly.

As a matter of fact, Microsoft has acquired a company specialized in this technology a few years back:
Microsoft acquires Simplygon to accelerate innovation in enabling 3D for everyone

Some useful links:
Vegetation optimization
Simplygon doc: Impostors

Back to the topic:

When experimenting I was able to make some of the trees fading away while moving closer and I suspected this was due to my changes. My understanding was that I was altering the ring distance for impostors and they were vanishing at a different distance than the distance the real 3D trees are supposed to replace.

However when reverting to the original file however I was having the very same behaviour: the closer you get to trees, the more they vanish, but as you are still closing in, they are reappearing after a short while. This is definitely a bug because simple distance eviction algorithm is binary: it is beyond or not.

Furthermore, when viewing the world in slew mode with the wide angle view, the trees are fading-in just at the right moment, that is when their size is large enough to cover a few pixels. Otherwise they are not showing and this is fine because they are usually appearing over a ground texture of the same colour. However, when in the cockpit or in zoom factors higher than 1, they are therefore appearing too late in view.

Therefore I’ve decided then to compare whether Tree LOD HIGH or ULTRA would make any difference. And yes it does!

Decideous trees are vanishing then reappearing as you get closer in ULTRA :

Conifer trees are vanishing then reappearing as you get closer in HIGH:

What is the source of the problem and what can be done?

I’m not sure because it seems modifying this file doesn’t really change the outcome much. However I’m pretty sure this file is using different values between the RTM and alpha and I’m wondering, should the ring distance be hard-coded in code, whether they also did synchronize the code in order to match the values in the file.

What is puzzling me is the Tree LOD setting is affecting different groups of trees and this further tells me the code has specific tables per tree-group which are hard coded and not in phase.

Of course I agree this is all just speculation but to me this shows there is a definitive bug in the tree ring distance handling.

What about buildings?

I believe the same bug exists in the code for the buildings. I don’t have any handy screenshots to share but it is very easy to try: start at LFMN, any runway, look toward the city to the East, and observe the following:

• closest building are showing windows.
• farthest buildings aren’t showing any window.
• some buildings in the middle of the ‘no window’ ring are still showing windows!

NB: because of the distance between LFMN and Nice, it is best visible when Buildings LOD is set to HIGH.

This tells me buildings, like trees, are in different groups and the code is not handling these uniformly in regard to ring distance visibility. On top of this, when the simulator is displaying buildings with no windows they just look like texture-less entities like big color lego bricks and this is very distracting. It would be better the simulator is displaying windows on every building even if farther away and blurry so that it gives a sense of volume and reality.

I’m now filling a Zendesk with this information.