Texture compression comparisons

[safemode]

This thread will be about what textures get compressed by nvidia, which get compressed by some other compressor. It only deals with textures that should end up bing shipped as dds files.

Whenever a texture is to be replaced in svn by some other copy it should be compressed in the correct format (DXT1 for non-alpha textures,etc), and the sample image showing how the replacement texture is better should be posted side-by-side with the current svn one.

Like this for instance.
http://signal-lost.homeip.net/images/bl ... arison.png

This shows that the replacement texture is better than the svn head texture, so it should get committed, and it did.

Though, future comparisons will have only two samples like this one

http://signal-lost.homeip.net/images/wa ... arison.png

This illustrates that the current svn is superior to the nvidia version, and thus will not be replaced.

You dont need to post comparisons where the replacement is worse than the svn head, as it would not be committed. But those textures that you wish to get committed should be posted in comparison form.

The replacement of certain textures with a dds file is going to be hit and miss for a while as there are so many different compressors both hardware and software, It will likely take a while before the best version of a dds texture is found, but that's the ideal goal

[loki1950]

Can't get past the portal page on the first link safemode the second works ok.

Enjoy the Choice

[charlieg]

Can't get past the portal page on the first link safemode the second works ok.

Enjoy the Choice

He mispelled homeip. Fixed link:
http://signal-lost.homeip.net/images/bl ... arison.png

[loki1950]

Thx charlieg i didn't look that closely

Enjoy the Choice

[DualJoe]

I find it very difficult to judge the quality of compression on these examples, without the original uncompressed ones.

Couldn't you just load the different versions in Gimp and do a substract of difference with the original to see which compression gave the best results?

[safemode]

like most lossy formats, more difference from the original doesn't equal worse quality. Take mp3 for instance, you can keep it much more close to the original if you want, that involves including all frequencies, but if you do, you get nasty ringing, removing them yields a better quality output. The same is true for images. Simply trying to remain as close to the original as possible doesn't necessarily yield a better image.

In the future, i will include the original as well.

The fact that you find it so hard to decide which is better is good. You need to view these images at 100% or more. It's really all about deciding which one looks noisier than the other. I've found that in the explosion textures the gimp-dds compressed files using hardware compression yields a smoother less blocky output than the nvidia software compressed ones.

[Madawg]

DXT5 will always give a better visual result but the file will be heavier than DXT1 which is indeed very lossy.
The other advantage of DXT5 is that it supports 8bit alpha channel (256 values of grey) while DXT1 only uses 1bit alpha, DXT3 is somewhere in between.
If you're looking for optimization, it would be nice to chose the compression depending on the nature of the image.
But if you're looking for best visual result, DXT5 with the ATI 3Dc compression algorithm i've found after a lot of researches. (but I haven't had time yet to test the DX10 compression, too much things to do at work).
Another trick we often use in the game indutry for better visual quality is using xBGR DTX5 for normal maps. This means we copy the content of the red channel to the alpha one and leave the the red channel black. We do this because the compression is less destructive on the alpha than on the color channels. (compression artifacts on a normal map can have a pretty big impact on the visual aspect)

[hellcatv]

madawg: we're doing the same DXT5 trick for normal maps, at least for now

[Madawg]

madawg: we're doing the same DXT5 trick for normal maps, at least for now

For now? You're tickling my curiosity there
Do you have a new technique in view?

I didn't mean to be a smart-ass or anything of this kind but I'm pretty used to all that kind of stuff and I'd like to be helpful as much as I can.

Unfortunately, I don't really have time to really make complete models and textures for you (I'm also working on a personal project) but I'd like to contribute at least a little bit if possible. So I tought that giving advices and sharing what I learned during all these years was a good way to do it...

PS: for all your artists, if you want to make xBGR normal maps and don't want to do the swapping manually (or if you don't know how/want to script it), there's this great tool from ATI/AMD that allows you to batch the process on multiple images at a time. It's called "The Compressonator" and it's available for free on ATI/AMD's website.

[hellcatv]

we actually also have a tool that converts rgb normalmaps into
0gba normal maps. it's in our bin directory and it's called normal_map.exe

(where 0 is black)


the trick that chuck_starchaser has been advocating is to use the alpha channel of one texture (like glow map) for du and another texture (like damage map) for dv

that way you get some compression, but it still looks good

it's a reasonable idea--but we haven't gone about standardizing it yet for artwork

[DualJoe]

There's a whole new artwork-pipeline being developed which complicate things a bit.

ChuckStarchaser made a post about the "current" new packaging and channel swizzle trick.

http://vegastrike.sourceforge.net/forum ... php?t=9346

The plan is to create a toolchain which will speed up texturing enormously, dramatically improve texture quailty and at the same time reduce the source file-sizes more than tenfold.
Chuck also explained the concept in one of safemode's threads (Can't find it right now, but I thought it was about storage of the original source files and a separate storage for the dds-versions)
The crux at the moment is what kind of shaders will be implemented in Vegastrike.

On top of that we want the artwork and toolchain to be able to survive the planned future Ogre3d-engine port.

We're planning to document and share this toolchain on the vegastrike wiki, so that other mods can benefit as well.

It's taking some time, because we have to generate completely new artwork first, including new models.
The original models we're working on were horrible and pretty much useless (no welding at all, floating geometry covering large parts of the model, big multiple textures for a single small ship with a lot of wasted uv-space per texture etcetera). The models nearing completion, but the toolchain including shaders takes some time as well.

I made a proof of concept with my Hornet-model and also posted it on this board somewhere (I don't remember where though). It's just to show that it works, but the new toolchain we're developing will be more generic and should be easy to use for everyone.

[safemode]

The only hesitation i would have to that is if there isn't a crossplatform open program to read in those files and generate the textures used to create the DDS files in the game data directory.

Basically, If at some point in the future, all the win32 guys left, there would be no way to read in the special blender source files and the project would be screwed.

Any source / master type file really should be made into a format that is not platform specific and not only readable by a propriatary program. If these blender source files fit that description, then fine...otherwise i only see trouble down the road.

[DualJoe]

Where did you get the impression that Blender doesn't work on win32?

Blender runs on more operating systems than Vegastrike does and is GPL.

EDIT
I can't think of a program better suited for the toolchain than blender.
xcf-files are much more problematic, because of the huge file-sizes and because the Gimp doesn't work for a lot of win32-people.

EDIT2
The source-files for the texture-processor will not be in a proprietary format, nor will the end-result.

[Moe479]

gimp2 work very fine under win32, okay the splittet toolwindow from the workspace appers somewhat strange to windows-children like me, but beside that and the long loadingtime at programmstart i use it more and more ... my 'old' corel 10 isnt capable of saving dxtx compressed files .. gimp2 with the proper plugin will do that exelent!

blender works also but i can't get things as fast done as in my aged lw7 modeler+unwrap3d, maybe i just need to toy around for a while to get things done faster ... but for now its as horrible as wings for me ^^