Insane Ring Tweak....Where is this??

Most likely your FPS is limited by GPU. Perhaps it is the common case (but I have an unusual PC with i7 860 from 2009 coupled with GTX 970, so I am rarely limited by the GPU).

I was also testing new code for my shaders and focused purely on CPU performance that's why I noticed a big impact there and wanted to share my observations :)
 
Most likely your FPS is limited by GPU. Perhaps it is the common case (but I have an unusual PC with i7 860 from 2009 coupled with GTX 970, so I am rarely limited by the GPU).

I was also testing new code for my shaders and focused purely on CPU performance that's why I noticed a big impact there and wanted to share my observations :)

Thanks very much for sharing your thoughts, Ankor. It is an opaque world to me, your rays of illumination (and Majormagee's) are most welcome.
 
My system runs at 60fps, got maybe 61 with this ring setup. What did change is that it eliminated all the stuttering, never seen this before, smooth as glass. Awesome. Checked out with eto and maw43 on a i7-6700 cpu 3.4ghz/16gb ram/64bit/GTX 1060 6Gb system.

Thanks everyone involved in getting cfs3 to where is today.

slacker
 
After some more flying, have to say that I don't really see that much of a difference. I guess it was wishful thinking at first, hoping I'd seen the last of stutters. Compared to the early days, the stutters on my system are really not a issue. Just have to ignore those that are left.

By the way I don't understand any of these technical details, so I'm grateful to all that have shared their knowledge and experience.

Thanks.

regards,

slacker
 
I was also testing new code for my shaders and focused purely on CPU performance that's why I noticed a big impact there and wanted to share my observations :)

I may have an even more extreme situation - an old Core2Duo, E6750 to be exact, paired with a 670 GTX. Previously I had a 470 GTX and with the rest remaining unchanged the FPS change was barely noticable so I'm very likely limited by CPU power. As a conclusion I should see quite a difference, results coming during the weekend.
 
After some more work to minimize the stutters, and to optimize the appearance out to a reasonable distance so that the objects don't suddenly pop into existence or change appearance suddenly, I came up with this for ETO at 3840 x 1024.

Scenery
<Rings AboveGroundLevel="0" MaxDistEyeInnerRing="0">
<Ring PatchWorldDim="4096" RingDim="9" LOD="25" MajorDensity="0.000044"/>
<Ring PatchWorldDim="2048" RingDim="15" LOD="25" MajorDensity="0.000044"/>
<Ring PatchWorldDim="1024" RingDim="23" LOD="75" MajorDensity="0.000044"/>
<Ring PatchWorldDim="512" RingDim="21" LOD="75" MajorDensity="0.000044"/>
<Ring PatchWorldDim="256" RingDim="19" LOD="125" MajorDensity="0.000044"/>
<Ring PatchWorldDim="128" RingDim="17" LOD="125" MajorDensity="0.000044"/>
</Rings>

The density of 0.000044 objects / sq m provides scenery objects spaced out on a 500 ft grid, out to a diameter of about 7-1/4 miles. (PatchWorldDim x RingDim / PI measured in meters.) creating about 4,600 autogenerated objects.

I spent some time doing this again for ETO on my new system. i7 7700K @ 4.6 GHz, 16 Gb DDR4 @ 3.2 GHz, 4 Gb GTX 980, and 100 mHz G-Sync ASUS monitor @ 3440 x 1440.

I tried this
<Budget Name="Five">
<Rings AboveGroundLevel="0" MaxDistEyeInnerRing="0">
<Ring PatchWorldDim="1024" RingDim="80" LOD="20" MajorDensity="0.00025"/>
<Ring PatchWorldDim="512" RingDim="25" LOD="50" MajorDensity="0.00025"/>
<Ring PatchWorldDim="256" RingDim="25" LOD="70" MajorDensity="0.00025"/>
<Ring PatchWorldDim="128" RingDim="25" LOD="100" MajorDensity="0.00025"/>
</Rings>
</Budget>

versus this
<Budget Name="Five">
<Rings AboveGroundLevel="0" MaxDistEyeInnerRing="0">
<Ring PatchWorldDim="8192" RingDim="10" LOD="20" MajorDensity="0.00025"/>
<Ring PatchWorldDim="512" RingDim="25" LOD="50" MajorDensity="0.00025"/>
<Ring PatchWorldDim="256" RingDim="25" LOD="70" MajorDensity="0.00025"/>
<Ring PatchWorldDim="128" RingDim="25" LOD="100" MajorDensity="0.00025"/>
</Rings>
</Budget>

I was careful to account for AnKor's discovery that the budget files will substitute values from lower budget levels if you try to skip over the intermediate values, so deleted those as required.

Both of the tests look the same in game and provide a density of 647.5 objects / sq mile on a 207 ft grid, which is in the middle of the Residential / Savanna scenery class, out to 26 km (16 miles). This now involves displaying 130,800 autogenerated objects!

In the first case, flying along at 2500 ft everything is nice and smooth with a steady 77 FPS on my system.

In the second case, the game still hits 77 FPS, but suffers from long pauses on a regular basis.

I suspect the problem with making an outer ring extend inward farther is that it creates a lot of overlapping segments that has to get sorted out. I really did not expect that simply making an inner ring extend farther out would work so well.
 
I tried Andrey's texture budgets mod, and got a modest 5-10 fps increase in built-up areas, but odd effects on terrain bump mapping at airfields. Up close it looks like heavily exaggerated bump mapping, and in the distance, it looks like this:
37YSZHr.jpg
 
MajorMagee,
I've tried using RingDim="5" with huge PatchWorldDim for scenery budgets and just 2 or 3 rings to get different LODs, but couldn't get conclusive result (I haven't tested much though). It reduces the number of draw calls (i.e. how many times CPU has to send commands to GPU), but CFS3 still has to generate every tree on the CPU. As you say overlapping may cause even worser performance.

I have reverse engineered a lot of scenery related code and hope to replace it with something more efficient (not sure if will succeed though).

gecko,
Good point. I completely forgot that I have bump-mapping hard-coded to 256 pixel textures.

Terrains.fx line 49
const static float fTextureSize = 256;

Changing this to match PatchPixelDim should return the correct look, though I haven't really tested it.
 
OK weekend's over, results.

Normally I'm getting around 65 fps, occasionally dropping to 55 or so. With the ring tweak the base figure shot to around 80 and I was jumping with glee - until I too encountered the long pauses. Not good. Something is improved but something goes wrong and in this case the problems outweigh the advantages.

On a more positive note, that bump mapping issue has been an annoyance and I can confirm that changing the figure to match PatchPixelDim fixes it for good. :encouragement:
 
The discussion over here

http://simhq.com/forum/ubbthreads.php/topics/4421045/re-mod-to-remove-blue-triangles#Post4421045

about the PatchPixelDim values and blue triangles helped me finally get control over some long standing repeating pauses I've never been able to eliminate. For a while I've been thinking that the hitching was related to some sort of memory reallocation that was happening. So, I lowered the value from the default of 256 to 128. With the 1032 texture patches I've been using (see post#82, and #99) this reduces the memory requirement from 270.5M to 67.6M. Flying fast, at low altitude I would see a micro-stutter about every 18 seconds before. By lowering the PatchPixelDim value that period has been extended to over 72 seconds, if I see it happen at all.
 
Last edited:
Thanks Andy for the previous in my other post. I have been playing around with the compositescenerybudgets.xml as suggested in your SimHQ post(s). I thought I had a pretty good machine (see below) but the High Density version caused serious problems! Mind you it was at 2000' over London. I am still playing around with it a bit but obviously my rig is a bit old for the higher density settings!

OS: Win10 Professional 64 bit
Intel(R) Core(TM) 17-2600 CPU 2 3.40GHz 3.70GHz
RAM 16Gb DDD3 (2 X 8Gb)
MB: Asus M4N68T-MV2
Vid Card: NVidia Gforce GTX 970
C Drive:Samsung SSD 850 EVO 1Tb
D Drive:Samsung SSD 850 EVO 500Gb
E Drive ITB Samsung HD103SJ 32M 7K OEM
F Drive: 2 x Seagate BarracudaGreen 2TB HDs in RAID
Power: PSU Seasonic X750 Gold 750W
Monitor: 46” Samsung 630 LED LCD + 2 27"Acer Monitors
Track IR5.
 
So I've been rediscovering the optimal CFS3 parameters to go with my new system (Ryzen R7 3700X and RTX 2070 Super at 3440 x 1440). The PatchPixelDim trick discussed above seems to be no longer valid with having twice the GPU memory available. Rather than lowering the value in AnKor's Terrain.fx from 256 to 128, I've now increased it to 512 and things "seem" smoother. (1024 quickly ends up with a game crash back to desktop)

In most situations this system can sustain slightly more than my Gsync monitor's 100 FPS refresh rate, so I looked at the various GPU settings to see if Fast Sync, Vsync or No Sync with and without FPS limiter would do best. For now I've settled on Vsync set with Nvidia Profile Inspector and no In Game or Nvidia FPS limiter. I did discover that setting AnKors d3d8.ini to
VSyncMode=-1 helped as the Default, or On values seemed to produce more frequent micro-stuttering when Nvidia is also trying to apply its Vsync process.

With Vsync limiting the max FPS the CPU and/or GPU are rarely ever maxed out, and their temps stay in the low 70C range, so there's very little fan noise from either one compared to what I used to have.
 
Back
Top