First and before I forget - Happy New Year!


Next, this post is not meant to minimize, marginalize, or denigrate anyone who has the blurries. This post is meant to discuss the data I have in front of me as a result of investigations on this topic. Please do not take this information in the wrong way and see it as an attempt to minimize, marginalize or denigrate as I do not intend it as such.


I want to cover 4 topics:

1) History of Blurries

2) SP1 isnt the sole cause of all blurries

3) More Details on Type 1 Blurries and Photo-scenery

4) Some systems do, some systems dont


1) History of Blurries, or Blurries existed prior to FSX

Here are several blog posts ( P1, P2 ) by Steve Lacey from well before FSX.


Here is Adam's post on about blurries, again before FSX shipped.


Here is comment by JohnMu indicating that the Google Earth flight sim can get blurries.


So it is clear this has been an ongoing problem and is not specific to FSX.  


Part of the issue is the FS engine takes the approach to "run with what it’s got" instead of waiting until all resources are available. You see this with aircraft, with panels, and yes with terrain where world items render with gray/missing textures or blurry textures if the resource isn’t available within a certain time quantum. If the engine didn't take that approach, the simulation would pause which is unrealistic.


From the reports of blurries with GoogleSim, it appears they have made a similar design choice to favor flying and simulating the flight over rendering. That tends to validate our design choice.

2) SP1 isnt the sole cause of all blurries across the board

We need to distinguish amongst the types of blurries first.


I identified 4 types of blurries in this article.


Let’s recap them, 1 by 1:


Type 1) Blurries with photo-scenery.


As mentioned, photo-scenery is one add-on type that can be directly impacted by the multi-core changes. However, this is not "across the board" as not all users of all photo-scenery show this issue. More on this in a moment.


Type 2) Blurries that catch up.


These are usually the result from settings that are too high for a given config. Whether that is from the hardware itself or from some other local problem is hard to say. I do see quite a few people who,when they flatten their machines and start over, do not have blurries. Or who when update their hardware can run at the settings they desire without blurries. This all seems to indicate a local issue.


Type 3) Some tiles just a little bit blurry.


I believe this is from misunderstanding texture filtering and how it affects pixels, and besides developing a nomenclature for blurries explaining the relationship between texture filtering, scene filtering and AA, view angles, and zoom was the main purpose of the PDF I posted about the blurries months ago. There have been several threads on where knowledgeble developers ( thanks Luis! ) have pointed out similar details recently.


Type 4) Blurries all the time


This seems, again, to be some local problem where the hardware/software config is just badly set up. Otherwise, how does anyone fly without blurries? That existence proof is key.

3) More Details on Type 1 Blurries and Photo-scenery

SP1 did make changes to texture composition to achieve better multi-core usage. Photo-scenery can show a negative effect from this in a special case. More on that in a bit.


We did 2 things in Accel/SP2 to try to mitigate the effect:

1)strengthened the IO handling

2)created an article for the SDK that helps point out to photo-scenery authors what can trigger this, including

"If aerial photography is being used to replace a large area with detailed imagery, involving the division of the target area into a large number of bgl files, there can be a significant increase in scenery load times. This can be due to an excessive amount of transparency within cells at one or more LOD level. Use the tmfViewer tool to examine the bgl files produced by the Resample tool, and note that transparent areas are shown in medium gray (see the image below).


If there is transparency within a cell at any LOD level, the terrain system has to load in multiple files to piece together the terrain texture for each cell. With a large amount of transparency, and a large number of bgl files containing images, this piecing together can become very time consuming. Minimize transparency within each LOD cell by preparing .inf files that target specific LOD levels. The default Destination parameter LOD=Auto should be changed to provide a minimum and maximum level, or simply one level, that minimizes transparency for the particular LOD settings. This will involve having several .inf files for each section of source data.


The number of bgl files used to hold image data at one level of detail should be reduced by a factor of four for the next level of detail. So, for example, if 16 files are used to hold an area at LOD 14, then four should contain all the imagery at LOD 13, and one at LOD 12. From then on there is no need to have one file for each level of detail, all the lower levels of detail can be placed in one file.


So that’s the advice in the updated SDK.


What this means is that the work in SP1 can cause an issue with certain authoring styles of photo-scenery as a consequence of parallelizing the file IO in SP1 to make better use of cores.  Once the file IOs are handled in parallel and not serialized, it is easier for FSX to pound the file system into submission and get behind if there are an excessive number of file loads. RTM with its sequential loads did not have this issue with this style of photo-scenery but did suffer from slow performance and stutters and thus had a hard limit on how far performance could go. This does not mean the design is inherently bad, just that there is a special case where it isn’t a win. The special case is photo-scenery with a lot of file IO loads and a lot of transparency. The transparency can make the situation even worse because that increases the number of loads since a single cell no longer depends on itself but on its neighbors and this makes the situation go from bad to worse.


This thread on shows that SP2 did help. This thread on shows that some products do work, while some older products do not. These two threads show both that there is an existence proof it is not an across-the-board problem and that there is a special case where there is a problem.


With that covered, lets discuss 2 photo-scenery products: Horizon's Gen-X and TileProxy ( TP ) to get specific.


Horizon forums don’t seem to show the same level of pain we see in AVSim forums. This thread on the Horizon forums, for instance seems to indicate all is not so tragic as some would have us believe after SP1.


This thread seems to indicate that the approach TileProxy uses is so vastly different from what Gen-X uses that TP and its authoring style contributes to the blurry problem, I quote:

"Using TileProxy, you would end up with 144,979 files in the TileProxy UK folders on your local drive compared with 1855 files in Gen-X folder.


The fact that Gen-X seems to not suffer these to the same degree that TP does would indicate that the authoring time change suggested by the Accel/SP2 SDK is an important piece of information. I have had discussions with Horizon that confirms this.


Let’s face it, 144,979 files is a lot. An extreme amount by any metric. Using a 4x4 technique to group the textures together would reduce that by a factor of 16 to in the 9-10k range. That would probably work. So using a 1:1 style authoring technique where there is one result texture for each source texture just isn’t going to work anymore. Yes, that is a consequence of the changes in SP1, but those changes are not inherently bad. I would say that having 144,979 files is bad and FSX hid that before SP1.


Unfortunately for TP, given how the data it references is stored and given the EULA issues it faces - I suspect that a re-authoring pass is hard to accomplish.


Net-net the tradeoff we made for performance gains in SP1 means that a new authoring style is necessary. And this is backed by real-world data in that the new authoring style actually works and end-users see a performance gain from both SP1 and SP2.


I suspect that, for the users that get better photo-scenery behavior when going back to RTM what is happening is they sacrifice those performance gains and that masks the loading costs that TP style photo-scenery causes in that slower FPS and more stutters exist due to all the IO happening more sequentially on a single thread.

4) Some systems do, some systems dont

Almost identical systems with and without the blurries points to a system factor. Think about it. The fact that systems A,B,C dont have blurries;and systems A', B', and C' that are almost identical do have blurries points to something unique about those systems being a contributor.


Else wise no system would run without blurries. This "existence proof" on the same hardware is key.


And many users who had blurries do not experience them when they upgrade to new hardware. This is a further existence proof that the blurries were caused by something specific and unique to that hardware configuration.


Unfortunately we have yet to figure out what this "unique factor" is. If we could determine what that factor was, of course we would be interested to hear about that and would examine the details.

I hope this explanation helps clarify where we are with respect to the blurries in FSX.