To mip or not to mip

[hjwalter]

Hi Guys,

 

Right from the very beginning when FS9 was first launched, I've embraced the general theory that ... ALL ... (standard and addon) scenery BMP textures found anywhere within FS9 and which are all viewed from variable distances, should be mipped, no matter how they are compressed as DXT1, DXT3, etc. This also includes all AI aircraft textures, standard or addon.

The only possible exemptions would be those textures related to flyable aircraft and which are in external view, normally never viewed from any great distances.

 

To check and to edit all such textures I've been extensively using a program called "MipMapManager v.0.03", which can firstly delete all mipmaps from any selected (and previously backed up) texture folder, followed in a second run by replacing them in it's own standard way.

However, it sometimes seems that the newly mipped BMP files are not always welcomed by certain BGL files, mostly by those originating from older sim versions and which can then cause blurries and other strange visible effects, e.g. scenery objects unrealistically popping up at far too short distances.

 

My questions are therefore:

 

Is it possible that some possibly older BGL files, have some kind of inbuilt mechanism for creating their own mipmap-like effects when using their own specific textures and which therefore do not need "extra" mipmaps ?

 

Are BMP file mipmaps always standard, whatever that "standard" may be ?

 

Any comments on my general mipmapping theory ?

 

Regards

 

Hans

 

 

 

 

 

[chris_eve]

The only "mipping" experience I've got is using DXTBmp Texture tool (mwgfx.co.uk) , which has a comprehensive analysis of the different types of "mips" as used by different versions of FS and CFS.

I'd suggest grabbing a copy and at least browsing through the help files, if not use the program ... there's far more info there than I've ever needed  

I seem to remember from my days using FSDS to make a few AI aircraft that some "viewability" parameters can be included in the models themselves, so there maybe some interaction between the mips setting and these parameters which might give noticeable artefacts.

The various Settings | Display settings from the Options menu within FS can/will also affect how subjects in the middle and far distance are shown ... this is where you'll notice "older" models not having any mips standing out starkly against a generally low-resolution background!

 

[PhrogPhlyer]

This tool is a must for anyone getting into retexturing your aircraft.

For detailed explanation of all this texturing lexicon see https://www.fsdeveloper.com/wiki/index.php/Category:Texturing

There is a lot of trial and error involved when first saving textures and seeing them work, or not, on an aircraft.

For anyone starting to retexture, I recommend that you write down the textures/alphas you use for a given aircraft, so you don't have to relearn these saved formats each time.

I found that doing several repaints of a given aircraft helped me learn the steps and I feel I improved with each one.

Also, I exclusively us paint.net for my repainting needs. It's free and does everything I've wanted to do. And it opens PaintShop psd files.

Here is the simplest tutorial I've found. https://www.fsdeveloper.com/wiki/index.php/Repainting_an_Aircraft

Good luck to those who haven't started yet. 

[hjwalter]

Hi Guys,

 

After much research within my own massive FS9, I've now concluded that structurally replacing/adding mipmaps to all my existing scenery and AI plane textures, can cause unpredictable visible irregularities here and there, more often concerning those textures which are called for by addon BGL files from older sim versions.

Moreover, some scenery authors also seem to have omitted/forgotten the BGL programming for the handling of mipped textures and which then automatically means that editing/adding unnecessary mipmaps to the related textures, can have further unpredictable results as well. At least that's the way it all now very strongly seems.

 

Anyway Guys, thanks for your reactions and long live FS9 !!

 

Hans

 

[chris_eve]

2 hours ago, hjwalter said:

Hi Guys,

 

After much research within my own massive FS9 ...

 

Anyway Guys, thanks for your reactions and long live FS9 !!

 

Hans

 

On a (slightly?) different note, how big is considered "massive"?

My installation is around 40GB, comprising just over half a million files, but I do only spend my time in the UK and western Europe

[wobbie]

Massive?

So far, my FS2004 install is about 120GB, my Golden Wings install is only 28GB, and still going strong.

[hjwalter]

chris_eve,

 

My main FS2004 folder is 135 Gb, in size, it contains a total of 1.029.131 files in 8288 sub folders. I also have 1356 AI aircraft/paints of all sorts and sizes flying around all over the world, mostly between my very much edited/expanded (only for personal use) addon sceneries. Additionally, my FS2004 has, through the years, been very strongly compacted and edited to get rid of all kinds of unnessesary ballast. This also includes the structural size reduction of far too highly detailed scenery textures (mostly --> DXT3/DXT1) wherever possible. This is in fact where I  began to run up against the subject of this thread, namely a number of not (yet) fully understood mipmap issues and of cause, quite some black alpha-channel transparrency problems.

 

Almost all my sceneries and especially the smaller tropical ones, have been strongly expanded, mostly to make them look less deserted but all of them based on pure fantasy on my part, e.g. extra tropical palms/coconut/trees/buildings/vehicles and self made local paint static aircraft, vehicles, etc. For this I have extensively used the EZ object placement program and mostly by using so called library file senery objects.

 

I'm still using the very original DVD copy of Win-7 64bit Professional, which has in fact never been updated, simply because my FS9 machine has never had any internet connections and I prefer to keep it that way because "If it's not broke then why fix it or have it fixed" !! RAM 32.0 Gb but sadly, FS9 only uses a very small part of this. CPU i7-3930K 3.8 GHz.

 

3 SSDs, two of which (25Gb each), contain my C partition (Win-7 etc) in RAID-0 setup, while the third one (D = 850Gb) contains my whole FS9 and most of it's supporting programs.

 

I also use this machine (and most of it's RAM) for the video processing of, e.g. self shot video movies and for finally burning them onto DVDs.

 

And yes, my real world crop dusting flying experiences many years ago, combined with an international ICT carreer has got me "hooked" onto flight-simming and FS2004 was the definite choice I made after FS98/FS2002) and mostly because of all it's supporting software, etc. etc. It has most certainly kept me off the streets and out of sleasy bars through all thos years. LOL !!

 

Regards and long live FS2004/FS9

 

Hans

 

[alanmerry]

Chris_eve,  Hans

I use DXT3 for everything with no problems and good resolution. If I find any textures that are not DXT3, I convert them using the  DXTBmp Texture tool (mwgfx.co.uk) software that you mention with "Mip Maps" unticked.  There is also Texture Manager by Don Grovestine that will convert whole folders of texture files.

 

As for "massive" my FS2004, aircraft, ai aircraft, sceneries, etc etc etc occupy 180.8 GB of a 223GB SSD.  Ridiculous, I know!

But I'm pleased to see that a steady stream of FS2004 stuff continues to appear on flightsim.com

[hjwalter]

alanmerry,

 

From your reaction above and especially from your "Mip Maps unticked" remark I conclude that you structurally remove scenery/texture Mip Maps wherever you can ???

Does this not defeat the very purpose of Mip Map technology, i.e. that your scenery items/objects are only visible at short distances and that they suddenly/unrealistically pop up when you approach them ?

Quite some of my own (airport/airfield) scenery objects keep popping up at such short distances, even although I have structurally added Mip Maps to all their textures ???

 

I use the same softwares as you evidently do but I ONLY "untick Mip Maps" for my flyable aircraft textures because firstly, these then remain somewhat smaller and secondly, they are never viewed from longer distances.

 

Keep the comments coming guys because this thread is becoming more and more interesting !!

 

Regards

 

Hans

 

 

[defaid]

1 hour ago, hjwalter said:

Does this not defeat the very purpose of Mip Map technology, i.e. that your scenery items/objects are only visible at short distances and that they suddenly/unrealistically pop up when you approach them ?

 

I don't think that's how mips work. Each grade of mipmap is just a smaller, lower-resolution copy of the base texture in an image. Just as different areas of a single-file aircraft texture are mapped to different parts of a 3d model, so different areas of a mipped texture file are mapped to different distances.

 

That is to say, each draw distance will use a different part of the mipped image.

 

If there are no mips, the high-res base image is used at all draw distances so you effectively get full texture detail right out to the horizon.

 

Image editing software such as DXTbmp doesn't show the whole set of mips in one image but mostly they would look like this:

 

Unpipped texture used at all distances:

 

Mipped texture. Larger file but easier on the graphics memory

because for distant objects, the graphics hardware doesn't have

to load the large hi-res image, just a small blurry version:

                                             

I strip the mips from all my aircraft textures because high-resolution modern PCs, graphics hardware & drivers, and monitors don't really need them. (As an aside, I also convert them to 32-bit as I sometimes edit them and each hard save of a compressed image degrades it). Stripping them makes the file slightly smaller. (Decompressing them makes them bigger...) The fundamental resolution of a modern monitor is good enough that -- mostly -- the sparkling and the moiree pattern just don't happen. Modern processors and memory don't struggle with the high-res, unmipped textures even when handling hundreds of them at a complex airport with heavy AI.

 

In the past I've also stripped them from other textures but occasionally came across problems so I leave those as the developer made them.

 

D

[alanmerry]

Hans,

 

I haven't noticed any problems and this includes not having scenery suddenly appear.  It's probably something to do with modern processors and video cards, as mentioned by defaid above, not that my hardware is particularly modern.  Processor is AMD Phenom II and video card is NVIDEA GeForce GTX960.  Converting textures to DXT3, without MIPS, usually makes them sharper, particularly when close up.

 

Alan

[defaid]

7 hours ago, alanmerry said:

Converting textures to DXT3, without MIPS, usually makes them sharper, particularly when close up

 

Except possibly from the subjective perspective of personal preference, that's absolutely not the case.

 

As I wrote above, mip mapping has no effect within a certain view distance because up to that point, the largest image will be used and not any of the mips. In that circumstance, mipped is exactly the same as unmipped..

 

Compressing to DXT-3 degrades the crispness by introducing dithering: blurring of edges and blending of colours as an artifact of the compression process. On top of that it seems also to reduce the bit depth of each channel, which alters the colours themselves.

 

That happens at all draw distances and by the nature of textures, is most obvious at close range.

 

Here's a snippet of a downloaded Shanghai livery for a Fruit Stand plane. I opened the 32-bit version (the repainter was farsighted enough to include it in the zip) and saved a couple of times as DXT3. Once was enough to introduce the artifacts but I made them more obvious by saving a couple more times.

 

Whether or not one or the other looks better in game to any specific person is entirely subjective but compressed formats are lossy and degrade the crispness.

 

D

 

First the 32-bit original:

 

 

 

Second, the DXT3 format:

 

 

 

[hjwalter]

defaid,

 

I've now done some tests with three different flyable aircraft, each of them fully DXT3 textured and done with and without mips. However, I did not see the crispness differences as in your two pics above. So, the only thing I can now think of is that you and I have different graphics cards and/or display screens.

 

My graphics card is an AMD Radion HD 7900 series, which outputs to a large Panasonic TV set (resolution 1920 X 1080) connected up via a HDMI cable. However, I must also admit that this very modern TV set has a whole series of it's own built in adjustment possibilities and some of those include picture "sharpness", colors, contrasts, etc. etc. All this is most probably the reason why I was originally not directly referring to flyable aircraft texture mipmaps but far more to those of scenery textures about which I've had my own mipmap theories for many years.

 

One of these theories is still that the highest possible frame rates should always be sought after and mipping scenery and AI plane textures were one of the surest ways to attain this but a few display problems remained here and there and the questions I had about these were the subject of my original posting in this thread. However, judging by your reactions and those of Alan, I have now understood that my few scenery problems still remaining are not very easy to rectify but because they are so few, it doesn't really remain a problem.

 

Anyway guys, thanks for your reactions, I learned a lot from them.

 

Regards

 

Hans

 

 

 

 

 

 

[jgf]

MIPs will not affect what you see at close range, they merely reduce graphics resource requirements as the objects get farther away (where you will not notice reduced detail/resolution).  Without MIPs the full size image is loaded regardless of where it is used - imagine the resources required to display all the scenery tiles visible on the screen using 2048x2048 images;  MIPs allow the distant textures to be rendered with 32x32, or smaller, textures.  Same with aircraft, a dozen AI without MIPs are using a lot of resources.

 

The image degradation referenced above is what happens when repeatedly processing a DXT/DDS image, just like a jpg file it is compressed every time it is saved, and each compression causes loss of quality.  Thus when painting aircraft always edit the original image and save as a new DXT, never edit and save the DXT.

[defaid]

This will be long and wordy but first...

 

@hjwalter Hans, to answer your original question, the only inbuilt mechanism for specifically an image is the computer's graphics engine, which has constantly to resize every texture file in order to create the illusion of distance. BGLs are a different matter and I can imagine that someone has managed to compile one one that does create mips from base textures. Seems redundant though -- the processing power to create mips on the fly and then render them would be exactly the same as simply resizing and rendering the base image.

 

I won't be at all offended if nobody reads this. I won't know unless some masochist points out a mistake...

 

21 hours ago, defaid said:

mip mapping has no effect within a certain view distance because up to that point, the largest image will be used and not any of the mips

 

2 hours ago, jgf said:

MIPs will not affect what you see at close range, they merely reduce graphics resource requirements as the objects get farther away...

 

... The image degradation referenced above is what happens when repeatedly processing a DXT/DDS image, just like a jpg file it is compressed every time it is saved, and each compression causes loss of quality.

 

@jgf Thank you for adding that. I thought my explanation was reasonably clear but perhaps it wasn't. It could be a language barrier, I suppose.

 

For anyone who just happens along and has the fortitude, I'll reiterate...

 

First, image compression.

 

DXT3 degrades image quality, right from the outset. And it gets worse with every hard save. I'll come back to that.

 

All compression degrades image quality. Not just game textures and not just the DXT format.

 

Every time you edit and save one of your photographs as a jpeg the image quality will diminish. Zoom right out from your newly compressed photo and it probably won't look so bad. Zoom in and you will see more of the degradation.

 

The same thing happens with music (except for a few formats like .flac) though most of our ears can't hear the difference between a wav and an mp3.

 

Decompressing a compressed image doesn't repair the damage. It is permanent. Converting DXT3 to 888-8 doesn't improve the image quality. I do it to downloads because 1) I'm likely to edit in the future and 2) I'll forget what format it is. I resave downloads as 888-8 to ensure that my future self doesn't mess up.

 

There is some good news though. Image editing software doesn't actually save the file when you click 'Save'. What it does is make a temporary file of what's essentially metadata comprising the sum of all the editing that you've done. The compression part of the metadata is only applied to the image file itself when you 'Save As' or when you save and close. You can save as often as you like as long as you keep the image open, and only one compression will be done, right at the very end.

 

DXT images are compressed. 32 bit are not. So, for the same number of pixels, DXT3 uses up much less disk space. They are arguably quicker to load into FS9 just because they are fewer MB in size but I've never noticed a difference, not even on my old XP machine.

 

On a slight tangent, resizing is also a form of compression: 2048 × 2048 down to 512 × 512 means a file 1/16 of the kB size but the different compression formats we have been discussing don't alter the image dimensions, only the quality.

 

Second, mip mapping.

 

It's one of the more interesting aspects of mathematics that just as you can map a piece of a flat image to a point on the surface of an imaginary 3d model (atlas to globe), so you can map a different piece of the same image to the concept of 'further away'.

 

Referring to the ISS images in my earlier post (which as usual came from Wikipedia), mips don't affect near objects because for close-ups, the highest-res base image is always used.

 

The explanation for mips being necessary dates back to the 20th century. The size of a building, a tree, an aircraft on your monitor is not 30 metres wide by 40 metres long. Its real size changes as it seems to move closer or further from your virtual viewpoint.

 

Sometimes the object may be 1000 pixels wide. A few minutes later it could be 30 pixels. Graphics hardware and software have to edit textures to create the illulsion of distance and perspective.

 

Imagine an FS9 building falling behind you as you taxi past it. As you go by, looking out of your cockpit window, it is a rectangle covering 500 × 500 pixels of your monitor. Taxi onward and look back over your virtual shoulder. The object is now a trapezium 50 pixels tall and 10 pixels wide.

 

The graphics stuff has to shrink the texture to make it look further away and has to skew it to account for perspective. Shrinking has to be done on a per-pixel basis so that's 262 000 pixels that have to be processed for a 512 × 512 texture. It has to be done for every texture in every frame of your fps. For a 2048 × 2048 it's nearly 4.2 million.

 

However, if the texture has mips, then much of the work has already been done. While you are near the virtual building, the graphics engine will still select the high-res, unmipped base image in the texture file. As you taxi onward, the graphics engine will select one of the pre-shrunk images from a different piece of the texture file and then only has perhaps 64 × 64 pixels to process. This is the purpose of mip mapping: reducing the load.

 

Fifteen or more years ago this was absolutely essential: small ram, weak processors, onboard graphics...

 

Nowadays, small textures like those in FS9 -- a maximum of 2048 × 2048 -- are no trouble for modern equipment and mip mapping is not necessary.

 

If you have an old PC and you find your framerate dropping then mip mapping textures may help. It's worth being aware that it may not: the framerate could be affected by the number of polygons in the frame, online weather or even by complex systems in the player aircraft. Lots of things affect it.

 

But... modern PCs don't struggle with unmipped textures in FS9.

 

D
 

[hjwalter]

defaid,

 

Thanks very much for your in depth technical explanations but it remains my opinion that when it concernes the general mipping of scenery textures this should increase my frame rates and that then becomes my way to go, even if my more "modern" hardware setup would not "struggle" without such textures being mipped. My frame rate has even been maximised at 30 FPS for many years already, which theoretically leaves more capacity for other FS9 (background) work.

However, comments remain welcome.

 

Regards

 

Hans

[defaid]

Hi Hans.

 

I fully agree with your decision to keep some processing power in reserve. I have my framerate locked at 60 fps to match my monitor. FS9 usually runs at 60 but at complex airports with lots of AI it can drop as low as 30 so my PC could be regarded as 'struggling'. On the other hand, I'm happy with anything down to around 30 fps so I don't regard it as an issue.

 

I have a lot of un-mipped 32-bit textures in my aircraft folder. I may make a copy of the folder and compress & mip all the textures. Then I can compare framerates to satisfy my curiosity. Whatever, as you wrote, spare processing power is always a good thing.

 

D

[hjwalter]

Hi defaid,

 

Your remark that you have locked your FPS at 60 in order to match that of your monitor has suddenly got me sitting upright and wide awake because as far as I know the standard FPS of any monitor (or TV set) is directly steered by the AC frequency. Therefore 60 Hz in the USA and 50 Hz in Europe.

 

My monitor (= a Panasonic 60Hz. TV set), which is therefore most probably a USA version, while my European AC power supply is 50Hz. ....... and all that while I'm supplying it with an FS9 maximum output of 30Hz ???

However, you are completely correct in saying that the FPS supplied by FS9 can vary strongly dependant on load etc. so, why everything in that hardware area keeps working correctly remains a mystery, at least to me. It may have something to do with a HDMI (type) connection, which seems to override evrything related to AC/FPS frequencies.

 

Tomorrow I'm now going to set my maximum FS9 FPS at 60 to see what happens and then at 50 but my expectations are not high because 30 FPS has seemingly already worked problem free for years in my setup.

 

Anyway, a very interesting thread indeed and ....... Long Live FS9 !!

 

Hans