->Blurry Ultimate Terrain

One of the topics that comes up a lot on the forums regarding Flight Simulator is that of “The Blurries”. There has been a lot of speculation regarding the cause of this, some of it close to being correct, some of it just plain wrong.

So what are the blurries? Well, they are just one aspect of the problem of resource starvation, most obviously manifesting itself as blurry terrain.

The interesting thing about this issue however, is that the resource we are running out of is time¹.

In order to understand the issue, I need to explain a little of the inner workings of Flight Simulator. Although it might be surprising to some, the application actually has a lot to do other than just render triangles as fast as possible. In order to render those triangles, we need to know what to render where and what to texture it with.

There’s a lot of data to process at runtime (as you’re flying at potentially 500 knots over the landscape). The terrain system needs to load source textures; composite them based on land class data; render roads and other vector features into the composited textures; light the terrain taking into account features such as valleys; figure out where auto-generated buildings and trees are to be placed; exclude some of those due to placed features such as the Space Needle; burn the shadows of the buildings into the textures; and much, much more.

There are also many other systems doing similar things, systems such as AI, ATC and weather.

The way that Flight Simulator handles these tasks is to divide all these tasks into much smaller jobs and then use a form of cooperative multitasking called fibers to schedule them. This system allows us to schedule exactly how much time all this processing gets in order to maintain a consistent frame rate. Without fibers, each system would need to be developed to play extremely nicely with other systems and would need to know how to suspend itself and maintain it’s state - we can’t have a particularly complex task run without interruption for hundreds of milliseconds.

So in summary, fibers allow us to write complex tasks without stalling the application.

But therein is the issue.

The fiber system needs time to run, so where does it get it from?

It’s a bit more complex than this, but basically the main loop in the application keeps track of how long a frame takes to run and it has a target frame rate. The time left over is given to the fiber system. If there isn’t any time left over, the fiber system is given a minimal amount of time to run so that some work gets done, but it ain’t gonna be pretty.

This is what happens when you set your target frame rate in the settings section to “unlimited” on a system that can’t cope.

When running with an unlimited target frame rate (or any target that your system cannot achieve), the fiber system is starved of time, work items take a long time to finish and you end up with a blurry terrain until (if ever) the system finally catches up.

If you’re flying at 500 knots and your system is not capable of keeping up with the processing needed, the fiber system may never catch up.

So what’s my recommendation? Drop the “lock to frame rate” slider to a level that the system can maintain.

Then drop it a little bit more. Give the system some time to do something else other than just render triangles as fast as possible.

¹ Caveat - video memory starvation can also cause blurry textures, but the issue described above is the main culprit.