Prepar3D Texture Map Converter (for Normal Maps and PBR Metallic Maps)

[Stephan Ertel]

HEY Guys and Girls
I've developed a quick and dirty little tool (C# .Net w32), it makes the texture/modeling life easier

1st feature: Convert Normal Maps (valid for both, Std. Diffuse Textures & PBR Textures):
You might know,
when using Industry-Standard-Normal-Maps for Prepar3D, you need to change the color channel mapping. Otherwise, you won't get the proper result (basically, the z-axis will be missing and your HQ-3D Normal map will act like a 2D Bumpmap). The tool will do that for you. (RED channel to Alpha, zero out red, green and blue untouched).
>> Click the button, select your file, and WAIT!!! (program will look unresponsive, a 4096x4096 texture can take more than a minute).

2nd feature: Combine the 3 source maps into the METALLIC texture for PBR):
per SDK: PBR Metallic maps have to include also a smoothness (also called roughness map, are the SAME) and can also include a Ambient Occlusion Map.. All needs to be fitted in the correct channels.
R=Metallic, G=Ambient Occlusion, B=unused (i zero it out), A=Smoothness. It's possible to have NO metallic map, just as a note.. Will be 100% non-metallic..
Source Maps are only gray scale per definition, as well as they won't fit in one color channel if colored . BUT to ensure this, i gray-scale all source maps.. changes nothing if already gray, but if colored, i make a gray one for you before writing the pixel.. THIS DOESN'T MEAN that you can input everything and the output will be PBR but you can play around and look what will come out
I developed the 2nd feature running as ASYNC thread, so unlike the 1st, program keeps responding and you get the current pixel as status..
usage: Add your maps and hit RUN

NOTES for both features: SOURCE files cannot be a DDS!! But other formats are allowed, like tif, bmp, jpg, png... No error message, if the application crashes with "memory error" than > wrong format)
- OUTPUT will be written into the source texture folder (bmp with alpha channel)
- I try to convert it into DDS (DXT5, mip, flipped vertically), but i don't know yet why, it doesn't work with every image.... For all my textures it works fine, when a try to take random jpg, it won't..
So, i do not delete the intermediate bmp. Naming will be like this (i simply add a suffix):

Asphalt10_2x2_1K_normal.tif_normalConverted.Bmp.dds
CliffLayered_4K_albedo.tif_metalmaps_combined.bmp

!! WAIT !! while showing "please wait"!!! 4096x4096 can take.. as well as the dds conversion also will take some seconds, like usually

 

[Deleted member 1281]

Looking like a useful tool, especially for collating the _metallic channels.

Unfortunately, it wouldn't install on my setup. I don't see any installation instructions, and I don't know where to put the [data] folder included in the zip. My mistake surely, but a small readme would come in useful.

You don't say anything about mipmaps, but users should be given the choice.

Selecting a single file from a default folder window is cumbersome -- surely users would prefer to use a file browser to drop several files to an in-tray.

Apart from this, this particular comment I found interesting:

when using Industry-Standard-Normal-Maps for Prepar3D, you need to change the color channel mapping. Otherwise, you won't get the proper result (basically, the z-axis will be missing and your HQ-3D Normal map will act like a 2D Bumpmap). The tool will do that for you. (RED channel to Alpha, zero out red, green and blue untouched).

The interesting thing about this is that you are in fact converting the _normal map to an FSX-type _bump map, correct? Speaking as a developer I find that awfully misleading. It's not what the V4.5 SDK says you should do; nor is it done in the example of the 60 ft Pusher Drone included in V4.5. Despite this I think your comment is correct: when converting the drone's _normal map to a _bump, the appearance is different (and better). We actually discussed the _normal issue in another thread:

https://www.fsdeveloper.com/forum/threads/mcx-texture-converter.445477/post-823597

and I'll crosspost your finding there as well.

 

[Stephan Ertel]

Not really.. It's extactly what the current SDK v4.5 says. Nothing gets lost, basically, i read every pixel color (gray) of the red channel, and write it completely 1:1 to the alpha channel. And i zero out the Red channel...
I believe in the FSX version, they are additionally deleting a channel. I'M NOT, green and blue keeps unchanged..

Per SDK: Page "Texturing Aircraft Models (there are the texture maps and so on commented)
Normal Map / Height Map / Bump Map

Normal maps are RGB textures which are generated from grayscale height maps. Once generated, the Normal map cannot be edited (with much success anyway). The display engine uses the component color channels to define bumpiness on a surface. Ordinarily, each component color value (R, G and B) is designated as an X, Y and Z vector for the display engine to interpret and then render. In Prepar3D, this has been changed somewhat and as a result Normal maps are not the same as those output by the NVIDIA plug-in. Most Normal maps tend to be 32 bit images in order to reduce compression artifacts. The Normal maps used in the rendering engine reassign the Red channel as an Alpha channel and leave the Green and Blue components unchanged. This saves disk space and aids performance.


For the purposes of texture creation, painters will make their maps as grayscale images which define height in terms of light and dark values. Lighter values represent higher points and darker values represent lower points. When a painter is ready to generate a Normal map from their height map, it should be flattened and any Alpha channels should be removed. There are several different settings which can be chosen in the Plug-in interface. We have found the best results usually come from leaving the settings at default and if anything, reducing the number in the Scale field to 1. See image below for the recommended settings.

 

[Stephan Ertel]

Looking like a useful tool, especially for collating the _metallic channels.

Unfortunately, it wouldn't install on my setup. I don't see any installation instructions, and I don't know where to put the [data] folder included in the zip. My mistake surely, but a small readme would come in useful.
THe "readme" was the publishing post

Yes, sorry, i'm lazy.. There is no instruction, becuause just extract and leave the data folder inside the main folder (where the .exe is). There is also currently no choice for the user.
I wrote the tool for me and thought maybe someone also likes the metal-combiner as well as the normal changer. Maybe i'll implement the choice for mips..
Basically: IF the conversion to DDS succeeds, I always create mip-maps of the texture (as there are more advantages the disadv.).
If you only find a successfully converted BMP in the source folder, then the known issue happened and the conversion failed -> NO mip maps, but the bmp is fully functional, it just needs some manual conversion..

 

[Stephan Ertel]

One last thing: I will prepare an Installer soon, for now, the program will need Microsoft .NET Framework v. 4.7.2 make sure you have this version installed.

 

[RED COOL]

i made the same program 3 weeks ago but never shared it, yours has an extra feature which is the normal map converter

thnx for the tool it will save some time for me

 

[Stephan Ertel]

i made the same program 3 weeks ago but never shared it, yours has an extra feature which is the normal map converter

thnx for the tool it will save some time for me

Cool i was bored by copying the 3 maps manually into the color channels using photoshop

Today i started to develop the next nice tool: professional textures mostly contains a height map, which is always unused by me.. Using Photoshop to create mesh out of it will end in 500.000 up to 6.000.000 polygons (4096x4096) which makes it unusable and you cannot scale the resolution...
My tool can scale it! You can tell the tool to just use every for ex. 8th pixel... the core is already working great...
it creates triangles from pixels, maybe (0,0)(0,8)(8,0) and then i read the value of the pixel and apply it as z-axis.... i just need to get into the syntax of a directX .X or an mdl and convert the values....

The little math is always confusing but i got it... creates a closed mesh after some programming.. could be a nice tool
I've drawn some lines to make sure i get everything..

 

[Deleted member 1281]

Stephan, what you are quoting from the current 4.5 SDK ...

Normal maps are RGB textures which are generated from grayscale height maps. Once generated, the Normal map cannot be edited (with much success anyway). The display engine uses the component color channels to define bumpiness on a surface. Ordinarily, each component color value (R, G and B) is designated as an X, Y and Z vector for the display engine to interpret and then render. In Prepar3D, this has been changed somewhat and as a result Normal maps are not the same as those output by the NVIDIA plug-in. Most Normal maps tend to be 32 bit images in order to reduce compression artifacts. The Normal maps used in the rendering engine reassign the Red channel as an Alpha channel and leave the Green and Blue components unchanged. This saves disk space and aids performance.

For the purposes of texture creation, painters will make their maps as grayscale images which define height in terms of light and dark values. Lighter values represent higher points and darker values represent lower points. When a painter is ready to generate a Normal map from their height map, it should be flattened and any Alpha channels should be removed. There are several different settings which can be chosen in the Plug-in interface. We have found the best results usually come from leaving the settings at default and if anything, reducing the number in the Scale field to 1. See image below for the recommended settings.

.. is in fact an unchanged text dating back to at least FSX SP2. IOW none of this is new information; and the recommended ImageTool conversion worked as perfectly well then as, to all intents and purposes, it does now.

Edit, maybe worthy of note, Stephan's procedure leaves the Blue channel unchanged, whereas ImageTool and the manual procedure sketched in the Wiki and elsewhere make it white! Whether that's of any consequence remains to be seen/tested.
Edit2, Checking this, I see that ImageTool actually leaves Blue as is (even though it looks almost white), so it's just like what Stephan's has now; whereas the Wiki, following Bill n4gix, suggests White, perhaps erroneously.

 

[Stephan Ertel]

You are right, even in the sdk sp1.... But they changed something "Flight Simulator X" to prepar3D.. AND i NEVER told that it was changed RECENTLY - i just said - with standard normal maps, you won't get a proper detaild result.. And basically that is what you can expect when you are doing things link deleting one channel without replacement, you will use details, 1 channel = 1 axis. for example you loose all the gaps betwenn wall bricks that are pointing from left to right...
As far as i know, your mentioned wiki was never official, i've read it one and never used, maybe some guys were just trying around...
___________________
Proof sinde fsx and such a discussion around...

 

[Deleted member 1281]

OK then, as far as BUMP maps are concerned, your tool is basically an alternative to ImageTool, and DxtBmp, yielding the identical result. That's what I asked in my first reply -

you are in fact converting the _normal map to an FSX-type _bump map, correct?

It appears the answer is "yes".

If the Wiki is wrong, and concerning the Blue channel it certainly looks like it is, then it should be changed. Before we do that maybe the developers involved could add their take on this.

 

[RED COOL]

can you explain what this mesh tool will
The features

 

[FSX3D]

I find your tool great!

I wonder if you could add a function?
It would be to be able to add an 'opacity' layer on the alpha channel of the 'Albedo' texture.

Congratulations again for this very practical little utility!

 

[FrancisJohannes]

HEY Guys and Girls
I've developed a quick and dirty little tool (C# .Net w32), it makes the texture/modeling life easier

1st feature: Convert Normal Maps (valid for both, Std. Diffuse Textures & PBR Textures):
You might know,
when using Industry-Standard-Normal-Maps for Prepar3D, you need to change the color channel mapping. Otherwise, you won't get the proper result (basically, the z-axis will be missing and your HQ-3D Normal map will act like a 2D Bumpmap). The tool will do that for you. (RED channel to Alpha, zero out red, green and blue untouched).
>> Click the button, select your file, and WAIT!!! (program will look unresponsive, a 4096x4096 texture can take more than a minute).

2nd feature: Combine the 3 source maps into the METALLIC texture for PBR):
per SDK: PBR Metallic maps have to include also a smoothness (also called roughness map, are the SAME) and can also include a Ambient Occlusion Map.. All needs to be fitted in the correct channels.
R=Metallic, G=Ambient Occlusion, B=unused (i zero it out), A=Smoothness. It's possible to have NO metallic map, just as a note.. Will be 100% non-metallic..
Source Maps are only gray scale per definition, as well as they won't fit in one color channel if colored . BUT to ensure this, i gray-scale all source maps.. changes nothing if already gray, but if colored, i make a gray one for you before writing the pixel.. THIS DOESN'T MEAN that you can input everything and the output will be PBR but you can play around and look what will come out
I developed the 2nd feature running as ASYNC thread, so unlike the 1st, program keeps responding and you get the current pixel as status..
usage: Add your maps and hit RUN

NOTES for both features: SOURCE files cannot be a DDS!! But other formats are allowed, like tif, bmp, jpg, png... No error message, if the application crashes with "memory error" than > wrong format)
- OUTPUT will be written into the source texture folder (bmp with alpha channel)
- I try to convert it into DDS (DXT5, mip, flipped vertically), but i don't know yet why, it doesn't work with every image.... For all my textures it works fine, when a try to take random jpg, it won't..
So, i do not delete the intermediate bmp. Naming will be like this (i simply add a suffix):

Asphalt10_2x2_1K_normal.tif_normalConverted.Bmp.dds
CliffLayered_4K_albedo.tif_metalmaps_combined.bmp

!! WAIT !! while showing "please wait"!!! 4096x4096 can take.. as well as the dds conversion also will take some seconds, like usually



View attachment 50298View attachment 50297

Thank you for making this software. It helped me.

 

[RicherSims]

Thank you for this project!
Is it still active? If so, I have a feature request.
Would it be possible to add a batch feature: one where it scans for multiple textures with different suffixes (_Metallic, _Ambient-Occlusion, _Smoothness/_Roughness, _Normal) and automatically creates multiple combined BMP/PNGs?
Of less importance would be an option to place these images in different channels. For example XPlane uses R+G=X+Y of normal map, B=Metallic, A=Roughness; while for P3D/MSFS R=Metallic, G=Ambient Occlusion, B=empty, A=Smoothness.

 

[=rk=]

for P3D/MSFS R=Metallic, G=Ambient Occlusion, B=empty, A=Smoothness.

The PBR schema for MSFS is:
R= AO
G= Roughness
B=Metalness (gloss)

 

[RicherSims]

The PBR schema for MSFS is:
R= AO
G= Roughness
B=Metalness (gloss)

Another change! Thank you for the correction. It can get difficult to keep track when combining maps for 3 separate platforms. Even more need for this option.

I managed to code a quick tool last night based on the trial version of a library, but it leaves watermark in the output image. I'm looking for a free alternative, otherwise I may have to fork out a couple hundred USD just to make this work easier witch batch processing.

 

[=rk=]

Seems like you could write an algorithm to make your images 20% taller, run them through the editor and then crop that 20% off again...

 

[RicherSims]

@=rk= Love that idea. Will try it out.

EDIT: Work's perfectly. Can't believe I didn't think of that. Sometimes the simplest solutions really do escape you.