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

starbage1 said:
What is this used for
<TerrainVertexBufferCapacity val="10000"/>
<TerrainIndexBufferCapacity val="10000"/>
Click to expand...

Um, cos I don't understand this stuff I've pulled a useful description off the net:

2.1.

Rasterization
Rasterization is a technique for rendering a three-dimensional scene. This method treats a 3D model as a set of polygons, usually triangles, and performs projectivetransformation to a plane.

This is the standard technique used by current graphics hardware. The Rasterization algorithm’s execution time is proportional to the number of triangles submitted, although the process is highly accelerated by parallelization. It is common in computer graphics to minimize the number of polygons used to draw a model by avoiding those which are not truly necessary.
This includes polygons outside the camera’s view and also any polygons which are behindother objects and cannot be seen. These are effective techniques for increasing the algorithm’sperformance. A common metric for measuring performance of a computer graphics algorithm is frames per second (FPS). This is a count of the number of images rendered within one second. 30 FPSis typically regarded as the lower - bound for the human-eye to perceive the frames as a continuous motion.

Vertex buffers are data structures used in graphics application development. A vertex buffer is filled with some data, specified by the developer.
This is typically data corresponding to a 3D model, which usually includes vertex data, normal data and texture coordinates. Data is generated on the CPU, either from a file or a procedural algorithm, which is then buffered into the GPU memory. This allows for faster access when rendering a scene. One limitation with vertex buffers is that the data cannot be modified, once it has been transferred, without the use of costly buffer function calls. For this reason, vertex buffers tend to be generated once and remain unchanged until no longer needed.

http://www.cosc.canterbury.ac.nz/research/reports/HonsReps/2014/hons_1401.pdf

So my guess is that to render all the bitty terrain triangles smoothly, a reasonable sized buffer is required. I seem to remember reading somewhere that making the buffer too big may not be a good idea. However with the sort of computer power and video cards we have these days, most CFS3 settings can be cranked up.
 
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.

The resolution of one pixel changes as the PatchWorldDimension divided by the texture patch dimension (256 in ETO). So with these budgets it goes from 1/2 meter per pixel in close up to 16 m per pixel at the far perimeter.


Texture
<ImageQualities>
<ImageQuality PatchWorldDim="16384" ImageQuality="0"/>
<ImageQuality PatchWorldDim="8192" ImageQuality="0"/>
<ImageQuality PatchWorldDim="4096" ImageQuality="0" />
<ImageQuality PatchWorldDim="2048" ImageQuality="0" />
<ImageQuality PatchWorldDim="1024" ImageQuality="0" />
<ImageQuality PatchWorldDim="512" ImageQuality="0" />
<ImageQuality PatchWorldDim="256" ImageQuality="0" />
<ImageQuality PatchWorldDim="128" ImageQuality="0" />
<ImageQuality PatchWorldDim="64" ImageQuality="0" />
</ImageQualities>
<Rings AboveGroundLevel="0" MaxDistEyeInnerRing="0">
<Ring PatchWorldDim="16384" RingDim="7" MinMaskRadius="49152"/>
<Ring PatchWorldDim="8192" RingDim="7" MinMaskRadius="24576"/>
<Ring PatchWorldDim="4096" RingDim="7" MinMaskRadius="12288"/>
<Ring PatchWorldDim="2048" RingDim="9" MinMaskRadius="8192"/>
<Ring PatchWorldDim="1024" RingDim="11" MinMaskRadius="5120"/>
<Ring PatchWorldDim="512" RingDim="13" MinMaskRadius="3072"/>
<Ring PatchWorldDim="256" RingDim="15" MinMaskRadius="1792"/>
<Ring PatchWorldDim="128" RingDim="17" MinMaskRadius="1024" DetailTileCount="16"/>
</Rings>

This provides textures out to a diameter of about 22-1/2 miles. (PatchWorldDim x RingDim / PI measured in meters.)

The resolution of one pixel changes as the PatchWorldDimension divided by the texture patch dimension (256 in ETO). So with these budgets it goes from 1/2 meter per pixel in close up to 64 m per pixel at the far perimeter.

The MinMaskRadius is calculated as the ((RingDim - 1) x PatchWorldDim) / 2 to provide smooth transitions of the overlay between rings.
 
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.

After some gpu setting changes I was able to increase my scenery density to 0.0004 or 4 objects per hectare (Savanna / Residential) while maintaining 60 fps.
 
In the cfs3 assets folder there should be these three files compositescenerybudgets.xml, compositetexturebudgets.xml, and landclasses.xml
 
MajorMagee said:
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.

The implication is that our scenery budgets should ideally be tailored to each particular landclass area rather than universally as they are now.

After some gpu setting changes I was able to increase my scenery density to 0.0004 or 4 objects per hectare (Savanna / Residential) while maintaining 60 fps.
Click to expand...

Majormagee,
does this mean that you can edit the landclasses xml to provide scenery densities tailored to landclass? How did you edit densities purely for savanna/residential? Sorry am away from my cfs3 puter so can't poke around the files.... :wavey:
 
Just needed this information again to adjust the scenery density to tune the FPS again after my migration to Win 10
 
This appears to be no longer available in the DL section. Could someone please post a link to, or maybe re-upload Winding Man's original files? If it is just a text file, perhaps copy & paste into this thread. :mixed-smiley-010:
 
FYI: These are in the Terrains folder in Rising Sun.

Should the entries given be entered at each and every 'Budget Name' or just the first one?
 
That depends on what detail settings you want to use in cfs3config.exe.

I've always had mine set to all fives, so that's the only level I bother to modify.
 
I have something interesting for you.
I've been investigating WOFF performance and found that terrain texture rings are probably the main contributor of bad FPS (another one is facility trees, but that's WOFF specific).

MajorMagee's example defines rings with dimensions from 7 to 17, with the most detailed having resolution = 128m/256px = 0.5m/pixel.
The total number of texture patches is the sum of squares of their dimensions and in this case equals 1032. Each texture is 256*256*4 bytes = 256 Kb, so the total memory usage is 258 Mb.
Everything seems good?
Well it does, but really it isn't.

For some reason CFS3 performance is very sensitive to the number of patches. It seems to run some kind of tesselation code on CPU for each frame even if you don't look at the ground. Maybe it has exponential complexity and 1000 patches means 1 million operations -- I don't know for sure, but I'm absolutely sure it is very slow.

What I found is that you can replace these patches with larger ones, reducing their total number and greatly increasing the FPS.
Here is my proposed settings:

<Budgets PatchPixelDim="1024" MinPatchDimUseThumb="4096">
....
<ImageQualities>
<ImageQuality PatchWorldDim="32768" ImageQuality="0"/>
<ImageQuality PatchWorldDim="16384" ImageQuality="0"/>
<ImageQuality PatchWorldDim="8192" ImageQuality="0"/>
<ImageQuality PatchWorldDim="4096" ImageQuality="0" />
<ImageQuality PatchWorldDim="2048" ImageQuality="0" />
<ImageQuality PatchWorldDim="1024" ImageQuality="0" />
<ImageQuality PatchWorldDim="512" ImageQuality="0" />
<ImageQuality PatchWorldDim="256" ImageQuality="0" />
<ImageQuality PatchWorldDim="128" ImageQuality="0" />
<ImageQuality PatchWorldDim="64" ImageQuality="0" />
</ImageQualities>
<Rings AboveGroundLevel="0" MaxDistEyeInnerRing="0">
<Ring PatchWorldDim="32768" RingDim="3" MinMaskRadius="65536"/>
<Ring PatchWorldDim="8192" RingDim="5" MinMaskRadius="16384"/>
<Ring PatchWorldDim="2048" RingDim="5" MinMaskRadius="4096"/>
<Ring PatchWorldDim="1024" RingDim="5" MinMaskRadius="2048"/>
<Ring PatchWorldDim="512" RingDim="5" MinMaskRadius="1024" DetailTileCount="64"/>
</Rings>

I've skipped 4096 and 16384 rings to save memory but this should not be noticeable. However it seems you have to either make all budgets the same or remove other budgets (i.e. if you use "Five", just clone it into budgets "One" to "Four" or remove them), otherwise cfs3 will merge missing rings from different budgets.

Note the most detailed ring has the same 0.5m/pixel resolution.
The total number of patches is just 103 here, though their memory usage is higher because of 1024*1024 texture (i.e. total is 4Mb * 103 = 412 Mb).
Unfortunately RingDim="3" looks bad at edges ("1" doesn't work at all), that's why I only use it for the outermost ring, otherwise we could have even less patches.

How is the performance?
To be honest I haven't tested it with existing DX9 shaders yet, but my development build produces more than x2 FPS with these new settings.

Since texture resolution is increased I recomment reducing texture blending operations per frame, in ConfigOverrides.xml default values are:
<TerrainMaxBlenderInstPerFrameNear val="256"/>
<TerrainMaxBlenderInstPerFrameFar val="128"/>
Try setting them to something really low like "16" to avoid occasional stutter when textures are updated.

By the way, AboveGroundLevel can be also used to optimize rings at high alt (you don't need 0.5m/px res when you are at 5 km), but it has to be done carefully to avoid flicker when switching levels.
 
You must log in or register to reply here.
Back
Top