My experiments with @##$##@$##@ blurries.

[Guest JohnC]

System: Dell XPS/1G of Ram/WinXP/Fresh install of Fs9/Virgin fS9.cfg +++except texture max load was doubled to 2048.. All sliders to the right, all options checked, hyperthreading disabled/fps capped at 24 fps/antialiasing set by video card directly/Raptor HD's with split file storage. Aircraft a downloaded A320 (source?) with no virtual cockpit(allowing a large field of view in VC mode).ONE measly single custom scenery rotating radar dome (40K) bgl,requiring 3 256x256 DXT1 with alpha bitmaps.(there is a second FS9 generic radar dome on the field)If I start FS9 and use a STORED flight above the ground in slew mode with above settings and airport viewed from approx 1000 meters or so (aircraft on final) I IMMEDIATELY have the blurries in VC mode....except that my custom radar dome appears crisply and cleanly textured ..a surprise to me .???!!?!!?. If I then right click to bring up view dialog, (sometimes) ALL the blurries go away..(sometimes??).....???!!!??. I cannot discern any pattern in terms of a view change fixing the problem, except that opening in cockpit mode is more effective than others in clearing this up.(I thought perhaps a radome with lots of rotating semitransparent mesh might be a problem, but disabling the animation did not change things).I can temporarily get rid of the blurries with a full custom scenery load by switching to cockpit mode, reducing the field of view and a large panel view, then stretching out the view itself, but it only lasts approx 1 second, then blurries pop back. Now, if I create and store a flight ON THE GROUND starting from scratch, everything works perfectly with a larger custom load of GMAX structures, altho many are untextured as yet. ?????. Now, up in the air, really aggressive panning around particularly in view plane mode will cause the blurries to come back, but sticking to one cockpit view, so far so good.

[Gridley 257]

In our continued battle against this phenomenon, Holger translated a german thread for us that suggests DXT1 or DXT3 textures require MIPs, and that order of loading is what causes the blurries - as soon as the non-mipped texture is loaded, other textures are loaded improperly - or something to that effect.Maybe try adding mips via imagetool to that radar dome, and see if that cures it?best,sg

[GHD 21]

I recently had exactly the same problem with a particular add-on scenery. The cure was to remove mip maps and add an aplpha channel to two of the textures. The texture folder has a mix of mip mapped and non-mip mapped textures.George

[Gridley 257]

You know what they say - two people in a room guarantee's three opinions!I should add that our issue was related to GMAX models of AI aircraft (well, boats). The same might not apply to terrain or other types of models...

[Guest JohnC]

I did add the mip maps and lo and behold, the blurries disappeared. Thanks for the suggestion.I will proceed further with this. I noticed you have some New England Scenery. I may have a way to get some really really good Vermont color aerial photos at pretty high resolution, but the cost would be $150. Have you any interest in splittng this several ways?

[Guest JohnC]

Were you using DXTBMP to do this? In the help section it says quote... All Extended and DDS formats are saved with Mips. This may be switched OFF using the "Include with save" checkbox in the MipMaps section of the right toolbar.A checked box increases the size of the file so I assume a check means mip maps are saved ...but when I read the above sentence , using the box switches off the saving of mip maps. To me using a box means putting a check in it. I thought mips were a default choice.This may seem like nitpicking but I would like to think I may save someone from many hours of tearing their hair out.

[GHD 21]

Here is a reference for you:http://www.vfraddons.co.uk/forums/viewtopic.php?t=237George

[Gridley 257]

Interest, yes. Finances, not at the moment...but a commercial venture might make that feasible! Several ways - who else have you got in mind? LOL!In all seriousness, I've toyed with aerials, and the combination of reprojecting to correct orthographic distortion and the fact that Vermont would absolutely NEED four seasons makes that a very difficult project...not that I am averse to difficulty, just that the imagery is a drop in the bucket...Drop a line in the shop talk section of our forums if you are seriously considering such a venture - I'd be happy to help.

[Holger 0]

Howdy,thanks for the link, George!And here's the translation of mine of that German-language thread. One addition from first-hand experience of a similar problem that Larry and I had with a simple tunnel portal texture is that its size was 128x128, so the 8:1 ration that Yves speaks of may not be a deciding factor.------------I just came across an impressive piece of investigative work in one of the German-speaking forums. The Swiss "detective" (his forum name is Yves G.) actually used the Freeflow Florida AI ships for the tests so I thought I try to translate his results for you guys. He just posted this yesterday and his results haven't been independently verified yet but they make a lot of sense, at least to me.In order to experience the sudden loss of mipmaps the "offending" texture(s) require all four factors:> height/width ratio of 1:8 or 8:1 (1024x128, 128x1024, 64x512, 32x256 etc.) > DXT1 oder DXT3 (all other formats are okay) > no alpha channel > no mipsAdding alpha or mips will reliably solve the problems.But why does the problem occur and why does it occur sometimes but not always? Here are Yves' conclusions:If FS loads a single object it will open and read the respective texture file(s) and immediately close the files again, completing the file access. In contrast, if several new objects come into view at the same time FS will open all of the textures together and also close them together once access has been completed - unless there's a "faulty" texture, which somehow leads to sudden drop of mipmap levels in all loaded textures.For example: there are three ships, A, B, and C, next to one another, and ship A has problematic textures while B and C are fine. If all ships come into view at the same time (by starting a flight facing the ships, or in a rapid in-flight turn toward them) the blurriness will occur if ship A is loaded first or second. That is, loading "good" textures after loading even a single "bad" texture will lead to blurriness.In other words, the problem occurs only if a mix of objects with good and bad textures are accessed by the sim as a group and if the bad textures are loaded before the last good one. If the ship with the bad texture is loaded all by itself there will be no loss of sharpness.Apparently, the order of access to a texture set for a particular model doesn't matter and it also doesn't seem to matter if other scenery files (water bodies, landclass, etc.) are loaded while an object with bad textures is being accessed. Yves determined this with a clever arrangement of ship placements/flight situations and the free Filemon utility, which monitors file access.Do his observations fit with yours?---------------Cheers, Holger

[Gridley 257]

JoeW did it for us. I'll drop him a line...maybe he'll stop in.

[Gridley 257]

Thanks Holger - that really should go in a faq somewhere. BTW, there's a new AI pack about to be uploaded...no blurries thanks to you (or more directly Yves G.)!Best,sg

[Joe W 0]

I used ImageTool from Microsoft (comes with the Gmax SDK) to convert all the textures to DXT1 with mips. I also in all the ground buildings added to the scenery ( not default), converted them to DXT1 with mips. DXT3 supports a shiney surface as well as semi transparencys. This is needed in aircraft, it's larger in size, so not very good for scenery. DXT1 will support transparencys too...... full transparency. DXT1 is smaller in size also than even 8 bit. DXT format is a compressed format.What I found out in all this is that you really need ALL textures in view to be DXT1 with mips (or at least the same format). If they are not and are in mixed format, then you are going to have a performance hit of some size on some machines. This is what made it so hard to track down.... some machines are not affected by this much and others are to a greater extent.I hope this helps in stamping out the Blurries.Joe W.

[GHD 21]

Hi Holger,Interesting observation, however, it doesn't fit with my problem. All textures were DXT1 and square:1024x1024 9 mips no alpha512x512 8 mips colorkey256x256 7 mips no alpha256x256 7 mips no alpha256x256 1 mips colorkey128x128 1 mips no alpha128x128 1 mips no alpha128x128 1 mips no alpha64x64 1 mips no alphaThe two offending textures were the 1024x1024 and 512x512, removing the mips and adding alpha to the 1024x1024 cured the problem ????I still have a mix of alpha and two of the textures have mips ????I had never before seen the aircraft textures become blurred at the same time as the ground.Regards,George

[Joe W 0]

>System: Dell XPS/1G of Ram/WinXP/Fresh install of Fs9/Virgin>fS9.cfg +++except texture max load was doubled to 2048.. All>sliders to the right, all options checked, hyperthreading>disabled/fps capped at 24 fps/antialiasing set by video card>directly/Raptor HD's with split file storage. Aircraft a>downloaded A320 (source?) with no virtual cockpit(allowing a>large field of view in VC mode).>ONE measly single custom scenery rotating radar dome (40K)>bgl,requiring 3 256x256 DXT1 with alpha bitmaps.(there is a>second FS9 generic radar dome on the field)>If I start FS9 and use a STORED flight above the ground in>slew mode with above settings and airport viewed from approx>1000 meters or so (aircraft on final) I IMMEDIATELY have the>blurries in VC mode....except that my custom radar dome>appears crisply and cleanly textured ..a surprise to me>.???!!?!!?. If I then right click to bring up view dialog,>(sometimes) ALL the blurries go>away..(sometimes??).....???!!!??. I cannot discern any pattern>in terms of a view change fixing the problem, except that>opening in cockpit mode is more effective than others in>clearing this up.>(I thought perhaps a radome with lots of rotating>semitransparent mesh might be a problem, but disabling the>animation did not change things).>>I can temporarily get rid of the blurries with a full custom>scenery load by switching to cockpit mode, reducing the field>of view and a large panel view, then stretching out the view>itself, but it only lasts approx 1 second, then blurries pop>back. >>Now, if I create and store a flight ON THE GROUND starting>from scratch, everything works perfectly with a larger custom>load of GMAX structures, altho many are untextured as yet.>?????. Now, up in the air, really aggressive panning around>particularly in view plane mode will cause the blurries to>come back, but sticking to one cockpit view, so far so good.John..... Try lowering the frames to 15. There is a line you can add to the Main section of your FS9.cfg, AVE_FRAME_RATE_DISPLAY=1 This will give you a low, Avarage, and high to the frames. there is also a V= ??? at the end. This is the Varation in frames. If your able to lower this to around v=3.0 or lower, you will find that it's very smooth and stable. Also the blurries are very hard to find.With your machine you should not have any blurries. My opinion.Joe W.

[Joe W 0]

>Hi Holger,>>Interesting observation, however, it doesn't fit with my>problem. All textures were DXT1 and square:>>1024x1024 9 mips no alpha>512x512 8 mips colorkey>>256x256 7 mips no alpha>256x256 7 mips no alpha>256x256 1 mips colorkey>128x128 1 mips no alpha>128x128 1 mips no alpha>128x128 1 mips no alpha>64x64 1 mips no alpha>>The two offending textures were the 1024x1024 and 512x512,>removing the mips and adding alpha to the 1024x1024 cured the>problem ????>>I still have a mix of alpha and two of the textures have mips>????>>I had never before seen the aircraft textures become blurred>at the same time as the ground.>>Regards,>>George>>>George.....You have 5 textures that don't have mips... 1 mip is no mip. Try adding mips to those textures, that is, If they are not default. Also.... colorkey is done with a alpha chanel and is a transparency notation, It's either full transparent or opaque.Alphas are not always needed. This is my personal opinion.Joe W.