Jump to content
  • Advertisement
Sign in to follow this  
ic0de

OpenGL S3TC mipmaps without DDS

This topic is 1945 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm trying to use S3 texture compression in my opengl game but it seems that if I want mip-maps I either have to load from a pre-compressed DDS file or generate mip-maps manually and I cant just use glGenerateMipmapEXT. I don't want to load from a DDS because I want to offer the user the option of disabling texture compression provided they have enough VRAM. I want the texture to be loaded from a lossless PNG and then compressed at load time if texture compression is enabled. If I do indeed need to generate mip-maps manually I was wondering if there was a simple library somewhere that could do this or if there are some straightforward code samples/tutorials detailing how to do this.

Share this post


Link to post
Share on other sites
Advertisement

yes, for example (for DXT5):

http://pastebin.com/8rq3z5F5

http://pastebin.com/8Sga1sd6

 

which basically try to do DXT5 compression reasonably quickly by reducing the process mostly to fixed-point arithmetic and bit-twiddly.

however, there is no real internal feedback or search for an optimal encoding, so the quality is basically "whatever the fixed point-math spits out".

 

 

there was also some fiddling with a non-DDS DXTn based format (which added a secondary LZ77 compression stage), mostly intended for video-decoding usage (to be cheaper to decode than my current usage of M-JPEG for video-map textures).

 

for the most part, I have just been loading PNG and JPEG images and converting to DXTn on load (post mipmap though, at least at present), as it has generally been "good enough"...

 

naively, LZ77 can reduce DXT5 to 1/2 its size by generally compressing down the often highly-redundant alpha-channel, but a lossy block-reduction filter can further increase compression... however, for size/quality tradeoffs (with on-disk storage), JPEG and PNG still have an advantage here in my tests.

 

 

ADD:

note that mipmaps aren't actually hard to generate.

basically, at each level you are dividing the X and Y resolution in half, and roughly averaging 4 pixels into a single pixel.

 

say, pixels:

A B

C D

become

P

 

so: P=(A+B+C+D)/4

 

in the simple case, this is basically done for all of the image pixels and for each component, and is basically repeated each time to generate each new mip-level.

 

slightly higher quality for alpha-blended images can be gained like this:

Ta=Aa+Ba+Ca+Da (where Aa=A's alpha, and Ta=Total alpha).

P=A*(Aa/Ta)+B*(Ba/Ta)+C*(Ca/Ta)+D*(Da/Ta)

 

or alternatively (Argb = RGB for A):

Prgb=Argb*(Aa/Ta)+Brgb*(Ba/Ta)+Crgb*(Ca/Ta)+Drgb*(Da/Ta)

Pa=Ta/4

 

then, each mipmap level can be converted into DXTn.

 

 

in actual code, this typically results in 2 levels of "for" loops (one for Y and one for X), with some math in the middle.

 

note that in the latter strategy (where Ta is used), a few special cases may need special handling: Ta=0 and Ta=1020, where a fallback to the original (simple average) strategy may be used. this also requires either fixed or floating point arithmetic (since with plain integer arithmetic, say, 240/960 will always give 0), or possibly alternatively something like (Argb*Aa)/Ta.

Edited by cr88192

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!