Texture compression comparisons
Moderator: pyramid
-
- Developer
- Posts: 2150
- Joined: Mon Apr 23, 2007 1:17 am
- Location: Pennsylvania
- Contact:
Texture compression comparisons
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
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
Last edited by safemode on Fri Aug 24, 2007 11:17 pm, edited 1 time in total.
-
- The Shepherd
- Posts: 5841
- Joined: Fri May 13, 2005 8:37 pm
- Location: Ottawa
- Contact:
Can't get past the portal page on the first link safemode the second works ok.
Enjoy the Choice
Enjoy the Choice
my box::HP Envy i5-6400 @2Q70GHzx4 8 Gb ram/1 Tb(Win10 64)/3 Tb Mint 19.2/GTX745 4Gb acer S243HL K222HQL
Q8200/Asus P5QDLX/8 Gb ram/WD 2Tb 2-500 G HD/GF GT640 2Gb Mint 17.3 64 bit Win 10 32 bit acer and Lenovo ideapad 320-15ARB Win 10/Mint 19.2
Q8200/Asus P5QDLX/8 Gb ram/WD 2Tb 2-500 G HD/GF GT640 2Gb Mint 17.3 64 bit Win 10 32 bit acer and Lenovo ideapad 320-15ARB Win 10/Mint 19.2
-
- Elite Mercenary
- Posts: 1329
- Joined: Thu Mar 27, 2003 11:51 pm
- Location: Manchester, UK
- Contact:
He mispelled homeip. Fixed link:loki1950 wrote:Can't get past the portal page on the first link safemode the second works ok.
Enjoy the Choice
http://signal-lost.homeip.net/images/bl ... arison.png
Free Gamer - free software games compendium and commentary!
FreeGameDev forum - open source game development community
FreeGameDev forum - open source game development community
-
- The Shepherd
- Posts: 5841
- Joined: Fri May 13, 2005 8:37 pm
- Location: Ottawa
- Contact:
Thx charlieg i didn't look that closely
Enjoy the Choice
Enjoy the Choice
my box::HP Envy i5-6400 @2Q70GHzx4 8 Gb ram/1 Tb(Win10 64)/3 Tb Mint 19.2/GTX745 4Gb acer S243HL K222HQL
Q8200/Asus P5QDLX/8 Gb ram/WD 2Tb 2-500 G HD/GF GT640 2Gb Mint 17.3 64 bit Win 10 32 bit acer and Lenovo ideapad 320-15ARB Win 10/Mint 19.2
Q8200/Asus P5QDLX/8 Gb ram/WD 2Tb 2-500 G HD/GF GT640 2Gb Mint 17.3 64 bit Win 10 32 bit acer and Lenovo ideapad 320-15ARB Win 10/Mint 19.2
-
- ISO Party Member
- Posts: 387
- Joined: Tue Mar 21, 2006 2:37 pm
- Location: Netherlands
- Contact:
-
- Developer
- Posts: 2150
- Joined: Mon Apr 23, 2007 1:17 am
- Location: Pennsylvania
- Contact:
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.
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.
-
- Explorer
- Posts: 9
- Joined: Tue Jul 22, 2003 9:41 pm
- Location: Belgium
- Contact:
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)
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)
-
- Developer
- Posts: 3980
- Joined: Fri Jan 03, 2003 4:53 am
- Location: Stanford, CA
- Contact:
madawg: we're doing the same DXT5 trick for normal maps, at least for now
Vega Strike Lead Developer
http://vegastrike.sourceforge.net/
http://vegastrike.sourceforge.net/
-
- Explorer
- Posts: 9
- Joined: Tue Jul 22, 2003 9:41 pm
- Location: Belgium
- Contact:
For now? You're tickling my curiosity therehellcatv wrote:madawg: we're doing the same DXT5 trick for normal maps, at least for now
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.
-
- Developer
- Posts: 3980
- Joined: Fri Jan 03, 2003 4:53 am
- Location: Stanford, CA
- Contact:
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
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
Vega Strike Lead Developer
http://vegastrike.sourceforge.net/
http://vegastrike.sourceforge.net/
-
- ISO Party Member
- Posts: 387
- Joined: Tue Mar 21, 2006 2:37 pm
- Location: Netherlands
- Contact:
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.
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.
-
- Developer
- Posts: 2150
- Joined: Mon Apr 23, 2007 1:17 am
- Location: Pennsylvania
- Contact:
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.
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.
-
- ISO Party Member
- Posts: 387
- Joined: Tue Mar 21, 2006 2:37 pm
- Location: Netherlands
- Contact:
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.
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.
-
- Merchant
- Posts: 57
- Joined: Wed Jan 24, 2007 7:13 am
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 ^^
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 ^^