Imagination PowerVR SDK Blog

PVRTexLib - Texture with mipmap count zero

pvrtextool

#1

Hi,



I am trying to create top level non-mip-mapped texture. I am using PVRTexLib version 4.5.



In order to achieve this, i am setting u32MIPMapCount as 0 while creating CPVRTextureHeader object.


CPVRTextureHeader sHeader(PVRStandard8PixelType.PixelTypeID,
256, // u32Height,
256, // u32Width,
1,
0, //mipmap count
1,
1, //cubemap
ePVRTCSpacesRGB,
ePVRTVarTypeUnsignedByteNorm,
false);

CPVRTexture sCompressedTexture(sHeader);

When i try to access data pointer of this texture using below code, i get null pointer.
void *p = sCompressedTexture.getDataPtr(0,0,0);
if(!p)
{
std::cout << "p is nulln";
}

Data pointer of texture is perfectly fine if i set u32MIPMapCount as 1 while creating CPVRTextureHeader object. But this will create top level plus one extra mipmap level.

Please confirm how can i get the correct data pointer for top level non-mip-mapped texture (u32MIPMapCount = 0).

#2

Hi Neha31Gupta,



The top level of a texture is included in the “number of mip maps”, so you actually want to set it to 1, rather than 0. 1 actually does just mean the top level, and no additional mip maps.



Thanks,

Tobias


#3

As per “PVRTexTool.User Manual.pdf” (section 5.4.1) - ‘u32MIPMapCount’ is the number of MIP-map sublevels present in addition to the top level: 0 means that only a top level non-MIP-mapped texture exists, 1 means the top level plus an extra MIP-map level, etc.



Am i missing something?


#4

I am blocked due to this issue. Can some body please answer my query?


#5

Hi,



Have you tried setting the value of “u32MIPMapCount” to 1 as Tobias suggested? Tobias is the lead engineer for TexTool, so I suspect the documentation may have an error in it.



Thanks,

Joe


#6

Hi Neha,



Sorry I was ill last week so didn’t get around to answering this - there is in fact a bug in the documentation as Joe suggested, not entirely sure how it got there but I’ll see that it gets fixed. What I said in my post is correct, the document is wrong.



Regards,

Tobias