[taylor]

my video card is a 256 meg card, and it can handel theese big textures, so does that mean its getting resized anyway?

Memory has nothing to do with it.  You can have a terabyte of memory on your video card but it still might have a 1024x1024 or 2048x2048 max texture size limit.  The limit is just what the video card can actually process and going over it either won't work or it gets resized by the API to fit within the limit.  Just run a debug build and in the graphics init part of the log it will say what the max size is for your card.  The higher end cards now will do 4096x4096, but most still do 2048x2048.

[Nuke]

yep my card does support that resolution. so i guess that my setup can handel that texture. i bought this card specifically for texture work. however i cant expect everyone to have it. so ive made the decison to distribute the mod with scaled down textures.

another thing. im currently working on an explosion animation. its gonna be an eff with 15 frames, 256^2 dxt1 with mips. now from what you said the mips should be all the loding this explosion needs. is this a correct assumption?

[taylor]

another thing. im currently working on an explosion animation. its gonna be an eff with 15 frames, 256^2 dxt1 with mips. now from what you said the mips should be all the loding this explosion needs. is this a correct assumption?

Correct.  It's also a good idea to include a modular weapon_expl table (or an entry in weapon_expl itself) to say that it has only the 1 LOD, just to avoid the stupid warning messages.  The graphics system will take care of using the mipmaps as LODs automatically.

Oh and unless the explosion animation is really small I'd recommend making it 512^2 instead.  The mipmaps will keep it from being any slower to use than a 256^2 version and you'll get the added detail when it has to magnify the image.  There isn't much point in going over 512^2 since it is an animation and that is memory probably best used on shockwaves or texture maps or something.  There is also the benefit of user controlled detail settings now.  The "3D Hardware Textures" slider will now affect base (the most detail) mipmap levels, so if the user can't spare room for the 512^2 plus full mipmaps they can lower the slider and only get a max size of 256^2 or 128^2, etc. for the effect in video memory.  This would allow you to create a detailed effect without having to worry too much about what the user will have to deal with since they can control it.

And that also brings up the point of making sure that you do your testing with that detail slider maxed out.  Otherwise you aren't seeing the full detail possible from the map/effect.  And this is just with OpenGL for now of course, D3D is still behind on the better mipmap support (used to be the other way around).  D3D support is coming though, once I figure out how to do the same things in it that OGL does.

[Nuke]

that animation came out to about 2.5 megs (i went 512 btw), which iis about the same as an average ship texture. i only need to make one other short explosion so im not too worried about memory usage. i have about 4 other anis to do but they are just for various particle effects and wont need very much detali. thanks for the advice.

[Vasudan Admiral]

'nother question:
I need to texture a LOT of polys on a rather over-detailed ship over on SG (here), and I intend to use 1 or 2 large 2048² res maps. However, only small parts of it need glowmaps, so there'd be no sense in making a huge glowmap just so those bits can glow.

My question is, would I be better off putting those glowing areas onto a separate, roughly 256 res texture, and not putting a glowmap on the big one(s), or is the performance cost of switching textures great enough that that'd be slower than having a big glowmap (and thus glow map render pass) on the main texture?
Thanks in advance.

[taylor]

It really depends on how many of the 256 res textures you need to use.  The fewer the better, but with that said, you could probably get away with using 4 or 5 of them before you will start to hit any sort of speed issue that the transfer limit of a 2048² texture could impose.  Also keep this in mind, if not everything in the mission can fit into video RAM then it would be quite a bit easier/faster to swap in/out those 256 res textures than it would be to handle that 2048² one.  Having to use a couple of 256² textures, even with texture switching, would greatly make up for the speed decrease and extra memory usage imposed by that one 2048² texture.  For those of us with the hardware to handle the 2048² without flinching, the little extra texture work for the 256² versions wouldn't mean squat in the grand scheme of things.  But those without that beefy hardware could benefit nicely from the 256².

And the main texture and the glowmap are rendered in the same pass, btw.

[Backslash]

I'd be interested in a few clarifications if you have time.  I've read the thread a few times and feel like I'm still missing a few concepts.

I get the idea that DDS is more efficient than everything else.  And you say TGA is to be avoided as possible.  But how does TGA compare to JPG and PCX?  According to the bits per pixel thing, am I right in thinking PCX is better than JPG, which is better than TGA?  (provided, of course, that color pallete is not an issue.)  And that was for memory usage; is performance any different?

Hmm, that makes me curious, why is the PCX support only 8 bit?  I'm not complaining, just curious.

I see a couple mentions of 'uncompressed DDS' but cannot find how to make this.  Or rather, upon searching I think I can with nvdxt but am not sure what format would be best for FSOpen.  u888 perhaps?  What do you recommend for options/switches?  But if this method no longer has the problems noted at http://www.penguinbomb.com/lightspeed/TGADDS.html, then that sounds like the thing to use for everything for which the compressed DDS is unacceptable!   

[taylor]

I get the idea that DDS is more efficient than everything else.  And you say TGA is to be avoided as possible.  But how does TGA compare to JPG and PCX?  According to the bits per pixel thing, am I right in thinking PCX is better than JPG, which is better than TGA?  (provided, of course, that color pallete is not an issue.)  And that was for memory usage; is performance any different?

PCX is 8-bit, but the game converts it to 16-bit for it's use in order to blend better and get transparency.  PCX always has a 256-color palette (not in the format, just for what the game supports) so you will always only have 256 colors to work with.  PCX is a very old format and so is better suited to the hardware it was written for, hardware that only used 16 or 256 colors and where disk space was a premium.  PCX is slower than all of the other support formats in FSO because it's converted out of it's native format in order for it to be used better by the game.  A PCX texture uses width x height x 2 worth of memory.

TGA is 8-bit, 16-bit, 24-bit or 32-bit depending on what you saved it as.  8-bit TGA isn't supported by the game so you can safely ignore that one.  16-bit is very uncommon so you typically won't see it, but the game supports it.  24-bit is an RGB image with no alpha and is pretty common.  32-bit is RGBA image, having an alpha channel.  A TGA texture uses width x height x (Bpp/8) worth of memory, where "Bpp" is 8, 16, 24, 32 corresponding to what format the file is.

JPG is always 24-bit.  It's compressed as a file format, but when it actually get's used it has to be uncompressed.  A JPG texture uses width x height x 3 worth of memory, the same as a 24-bit TGA.  Compression degrades image quality though and so JPG really only saves you disk space and nothing else.

I see a couple mentions of 'uncompressed DDS' but cannot find how to make this.  Or rather, upon searching I think I can with nvdxt but am not sure what format would be best for FSOpen.  u888 perhaps?  What do you recommend for options/switches?  But if this method no longer has the problems noted at http://www.penguinbomb.com/lightspeed/TGADDS.html, then that sounds like the thing to use for everything for which the compressed DDS is unacceptable!   

Pretty much anything that supports saving DDS images should also be able to save uncompressed DDS.  Currently supported uncompressed DDS formats are u1555, u888 and u8888.  "u1555" is a 16-bit format with 1-byte alpha, this is what PCX images are turned into by the game engine.  "u888" is a 24-bit RGB image, bascially the exact same thing as a 24-bit TGA image.  "u8888" is a 32-bit RGBA image offering a full alpha channel, basically the exact same thing as a 32-bit TGA image.  As you can guess from "uncompressed", it doesn't save any memory to use these formats, and the memory needed for the image is the same as the size of the file (ie, a 2meg file will need 2meg of both system RAM and video RAM).  The only really advantage to uncompressed DDS is that you can have a full set of mipmaps in the one file, and you can make cube maps (used for environment mapping) out of them.  It's not going to save any memory or disk space.

Always try to use a compressed DDS format (DXT1, DXT3, DXT5) whenever possible since it saves a ton of memory.  For instance, a DXT1 image will use 1/6th of the memory that a 24-bit TGA or u888 image uses.  The compression artifacts are an issue so just test it and see if it's acceptable or not.  If not then use one of the uncompressed formats.  Compressed DDS is the fastest of the formats used by FSO since it requires no additional processing (like everything else does), it's sent to the video card as is and the video card uses it the same way.

[Vasudan Admiral]

It really depends on how many of the 256 res textures you need to use. The fewer the better, but with that said, you could probably get away with using 4 or 5 of them before you will start to hit any sort of speed issue that the transfer limit of a 2048² texture could impose. Also keep this in mind, if not everything in the mission can fit into video RAM then it would be quite a bit easier/faster to swap in/out those 256 res textures than it would be to handle that 2048² one. Having to use a couple of 256² textures, even with texture switching, would greatly make up for the speed decrease and extra memory usage imposed by that one 2048² texture. For those of us with the hardware to handle the 2048² without flinching, the little extra texture work for the 256² versions wouldn't mean squat in the grand scheme of things. But those without that beefy hardware could benefit nicely from the 256².

And the main texture and the glowmap are rendered in the same pass, btw.

Ah ok - that's excellent. Thanks muchly.

[Backslash]

Very clear, complete, and helpful answers.  Thanks.   

Steel01 and I are doing some testing on how much performance is gained by turning just about everything in the mediavps to DDS.  For some of the effects in particular, IMO, compression may not be a good idea -- because of, as you say, the compression artifacts.  So while uncompressed doesn't save memory, still since there's no additional processing there's some performance gain, correct?

Here comes a few questions about effects and mipmaps that don't really have to do with 'creating efficient models', so split me off into a separate thread if you prefer.

How many mipmaps would you say are necessary for large background images, like nebulas and planets?  They are big and don't get resized often (only once per mission, right?), so maybe 2?  1?  0?  (How would the 3D Hardware Textures slider affect this, being backgrounds?)  I notice the DDS versions of the planets in mv_effects have up to 11, is this a good idea?

How about stuff like lasers, thrusters, and explosions?  Those get resized a lot.  Of course, some start out pretty small to begin with.  I notice most of the current EFF-animated DDS series of laser effects have no mipmaps at all.  Meanwhile the WarpMaps, a 512x512 EFF-animated DDS series, have 9.  I like that with the mipmapped explosions we can eliminate the LOD files, but do I follow the (exp4.ani 256x256) example and have 2 or so mipmaps, or would more be better?

I'm guessing for some things there are no concrete answers, but it will be nice to hear some general guidelines.  Thanks for putting up with my questions 

[taylor]

So while uncompressed doesn't save memory, still since there's no additional processing there's some performance gain, correct?

There's not really any extra processing going on during load for a uncompressed DDS, but the video card does have to do more work.  An uncompressed 32-bit DDS with a size of 512x512 is a total size of 1meg.  A compressed 32-bit DDS with a size of 512x512 is a total size of 256k.  It's going to take more time for the video to get the image, manipulate the image, and use the image if it's uncompressed.  In that case it doesn't matter if it's uncompressed DDS or not.  I'm more willing to deal with the compression artifacts than the speed decrease in most instances.

But that's why we have -img2dds (when it actually works for everyone).  Then you can have a 32-bit TGA image (uncompressed DDS isn't affected by -img2dds!!) without any sort of compression artifacts and let the user decide if having that image compressed is the best option or not.

So while uncompressed doesn't save memory, still since there's no additional processing there's some performance gain, correct?
How many mipmaps would you say are necessary for large background images, like nebulas and planets?  They are big and don't get resized often (only once per mission, right?), so maybe 2?  1?  0?  (How would the 3D Hardware Textures slider affect this, being backgrounds?)  I notice the DDS versions of the planets in mv_effects have up to 11, is this a good idea?

This is actually a loaded question so try and stick with on it, it may not make much sense...

A mipmaped file is one that contains various sizes of a particular image.  So, when you use a 1024x1024 image of a planet, with full mipmaps, you are sending to the video card a 1024x1024 image, plus a 512x512 version, a 256x256 version, a 128x128 version, a 64x64 version, a 32x32 version, a 16x16 version, a 8x8 version, a 4x4 version, a 2x2 version, and a 1x1 version.  11 mipmaps == 11 images.  For that planet you could probably just get away with the first 3 (1024x1024 -> 256x256) and let the video card just resize the smallest version itself.  Of course you could just not use mipmaps for those at all.  The mipmaped version will be slightly faster to render, since it will just use the version that best matches the size in use, but then you are wasting all of the other mipmap levels which are also loaded into memory.  So while you will get an increase in rendering speed, and probably an increase in quality, you are using more memory to do it.  You aren't wasting much memory on the low side (the size of all mipmap levels, below 512x512, *combined* are 1/3rd the size of just the 512x512 level in memory) but you do waste memory on the high side (if you only need the 256x256 version then are wasting at least 75% of the memory used by the image).  In other words, this part is tricky.

Eventually I plan to fix this so that the code will only try to use the mipmap level that best matches the size of the starfield bitmap (suns, planets, nebula) in use.  This is possible, just not a high priority.  When that gets fixed though you can do whatever you want with the mipmap levels and the game will go with what works best automatically.

If you want an answer on what to do then I can't really give it to you.  For now it's totally a judgement call based on the image.  My basic opinion is (if using a 1024x1024 image) to make at least 3 mipmap levels, just to try and help people out rendering speed wise, but making the full set of mipmaps is only going to use another 21k of memory so why bother not doing it.

How about stuff like lasers, thrusters, and explosions?  Those get resized a lot.  Of course, some start out pretty small to begin with.  I notice most of the current EFF-animated DDS series of laser effects have no mipmaps at all.  Meanwhile the WarpMaps, a 512x512 EFF-animated DDS series, have 9.  I like that with the mipmapped explosions we can eliminate the LOD files, but do I follow the (exp4.ani 256x256) example and have 2 or so mipmaps, or would more be better?

I don't think lasers matter much, but I mipmaped mine and really like the result.  It just looks nicer in my opinion.  Thrusters and glowpoints, these are considered part of the model so they should have full mipmaps like any other ship texture.

Explosions and warpmaps are two things that can benefit heavily from mipmaps.  I say that it's basically a crime at this point to not use mipmaps for those.  Of course you have to tell the game (via a weapon_expl.tbl, or the XMT version) to only use the one LOD image in order to avoid also mixing in retail effects.  For both of these types you aren't really going to waste memory by making a full set of mipmaps since nearly every level will end up being used by the game.  This certainly falls into the "more is better" category, do the full set and be happy knowing that you are doing everyone a favor.

[Backslash]

Me again     Thanks for your answers... even the opinions on the questions that can't have clear answers yet, they were what I needed to know.  And I understood the one that might not have made sense 

But that's why we have -img2dds (when it actually works for everyone).  Then you can have a 32-bit TGA image (uncompressed DDS isn't affected by -img2dds!!) without any sort of compression artifacts and let the user decide if having that image compressed is the best option or not.

This sounds awesome, when it works.  Might part of the reason it has troubles be because of some textures that are not power-of-two?

Eventually I plan to fix this so that the code will only try to use the mipmap level that best matches the size of the starfield bitmap (suns, planets, nebula) in use.  This is possible, just not a high priority.  When that gets fixed though you can do whatever you want with the mipmap levels and the game will go with what works best automatically.

I understand why it's not a high priority, but it sounds great for someday 

My basic opinion is (if using a 1024x1024 image) to make at least 3 mipmap levels, just to try and help people out rendering speed wise, but making the full set of mipmaps is only going to use another 21k of memory so why bother not doing it.

Heh, I didn't think about that all the way through.  Makes sense now.  Full mipmaps it is, then.

Now I have a question about alpha channels.  This came up while messing with DXT1/3 vs DXT5.  Basically, are there any effects that NEED the alpha channel?  (so I should leave them as DXT5 rather than DXT1 or 3?)  I know Freespace does a lot of automatic transparency with most of the effects -- guns, explosions, thrusters, etc -- so in which cases is the alpha channel actually useful?  (I'm guessing just the suns/sunglows, planets and nebulae?)

Minor thing: in an EFF animated series of DDS files, are there any issues with having some frames be one format (DXT1) and some be another (u1555), in the same animation?

Also, is run-length-encoding supported in the game's use of TGAs?  I think I found a couple files in the mediavps compressed this way... would it be better to resave them as uncompressed, or leave them [and perhaps convert others to] compressed?  (I'm guessing there's a tradeoff between memory and performance... do you have opinion on which is worse in this case?)  Of course, moving to DDS, hopefully soon this point will be moot 

[taylor]

This sounds awesome, when it works.  Might part of the reason it has troubles be because of some textures that are not power-of-two?

Actually I think I fixed the problem the other night.  Just waiting for the next CVS build to know for sure.  And power-of-two isn't an issue here, it tests first to make sure that the image is good for compression and a power-of-two test is part of that.  If the texture isn't power-of-two then it just stays as it is, there is plenty of fail-over to prevent things like this from making you see no image.  The problem here was that it thought that the image data was reversed for 32-bit images (making the alpha appear to be a primary color).  Just a minor little thing that took me forever to finally notice.

Now I have a question about alpha channels.  This came up while messing with DXT1/3 vs DXT5.  Basically, are there any effects that NEED the alpha channel?  (so I should leave them as DXT5 rather than DXT1 or 3?)  I know Freespace does a lot of automatic transparency with most of the effects -- guns, explosions, thrusters, etc -- so in which cases is the alpha channel actually useful?  (I'm guessing just the suns/sunglows, planets and nebulae?)

The game uses two basic forms of transparency: alpha, and alphablend.  The alphablend images are the ones that use black to depict alpha color, these images can/should be DXT1 as they don't actually use a real alpha channel.  Starfield bitmaps (suns and backgrounds) and most effects (explosions, lasers, etc.) are the best case of using this type of blending.  The other form is, of course, a true alpha channel in the image.  This is good for some ship textures (if you need alpha, like for glass or something) and also for planets (so that you can have a dark side to the planet without it also being transparent).

You only really need an alpha channel if you actually need it.  A good point of reference is that if you are upgrading an effect then look at the old one.  If it's using a black background then it's an alphablended image and you shouldn't need an alpha channel.

Minor thing: in an EFF animated series of DDS files, are there any issues with having some frames be one format (DXT1) and some be another (u1555), in the same animation?

Nope.  They only have to be the same file type (DDS, TGA, JPG, etc.) and of the same dimensions.  You can easily mix DDS formats for the different frames in an EFF, that was part of the point in fact.  Each image is loaded separately by the game so each one can be a different basic format.  And that can actually be different dimensions as well, but then it doesn't render properly (just in case you try it ).  I had originally wanted it to be possible to only use the size image that you needed for the frame content, but that didn't work out too well so I scrapped the idea.

Also, is run-length-encoding supported in the game's use of TGAs?  I think I found a couple files in the mediavps compressed this way... would it be better to resave them as uncompressed, or leave them [and perhaps convert others to] compressed?  (I'm guessing there's a tradeoff between memory and performance... do you have opinion on which is worse in this case?)  Of course, moving to DDS, hopefully soon this point will be moot 

Yes, RLE compressed TGAs are supported.  RLE is a lossless compression so the image will look the same whether it's compressed or not, but being compressed it saves on disk space.  RLE compressed TGAs will use the same amount of memory and they don't load any slower (perhaps a little faster actually) so there is no harm in using them over uncompressed TGA.  I have converted nearly all of the TGAs I use to DDS, but some of them can just look too bad when compressed to a DXT format.  At that point it's better left up to the end-user to decide, let it use more memory for better quality, or use -img2dds to compress the images.  The only real loss here is with mipmaps since they aren't created for such images (yet, that will get fixed at some point).

[PotzUK]

Just re-read this one, and I've been trying to change some of my PCX backgrounds to DDS using the nVidia plugin for Photoshop...

However the game doesn't show the backgrounds anymore, I've tried a few different settings but no joy.  Is it something simple I'm missing, or do the backgrounds need to be .pcx?

[Wanderer]

IIRC Photoshop dds plugin is very buggy and does odd things time to time... you are much better of with either ATI's Compressonator or Nvidia's command line tool (Nvdxt or something).

Backgrounds work fine as dds. Just make sure you are using proper dds type (for backgrounds either u888 or DXT1 is probably the best) so that you dont get problems from bad alpha.

[PotzUK]

ahh - I sussed it.  The image dimensions need to be a multiple of 2 (2,4,8,16,32,64,128,256,512,1024 etc etc)

[Wanderer]

Yeah, but AFAIK only for compressed dds files - for FreeSpace related graphics that equals either DXT1 or DXT5

[Taristin]

Yeah, but AFAIK only for compressed dds files - for FreeSpace related graphics that equals either DXT1 or DXT5

I was under the impression that every graphic fils whould be a power of 2, otherwise it must be resized by the graphics card, wasting gpu cycles.....?

[taylor]

Yeah, but AFAIK only for compressed dds files - for FreeSpace related graphics that equals either DXT1 or DXT5

I was under the impression that every graphic fils whould be a power of 2, otherwise it must be resized by the graphics card, wasting gpu cycles.....?

It's resized by the game, not the graphics card, and it only has to be done when it's initially sent to the video card in the first place.  But, for texture maps and effects, it's still better to have everything as power-of-2.  Interface graphics don't have to be power-of-2, and the game will try to use them that way if possible.  That only applies to interface graphics though and everything else will have to be power-of-2, whether the image was originally or the game makes it that way, unless you have a GeForce 6800+ video card that can actually use non-power-of-2 images natively.

The issue with compressed DDS is that they won't even load if they aren't power-of-2.  If compressed DDS images aren't power-of-2 then it will fail to load them and you'll just get blank/missing texture related issues (graphical errors, warnings, etc.).

[Taristin]

Good to know.