Damn. Those are insane! How's the FPS though? Microstutters?

Okay finally running again. I guess the third time's a charm.

<Budgets>
<Budget Name="Debug">
<Rings AboveGroundLevel="0" MaxDistEyeInnerRing="0" MaxMilesPerHour="50">
<Ring PatchWorldDim="64" RingDim="3" LOD="250" MajorDensity="0.0001"/>
<Ring PatchWorldDim="128" RingDim="7" LOD="250" MajorDensity="0.0001" />
<Ring PatchWorldDim="256" RingDim="7" LOD="20" MajorDensity="0.0001" />
<Ring PatchWorldDim="512" RingDim="13" LOD="17" MajorDensity="0.0001" />
</Rings>
<Rings AboveGroundLevel="0" MaxDistEyeInnerRing="0">
<Ring PatchWorldDim="128" RingDim="7" LOD="250" MajorDensity="0.0001" />
<Ring PatchWorldDim="256" RingDim="7" LOD="20" MajorDensity="0.0001" />
<Ring PatchWorldDim="512" RingDim="13" LOD="17" MajorDensity="0.0001" />
</Rings>
<Rings AboveGroundLevel="250" MaxDistEyeInnerRing="0">
<Ring PatchWorldDim="256" RingDim="7" LOD="20" MajorDensity="0.0001" />
<Ring PatchWorldDim="512" RingDim="13" LOD="17" MajorDensity="0.0001" />
<Ring PatchWorldDim="1024" RingDim="13" LOD="17" MajorDensity="0.00005" />
</Rings>
<Rings AboveGroundLevel="500" MaxDistEyeInnerRing="0">
<Ring PatchWorldDim="512" RingDim="13" LOD="17" MajorDensity="0.0001" />
<Ring PatchWorldDim="1024" RingDim="13" LOD="17" MajorDensity="0.00005" />
<Ring PatchWorldDim="2048" RingDim="13" LOD="17" MajorDensity="0.000025" />
</Rings>
</Budget>
<Budget Name="One">
<Rings AboveGroundLevel="0" MaxDistEyeInnerRing="0">
<Ring PatchWorldDim="1024" RingDim="50" LOD="20" MajorDensity="0.000150"/>
<Ring PatchWorldDim="512" RingDim="25" LOD="50" MajorDensity="0.000150"/>
<Ring PatchWorldDim="256" RingDim="25" LOD="70" MajorDensity="0.000150"/>
<Ring PatchWorldDim="128" RingDim="25" LOD="100" MajorDensity="0.000150"/>
</Rings>
</Budget>
<Budget Name="Two">
<Rings AboveGroundLevel="0" MaxDistEyeInnerRing="0">
<Ring PatchWorldDim="1024" RingDim="50" LOD="20" MajorDensity="0.000175"/>
<Ring PatchWorldDim="512" RingDim="25" LOD="50" MajorDensity="0.000175"/>
<Ring PatchWorldDim="256" RingDim="25" LOD="70" MajorDensity="0.000175"/>
<Ring PatchWorldDim="128" RingDim="25" LOD="100" MajorDensity="0.000175"/>
</Rings>
</Budget>
<Budget Name="Three">
<Rings AboveGroundLevel="0" MaxDistEyeInnerRing="0">
<Ring PatchWorldDim="1024" RingDim="50" LOD="20" MajorDensity="0.000200"/>
<Ring PatchWorldDim="512" RingDim="25" LOD="50" MajorDensity="0.000200"/>
<Ring PatchWorldDim="256" RingDim="25" LOD="70" MajorDensity="0.000200"/>
<Ring PatchWorldDim="128" RingDim="25" LOD="100" MajorDensity="0.000200"/>
</Rings>
</Budget>
<Budget Name="Four">
<Rings AboveGroundLevel="0" MaxDistEyeInnerRing="0">
<Ring PatchWorldDim="1024" RingDim="50" LOD="20" MajorDensity="0.000225"/>
<Ring PatchWorldDim="512" RingDim="25" LOD="50" MajorDensity="0.000225"/>
<Ring PatchWorldDim="256" RingDim="25" LOD="70" MajorDensity="0.000225"/>
<Ring PatchWorldDim="128" RingDim="25" LOD="100" MajorDensity="0.000225"/>
</Rings>
</Budget>
<Budget Name="Five">
<Rings AboveGroundLevel="0" MaxDistEyeInnerRing="0">
<Ring PatchWorldDim="1024" RingDim="50" LOD="20" MajorDensity="0.000250"/>
<Ring PatchWorldDim="512" RingDim="25" LOD="50" MajorDensity="0.000250"/>
<Ring PatchWorldDim="256" RingDim="25" LOD="70" MajorDensity="0.000250"/>
<Ring PatchWorldDim="128" RingDim="25" LOD="100" MajorDensity="0.000250"/>
</Rings>
</Budget>
</Budgets>

This runs well on my system (i7 7700 @ 4.6 GHz CPU, GTX 980 GPU, and 100 MHz 3440 x 1440 G-Sync monitor) at level Five. (Makes me wonder if I should be pushing the density values even higher.)

This does take care of making the auto generated scenery steady out to about as far as you can see. You will still see some predefined things like airfield objects pop into existence and change LODs as you approach them.

yaan98, the original file has DetailTileCount="8", right? What is the major impact of changing this value?

DetailTileCount – This value specifies the number of times to tile the detail texture across a single texture patch. The default value is zero; when this value is non-zero, an additional detail texture is blended with the terrain textures.

Thanks for that info.

My final modifications to scenerybudgets which worked very good on my system (so far):

<Ring PatchWorldDim="1024" RingDim="21" LOD="17" MajorDensity="0.00046"/>
<Ring PatchWorldDim="512" RingDim="45" LOD="50" MajorDensity="0.00046"/>
<Ring PatchWorldDim="256" RingDim="45" LOD="70" MajorDensity="0.00046"/>
<Ring PatchWorldDim="128" RingDim="45" LOD="100" MajorDensity="0.00046"/>

Interestingly, the first ringdim makes a huge impact to the point it crashes cfs3.exe if I wander into the 30s or 40s. However, I can raise any of the other ones besides the first without crashes. Also, I see no difference in view distance if I reverse those numbers and put the first ringdim at 45 while the rest at 20s. I noticed that density setting at 46 is just as good as 50s and 60s. Between ~36 - 44, there is slightly lower density of trees/buildings, but better FPS (~5 FPS) and less hanging.

Overall, I'm pleased with these results.

This is all top-notch, everyone! Thank you, Hellshade, for opening this up for discussion; and thank you, AnKor, MajorMagee, and yaan98 for your experiments with the compositescenerybudget.xml and compositetexturebudget.xml files! I have also experimented with these variables and am generally pleased with the results.

Notably, altering the compositescenerybudget.xml file also has an effect on how clouds are displayed. Generally speaking, the cloud shimmering that people tend to see with certain clouds can be "pushed back" into the distance by increasing the diameter of each of the texture rings. While this doesn't get rid of the problem, it does tend to push it into the distance where it may be less noticeable. I suspect that the cloud popping problem is influenced by the size of overlapping texture rings, as well. Increasing the diameter of each ring may make this less noticeable, as well. Unfortunately, coming up with settings in the compositescenerybudgets.xml file that both improve the rendering of objects on the ground and clouds in the sky at the same time may be quite difficult to achieve. We will have to see!

As was discussed during the course of this thread, the values are going to need to be tuned to each system that's running this Mod to avoid running out of memory. My problems started only when I pushed the outer RingDim up to 80 from the 50 shown above. Since the area driving the object count for a given density is a function of the square of the distance (pi * r^2) dialing that back to 50 (5 mile view distance instead of 8) resolved the issue for me. If you are having a problem, then you can either reduce that further (45, 40, etc), or lower the density (use one of the lower Scenery Budget settings) if you want to keep seeing auto-generated trees and buildings out to the edge of the haze. This need to tune it for each user is why I've been cautious about recommending this getting converted into a one-size-fits-all Mod.

I believe DX9 shaders ignore the value of DetailTileCount, just set it to a small non-zero number for best performance (or zero but you will lose terrain details for the nearest texture).

The diameter of the ring is calculated as the PatchDim x RingDim / 3.14 ( derived from Pi x Diam = Circumference) where the Patch Dim is the dimension of the patch in meters, and the RingDim is the number of patches around the edge.
The way you show it above the 1024 ring (6844m diam) is a smaller diameter than the 512 ring (7333m diam). I'm not sure what the rendering engine is going to do with the overlap, but that's why the view distance didn't change.

I spent a lot of hours twiddling with the numbers until I got a steady 77 FPS on my system with a reasonable looking scenery density.

I did some research into the classification of real world object densities. It turns out that we measure trees in a similar way to buildings.

Trees, Buildings, Scenery Density, Objects/hectare, Objects/sq mile, Spacing in ft
Prairie, Rural, <0.00005, 0 - 0.5, <129.5, >464
Savanna, Residential, up to 0.00050, 0.5 - 5, 129.5 - 1295, 147 - 464
Woodland, Mixed Residential, up to 0.001, 5 - 10, 1295 - 2590, 104 - 147
Forest, Urban, >0.001, >10, >2590, <104

The implication is that our scenery budgets should ideally be tailored to each particular landclass area rather than universally as they are now. Building the scenery density values into the landclasses.xml would make the simulation look much more realistic, but from a programming perspective the memory allocation becomes very difficult because the requirement is constantly changing as a different mix of landclasses comes into view while you're looking around. You could error on side of allocating the maximum possible (like flying over a city center all the time) but that might eliminate some systems from being able to run the sim at all.

p.s. The landclass.xml file provides a dimension value in multiples of 1024. The number of objects that are generated within each landclass changes as a combination of this dimension and the density set in the scenery budget. When the land class files were created the pixel locations within the tile where the auto-generated scenery objects could appear was predefined (e.g. trees only appear around the edges of open fields). Adjusting the Dim value in the landclass.xml file can change the total number of objects being created for a given scenery density value, but it also changes things like the size of the fields, and city blocks within a particular landclass area being displayed. So, in addition to adjusting the global scenery density values, you can tune the performance by making localized changes to the Dim values in the landclass.xml, but you will change the size of the terrain features you see by doing it that way. For example with a large value like 10240, you could end up making the small hedgerow fields of Normandy look like the wide open spaces of the American Mid-West.

From my experimenting over the years I've never found anything that was able to influence the draw distance for the clouds. I've come to the conclusion that it's hard coded, but I'd love to find out that I'm wrong.