Great thanks I will try them!
May I ask how you interpreted all this for the settings? Microsoft left no docs.
Great thanks I will try them!
May I ask how you interpreted all this for the settings? Microsoft left no docs.
Most are just the defaults. The rest are trial and error.
US Army, Major, Ret.
Service To The Line,
On The Line,
On Time
US Army Ordnance Corps.
I needed this info again...
US Army, Major, Ret.
Service To The Line,
On The Line,
On Time
US Army Ordnance Corps.
What is this used for
<TerrainVertexBufferCapacity val="10000"/>
<TerrainIndexBufferCapacity val="10000"/>
ETO? How do I install it? Download Links? HERE Horizontal lines at menu after installing ETO? - FIX - choose a wingman, plane, then try quick mission.I found this config setup ArgonV posted at simhq, works good HERE Graphics card updates change your game settings? With error? Ankor's Shader fixes it HERE Nvidia HERE
After trying every imaginable tweak ever listed for resolving micro-stuttering, I discovered that it would only go away if I turned off the scenery entirely by disabling it in cfs3config. That put me onto rebalancing the compositescenerybudget.xml file again. What I ended up with is a somewhat limited density, but one that looks natural, in that it does not suddenly pop into existence (uniform density), or change it's size and shape (uniform LOD) as you approach it.
<Budget Name="Five">
<Rings AboveGroundLevel="0" MaxDistEyeInnerRing="0">
<Ring PatchWorldDim="2048" RingDim="13" LOD="35" MajorDensity="0.00015"/>
<Ring PatchWorldDim="1024" RingDim="23" LOD="35" MajorDensity="0.00015"/>
<Ring PatchWorldDim="512" RingDim="23" LOD="70" MajorDensity="0.00030"/>
<Ring PatchWorldDim="256" RingDim="19" LOD="70" MajorDensity="0.00030"/>
<Ring PatchWorldDim="128" RingDim="15" LOD="70" MajorDensity="0.00030"/>
</Rings>
This lets me run 3840 x 1024 at 55 fps pretty smoothly now.
US Army, Major, Ret.
Service To The Line,
On The Line,
On Time
US Army Ordnance Corps.
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/res.../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.
US Army, Major, Ret.
Service To The Line,
On The Line,
On Time
US Army Ordnance Corps.
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.
US Army, Major, Ret.
Service To The Line,
On The Line,
On Time
US Army Ordnance Corps.
Time for a
US Army, Major, Ret.
Service To The Line,
On The Line,
On Time
US Army Ordnance Corps.
"Someone" needs to take a copy of the essence and add to project knowledge base.
Cato said "Carthaginem esse delendam"
I say "Carthago iam diu deleta,sed enim Bellum Alium adhuc aedificandum est"
Forgot about this
Cato said "Carthaginem esse delendam"
I say "Carthago iam diu deleta,sed enim Bellum Alium adhuc aedificandum est"
Which files exactly should I put those settings into?
In the cfs3 assets folder there should be these three files compositescenerybudgets.xml, compositetexturebudgets.xml, and landclasses.xml
US Army, Major, Ret.
Service To The Line,
On The Line,
On Time
US Army Ordnance Corps.
Thank you!
Yes, it can be done with just a text edit.
US Army, Major, Ret.
Service To The Line,
On The Line,
On Time
US Army Ordnance Corps.
Just needed this information again to adjust the scenery density to tune the FPS again after my migration to Win 10
US Army, Major, Ret.
Service To The Line,
On The Line,
On Time
US Army Ordnance Corps.
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.
Another bump to answer a question.
US Army, Major, Ret.
Service To The Line,
On The Line,
On Time
US Army Ordnance Corps.
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.
US Army, Major, Ret.
Service To The Line,
On The Line,
On Time
US Army Ordnance Corps.
I needed the information from post #82, and #83 again.
US Army, Major, Ret.
Service To The Line,
On The Line,
On Time
US Army Ordnance Corps.
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.
At least on my system, when I gave it a quick try in ETO, it didn't seem to make a difference.
US Army, Major, Ret.
Service To The Line,
On The Line,
On Time
US Army Ordnance Corps.
Bookmarks