[Water]

A simple way of converting the green dxt5nm maps back to the blue version. The original conversion process throws away the blue channel, this just recalculates the blue and swaps the channels back.

The formula I found for it is z = sqrt(1-x²-y²)  If there is a better way, let me know.

The MathMap filter for the Gimp has the ability to run formulas. http://www.complang.tuwien.ac.at/schani/mathmap/
It includes a lot of other stuff as well.

Once it's installed it's found under generic for some reason.


The Expression tab can be used to run formulas, which is what we're after.

filter dxt5nm (image in)
    p=in(xy);
    rgbaColor(alpha(p),green(p),sqrt(1-((alpha(p)*alpha(p))-(green(p)*green(p)))),1)
end



Just paste that in. Save as dxt5nm-blue or something.
Click preview.

[redsniper]

So... what? We can use this to reverse engineer normal map?

[Water]

So... what? We can use this to reverse engineer normal map?

If you want to put a ship in Blender etc with standard blue normal maps then yes.

[Herra Tohtori]

Just making the blue channel white should work as well, though not quite as well.

In RGB normal maps, red and green channel are used to store U and V normals information, while blue channel stores an elevation data map of a sort. In more sophisticated normal map rendering, this elevation data is used as well as the actual normals information, while FS2_Open and most games only use the actual normals information on the model geometry.

At least as far as I know.

A working conversion of normal map back to height map would be fairly useful anyway, and I can probably think of some uses for this sort of plugin... thanks for the link!

[DaBrain]

What I do in Photoshop:

-Copy the alpha channel into the red channel
-Make the blue channel white
-Use the Nividia tools to normalize the result


Your red channel will still suffer from the lossy DXT5 compression... so avoid compressing this map again if you can.

[Scooby_Doo]

Correct, avoid compression normal maps unless absolutely needed.  A lower-res uncompressed will look better than a high-res compressed.

[DaBrain]

No, that's not what I ment.


A higher-res DXT5nm map will look better than a smaller uncompressed map in most cases.
I don't know any game that still uses uncompressed normal maps anymore.
Games that come with uncompressed normal map use real-time compression.

It's not only about space, but also about speed:

On today's graphics hardware, normal maps can also be stored in several compressed formats, that are decompressed in real-time during rendering. Compressed normal maps do not only require significantly less memory on the graphics card, but also generally render faster than uncompressed normal maps, due to reduced bandwidth requirements.

Source:
http://developer.nvidia.com/object/real-time-normal-map-dxt-compression.html


Although the A8L8 and V8U8 formats would be a pretty good alternative.


What I actually ment in my prior posting was:
Don't open compressed maps and compress them again! Always keep the uncompressed file and use that one if you have to make changes.

[Herra Tohtori]

Don't open compressed maps and compress them again! Always keep the uncompressed file and use that one if you have to make changes.

Quoted for the everlasting truth.

[Nuke]

you really shouldnt do this because you would just ind up stacking compression artifacts.its better to keep uncompressed source bitmaps around whenever possible.

[Water]

you really shouldnt do this because you would just ind up stacking compression artifacts.its better to keep uncompressed source bitmaps around whenever possible.

True, if you have access to the uncompressed version. Blender can't use dxt5nm, and this does the conversion with one operation. I think we all agree that a format change from say jpg to tga doesn't make the existing compression go away.

[Scooby_Doo]

No, that's not what I ment.


A higher-res DXT5nm map will look better than a smaller uncompressed map in most cases.
I don't know any game that still uses uncompressed normal maps anymore.
Games that come with uncompressed normal map use real-time compression.

It's not only about space, but also about speed:

On today's graphics hardware, normal maps can also be stored in several compressed formats, that are decompressed in real-time during rendering. Compressed normal maps do not only require significantly less memory on the graphics card, but also generally render faster than uncompressed normal maps, due to reduced bandwidth requirements.

Source:
http://developer.nvidia.com/object/real-time-normal-map-dxt-compression.html


Although the A8L8 and V8U8 formats would be a pretty good alternative.


What I actually ment in my prior posting was:
Don't open compressed maps and compress them again! Always keep the uncompressed file and use that one if you have to make changes.

I'm not sure, but I think we (saga) went with uncompressed 8-8-8-8 dxt for the normal maps, the compressed versions produced too many artifacts that messed up the texture.

[Water]

I'm not sure, but I think we (saga) went with uncompressed 8-8-8-8 dxt for the normal maps, the compressed versions produced too many artifacts that messed up the texture.

Have you tried using 3Dc/BC5 compression?

[Scooby_Doo]

I'm not sure... we did try several out and they all produced aliasing.

[DaBrain]

Well... using compressed normal maps is the industry standard for a reason.

If you want to go for a very unique style (maybe a special cell-shaded look) using uncompressed, smaller normal maps might look better.
I don't mind the artifacts for getting four times the resolution. If the pixel² per meter is high enough, the artifacts will be very small anyway. On rough surfaces, they don't even matter at all.


3Dc would be pretty nice, but some older chips do not support it and I have no idea about Intel chips at all...
BC5 isn't supported by FSO. The OpenGL extension would have to be added.

[Water]

3Dc would be pretty nice, but some older chips do not support it and I have no idea about Intel chips at all...
BC5 isn't supported by FSO. The OpenGL extension would have to be added.

Just did some checking. it turns out BC5 is another name for 3Dc in directx 10.