Hi, we are having some issues with PVRTexLib:
- 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 64x64 texture reports as having 8 mipmaps, even including the base-texture, there should only be 7 images in a 64x64 mip-chain. (n+1) Mips for a (2^n) texture. The source DDS image reports as having the correct 7 mip-maps for a 64x64 image.
The extra mipmap is reflected in the converterd PVR texture which seems to have two 1x1 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 1x1 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 1x1 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.
