Hard Light Productions Forums
Modding, Mission Design, and Coding => The Modding Workshop => Topic started by: Nighteyes on October 07, 2011, 12:03:28 pm
-
I want to know how bad is it to use TGA/uncompressed DDS files, I need uncompressed as I'm making some suns with dark smooth gradients, whenever I compress it to DDS DXT1 it gets very bad color banding, using uncompressed files solves this problem.
as its only a sun and probably there won't be more than 1-2 in a mission it might be OK?
-
It's very simple when you're using dds. File size == graphics memory used.
-
It shouldn't be a problem. I've had this problem myself. Basically, darkening any textures and converting them to DXT1 usually results in a major loss of detail and purple/green artifacts. I've used uncompressed DDS for strikecraft maps and it wasn't too much of a problem (of course, there weren't many of these strikecraft in one mission). Although my experiments may be a bad example, since I have 4GB of RAM (even for Vista, it's more than enough for nearly everything).
-
Main system RAM != GPU memory.
-
TGA's take up a lot of memory, quite a bit, actually.
Ok, say you have a 1024x1024 texture, this means you have 1,0242
pixels or 1,048,576 pixels.
Ok, TGA's have 8-bit color, which means they have a total of 256 bits each for Red, Green, Blue, and Alpha. So multiply 256 * 4 and you get
1024 bits per pixel
See where this is going? Muliply 1,048,576 by 1,024, and you get 1,073,741,824 bits (1,024 MB) used for your TGA... not including the TGA identifiers.
I think most of the modern GPU's won't care at all, but the older ones will have a heart attack if you use too many of them... I also think that the OpenGL 2.1 GPU's had a maximum of 256 or 512MB for RAM.
P.S.
TGA format supports Run-Length compression, which helps mainly for images that have areas that have the same color value.
Also, there are other DDS formats out there.
-
as its only a sun and probably there won't be more than 1-2 in a mission it might be OK?
I guess that as long as you keep the resolution reasonable, it should work for a single sun.
-
TGA's take up a lot of memory, quite a bit, actually.
Ok, say you have a 1024x1024 texture, this means you have 1,0242
pixels or 1,048,576 pixels.
Ok, TGA's have 8-bit color, which means they have a total of 256 bits each for Red, Green, Blue, and Alpha. So multiply 256 * 4 and you get
1024 bits per pixel
See where this is going? Muliply 1,048,576 by 1,024, and you get 1,073,741,824 bits (1,024 MB) used for your TGA... not including the TGA identifiers.
I think most of the modern GPU's won't care at all, but the older ones will have a heart attack if you use too many of them... I also think that the OpenGL 2.1 GPU's had a maximum of 256 or 512MB for RAM.
P.S.
TGA format supports Run-Length compression, which helps mainly for images that have areas that have the same color value.
Also, there are other DDS formats out there.
Exceeeeeept you're wrong.
TGA is a 24- or 32-bit format (depending on whether or not an alpha channel is present). This means that, for every pixel, three or four 8-bit values are stored. Which means that, after decompression (Yes, tga is technically a compressed format, but given that it uses simple run-length encryption compression, it's rather inefficient), your 1024^2 tga file takes up 1024^2*32 bits of memory, or about 32 MB.
You probably got confused by the fact that, for each color channel, there are 256 possible color values, from 0 to 255.
-
tga actually supports a lot of pixel formats, but 24 and 32 are the ones we use (it also does 8 and 16 bit pallette, 15/16 bit rgb and 5551 rgba, to name a few). tga does support some compression (i really should point out that the format is not compressed by default) but not in either of the formats we use. you can still use it but theres no real point, it will take up the same video memory as the uncompressed version (in contrast to dxt1 which can be decompressed on the fly with little overhead). tga isnt really that complex of a format (ive written no fewer than 2 tga parsers), but i think id use dds because its a more modern format which better models the way modern graphics cards handle textures (tga was designed for rather old skool graphics hardware).
-
Uncompressed DDS / TGA will have the same memory usage in the end - 24 or 32 BPP. Only, DDS images can be used straight away, while TGA images need to be converted first; you'll gain a tiny bit of performance there.
And yeah, it quite sucks that (AFAIK) there's no decent compressed DDS for 24 BPP files...
-
dxt1 is technically a 16 bit format. it can gain higher depth through interpolation though, since the format works though a process of range reduction. not a whole lot of color variation happens within a 4x4 pixel block, so this is how the image breaks down. a dxt1 is really just a mosaic of independently compressed blocks. 2 colors are up-sampled from 565 to 888. these colors represent the min and max color values. interpolation is done to double the number of colors to 4 (these colors are between the min and max color). from there each pixel is just 2-bit indexed color. its possible for the interpolated colors to have more range than the stored colors (because of the interpolation operation) and this gives you slightly better image quality than you would expect. dxt1 has the added bonus that if you dont like the quality of the image you can double the resolution and still take half the space than the uncompressed original texture.
i think i would only ever want to use uncompressed textures with interface graphics, and lower res normal maps (though i think id prefer bc5/3dc over either uncompressed or dxt5nm for normal maps that we are using now. unfortunately the format was an ati format, nvidia only started using it in the geforce 8 series and later cards).
-
my policy on the uncompressed formats (which i do actually keep in tap) is "They are a must in non-release situations. When we release, DDS is our king. Before that, before we lock down every single graphic, piss off with compression."
Btw, isnt it possible to use DXT5 compression and just drop the alpha channel, so it doesnt get included? (isnt this what DXT3 is basically?) That migth solve the issues with DXT1 and banding you haff?
-
Btw, isnt it possible to use DXT5 compression and just drop the alpha channel, so it doesnt get included? (isnt this what DXT3 is basically?) That migth solve the issues with DXT1 and banding you haff?
Both DXT3 and DXT5 have an alpha channel, and so FSO will (and should) use it in rendering. Which makes it rather unsuitable for things like sun flares... unless you turn the black into alpha yourself, of course.
-
my policy on the uncompressed formats (which i do actually keep in tap) is "They are a must in non-release situations. When we release, DDS is our king. Before that, before we lock down every single graphic, piss off with compression."
Btw, isnt it possible to use DXT5 compression and just drop the alpha channel, so it doesnt get included? (isnt this what DXT3 is basically?) That migth solve the issues with DXT1 and banding you haff?
i tend to use compressed images in development and keep my source maps in a layered format (psd for example) so that it is easy to make changes later.
i should also point out that dxt1 and 5 both store the rgb data in exactly the same way, the alpha channel is done differently however, it stores 2 8 bit values, interpolates 6 more and uses a 3-bit pixel indices to select which alpha level to use. the reason they use dxt5nm for normal maps is that you can take advantage of the 6 bit green channel and the 8 bit alpha giving you both independant channels and more bits of resolution than the 5 and 6 bits you get using red and green. 3dc is essentially 2 dxt5 alpha channels and no color data so its a good candidate for normal maps.
to solve the banding issue one might consider using uncompressed 565 to save memory, thought its possible that it could cause banding. you could also try doubling up the resolution and see if that helps, give it more space to perform range reduction. also not all dds converters are made equal, some seem to generate better quality images than others or offer quality settings.
-
just thought I'd share my trail and error, the best method I found for no banding sun flares was converting using photoshop, saving the file as DDS 8,8,8 total file size for a 1024x1024 texture is 3mb, seems ok for a sun I guess :yes:
-
just thought I'd share my trail and error, the best method I found for no banding sun flares was converting using photoshop, saving the file as DDS 8,8,8 total file size for a 1024x1024 texture is 3mb, seems ok for a sun I guess :yes:
u888 format, i assume?
-
no sure, in photoshop its called: 8.8.8 RGB 24bpp, unsigned
-
no sure, in photoshop its called: 8.8.8 RGB 24bpp, unsigned
yeah, thats the one. you dont get compression, but you get the joys of dds. if you need to use uncompressed formats for releasing something, thats the way to go
-
TGA's take up a lot of memory, quite a bit, actually.
Ok, say you have a 1024x1024 texture, this means you have 1,0242
pixels or 1,048,576 pixels.
Ok, TGA's have 8-bit color, which means they have a total of 256 bits each for Red, Green, Blue, and Alpha. So multiply 256 * 4 and you get
1024 bits per pixel
See where this is going? Muliply 1,048,576 by 1,024, and you get 1,073,741,824 bits (1,024 MB) used for your TGA... not including the TGA identifiers.
I think most of the modern GPU's won't care at all, but the older ones will have a heart attack if you use too many of them... I also think that the OpenGL 2.1 GPU's had a maximum of 256 or 512MB for RAM.
P.S.
TGA format supports Run-Length compression, which helps mainly for images that have areas that have the same color value.
Also, there are other DDS formats out there.
Exceeeeeept you're wrong.
TGA is a 24- or 32-bit format (depending on whether or not an alpha channel is present). This means that, for every pixel, three or four 8-bit values are stored. Which means that, after decompression (Yes, tga is technically a compressed format, but given that it uses simple run-length encryption compression, it's rather inefficient), your 1024^2 tga file takes up 1024^2*32 bits of memory, or about 32 MB.
You probably got confused by the fact that, for each color channel, there are 256 possible color values, from 0 to 255.
Yeah, your right. I think I was half asleep when I wrote that or something. 256 bits per pixel? Really?
I can never seem to get a good sleep cycle these days...
-
no sure, in photoshop its called: 8.8.8 RGB 24bpp, unsigned
yeah, thats the one. you dont get compression, but you get the joys of dds. if you need to use uncompressed formats for releasing something, thats the way to go
just save with mipmaps. they will be a bit bigger but the game will just copy it to the video card and call it done. i dont think id go more than 1024^2 uncompressed though (512^2 if you use a lot of uncompressed maps).