Hard Light Productions Forums
Modding, Mission Design, and Coding => The Modding Workshop => Topic started by: Scooby_Doo on February 10, 2009, 10:36:22 pm
-
I ran into a rather annoying issue with DDS, DXT5_nm to be precise. When a normal map is compressed it processes some very nasty artifacts that I can't seem to get rid of them. Panel lines that are diagonal produce some nasty aliasing thats very noticeable ingame ruining my texturing work :(. Photoshop's plugin, nvcompress and even Compressonator produce the same results. The only DDS format I found not to produce as noticeable errors is Compressonator's D3D10 BC5 format.
Are there any other image formats supported for normal maps? Keldor suggested png support, but neither it nor tga seem to work.
Heres an example:
(http://i74.photobucket.com/albums/i270/Skaarj_Saga/compress_errors.jpg)
-
I'm not entirely sure, but I think u8888 (uncompressed) may be supported for normal maps.
-
I've already tried u8888 (ARGB) and doesn't seem to accept it. (no normal map detail is shown ingame). It does however produce a clean normal map.
-
For u8888 to work, you must copy the NM output Red Channel to the Alpha Channel.
Then color Red and Blue channels solid black.
Then save as u8888.
-
For u8888 to work, you must copy the NM output Red Channel to the Alpha Channel.
Then color Red and Blue channels solid black.
Then save as u8888.
Thanks!!! That works, now I'll just script it :)
Edit: Is it possible to do this before creating the orignal dds file?
double edit: nevermind, answered that one myself, yes, just add a alpha channel to the orignal map.
-
i wish fs supported 88VU or 88AL formats for normal maps. be a lot better than wasting a bunch of 8 bit channels. video cards have such ridiculously large amounts of memory now. as games started using dxt1 and 5 en masse i noticed a lot of washed out color. when it comes right down to it dxt compression is just an upsampled 565 format. while i have no problem using dxt1 for a diffuse texture, the development of dxt5_nm as a texture format was more of a cheap hack of a format than an acceptable solution (i blame john carmack, lol). seems since that format was established texture memory on the average video card has doubled.
im also looking at this format (http://en.wikipedia.org/wiki/3Dc), supposidly its the same size as dxt5, but stores the "colors" (and by that i mean uv data) as 8 bit rather than is a 6 and 8 bit respectively (dxt5_nm). essentially all it does is compress both chanels in the same way dxt5 compresses its alpha.
another thing you might want to try, is to copy the green channel to red and blue, or make red and blue 50% grey instead of black. it might remove thr artifacts while keeping the benifits of a compressed texture. only 2 rgb (565 mind you) colors get stored for each pixel block, more color divergance (resulting from red and blue being 0) might result in the converter calculating darker than required color samples for the 2 interpolated colors, causing the normals to lean one way or the other when the 2 bit clor table tells em to use an intrepolated color.
-
Actually 3dc also suffers from compression issues too.
Also sorry neither of those tricks seemed to help, aliasing is still there, unless I did something really wrong.
-
all compression formats are gonna suffer compression issues no matter how use slice it. 3dc is just taking the idea behind dxt5_nm and improving it, slightly, in that the horizontal channel has the same bit depth as the vertical. but heres the kicker, if fs2 supports a 2 chanel format for normal maps, then you would have the choice between 3dc and uncompressed 88.
you know if i were to have to choose between dxt5_nm and 8888 id probibly pick the former and double the resolution. since the compression ratio is 4:1 if you use dxt5. you might consider doubling the resolution of the image and going with the compressed format.
-
Also take a look at D3D10 BC5 format. It produces a very nice end result and about the same size as DXT5 and 3DC.
-
bc5 is technically the same as 3dc, from wht ive read :D
if youre gonna go with 8888, it would be better to use one of the 32 bit 2 channel floating point formats.
-
bc5 is technically the same as 3dc, from wht ive read :D
if youre gonna go with 8888, it would be better to use one of the 32 bit 2 channel floating point formats.
Oh, I can't seem to read 3DC files, infraview doesn't support it.
-
well the headers are probably different :D
bc5 is the newer standardized version of the format.
i actually find it amusing that nvidia tools call it by ati's name, while ati tools call it by m$'s name