PvrTexLib (Win32) Problems

This topic contains 4 replies, has 2 voices, and was last updated by  Tobias Hector 4 years, 8 months ago.

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • #31152

    Hi, we are having some issues with PVRTexLib:

    1) CPVRTexture(szFilePath) fails to load

    I’ve discovered a problem / workaround for when trying to load certain *.DDS textures into CPVRTexture( fizePath ) constructor.
    Our pipleine runs various files through a texture-converter which outputs DDS files – not necessarily DX1 etc.
    The file in question is in the A8R8G8B8 format.
    The PVRTexLib was failing on the DDS files from the converter but not from DDS files saved in DirectX Texture Tool.

    After calling the constructor, the CPVRTexture header would be correct for the DDS and the dataSize member would be set but the m_pTextureData member would be NULL. The NULL dat apointer would then cause Transcode() to crash in the DLL ( no symbols / stack ).

    I have found through comparing the files in a HexEditor that our converter is setting the DDSD_PITCH flag and setting the appropriate (correct) pitch value, wheras it is not set in the working textures, for some reason this is causing the load to fail.

    Our rather nasty workaround is to open the converted *.DDS, manually clear the Pitch flag and value and re-save to disk. The CPVRTexture object then loads the file correctly and has a valid m_pTextureData.



    2) Too many mipmaps.

    It appears that after loading a DDS file via the CPVRTexture( fizePath ) constructor, the number of reported mipmaps is 1 too many for the size of the texture, a 64×64 texture reports as having 8 mipmaps, even including the base-texture, there should only be 7 images in a 64×64 mip-chain. (n+1) Mips for a (2^n) texture. The source DDS image reports as having the correct 7 mip-maps for a 64×64 image.

    The extra mipmap is reflected in the converterd PVR texture which seems to have two 1×1 mip-maps. While traversing the pvr-data and extracting mip-map levels for use in glCompressedTex2D(), the algorithm works fine and the descending texture images are valid and uncorrupted, but on many textures (if not all) the actual data-size is larger than expected given the correct number of mipmaps.
    In such cases there is always one 1×1 mip-map level’s worth of data left over on the end (32 bytes) – even for cubemaps (192 bytes).

    We are compensating by simply exiting the algorithm once the first 1×1 mipmap is found, rather then loop until the data is exhausted.



    3) PVR Compressed CubeMaps have a pixel offset problem.
    It seems that each face of the cube map after Face0 (positive X) has its pixels rotated left by one pixel left per face
    The offset is the same in each mip-map level.

    0: Positive X ( no offset )
    1: Negative X (1px)
    2: Positive Y (2px)
    3: Negative Y(3 px)
    4: Positive Z (4px)
    5: Negative Z (5px)
    etc.

    The pixels are offset inside the same texture and same mipmap level – meaning its not a simple data-offset problem ( otherwise the pixels would be wrong towards the end of the texture not simply a horizontal offset).

    Creating a CubeMap from six individually compressed PVR textures (with mips) works fine, but converting a DDS cube-map as one texture causes the offset problem.

    Example:

    The offset appears the same on the Positive Y and Negative Z becasue the Positive Y is using a lower mipmap level and hence has texels double the size.



    We have workarounds for the problems but they are not ideal.
    The CubeMap problem ( use separate 2D images ) will affect our pipeline the most as it requires the most meddling with data.

    Thanks, H.

    #36710

    Hi Henry,

    Could you confirm that you’re using the latest version (4.3) of the library? The version number is stored in “PVRTextureVersion.h”. These issues should have been fixed in the last two releases, though I admit my testing was performed on output from the DirectX Texture tool.

    Assuming you are using the latest version, would you be able to either some example offending files somewhere, or send them to DevTech@imgtec.com? I will take a look at them and try to create a fix.

    Thanks,
    Tobias

    #36711

    Ah, it appears we are currently using an older version ( 4.01 ). I have downloaded the latest SDK. I will let you know if it it fixes the issues.
    Thanks,
    H

    #36712

    Hi, the mipmap and pitch-flag issues are indeed fixed with the update – Im now seeing a problem with cubemaps not exporting with the correct number of faces though.

    Its seems that now, a DDS cubemap – which was created with DirectX Texture Tool and is saved with RGB888 format, now only has one surface (face) when loaded via the PVRTexLib constructor pvrtexture::CPVRTexture(m_szSrcFile.c_str());
    Before all six faces loaded fine – but had the aforementioned offset bug, now the loaded header just reports and compresses one face to PVR.

    Here is the cubemap file im trying to convert:
    Test CubeMap

    #36713

    Hi Henry,

    The cubemap problem is a known issue – I accidentally wrote the wrong bitwise operator when checking for cubemap flags, and it means that it’s ignoring the additional faces in the DDS files. I fixed it in our codebase recently, and the fix will be in our next release, which should be out in the next couple of weeks.

    Thanks,
    Tobias

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