glCompressedTexImage2D

Hi all,

I’m looking for some clarification on glCompressedTexImage2D.

From the function description on khronos.org:
“level - Specifies the level-of-detail number. Must be less than or equal to 0. Level 0 indicates a single mip-level. Negative values indicate how many mip-levels are described by data.”

Does this mean that the variable “data” points to successive mipmaps such that each mipmap is always half the size of the mipmap that came before it? If this is true, does this not mean that it is impossible to assign a compressed image of a specific size as a mipmap for two or more consecutive levels, and impossible to have “irregular” mipmap sizes (i.e. 256 x 256 followed by 192x192 and followed again by 128x128 …)

Appreciate any help,

  • Ben

You observations about these restrictions seem correct.

I think the power of 2 requirement even holds for regular mipmap textures that are specified individually.

  • HM

I don’t believe so. A quick look at glTexImage2D suggests nothing about defining several mipmap values at once.

There should be no reason, unless an implementation has made such an assumption, why someone couldn’t define “irregular” mipmaps individually - the function definition doesn’t mention returning GL_INVALID_OPERATION or some other error in such a case.

I’m sure you’re right, in any case, about the compressed equivalent. I just needed some sort of reassurance before I carried on with it :wink:

Thanks,

  • Ben

There’s a clause deep in the spec. about what makes a mipmap “complete”. At that point the requirement that the sizes are consecutive powers of 2 is enforced.

That they have to be powers of 2 in general is already in the reference manual.

<BLOCKQUOTE><font size=“1” face=“Arial, Verdana, Helvetica, sans-serif”>quote:</font><HR>
width:
Specifies the width of the texture image. Must be 2^n + 2border for some
integer n. All implementations support texture images that are at least 64
texels wide.

height:
Specifies the height of the texture image. Must be 2^m + 2border for some
integer m. All implementations support texture images that are at least 64
texels high.

border
Specifies the width of the border. Must be 0.
<HR></BLOCKQUOTE>

  • HM

[ August 04, 2004: Message edited by: Hans-Martin Will ]

Granted, yes, they must be powers of two - but I’m suggesting that we could skip any such power where we please, though I’m not sure anyone actually would.

i.e. mipmap 0 being 128x128, and mipmap 1 being 32x32 … or 32x64 would still be legal.

  • Ben

If “legal” includes that it does not use such a texture, we are on the same page…

  • HM

I think so - aren’t we? heh :wink:

Thanks for your time,

  • Ben

> Granted, yes, they must be powers of two - but I’m suggesting that we could skip any such > power where we please, though I’m not sure > anyone actually would.
>
>i.e. mipmap 0 being 128x128, and mipmap 1 being 32x32 … or 32x64 would still be legal.
>
>- Ben

Such a texture is legal, but not complete. If this texture would be used with mipmapping enabled, the texture wouldn’t get displayed at all.

From the specification (gl1.3, texture completeness):

“The dimensions of the arrays follow the sequence described in the Mipmapping discussion section of 3.8.7.”

3.8.7 states then that the next level always has to be:

   @(i-1) x @(j-1) x @(k-1)

i,j,k are pow-2 exponents of the dimensions of the previous level, @ operator is:

 x &gt;  0:   @(x) = 2^x
 x &lt;= 0:   @(x) = 1

The only case where one of your texture dimensions can be other than half of the dimension in the previous level is when the size gets below 1 other dimension is still bigger than 1.

For example:

256x64, 128x32, 64x16, 32x8, 16x4, 8x2, 4x1, 2x1, 1x1 is ok, but

256x64, 128x64, 64x64, 32x32, 16x16, … is not.

–jani;

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.