DXTC texture, mipmaps and work around ...

Hi,

I notice something weird in my code and I thought it would not be complicated to clean up… and half of the day is gone now!

Basically, when I load a compressed texture, I start with these few calls:

glGenTextures(1, &Name);
glBindTexture(GL_TEXTURE_2D, Name);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
glTexParameteri(GL_TEXTURE_2D, GL_GENERATE_MIPMAP, GL_TRUE);

and then call glCompressedTexImage2D for each mipmaps which size if bigger than a block size.

Well I got really surprised to notice this awful “lTexParameteri(GL_TEXTURE_2D, GL_GENERATE_MIPMAP, GL_TRUE)” that I try to always replace with glGenerateMipmap now days when I can.

I tried to remove that call because I already have my mipmaps I don’t see the point to generate anything and I actually wonder what it actually generate … probably no compressed data.

It didn’t work, the texture was render black!

I added glGenerateMipmap at the end, it works!

I played around with GL_TEXTURE_BASE_LEVEL and GL_TEXTURE_MAX_LEVEL. It works if I limit the number of mipmaps to the number I have loaded minus one …

Should I use something to generate mipmaps? Is it possible to load compressed texture without work around?

I Have a GeForce 8 with drivers 190.57

Thanks

glTexParameteri(GL_TEXTURE_2D, GL_GENERATE_MIPMAP, GL_TRUE);

and then call glCompressedTexImage2D for each mipmaps which size if bigger than a block size.

Don’t generate mipmaps when you’re using compressed textures. Generate them offline and load each mipmap.

“Read the post when you answer on’t post”

I can do the same kind of statement…

The issue is that I don’t want to use generate mipmaps but if I don’t the texture is display black

Are you loading ALL mipmap levels?

Sounds a lot as if there are a few missing.

And even though it doesn’t answer your question, Alfonse is right.

Jan.

I had the same problem, but I was targeting trilinear filtering, the texture would show if I used linear (not nearest).
http://www.opengl.org/discussion_boards/…4171#Post254171

Just set
glTexParameteri (GL_TEXTURE_2D, GL_TEXTURE_MAX_LEVEL, iMaxMipmapUsed); // iMaxMipmapUsed=NumMips-1
and you’re ready to go.

and then call glCompressedTexImage2D for each mipmaps which size if bigger than a block size.

From this I conclude that you don’t upload mipmap levels down to 1x1 size. In this case you’re facing an incomplete texture and the behaviour you see is to be expected. Though, I’m used to get a fully white output for imcomplete textures :wink:

I wonder why there has never been a “glIsTextureComplete()” call… texture incompleteness hits everyone from time to time.

That’s actually one work around I found… still a work around.

If I load the 1x1 texture I have an error. Which fairly make sense to me, no block feet in 1 texel…

I actually use trilinear filtering, just not when I load a texture…

Thanks Ilian Dinev, I like to see someone end up to the same thing I did even if I don’t understand why I need a work around for that …

There simply is no (clear) documentation and not even one tutorial on the whole net on this most-basic real-world subject. DXT1 tutes show no mipmapping, mipmapping tutes show only uncompressed textures >_< .

DXT1 tutes show no mipmapping, mipmapping tutes show only uncompressed textures >_< .

That’s because you’re expected to be able to put 2 and 2 together. The only difference between compressed textures and uncompressed textures is the function you use to upload data to them. If you’re getting problems, it’s because either your GL implementation let something slide in the standard texture case that it’s not in the compressed case, or you’re doing something wrong.

Well, the mipmapping tutes use gluBuildMipmaps … :slight_smile:

All mipmap levels smaller than 4x4 are uploaded as 1 block. So, the last 3 mipmap levels have all the same ‘imagSize’ (i.e. size in bytes).

You’ll encounter something similar when trying to upload NPOT-DXTn compressed textures. In this case you have to calculate ‘imageSize’ with width and height rounded up to the next multiple of 4. For example, you would upload a 10x9texels Image as 3x3 blocks.

Thanks Skynet! That’s fix by issue, no more workaround required!

I actually notice a bug in my code where I load the right amount of data for small mipmaps but I was loading the texture with the wrong sizes because a compute the data size at loading.