Sign in to follow this  
NoisyMonk

Textures: Size and Format

Recommended Posts

NoisyMonk    100
Greetings,

I've been searching everywhere for this info, but I'm having a difficult time finding solid answers. I know this isn't specifically programming related, but I'm looking for some of the fundamentals to these questions, which always leads back to the code.

Power of 2: Why is this so important? From what I could find, video cards a few years ago couldn't handle non ^2 textures, but today's cards can. With current hardware, is there a performance or quality hit if you use non ^2? Or is the only reason to use ^2 textures to support those older cards that might be kicking around in some older PCs/Laptops?

Format: PNG or DDS(DXT5)? I realise that this is slightly more situational, and there are perks to either one depending on the situation.

PNG - High quality (lossless). Built in 8-bit alpha. Small on-disk file size. Slow decompress/load time and large size in VRAM.

DDS(DXT5) - Lower quality (lossy). 8-bit alpha channel. Mipmap generation/storage. Larger on-disk file size. Fast load times because there is no decompression necessary.

So PNGs would be better suited for a 2D side-scroller (no need for mipmaps) since there is generally a small amount of content, and there is no real need to give up texture quality? And DDS would work better for a 3D, graphically intense game?

Please let me know if I'm wrong on any of this. I appreciate your input.
NoisyMonk.

Share this post


Link to post
Share on other sites
Krohm    5030
I sense some confusion here... you're messing up the "runtime" format (such as DXTC-5) and the file format (such as png).

Runtime formats: check out DXSDK for device caps, it's a table full of interesting information. Want to know about GL? That's for nVidia. Now to the questions...
Quote:
Power of 2: Why is this so important? From what I could find, video cards a few years ago couldn't handle non ^2 textures, but today's cards can. With current hardware, is there a performance or quality hit if you use non ^2?
Discrete cards seems to work with NPOT just fine for me since a few years, but I'm not up to date with integrated chipsets, I bet they'll have issues. Maybe someone tried more intensive tests than me.
You still want to do POT when possible because the math is simply far better defined for POT textures (NPOT is a bit quirky on edges when mipmapping).

Disk storage
There's no "better choice", you have to choose on a case by case basis.

  • JPEG: best compression/file size for the vast majority of the cases, at the cost of limited color features.

  • PNG: lossless, both 8 and 16 bit, integer.

  • EXR: this is quite flexible, I used it some time ago mostly for HDR data. Various encoding modes, mostly useful for float data.

  • DDS: jack of all trades, it's a container format able to do essentially everything. I suggest to use it if (1) textures are stored compressed or (2) need to pack explicit mipmaps/cube faces/volume slices.


The runtime format you use has little to deal with the file format you use for persistent storage. You can take a .bmp and compress it in some DXTC (especially easy for GL). It probably makes little sense than taking a cubemap out of a DDS and save it as texture2d. There's clearly some relationships between the storage and the runtime format but it's not a so clear cut.
If using Direct3D then DDS makes your life easier, it says essentially everything on what you need to do with your texture, while other file formats will require some mapping.
Similarly, you can generate mipmaps or not, depending on your needs. Unless you have explicit mips, just ask the API to deal with them by itself.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this