PVRTexLib – Texture with mipmap count zero

This topic contains 5 replies, has 3 voices, and was last updated by  Tobias Hector 4 years, 6 months ago.

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • #31290

    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).

    #37334

    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

    #37335

    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?

    #37336

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

    #37337

    Joe Davis
    Member

    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

    #37338

    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

Viewing 6 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic.