FSX Bump mapping and mips

#1
Like (I am sure) most of folks on this forum, I'm kind of a person that implicitly trusts what is written in official documentation, and take it as (largely) correct. So, when I was dissatisfied with how bump-mapped parts of my models looked like from afar (bright pixels that made it look as if the part was made of crystal :rolleyes:), I looked more closely at the SDK documentation for both FSX and ESP, on how bump maps are processed. I was using a string taken directly from the documentation to process my bump maps (I create cmd files that batch-process my textures). Here is the processing string:

FSX SDK:
imagetool -nobeep -nomip -dxt5 -RedInAlpha -dds -nodither <path/filename>

ESP:
imagetool -nobeep -nomip -dxt5 -RedInAlpha -dds -nodither <path/filename>

One detail I noticed is that there is a -nomip switch in both versions of documentation (ESP seemingly being just a carbon copy of the original FSX SDK). I removed the switch and processed my bump maps with mips, and lo and behold, my models looked way better, cleaner and the performance slightly improved. Unless there is a very good reason for not using mips on a bump map I'm not aware of, this was obviously an oversight. For sanity, I checked Prepar3D documentation (which I suppose is the most recent and most relevant), and sure enough, -nomip switch is gone!

Prepar3D:
imagetool -nobeep -dxt5 -RedInAlpha -dds -nodither <path/filename>

So, (unless this is old news for everyone except me ;)), if you haven't done this already, re-do your bump textures to use mip maps. I'm sure glad I did.
 
Last edited:
#2
Interesting. Could you show a screenie or two demonstrating the difference?

Not that I am doubting your word, but MIPs cut in when you see the a/c from a distance. Bumps, on the other hand, typically affect very small areas such as rivets, which can only be seen from a resonably close POV. If you can't see rivets from a distance why would the mip be needed? Of course, Mips also increase file size. Bumps drastically increase mdl size; again it would be interesting to see if there is a further increase if mips are used.
 
#3
You are missing the point:

The "bumps" are still there when the Aircraft is far away, and it is the largest version of the bump map that is being used, thus hogging the memory and defeating the purpose of the MIPs. If the aircraft has been designed with bump maps that do not contain MIPs, the full size version of that bump map will be used even when the aircraft is far away, thus needlesly occupying the memory for something that's hardly visible. The artefacts that look bad, which I noticed, are the result of my video hardware trying to shrink a large texture into a small area. If it had an already shrunk version (a MIP), the artefacts wouldn't be so pronounced.

So, it is precisely MIPs that you want to kick in when AC is far away, so that the material doesn't use the largest texture (unless the lower LOD has been designed with a different material, which doesn't contain bump maps, but I never heard of anyone doing this). Sure, the initial loading size of the texture is a bit larger, but the size of actual video RAM that the MIP occupies is far far smaller, compared to the full size the texture would need at all times.

Also - how exactly do bumps "drastically" increase MDL size? They are contained in the texture, not the MDL. MDL only contains a reference (name) of the texture a part is using.

And finally, why would P3D documentation remove this setting, as I am suggesting? Obviously, someone from LMart went through the P3D with a fine comb and realized the same thing. :)
 
#4
You first spoke of a difference in quality and I asked for some ocular proof. How is that missing the point?

Yes, Bump materials increase model size drastically. I'll be happy to demonstrate.

Why would a documentation omit something? Maybe because they forgot?
 
#5
Respectfully, you were missing the point on what you said here:

" If you can't see rivets from a distance why would the mip be needed?"

It doesn't matter if you don't see the bumps. Just because you don't see the bumps, doesn't mean they are not there. The bump map is still used, and sitting in memory, with it's largest (and only) version.

To further illustrate, take a look at, for example, a stock DC3 texture in Microsoft Flight Simulator X\SimObjects\Airplanes\Douglas_DC3:

Douglas_DC3_1_T.dds and Douglas_DC3_1_t_bump.dds

It covers the wings, fuselage, tail, engines, even the tyres... whole aircraft, not just a few rivets. And the bump texture is only one size, no mips, so even when the AC is a tiny speck, it uses the full texture.

As for the demo, I have converted all my models to mipped bump textures. I can certainly provide before and after shots once I finish up a few current tasks on my desk.

re: documentation - they didn't omit it, they left -nomip flag in. You have to explicitly tell ImageTool not to do MIPs on a texture. A mistake can crop in, sure. I keep finding all kinds of small, mostly typographical, mistakes. But this one, in my opinion, is quite a doozy :rolleyes:... think of all the needles video RAM being wasted this very moment as we debate this point :laughing:
 
Last edited:

Pyscen

Resource contributor
#6
There is also differences in quality between ImageTool & NVidia Texture Tool plug-in and/ or GIMP Normalmap plugin,... The 2 latter are better in compression quality for dxt5 files. Have you noticed,... That within FSX SDK states -nomips for normal (bumps) maps because it will crash it. I have tested that personally,... and it does crash. On the other hand, I haven't tested it in P3D v4.2.
 
#7
Have you noticed,... That within FSX SDK states -nomips for normal (bumps) maps because it will crash it.
Where does it say that?

From FSX and ESP SDK:

To avoid performance degradation, it is recommended that all textures include mip-maps.
I have never experienced a mipped bump texture related crash, and I am using "stock" ImageTool and NVIDIA PS Plug in, and running stock FSX SP2
 
Last edited:

Pyscen

Resource contributor
#8
Sorry I was referring to Environment Maps. They being mipmap'ed will cause the simulator to crash.

What textures do you have within FSX (the defaults - aircraft) that have mipped that are normal (bump) maps? I would believe the reason was memory constraints at the time of computers when FSX originally was released,... As Mjahn suggested earlier,... aircraft or scenery from long distances will not show details. It's not even possible in the real world. ImageTool isn't perfect in compression handling at all... there is a lost in quality. Also,... ImageTool doesn't handle alpha channels well,... and since the Red Channel is being placed in the alpha channel upon converting to a bump map, could be the very reason for the quality lost. There are other factors that could occur to the quality lost as well...
 
Last edited:
#9
It may not of been within the SDK, but it has cause crashes, for me personally. If you haven't, what textures do you have within FSX that have mips that are normal (bump) maps?
There is no such warning in SDK, anywhere. The only thing that SDK does is it contradicts itself, stating first that all textures should be MIPed, and then offering a command line for bumps that has -nomip switch.

As of a few weeks ago, ALL my bump map type textures have MIPs without as much as a single hiccup, and with far better visual appearance. I have perhaps 50 objects with the project I am currently on, some aircraft, some simple objects and some static scenery (BGL) objects. I have converted ALL of my non-MIP bump textures to MIPs.

As for your crashes, can you reproduce them if you MIP one of your bump textures? Perhaps something changed in video hardware advancements during the last few years, and this is now handled better? (Assuming you upgraded your HW recently - I'm on GE FORCE 1060 6GB RAM... )
 
#10
Misho, you are raising an interesting point, and I am grateful for your find . As an a/c modeler I just want to nail it down in more detail.

I now understand that you are saying that unmipped bumps exert a memory load that creates (may create?) texture artefacts. I'd still be interested in when this becomes critical.

Talking of MIPs and memory loads we whouldn't forget that there is a strong correlation between MIPs and our use or non-use of LODs. If you are using LODs you would clearly skip the Bumps for the lower level ones.

I believe, in the past, the main reason for developers to not use Mips was that Mips sometimes produced blurry artefacts in FS9, which may or may not still be relevant in FSX, P3D upto 3.4, or V4., I don't know. In my own practice, I do not use MIPs, but may think again, depending on the evidence produced in this discussion.

Of course to mip or not to mip also goes for Specs and Diffuses, doesn't it, so I guess we shouldn't restrict the discussion to Bumps.

When the SDK says "all" textures have to be mipped, surely that doesn't include VC textures.

As far as I can see, the revised Imagetool setting (leaving out the -nomip) is only included in the P3DV4 SDK. So it may or may not be V4 specific. The V4 SDK also points out that

Code:
Imagetool is available in the root folder of the SDK. . . . Note that this tool has been updated and ensure that you are using the latest version.
I just ran a bump psd through this new ImageTool, omitting the -nomips, and indeed the result is a mipped bump. Now the question is, do we change our textures for V4, or also for the previous versions, such as vanilla FSX. Did LM themselves change them for their revised V4 default aircraft? I can't say because I got rid of the F22, don't ask why.

Some tests would be greatly appreciated. That includes any ImageTool quality defects users may have experienced (not me).

--Manfred
 
Last edited:

Pyscen

Resource contributor
#11
There is, generally speaking, 3 steps in creating bump maps and I know of a few artifacts that can occur if the first & second steps aren't done (I'm sure there are more though).

The 1st step is converting the diffuse into a height map or into a black and white image. If the image is just placed in black & white, one would need to make sure that the darker colors are represented correctly. Meaning, if the colors that are darker that is suppose to appear closer to the user, then it would need to be reversed. If the user doesn't convert it to a height map or black and white (leaving it as is - jumping to step 2), artifacts can occur. The only application that I know of that handles this without possible conversion is within Adobe Creative Cloud, but it still would not know the difference in the colors (what is suppose to appear closer).

The 2nd step involves converting into a normal map, which is done through the NVidia Texture Tool or GIMP Normalmap plugin. This is where another anomaly can occur, the user stops here believing that this is all that needs to be done.

Step 3 involves using Imagetool or MCX, which converts to a Bump map. I personally call it the RGB Conversion process.

How the FSX's engine uses a single mipmap bump when the pov increases is not certain. Does the single mipmap drop off out of memory, I think not. But in reality, can a human being see the definition of details when the pov increases. LODs are different and could actually require more memory then a single mipmap. The general rule that I follow is this, depending on the size of the object as well as its importance within a scenery, should have mipmaps in the Diffuse, Light (night), and Specular maps. The Bump map can if one wishes, but only on the largest of objects within a scenery.

There are number of default textures that the Bump maps are not the same resolution size as the Diffuse or Light maps. I bring this up to ask, does this mean that the Bump map only works on that given size or is it only smaller in memory and applied to the largest resolution of it's counter parts? With that in mind, one can change the resolution of a Bump map to 256 x 256, even though the Diffuse map is 512 x 512, and create mipmaps for the Bump map which start at 256 x 256 and goes down for there. Thus, using less memory.
 
Last edited:
#12
I now understand that you are saying that unmipped bumps exert a memory load that creates (may create?) texture artefacts. I'd still be interested in when this becomes critical.
No. Memory load and artefacts are two different detrimental effects of no mipping. One is not the cause of the other. A model with all textures mipped except bump texture will always "hold" extra 1 MB of unnecessary video RAM PER MATERIAL. For example, B747 and B737 have 2 bump mapped materials. If you have an airport with a lot of AI aircraft, plus some complex scenery with bump mapped textures, that can add up to a lot of wasted video RAM.

Artefact is a different thing - basically, it appears when a full-sized, not mipped bump texture is shrunk to a small area of a far-away model. Video hardware does that, and it does a much better job if there is a mipped version. Artefact is what I noticed when I started experimenting with this. Memory load has nothing to do with creating artefacts.

Talking of MIPs and memory loads we whouldn't forget that there is a strong correlation between MIPs and our use or non-use of LODs. If you are using LODs you would clearly skip the Bumps for the lower level ones.
I agree, but this seems like a bit of a hassle to keep track of different materials for different LODs. Just use Mips on everything and let them do their job, what they were designed for. ;)

I believe, in the past, the main reason for developers to not use Mips was that Mips sometimes produced blurry artefacts in FS9, which may or may not still be relevant in FSX, P3D upto 3.4, or V4., I don't know. In my own practice, I do not use MIPs, but may think again, depending on the evidence produced in this discussion.
I really don't want to even raise FS9, as I tagged this discussion as "FSX" (and I wish there was a tag "FSX and its derivatives"). FS9 is a whole different beast, and ancient history. ;)

Of course to mip or not to mip also goes for Specs and Diffuses, doesn't it, so I guess we shouldn't restrict the discussion to Bumps.
Again, I don't agree. As per SDK, Specs and Diffuses should always be mipped, as they are with default AC. My point is, As per SDK, ALL textures, including bumps, should be mipped, as there are no clear disadvantages to it (maybe there were in FS9, but we're talking about FSX and its derivatives), and a few important disadvantages of NOT using it.

When the SDK says "all" textures have to be mipped, surely that doesn't include VC textures.
Correct. No point in using mips on materials that are always close by.

As far as I can see, the revised Imagetool setting (leaving out the -nomip) is only included in the P3DV4 SDK. So it may or may not be V4 specific. The V4 SDK also points out that

Code:
Imagetool is available in the root folder of the SDK. . . . Note that this tool has been updated and ensure that you are using the latest version.
I just ran a bump psd through this new ImageTool, omitting the -nomips, and indeed the result is a mipped bump. Now the question is, do we change our textures for V4, or also for the previous versions, such as vanilla FSX. Did LM themselves change them for their revised V4 default aircraft? I can't say because I got rid of the F22, don't ask why.
I hate to disappoint you, but the very same notice about the "new and updated" ImageTool is in the SDK documentation for FSX SP2 (which I am using) AND the ESP SDK documentation, which are both from about 10 years ago. I do remember that they released an update to SDK from the original 2006 version when FSX came out, and I believe they updated ImageTool as well. This note is referring to that update, nothing recent that "only P3D has". In fact, It has nothing to do with P3D SDK: LMart copied large portions of P3D SDK verbatim from the FSX SP2 SDK, as was much of the documentation. They amended P3D SDK in areas where thy made P3D specific improvements to the base code and added new features. As far as -nomip switch, I still believe they just noticed what I noticed, and corrected their own SDK. No advantage of letting our community know, since they are commercial outfit :(
 
Last edited:
#13
There is, generally speaking, 3 steps in creating bump maps and I know of a few artifacts that can occur if the first & second steps aren't done (I'm sure there are more though).

The 1st step is converting the diffuse into a height map or into a black and white image. If the image is just placed in black & white, one would need to make sure that the darker colors are represented correctly. Meaning, if the colors that are darker that is suppose to appear closer to the user, then it would need to be reversed. If the user doesn't convert it to a height map or black and white (leaving it as is - jumping to step 2), artifacts can occur. The only application that I know of that handles this without possible conversion is within Adobe Creative Cloud, but it still would not know the difference in the colors (what is suppose to appear closer).
I NEVER create a bump map straight out of a diffuse texture. I use vector elements of the diffuse components in my Photoshop layer, duplicate it, and adjust coloring to reflect the effect I want to achieve. For example, if there is a bright white and dull dark panel on the fuselage, and I want them both to appear popped out, looking like covers rather than recesses, using this diffuse map as a bump map would make white panel pop out, and dark panel appear as a hole.

How the FSX's engine uses a single mipmap bump when the pov increases is not certain. Does the single mipmap drop off out of memory, I think not. But in reality, can a human being see the definition of details when the pov increases. LODs are different and could actually require more memory then a single mipmap. The general rule that I follow is this, depending on the size of the object as well as its importance within a scenery, should have mipmaps in the Diffuse, Light (night), and Specular maps. The Bump map can if one wishes, but only on the largest of objects within a scenery.
It is not uncertain at all - While they are created a bit differently, with a few more steps, the end result is a dds bump map texture, which is treated by the rendering engine exactly the same as other maps. It does not drop out of memory - it is retained. In fact, Mips are simply LOD equivalents of textures, and should be treated and designed the same way. LODs and Mips work in unison in order to optimize rendering engine load.

There are number of default textures that the Bump maps are not the same resolution size as the Diffuse or Light maps. I bring this up to ask, does this mean that the Bump map only works on that given size or is it only smaller in memory and applied to the largest resolution of it's counter parts? With that in mind, one can change the resolution of a Bump map to 256 x 256, even though the Diffuse map is 512 x 512, and create mipmaps for the Bump map which start at 256 x 256 and goes down for there. Thus, using less memory.
If a material that uses bump map is at a mip level of, say 128x128, it will "ask" all of its textures for a level 128 mip version. If it doesn't get it, it will use next best available version, which in case of unmipped bump texture, is a full unmipped (the only one) version. There is nothing "smaller in memory" and rendering engine will not reduce a physical size of the texture on the fly - that would be way too demanding computationally. (if you're programming instrumentation, you'll know what I'm talking about). Sure - if you design a material with 1024x1024 texture with mips, and give it a 256x256 bump texture with mips, it will get 256 bump version for 1024, 512 and 256 levels of mips . That is one way of being efficient and lowering the memory load, however, it depends on what you're trying to model. If you use a 1024x1024 texture and design a fuselage cover with sharp corners, using a 256 mip level will make those corners smooth out into a "hill" with gentle slopes ;)
 
#14
Sorry I was referring to Environment Maps. They being mipmap'ed will cause the simulator to crash.
Oh yes, that is definitely the case ;)

What textures do you have within FSX (the defaults - aircraft) that have mipped that are normal (bump) maps? I would believe the reason was memory constraints at the time of computers when FSX originally was released,... As Mjahn suggested earlier,... aircraft or scenery from long distances will not show details. It's not even possible in the real world. ImageTool isn't perfect in compression handling at all... there is a lost in quality. Also,... ImageTool doesn't handle alpha channels well,... and since the Red Channel is being placed in the alpha channel upon converting to a bump map, could be the very reason for the quality lost. There are other factors that could occur to the quality lost as well...
Aircraft from long distance will not show details, but WILL use a full size bump texture if bump texture is not mipped. Just because you don't see bumpy rivets from a great distance, doesn't mean the bump map isn't used and in memory.

NONE of the default aircraft in FSX have mipped bump textures. It is easy to spot a "stock" 1024x1024 mipped and non-mipped texture: Mipped is 1366 Kb, non-mipped is 1025 kb. The reasoning for memory constraint actually goes in favor of mipping bump textures. A fully mipped bump texture is still used for aircraft very far away - it stays in the memory. I believe MS overlooked this by mistake, and their SDK command line for bump textures reflects this. It is either that, or, 12 years ago video hardware couldn't handle mipped bumps, and since then something changed. The fact is, I observed marked visual improvement by mipping bumps, and memory consumption advantages are self evident - that's what the point of mipping is, to conserve video RAM.
 
#15
We seem to be talking at cross purposes.

I am not interested in FS9 either, but blurries and their cure (by removing MIPs) have been reported for FSX as well.

Re ImageTool versions -- on my current setup I have three, perhaps more:

ImageTool.exe 226 712 10.05.2007 23:05 -a--
ImageTool.exe 226 880 10.12.2007 21:38 -a--
ImageTool.exe 227 328 08.02.2018 11:09 -a--

As you can see they are all different. The last one is the one from P3d V4. So their point about the new version is correct.

Do they follow their own advice on MIPs and Bumps?
 
#16
Ok - to illustrate, here are the screenshots :cool: (I'm putting my money where my mouth is :D)

I have here 2 identical parts: Circular rocket engine mounts - this is a part of a rocket stage, I am working on a spaceflight add on. The part is made with this honeycomb structure that increases material rigidity. This is a widely used practice in aerospace industry. Parts are identical, except that the part on the LEFT has a mipped bump texture, and the part on the RIGHT has a non-mipped bump texture.

First, up close, there is not much difference between the parts, which is to be expected, as they are at the same MIP level:
2018-6-14_13-11-58-176.jpg Bump Mip Level for the left and right part is 1024

Then, zoom out a bit, starting to notice some "crispy" pixels on the right part:
2018-6-14_13-7-3-763.jpg Bump Mip Level for the left part is now ~512, while the right part remains at 1024

And finally, from afar, you can clearly see how the right part becomes "sparkly"... the effect is even more pronounced when moving viewpoint, as the pixels shift and "shimmer", while the graphics engine tries to fit the large bump texture to an increasingly smaller area.
2018-6-14_13-7-25-834.jpg Bump Mip Level for the left part is now at ~64, while the right part remains at 1024

Meanwhile, the left part is staying nice and smooth, all the while bump mapped.
 
Last edited:
#17
Re ImageTool versions -- on my current setup I have three, perhaps more:

ImageTool.exe 226 712 10.05.2007 23:05 -a--
ImageTool.exe 226 880 10.12.2007 21:38 -a--
ImageTool.exe 227 328 08.02.2018 11:09 -a--

As you can see they are all different. The last one is the one from P3d V4. So their point about the new version is correct.
I was specifically talking about the textual note:
"Note that this tool has been updated and ensure that you are using the latest version."
... which is present, identical word for word, in FSX SDK, ESP SDK and P3D SDK. I don't own or use P3D, so I wouldn't know if they updated ImageTool. As I was noting, I know they updated things and added features, and it doesn't surprise me they upgraded ImageTool - with what, I have no idea, but my point is, the "plain Vanilla" Imagetool works without problem with creating bump mips. Perhaps their note should say:
"Note that this tool has been updated yet again and ensure that you are using the latest version."
That would probably avoid some confusion! :D

Do they follow their own advice on MIPs and Bumps?
Again, no idea, since I don't own any of their products. Do you? It is easy to check: Their *_bump.dds textures should be 1366 Kb instead of 1025 Kb. Let me know if you can verify.
 

krispy1001

Resource contributor
#18
Like (I am sure) most of folks on this forum, I'm kind of a person that implicitly trusts what is written in official documentation, and take it as (largely) correct. So, when I was dissatisfied with how bump-mapped parts of my models looked like from afar (bright pixels that made it look as if the part was made of crystal :rolleyes:), I looked more closely at the SDK documentation for both FSX and ESP, on how bump maps are processed. I was using a string taken directly from the documentation to process my bump maps (I create cmd files that batch-process my textures). Here is the processing string:

FSX SDK:
imagetool -nobeep -nomip -dxt5 -RedInAlpha -dds -nodither <path/filename>

ESP:
imagetool -nobeep -nomip -dxt5 -RedInAlpha -dds -nodither <path/filename>

One detail I noticed is that there is a -nomip switch in both versions of documentation (ESP seemingly being just a carbon copy of the original FSX SDK). I removed the switch and processed my bump maps with mips, and lo and behold, my models looked way better, cleaner and the performance slightly improved. Unless there is a very good reason for not using mips on a bump map I'm not aware of, this was obviously an oversight. For sanity, I checked Prepar3D documentation (which I suppose is the most recent and most relevant), and sure enough, -nomip switch is gone!

Prepar3D:
imagetool -nobeep -dxt5 -RedInAlpha -dds -nodither <path/filename>

So, (unless this is old news for everyone except me ;)), if you haven't done this already, re-do your bump textures to use mip maps. I'm sure glad I did.
Hi Misho!

Very good information to know. I do the very same thing you said that you did. Just use the line of code as it is. I did not even think about the not mip map part of the line.

Thanks for the information!!!!!!!!

Kris
 
#19
In 4.1 it seems none of their planes' bump textures are mipped. I only have a selection of them, however, and not the latest 4.2 version, maybe they did add them to their reference plane, the F22.

Thanks for the screenshots.
 

Pyscen

Resource contributor
#20
I NEVER create a bump map straight out of a diffuse texture. I use vector elements of the diffuse components in my Photoshop layer, duplicate it, and adjust coloring to reflect the effect I want to achieve. For example, if there is a bright white and dull dark panel on the fuselage, and I want them both to appear popped out, looking like covers rather than recesses, using this diffuse map as a bump map would make white panel pop out, and dark panel appear as a hole.
Yes,.. that is creating a Height Map - using data from the diffuse map. I didn't go into detail on the specifics on creating one.
 
Top