[Dragon]

I've recently been working with a number if very dark textures, which needed to be made grayscale, or close to it (for team colors, mostly). It turns out that DDS compression sucks at saving this kind of textures, resulting in hideously ugly green and purple dots littering the texture. Otherwise pretty shinemaps get hit especially hard. Not using compression is not a good idea, because the textures then balloon to a ridiculous sizes, especially shinemaps. Did any of you deal with this such artifacts before? What's the best way of getting rid of them?

[MatthTheGeek]

What do you use to export to DDS ? Depending on the software, you may have more or less detailed compression settings available.

As a general advice (you may already know about it), use DXT1 for non-alpha textures and either DTX3 or DXT5 for alpha textures.

Other people can probably enlighten you more.

[Dragon]

Forgot to mention, I'm using GIMP DDS plugin. Neither of the DXT compression formats changes anything about the artifacts, they're identical in all three cases.

[MatthTheGeek]

well there's your problem. You might want to try exporting to something lossless from GIMP first then back to DDS with a better converter, like the nvidia command line one (cba to get a link, just google it).

[Kobrar44]

I propose decomposing the picture AFTER saving into RGB [RGBa] and either saving the red channel alone as grey map or playing with layers in whatever way you develope[maybe several times]. Experiment.

The original before compression [already crap]:

First DXT1 compression:

Compresed red channel from the above one:

Yet again compressed red channel from the above one [WARNING: second iteration!]:


It looks crap[but compression is always crap], but is almost grey.

GIMP exporter used.

[MetalDestroyer]

Try with Paint .NET

[Dragon]

Is the filesize normal? Also, I wouldn't want too many iterations. Oh, and it can't be a greyscale DDS, because they don't work in FS (tried that already). Also, the map isn't only grays and blacks, it has some colors as well. Whatever method I use needs to preserve them.

I'll check out Paint .NET, maybe it'll help.

[FreeSpaceFreak]

Yeah, the GIMP plugin is not so great at saving DDS files - only useful for opening them. When it comes to DDS compression, NVDXT has always done a fine job in my experience - don't know about Paint.NET.

[The E]

As far as I can tell, Paint.Net does a much better job at preserving the colours.

[attachment deleted by ninja]

[fightermedic]

didn't know gimp's plugin is so much worse than paint.net
i tink i'm going to use that one instead, thanks for the info

[Fury]

I see no reason to use anything but nvdxt to generate dds files.
http://www.hard-light.net/forums/index.php?topic=64769.msg1279126#msg1279126

[Black Wolf]

I see no reason to use anything but nvdxt to generate dds files.
http://www.hard-light.net/forums/index.php?topic=64769.msg1279126#msg1279126

Bugger that. GUI 4 LYFE.

And yeah, you can use Paint.net to export uncompressed DDS. I think it's 8888 or something like that (I.e. 8 bit RGB and Alpha channels).

[Dragon]

And yeah, you can use Paint.net to export uncompressed DDS. I think it's 8888 or something like that (I.e. 8 bit RGB and Alpha channels).

You can use GIMP for that, too, and they will be good. But I want compressed, and that's the problem. I haven't checked Paint.net yet (need for free up HD space), but I will.

[Herra Tohtori]

This is what happens when you use tools that obfuscate useful options, such as compression quality.

It's the same as exporting images to JPG or PNG using MS Paint. It sort of works but you lose quite a bit of control over the actual quality.


Also consider this - when DXT compression is used, the algorithm checks for differences in the colour channels and those can affect what ends up being in the final product. This is the main reason why, when converting normal map to DXT5nm mode, you have to make sure that the Red, Green and Blue channels are either filled with identical channel information, or alternatively the Green channel has information and Red and Blue are filled with black (zeroes). If there's different information in Red and Blue channels it will affect the contents of the Green channel. Similar properties of the DXT compression can cause this kind of colouration in a low-saturation image.

If you desaturate the texture so that all colour channels (red, green and blue) have the exact same information, you should end up with a cleaner grey end result, but you really should use a DDS export utility that allows you to set options such as compression quality, MIP map filtering options, number of MIP maps if relevant, etc.

In some instances, I seem to recall that FSO actually doesn't use MIP maps, so keeping MIP maps on the textures is just unnecessary file size ballast. And in other cases, the MIP maps are just plain unnecessary - one such case would be skyboxes. Or you might want to just include two LOD's - the 1:1 size and 1:2 size MIP map layers.

NVidia's command line texture utility is excellent and, for anyone even remotely familiar with command line operation (regular expressions and such), the batch operations are better than I've seen with any of the other programs that export DDS (Adobe DDS plugin, GIMP DDS plugin). Haven't personally tried Paint.NET DDS export, and I'm not sure if IrfanView supports DDS exports, but for me, the command line tools just work the best.

In addition to the good old nvDXT which works anywhere, NVidia also has something like DDS Texture Tools (don't recall the name exactly) which is also a command line utility, but uses GPU power to achieve much lower conversion times. The command line syntax is a bit different and I think you need an NVidia graphics card (which would be quite obvious), but the few times I tried it, it was blazingly fast.

Being more comfortable with the nvDXT, I've stuck to it for now however. And it doesn't require NVidia graphics card to work.

[Fury]

In some instances, I seem to recall that FSO actually doesn't use MIP maps

Perhaps you're referring to FSO's mipmaps command line option? That was used to generate mipmaps on maps that did not have them, but since all maps where mipmaps are useful should have mipmaps this day and age, the option was moved to under troubleshooting (iirc). FSO not using mipmaps at all doesn't make any sense. Different question is on which maps mipmaps are not needed, a question I don't know an answer to.

[MatthTheGeek]

I think Herra meant that FSO doesn't use mipmaps in all circumstances.

I think for example skyboxes don't mipmap, but I might be wrong.

[Herra Tohtori]

Not sure if skyboxes do or don't use mip maps, but I definitely recall DaBrain saying in the past that effects (like weapon sprites or explosion shockwaves) don't use mip maps.

Which always seemed a bit strange to me, but I don't know enough of the engine workings to say anything about whether they do or don't.


Just a personal input; skyboxes would actually benefit from MIP maps in the sense that they would then be more easily used at variable field of view. A very high resolution skybox is good for a narrow field of view, a "zoomed in" view, if you will. Some people use narrow field of view as a preference, and I think I've seen it used in a few occasions in cutscenes. However, the same high-resolution skybox would result in aliasing (twinkling stars) at lower resolutions which are more generally used.

Having two LODs on the texture would make it possible to use same skybox for both wide and narrow FOV (display resolution also has effect on this, of course).