Texture formats - why tga?
Moderators: MR.D, Moderators
-
LathanStanley
- Posts: 1429
- Joined: 20 Jun 2005, 05:16
PNG would be my choice on textures... (I'm anal with detail) but a dds, if done correctly, can be beneficial...giving approx 10-15% loss in image quality for a 10% increase in performance.. (if you are hitting memory limits)...
but to do the "editing" required to make a dds useful... you have to have ALOT more pixels on each face than it allready has..
a dds file breaks an image into 4x4 blocks of pixels all sharing 2 of the 3 color attributes.. and as they overlap, the 3rd value changes with the other two making an oscilloscope of colors that overlap to "re-create" the origional colors to a "close" extent.
the format isn't perfect, it has its good places to be used, and its bad.
when gradients, or smooth transitioning colors are used on an object, be it any part of it in any direction, dds will create "banding" issues that TERRIBLY detrement the piece without planned alteration beforehand. I.E. adding noize.
also, SHARP lines and contrast in colors is near impossible to do with dds, it blends them all over 4x4 area's and bleeds the results (why I disliked them the most, my textures were VERY detailed)
then, post dds comparisons, dds tends to push textures towards green and red, (greys will NOT be grey, but slightly different etc.) and that takes a filter mask, and gradient/noize applications to "trick" the compressor into using grey, instead of near-grey.. etc.
basically... I'll find time eventually to get them to a dds properlly.. heck, maybe even write a vbasic script with photochop to do it for me... but for now, they are TGA's and I'd reccomend using PNG's for the compression ratio.. dds "can" be better.. but it takes ALOT of work to make it "right"...
running them through a simple DX1 compression isn't gonna cut it right..
link to source of information I drew this conclusion from:
http://www.gamasutra.com/features/20051 ... e_01.shtml
but to do the "editing" required to make a dds useful... you have to have ALOT more pixels on each face than it allready has..
a dds file breaks an image into 4x4 blocks of pixels all sharing 2 of the 3 color attributes.. and as they overlap, the 3rd value changes with the other two making an oscilloscope of colors that overlap to "re-create" the origional colors to a "close" extent.
the format isn't perfect, it has its good places to be used, and its bad.
when gradients, or smooth transitioning colors are used on an object, be it any part of it in any direction, dds will create "banding" issues that TERRIBLY detrement the piece without planned alteration beforehand. I.E. adding noize.
also, SHARP lines and contrast in colors is near impossible to do with dds, it blends them all over 4x4 area's and bleeds the results (why I disliked them the most, my textures were VERY detailed)
then, post dds comparisons, dds tends to push textures towards green and red, (greys will NOT be grey, but slightly different etc.) and that takes a filter mask, and gradient/noize applications to "trick" the compressor into using grey, instead of near-grey.. etc.
basically... I'll find time eventually to get them to a dds properlly.. heck, maybe even write a vbasic script with photochop to do it for me... but for now, they are TGA's and I'd reccomend using PNG's for the compression ratio.. dds "can" be better.. but it takes ALOT of work to make it "right"...
running them through a simple DX1 compression isn't gonna cut it right..
link to source of information I drew this conclusion from:
http://www.gamasutra.com/features/20051 ... e_01.shtml
-
SwiftSpear
- Classic Community Lead
- Posts: 7287
- Joined: 12 Aug 2005, 09:29
Isn't there other compressions formats up to DX5 with DDS? Or are those even worse quality then DX1? Either way, based on those images I don't think the degrading of quality is bad enough that it shouldn't be used for in game textures. I mean compared to an FPS here you rarely are right up in the texture, the performance loss is more destructive then the slight quality loss.
-
LathanStanley
- Posts: 1429
- Joined: 20 Jun 2005, 05:16
considering what I read, learned, etc.
I've decided to try a few tests tomorrow at home when I get back to my tower... (I'm still at work)
I'm planning on increasing the texture sizes by 4.. 2x on the height, and 2x on the width...
then applying a DX1 compression in a dds format (4x4) blocks.. it will reduce the image size by 4 then compare it to the origional (though it has size differences.. the palette is smaller, and thus the file smaller, yet the detail will be 90%+ retained..) I'll compare a red area, green area, blue, yellow, orange, etc.. and apply filter masks to "match" the colors better UNIVERSALLY across the image (after a SECOND DX1 pass, planning ahead), as to not add any new palette colors...
after its colors are "matched" I'll convert the file back to a png or bmp, and scale it back to its standard size... without aniscropic filtering.. (thus it will not BLEND anything, only chop pixels.. I'm hoping the effect isn't too terrible) and after its back to its origional size, on a more "blocky" and "unified" texture pallete, I'll then apply a VERY mild noize to the majority of the image where detail isn't present to prevent extreme banding (how? dunno yet...) ...
after that editing... I'll take the "modied and prepared" BMP or TGA and compress it back to dds. It "should" then have a VERY compareable detail level, color quality, and the such, without random bleeds and artifiacts.. or at least reduced amounts significantly..
the overall texture will suffer somewhat... it will blur slightly.. and it will lose some of the pixel to pixel detail.. (some of the minor cracks and scratches).. but on the other hand, it might cover up a mistake or two...
in the long run, when I re-compress it to dds the second time, the filesize should be VERY compareable to ARGH's (sorry I jumped on you SO hard... the dds format is useable, I just saw that you cut the resolution by 1/2 and the colors were way different.. and it was quite fugly to me) but contray to what argh did.. I'll maintain the higher resolution... (you can STILL reduce it as a mapper if you feel the need to) I only hope that you don't put THAT many of these features on the maps.. I mean c'mon 100+ of like the big tyranid towers?? they are no longer "cool" when they are like "super-common" lol
but yeah... in all regards, the filesize is gonna be smaller (guessing about 1/2 to 1/3 size) the resolution, the same and the texture quality reduced by about 10-15%...
it will use less texture memory on your videocard to load the textures than TGA (simply because TGA, PNG, etc. are all hardware compressed as the card loads them), the textures will LOOK the same in-game at normal and far distances (hopefully).. very close distances.. will look bad.., but don't expect any better FPS... just the ability to load MORE of them on a lower end videocard..
we'll see what happens.
god I hope I don't eat my own words and have to feel like a jackass jumpin on Argh like I did...
One Question though:
I still don't see any use for "included mip-mapping" in spring though... I've never seen the engine use it... maybe its cause I have an ATI card? meh, I dunno... (yes I know what mip mapping is, and what anti-aliasing does to make it pretty.. IE, pattern textures like grated floors on doom 3... when you are running a texture compression... anything but Ultra Quality...)... is there any purpose to consider what the mipmaps will do in the dds with spring?? or is that just something I can ignore??
I've decided to try a few tests tomorrow at home when I get back to my tower... (I'm still at work)
I'm planning on increasing the texture sizes by 4.. 2x on the height, and 2x on the width...
then applying a DX1 compression in a dds format (4x4) blocks.. it will reduce the image size by 4 then compare it to the origional (though it has size differences.. the palette is smaller, and thus the file smaller, yet the detail will be 90%+ retained..) I'll compare a red area, green area, blue, yellow, orange, etc.. and apply filter masks to "match" the colors better UNIVERSALLY across the image (after a SECOND DX1 pass, planning ahead), as to not add any new palette colors...
after its colors are "matched" I'll convert the file back to a png or bmp, and scale it back to its standard size... without aniscropic filtering.. (thus it will not BLEND anything, only chop pixels.. I'm hoping the effect isn't too terrible) and after its back to its origional size, on a more "blocky" and "unified" texture pallete, I'll then apply a VERY mild noize to the majority of the image where detail isn't present to prevent extreme banding (how? dunno yet...) ...
after that editing... I'll take the "modied and prepared" BMP or TGA and compress it back to dds. It "should" then have a VERY compareable detail level, color quality, and the such, without random bleeds and artifiacts.. or at least reduced amounts significantly..
the overall texture will suffer somewhat... it will blur slightly.. and it will lose some of the pixel to pixel detail.. (some of the minor cracks and scratches).. but on the other hand, it might cover up a mistake or two...
in the long run, when I re-compress it to dds the second time, the filesize should be VERY compareable to ARGH's (sorry I jumped on you SO hard... the dds format is useable, I just saw that you cut the resolution by 1/2 and the colors were way different.. and it was quite fugly to me) but contray to what argh did.. I'll maintain the higher resolution... (you can STILL reduce it as a mapper if you feel the need to) I only hope that you don't put THAT many of these features on the maps.. I mean c'mon 100+ of like the big tyranid towers?? they are no longer "cool" when they are like "super-common" lol
but yeah... in all regards, the filesize is gonna be smaller (guessing about 1/2 to 1/3 size) the resolution, the same and the texture quality reduced by about 10-15%...it will use less texture memory on your videocard to load the textures than TGA (simply because TGA, PNG, etc. are all hardware compressed as the card loads them), the textures will LOOK the same in-game at normal and far distances (hopefully).. very close distances.. will look bad.., but don't expect any better FPS... just the ability to load MORE of them on a lower end videocard..
we'll see what happens.
god I hope I don't eat my own words and have to feel like a jackass jumpin on Argh like I did...
One Question though:
I still don't see any use for "included mip-mapping" in spring though... I've never seen the engine use it... maybe its cause I have an ATI card? meh, I dunno... (yes I know what mip mapping is, and what anti-aliasing does to make it pretty.. IE, pattern textures like grated floors on doom 3... when you are running a texture compression... anything but Ultra Quality...)... is there any purpose to consider what the mipmaps will do in the dds with spring?? or is that just something I can ignore??
-
LathanStanley
- Posts: 1429
- Joined: 20 Jun 2005, 05:16
yes, there are multiple DX compression formats.. but the DX1 is the STRONGEST and the most beneficial..SwiftSpear wrote:Isn't there other compressions formats up to DX5 with DDS? Or are those even worse quality then DX1? Either way, based on those images I don't think the degrading of quality is bad enough that it shouldn't be used for in game textures. I mean compared to an FPS here you rarely are right up in the texture, the performance loss is more destructive then the slight quality loss.
the others, are such a SMALL increase in anything, they are pretty.. worthless.. unless you REALLY wanna try to squeeze out 1 more frame per minute!!
With DDS, it mainly matters how you have your compression set up, what format you're using, and how much value you're placing over exact detail vs. "good enough". As a practical thing, cutting down on download bandwidth is a real consideration, for example, and then there's the savings on performance. 10% is a very, very large number when you're at full load in Spring- frames are getting eaten left and right by the CPU side of things, and cutting down on the visuals whereever it's practical is a real must.
In my experience, if you want maximum clarity of details and colors, with the sharpest preservation of tones, then use DDS DXT3. DDS DXT1 is ok for things like simple color-channel stuff, like the glow/reflective maps on a Spring S3O, but I generally use DXT3/DXT5 for everything else.
There are a lot've settings on the DDS compressor from nVidia for Photoshop that are aggravating and/or downright harmful, unless you're doing something super-specific. Most of the time, tbh, it's a complete waste of time to fiddle with it, because you're maybe getting a slightly sharper edge or saving a few dozen kilobytes- not worth 30 minutes of labor time.
As for their comments about gray tones and sharp lines... well... I guess they're technically accurate statements, but when it's all said and done, the performance argument wins for me, every time.
You can always be more aggressive and up the contrast of areas you're afraid aren't going to come out right, and do post-work once you've run it through the mill. I really can't say that I've ever had a situation where I haven't been able to arrive at satisfactory results with that format, and with anything that's in motion most of the time, and usually isn't seen up close anyhow, teeny-tiny flaws don't even matter to the audience- it's just like painting for the theatre, really... where it looks great from a distance, but like crap up close.
RTS games aren't meant to have anything like the fidelity of a FPS. It's simply not practical- the number of objects is so much higher, and every one of them is competing for processing time. When you look at a modern RTS... you're either going to see fairly crude, low-rez work masterfully hidden by clever camera limitations, such as Dawn of War... or you're going to see really gorgeous, high-polycount things with all of the modern bells and whistles, such as normal mapping and shaders... but there won't be more than a few things on screen at once, such as Earth: 2160. And even in that game, the designers had to use multiple LODs to keep performance acceptable.
Most Spring game designs that are likely to be made and played aren't going to go for Earth's gameplay, and implementation of LODs isn't even on the drawing boards yet... therefore, it's going to be wiser to keep things down to the minimal level that looks acceptable.
[EDIT]
As for mipmapping... every 3D card in Spring is using it. All a mipmap is is a series of smaller versions of the texture, and the engine tests to see if X polygon is covered by Y mipmap... if yes, then test the next smaller one, etc., so that the very smallest texture that won't look like crap is used. DDS includes mipmaps if you enable that feature (which you should, since otherwise the game engine has to make them when your Feature/Unit is loaded by Spring- adding to startup times... or, as I discovered with NanoBlobs, serious delays in gameplay when people built their first units and the texture was loaded the first time).
It's not Anti-Aliasing that makes use of mipmaps. It's Anisotropic Filtering. If you've never played with that before... give it a try in Spring. 4X SF makes a pretty big difference in how Spring looks... 8X makes everything razor-sharp. However, the performance costs are quite high.
In my experience, if you want maximum clarity of details and colors, with the sharpest preservation of tones, then use DDS DXT3. DDS DXT1 is ok for things like simple color-channel stuff, like the glow/reflective maps on a Spring S3O, but I generally use DXT3/DXT5 for everything else.
There are a lot've settings on the DDS compressor from nVidia for Photoshop that are aggravating and/or downright harmful, unless you're doing something super-specific. Most of the time, tbh, it's a complete waste of time to fiddle with it, because you're maybe getting a slightly sharper edge or saving a few dozen kilobytes- not worth 30 minutes of labor time.
As for their comments about gray tones and sharp lines... well... I guess they're technically accurate statements, but when it's all said and done, the performance argument wins for me, every time.
You can always be more aggressive and up the contrast of areas you're afraid aren't going to come out right, and do post-work once you've run it through the mill. I really can't say that I've ever had a situation where I haven't been able to arrive at satisfactory results with that format, and with anything that's in motion most of the time, and usually isn't seen up close anyhow, teeny-tiny flaws don't even matter to the audience- it's just like painting for the theatre, really... where it looks great from a distance, but like crap up close.
RTS games aren't meant to have anything like the fidelity of a FPS. It's simply not practical- the number of objects is so much higher, and every one of them is competing for processing time. When you look at a modern RTS... you're either going to see fairly crude, low-rez work masterfully hidden by clever camera limitations, such as Dawn of War... or you're going to see really gorgeous, high-polycount things with all of the modern bells and whistles, such as normal mapping and shaders... but there won't be more than a few things on screen at once, such as Earth: 2160. And even in that game, the designers had to use multiple LODs to keep performance acceptable.
Most Spring game designs that are likely to be made and played aren't going to go for Earth's gameplay, and implementation of LODs isn't even on the drawing boards yet... therefore, it's going to be wiser to keep things down to the minimal level that looks acceptable.
[EDIT]
As for mipmapping... every 3D card in Spring is using it. All a mipmap is is a series of smaller versions of the texture, and the engine tests to see if X polygon is covered by Y mipmap... if yes, then test the next smaller one, etc., so that the very smallest texture that won't look like crap is used. DDS includes mipmaps if you enable that feature (which you should, since otherwise the game engine has to make them when your Feature/Unit is loaded by Spring- adding to startup times... or, as I discovered with NanoBlobs, serious delays in gameplay when people built their first units and the texture was loaded the first time).
It's not Anti-Aliasing that makes use of mipmaps. It's Anisotropic Filtering. If you've never played with that before... give it a try in Spring. 4X SF makes a pretty big difference in how Spring looks... 8X makes everything razor-sharp. However, the performance costs are quite high.
-
LathanStanley
- Posts: 1429
- Joined: 20 Jun 2005, 05:16
points taken, I'll "play" with it this afternoon with some beer and shouting
lol
but yeah.. I guess I had mipmaps confused with lod? maybe? not polygon lod.. but texture lod...
like hummmph.. I'd have to go mess around and take screenies... but yeah
ok, mipmaps are for the texture cropping placement dependant on geometry...
that makes more sense anyways
lol
but yeah.. I guess I had mipmaps confused with lod? maybe? not polygon lod.. but texture lod...
like hummmph.. I'd have to go mess around and take screenies... but yeah
ok, mipmaps are for the texture cropping placement dependant on geometry...
that makes more sense anyways
-
Wolf-In-Exile
- Posts: 497
- Joined: 21 Nov 2005, 13:40
Hitting the memory limit is more than a 10% loss, the framerate hits rock bottom in that case. Means 1-2 FPS.
DXT1 is the best format for 24bit images, most of the others are meant for images with an alpha channel.
I've used it mostly in UT2004, didn't notice any color errors there.
you're either going to see fairly crude, low-rez work masterfully hidden by clever camera limitations, such as Dawn of War...
I didn't know "crude" and "low res" were words to apply to 3000 polygon models?
but there won't be more than a few things on screen at once, such as Earth: 2160.
I must be doing something wrong because I always have more things on screen in Earth 2160 than Dawn of War. The average ED base has more objects than you can bring into play in DoW.
And even in that game, the designers had to use multiple LODs to keep performance acceptable.
LODs are standard practice these days, going without them would mean you couldn't adjust the polygon numbers for high load situations or lower quality settings. It's just a waste of GPU cycles to draw all 3k polygons of an ork that's 10 pixels large on the screen, having those cycles available for nearer units means more LOD0 detail.
DXT1 is the best format for 24bit images, most of the others are meant for images with an alpha channel.
I've used it mostly in UT2004, didn't notice any color errors there.
you're either going to see fairly crude, low-rez work masterfully hidden by clever camera limitations, such as Dawn of War...
I didn't know "crude" and "low res" were words to apply to 3000 polygon models?
but there won't be more than a few things on screen at once, such as Earth: 2160.
I must be doing something wrong because I always have more things on screen in Earth 2160 than Dawn of War. The average ED base has more objects than you can bring into play in DoW.
And even in that game, the designers had to use multiple LODs to keep performance acceptable.
LODs are standard practice these days, going without them would mean you couldn't adjust the polygon numbers for high load situations or lower quality settings. It's just a waste of GPU cycles to draw all 3k polygons of an ork that's 10 pixels large on the screen, having those cycles available for nearer units means more LOD0 detail.
Um... the DoW models on-screen, unless you used the hi-rez switch on the EXE, are about 900 tris, I'd say. They're not very high-poly- hands are blocks, arms are simple pipes, etc.
I don't have any of the models sitting around though, so it's kind've moot.
If you used the hi-rez switch, then you were looking at the high-poly versions, and I doubt very much their tricount was over 2000 or so. But hey, if you've got a model we can look at, let's see the facts.
As for the "crude" comment... aw, give me a break. Comparing the graphical quality of DoW even with Spring, with all of the bells and whistles on = DoW getting pwnd, and if we had some maps done in the style used, people would see that right away.
DoW was not the best-looking game ever made... which was a decision that the designers made in order to keep performance up on lower-end machines. Personally, I think they did a brilliant job. I picked out DoW in my comments because it's actually a really good example of how to make a game look good and play well at the same time, whereas Earth: 2160 is pretty rough on anything but a really nice, modern machine. But they aren't even close, in terms of overall graphical quality.
On number of units... I stand corrected. I'd forgotten that I modded out all the unit limits just about as soon as I got the game, because they were lame anyhow
As for LODs... no argument there. It'd be nice if Spring supported LODs. However, the amount of work that would add to the content-creation workload is far from trivial, and it already takes a long time to get units done. Hopefully this will start to get better, once my newest work is revealed...
I don't have any of the models sitting around though, so it's kind've moot.
If you used the hi-rez switch, then you were looking at the high-poly versions, and I doubt very much their tricount was over 2000 or so. But hey, if you've got a model we can look at, let's see the facts.
As for the "crude" comment... aw, give me a break. Comparing the graphical quality of DoW even with Spring, with all of the bells and whistles on = DoW getting pwnd, and if we had some maps done in the style used, people would see that right away.
DoW was not the best-looking game ever made... which was a decision that the designers made in order to keep performance up on lower-end machines. Personally, I think they did a brilliant job. I picked out DoW in my comments because it's actually a really good example of how to make a game look good and play well at the same time, whereas Earth: 2160 is pretty rough on anything but a really nice, modern machine. But they aren't even close, in terms of overall graphical quality.
On number of units... I stand corrected. I'd forgotten that I modded out all the unit limits just about as soon as I got the game, because they were lame anyhow
As for LODs... no argument there. It'd be nice if Spring supported LODs. However, the amount of work that would add to the content-creation workload is far from trivial, and it already takes a long time to get units done. Hopefully this will start to get better, once my newest work is revealed...
That's because they don't use the full LOD. If they were there wouldn't be a highres models option.Argh wrote:Um... the DoW models on-screen, unless you used the hi-rez switch on the EXE, are about 900 tris, I'd say. They're not very high-poly- hands are blocks, arms are simple pipes, etc.
Eh, no. DoW supports and uses proper animations and transparencies, for example, never mind much more configurable effects. Is it even possible to make something like the psy storm in Spring?I don't have any of the models sitting around though, so it's kind've moot.
If you used the hi-rez switch, then you were looking at the high-poly versions, and I doubt very much their tricount was over 2000 or so. But hey, if you've got a model we can look at, let's see the facts.
As for the "crude" comment... aw, give me a break. Comparing the graphical quality of DoW even with Spring, with all of the bells and whistles on = DoW getting pwnd, and if we had some maps done in the style used, people would see that right away.
Doesn't Spring already have some rudimentary LOD support? The LOD distance slider certainly works although the higher LODs are untextured and as such lack teamcolors, meaning they are useless for seeing what's going on.DoW was not the best-looking game ever made... which was a decision that the designers made in order to keep performance up on lower-end machines. Personally, I think they did a brilliant job. I picked out DoW in my comments because it's actually a really good example of how to make a game look good and play well at the same time, whereas Earth: 2160 is pretty rough on anything but a really nice, modern machine. But they aren't even close, in terms of overall graphical quality.
On number of units... I stand corrected. I'd forgotten that I modded out all the unit limits just about as soon as I got the game, because they were lame anyhow
As for LODs... no argument there. It'd be nice if Spring supported LODs. However, the amount of work that would add to the content-creation workload is far from trivial, and it already takes a long time to get units done. Hopefully this will start to get better, once my newest work is revealed...
First off, referring to a bunch of static frames as "proper" isn't fair to Spring. Now that I'm getting farther into what can truely be done with BOS... I am confident that people are going to be wondering how we built such dynamic stuff, that does truely random variations and isn't just a series of static poses... and soon. I'm very close to releasing some definitive work in this regard.Eh, no. DoW supports and uses proper animations and transparencies, for example, never mind much more configurable effects. Is it even possible to make something like the psy storm in Spring?
Secondly... about all that's stopping Spring from supporting transparencies on all things... is probably about 20 lines of code. It's not like OpenGL can't do this pretty easily, and we're already reading the R and G channels on the secondary S3O bitmap... getting the B to be transparency alpha is almost certainly trivial, and I'm really not sure why nobody's bothered yet, but meh.
Thirdly, while I'd agree that the current version of Spring cannot yet match the customizable particle systems in DoW... I'd say that after the next version, that will be arguable, especially if I can get my way about the BITMAP thingie- that could change everything!
Yeah... it's super... rudimentary, though. Right now, it distorts the models and does other weird stuff. Personally, I think that the new UnitIcons feature's going to make that problem moot- if developers want to build games with hundreds of things in huge battles, they'll just have them get culled and turned to Icons when needed... that'll take care of most of the framerate-stopping stuff, methinks. But true LOD support would be very nice... and, I think... pretty simple. All we'd need is a model01=X.s3o in the TDF, and a model01lodDistance=X to determine when it gets displayed. It would, and should, assume that the model has the same number of parts, so that we don't have to fool around with animations for each LOD, which would get very old, very fast...Doesn't Spring already have some rudimentary LOD support?
Scripting animation is tedious as hell. How long do you need to implement a basic walk cycle? That takes like 5 minutes in a 3d program and it's WYSIWYG. Look at the complexity of most motions (even a normal walk), I don't want to try scripting that by hand. There's a reason motion capture is gaining more and more popularity and you can't use MC with scripting.
Current LOD is done with generating a bunch of textures of the unit in it's non-animated state. The textures are generated by rendering the unit from different directions. This is known as "2d imposters"Doesn't Spring already have some rudimentary LOD support? The LOD distance slider certainly works although the higher LODs are untextured and as such lack teamcolors, meaning they are useless for seeing what's going on.
IMO if lod was implemented, it would have to be done with an automatic technique. There exist very good algorithms to make lod versions of a model, so in any case it shouldn't be the unit creator making LOD versions. The exception would be if there is normal map support, because afaik there are ati and nvidia tools to generate low-detail meshes+normalmap from a high-detail mesh.
But ofcourse model code cleanup needs to be done first
