Very interesting find… Hope it’s been reported on Zendesk too.
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.
thank you for your feedback @Wookie042. This is really puzzling indeed.
And it looks like there is a limit set for rendering at half the screen also.
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.
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
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.
Outstanding work, and fingers crossed the ticket gets marked as “Solved”, and gets added to their list.
Good find! That explain not intentional downgrade from the Q@A, it’s a bug, these started since release to patch, trees\building there is always tweaking on these it did reduce LOD indirectly.
Actually from alpha to release it was reduced, and on patch 2, this was not intentional LOD reduce, because of the height vs LOD bug.
Wow nice find
Another great find from you, after getting to the core of the building height bug.
They really should pay you for all the actual beta testing you are doing for them.
Cool. Thank you. Is there anything we can do in the mean time to keep the tree draw distance up? I don’t particularly care if the trees are too tall, though I understand that others do.
The problem is not only the size of tree, there are too much trees in lot of places. This impact the realism and performance.
Bushes are taken for trees, shaded roads are taken for rows of trees, shaded areas in town are taken for trees …
It’s not just with trees. The draw distance of objects seems to be directly related to their size. So small cones on a runway disappear much earlier than a windsock, which disappears earlier than a hangar…
Nice find. I hope Asobo can analyze this.
There is no much we can do for now but Asobo identifying and resolving the problem in their code. In the meantime, you can still use the Trees-Fix-75pct_max community fix to lower the size of the tree along with Trees LOD set to HIGH or ULTRA depending if you fly more over Decideous (mostly plains) or Conifer (mostly mountains) respectively.
Just going to keep them default for now. The draw distance is much better. Personally I like to see them in the distance while flying.
(sorry SurlierMovie919 the forum limits to referencing 10 people max!)
Thank you all for your kind words!
I’m glad their latest feedback snapshot is mentioning next patch (#4) will fix the buildings.
However there remains a lot of “tree and LOD” related posts which investigation isn’t even started:
There is valuable information in all these discussions but this is all spread out and buried in various posts. This is one of the reason I’ve tried investigating and documenting at least a single problem related to trees and ring distance which I hope will be helping Asobo finding a solution faster.
We also must try getting their attention to the information I’ve disclosed in raising the vote count above their minimum threshold (the 30th in their list is 142 votes and this discussion is only at 50% of this threshold).
Let’s help us all: please cast your vote to this discussion and tell your friends!
I swear sometimes I think developers are just better off opening their code up to the community. Imagine if you all had access to everything you needed to tweak to your hearts content?! The scenery modders, The A320 team, the G36 team, the G1000 team, everything would be done within a few months
EDIT: Removed “guys” because it’s 2020.
I thank you for your vote of confidence!
You might be onto something though because history shows the most prolific mod creativity often come with the most open platform.
However I imagine in this case, one of the first thing I’ll probably do is making sure you’d get the Reality XP GTN 750/650 and the Reality XP GNS 530/430 V2 in FS2020!