Yes, the combination of distance and objects density creating too many things for the system to keep in memory is the the source of the problem. If you want to maintain a larger view distance then the density would need to drop. This is probably the better choice if you are trying to avoid having objects pop into existence within view range. If you really need to see a high density of objects with a less powerful system then you're probably stuck with seeing them suddenly appear only a couple of miles away.

Remember the premise of these edits is to eliminate the sudden popping up of new objects that happens as you move along over the terrain. Keeping smaller LOD changes, and uniform auto-generated object density, out to a large view distance is the key to making this work.

I built a spreadsheet calculator to help me understand the math behind the patch ring distances, pixel size resolution, and the number of objects being placed, so I could quantify the effect it was having on my system. In addition to the CPU/Memory/GPU system tuning, I've had to redo some of these values as I've changed monitors and FOV settings in the d3d8.ini as well.

Good information, MM.

I notice that the Dim values for Landclasses.xml range from a low of 2048 to 5120 and are in multiples of 1024. Do you know if they can be in smaller values, say 512? Also, do increasing or decreasing these values displace landclass objects on the ground, say for example, towns or forests if you alter these values, or do they just make the landclass objects bigger or smaller without displacing adjacent objects?

Finally, what does the "Priority" setting do? I presume it helps the GPU decide which landclass object is rendered first?

Thanks. As a new owner of a Nvidia 1050 Ti video card, I am intrigued by your findings.

The priority setting determines which one is predominantly on the top when the transition edges between landclass types gets blended together.



The SDK doesn't say what happens if you try something less than 1024. Each landclass is mapped to local regions of the theater map. So, within a given landclass' assigned area the patches will be larger or smaller depending on the value listed in the landclass.xml.

Thanks, MM.

Here are the settings that I am currently playing around with:
Notice that the inner RingDims are slightly larger than MM's settings, while the outer RingDim is slightly smaller. I also raised the LOD of the second closest ring from 70 to 75.

Have any of you guys tried putting all lod values to 100? Shouldn't have any impact on a 3GB+ card, and will save the engine swapping lod values continuously for a possibly smoother flight and definitely reduce the hideous and noticeable texture switching.

I know I probably sound like a broken record, but the textures in this game are tiny file wise compared to any modern game.

May not do anything, may give you a crippling framerate, but I personally would give it a go. No harm in trying.

I'm leaving for a 4 day conference but I hope somebody does try this. Reducing texture switching wouldn't be a bad thing. Hopefully it doesn't have a downside with the larger RAM cards.

Thanks for the tip 4L0M. It gave me more options to try. Unfortunately, although it initially runs smooth, it severely hangs going down from a 90 FPS to teens for a couple of seconds which is enough to throw my head tracking off and I need to recenter. I've tried setting all the LODs to 100, then 250, then 1000 with the same outcome. Just had to set the last LOD to 250 which actually gave me a small FPS boost (~5).

After 2 days of fighting with my PC to get WOFF running smooth with an extended view and no popping, I finally found a winner. I still get the occasional stutter just like I do in WOFF without this MOD. However, I also had to increase the MinPatchDimUseThumb to 8192 which resulted in less stutter (but it may also be a placebo effect).

Maybe this will be of use to someone, so, here are my numbers:

compositescenerybudgets.xml:

<Ring PatchWorldDim="2048" RingDim="13" LOD="17" MajorDensity="0.000460"/>
<Ring PatchWorldDim="1024" RingDim="27" LOD="30" MajorDensity="0.000460"/>
<Ring PatchWorldDim="512" RingDim="27" LOD="50" MajorDensity="0.000460"/>
<Ring PatchWorldDim="256" RingDim="27" LOD="70" MajorDensity="0.000460"/>
<Ring PatchWorldDim="128" RingDim="27" LOD="100" MajorDensity="0.000460"/>
<Ring PatchWorldDim="64" RingDim="27" LOD="250" MajorDensity="0.000460"/>

compositetexturebudgets.xml

<Ring PatchWorldDim="16384" RingDim="3" MinMaskRadius="49152"/>
<Ring PatchWorldDim="8192" RingDim="3" MinMaskRadius="24576"/>
<Ring PatchWorldDim="4096" RingDim="3" MinMaskRadius="12288"/>
<Ring PatchWorldDim="2048" RingDim="5" MinMaskRadius="8192"/>
<Ring PatchWorldDim="1024" RingDim="5" MinMaskRadius="5120"/>
<Ring PatchWorldDim="512" RingDim="5" MinMaskRadius="3072"/>
<Ring PatchWorldDim="256" RingDim="5" MinMaskRadius="1792"/>
<Ring PatchWorldDim="128" RingDim="5" MinMaskRadius="1024" DetailTileCount="6"/>




Unfortunately, I'm not going to mess with the landclass file because it seems like a daunting task which I don't have enough knowledge.

Looks good!

Unless I'm being a bit dumb, having a lod number higher than 100 in your compositetexturebudgets.xml is completely pointless? LOD (Level of detail) normally tells the game what level of texture details to use depending on your distance from an object. As the tree and building textures are in .Dds format, going off the top of my head as I'm on my phone, there are 7 levels of mipmaps created when using dds files in Woff. This should give the game 7 levels of detail of texture to use for an object depending on your distance to it. Lod value of 100 being the best quality texture.

Having a LOD value over 100 is probably just confusing your game to be honest. I can't test this at the minute, but that's how it normally works.

4L0M, for scenery budgets LOD has quite unusual meaning: it is the maximum number of triangles (or vertices? I don't remember what SDK says) in a single object - a tree or a building.

It seems we are going from higher performance and drop in visual quality, to the other way totally and higher quality and slower rendering and straining the system with higher ring dims. Everyone likes different things of course.

Problem lies with it being a really old engine, yet people's hardware getting more and more powerful. It's not actually a problem, that's the wrong word, but surely with the power we have available, some things can be tweaked for better performance and/or better visuals.

I have spent the last 10 years tweaking FSX for the best available performance, and when I first fired it up (day1) I'm sure people who used it back then remember the blurry textures, horrific autogen etc. Now, in P3D I'm able to use 99.9% of all my FSX addons with an absolute stack of AI planes flying round the world in beautiful smooth 4K with fantastic performance.

My mind would have been blown if you had a time machine and shown me what my PC would be capable of 10 years down the line.

Yes, the SDK says:

LOD – The maximum number of triangles that each scenery model can contain. Each scenery model has multiple levels of detail (LOD), each with different numbers of triangles. The LOD with the triangle count closest to this number without going over is used.

I suppose finding the right balance for the default settings is going to be a challenge in WOTR, as there has grown to be such a diversity of machines that people will be trying to use it with. The key will be to provide for user customization that will allow for the sort of fine tuning we're seeing discussed here. The old days of having only five preset levels to pick from may not get the job done anymore.

If we can eventually switch the rendering to DX11, then we can add both features and performance to the game like when we went from DX8 to DX9, and the whole process starts over again.

Polovski:
I like the new mod improvement that Ankor provided at the beginning just fine. I allows my 7700K, 980 Ti PC and 2160x1440 Monitor to improve the overall FPS by at least 10 FPS without a hitch (almost always above 100 FPS now).

As for the loss in terrain detail, if I look close, I can see it just outside the haze ring, so I just ignore it with the increase in the FPS in the game. My PC (set at all 5's) never drops below 65 FPS, whether it be high, low, landing or in dogfights.

Remember that the distance you can see into the distance is limited by the amount of haze on the horizon, which is controlled by the precipType variable. In unmodded WOFF, most of the time this variable is set to "HeavyRain" meaning that the view to the horizon is limited to less than 8 to 10 kilometers. Everything beyond that (including rivers, buildings, and trees) is hidden behind the haze. Of course, the computer still has to calculate these objects even though you can't see them, taking up more and more cpu cycles and computer resources the farther you have extended the view via the RingDim variable. Most people will only see objects farther than 10 kilometers away if they use JJJ's Mission Editor and click the "Horizon fix" button, which only removes the haze in Good or Light weather conditions. Something for everyone to keep in mind.

That's just it everyone likes different things. Some guys like higher fps and others prefer more eye candy, inevitable trade off.

Sure it's an old engine, but with many changes and improvements along the way, including Ankor's fantastic DirectX shaders and it's pushed way beyond it's original scope now so we have stunning visual crispness and good fps.
AnKors rings settings give more fps, and look fairly good but "5" is no longer visually what 5 in WOFF is of course.

For us to release something incorporating something useful for everyone it will have to cover all the angles, so may be a while before we have something that can be configured for everyone.

IMHO this is part of the problem: The emphasis on higher "FPS" rather than smoother, more even distribution of frames. It simply doesn't matter if you get 100+ frames per second; if the FPS bottoms out for even a split second every so often, you'll notice.

Yet, most people continue to confuse high FPS with smooth graphics. They are not the same thing; this has been covered at great length all over the internet, and it happens that the continued misapplied fixation with higher frame rates is not only part of the problem, but is genuinely misleading. You can be cruising along at 60 or even 100 FPS, but the 'stutter' that you get when the frame rate drops, even briefly, is the real problem.

I'd take a smooth 35 FPS any day over even 100+FPS that dips and stutters. Here's an example: 60+ FPS is generally a decent number, and most people that get at least 60 FPS are generally satisfied with graphics performance at that level. Now, take a machine/scenario that typically runs ~100 FPS . It will still be very noticeable when it dips down to 60, even though 60 is a very good frame rate.

If you prefer to make the example more clear and insist on higher numbers, no problem: Take a machine that generally gets ~144 FPS, and let it drop to ~100 sporadically. Even though 100 is considered an excellent frame rate, you're still going to notice when it drops to 100 (a change of ~45 frames is still roughly a 33% drop, exactly the same delta as going from 100 to 66).

If a given setup runs FPS most of the time above 100, and never below 65, that means there are still changes of as much as 35% - essentially dropping one-third the frame rate.

Especially if folks claim they can see the difference in 40 and 60 FPS, then it's hard to reconcile that a 35% change in frame rates isn't noticeable, no matter how high the FPS.

The truth is, it doesn't matter how high your FPS is, nor does it matter that it never drops below x. The extent of the values (highest/lowest) isn't what you see when there's stutter; what you notice is the change. If there's enough of a delta in the rate frames at which are being displayed, it will be noticeable.

FWIW, just my own $.02

(EDIT: Incidentally, the reason there is so much confusion, I believe, is because there are a lot of games and utilities that have FPS counters/displays, which is fairly easy to do in software. However, it's an entirely different thing to monitor and keep track of how much a frame rate is varying. So, people have gotten accustomed to expressing the only values thy have access to - but this doesn't mean it's an accurate way to measure or record the actual behavior.)

Another point is that most people are running 100fps while it is an 60hz monitor.
If I do check whats is the best adjustment, I let afterburner log me an frametime graph, to compare two settings.
Frametimes guys thats the only factor to be used, not FPS.

Good points, kksnowbear.

I just recently upgraded from a Nvidia GTX 460 to a Nvidia 1050 Ti. Before, I was getting framerates in the 30's and 40's, but no noticeable stutter. With the new card, my framerates are much improved, but the stutter has become more noticeable (not a killer for me, but still more noticeable than before). Sudden drops from 60 fps to 40 fps is apparently more noticeable to my eyes than a drop from 30 fps to 20.

Another thing I've noticed is that with the old card, the stutters lasted longer, akin to mini screen freezes. With a faster card, maybe the pauses are shorter and therefore appear as microstutters?