My question is about “PVRTexLib”. I am using an old version of the library “3.20”. My question is about the cubemaps.
I created a cubemap (dds file) using DirectX Texture Tool. The image is a simple one with numbers from 1 to 6 marked on each surface.
+X ---- 1
-X ---- 2
+Y ---- 3
-Y ---- 4
+Z ---- 5
-Z ---- 6
Now I opened the dds file using the “PVRTexLib” and created a PVR file using the library
<br />
std::string cubemap[] = { "../images/numbers.dds", "../images/numbers.pvr" };<br />
CPVRTexture sOriginalTexture(cubemap[0].c_str());<br />
sOriginalTexture.writeToFile(cubemap[1].c_str());<br />
```<br />
<br />
When I opened the resultant PVR file in the "PVRTexTool", the image surfaces are changed to<br />
<br />
+X ---- 5<br />
-X ---- 6<br />
+Y ---- 1<br />
-Y ---- 2<br />
+Z ---- 3<br />
-Z ---- 4<br />
<br />
Is this a bug in this version of the library or am I doing something wrong? If you guys want some more details I have created a sample project. It includes the header files, library files and dll I am using. The sample dds file is also included.<br />
<br />
You guys can download the sample program and images from <a href="https://drive.google.com/file/d/0ByWTs9CI_TeRM2hyVnVWY01UUlE/edit?usp=sharing">https://drive.google.com/file/d/0ByWTs9CI_TeRM2hyVnVWY01UUlE/edit?usp=sharing</a>
It’s a weird bug, caused by a strange decision to support a “DX” and “GL” mode of handling the cube map order in the old version. In actual fact there’s no such thing - so I’m not sure where this weird alternative way of handling the two came from… Unfortunately it does this swapping silently, and in a limited set of cases, as there’s no explicit flag to change the order.
I suspect if you compress it to an OpenGL format and then back to the original format, it would fix it, but this would be slow. I think you’ll have to manually swap round the faces to get them in the correct order.
Out of interest, are you viewing these pvr files in the new version of PVRTexTool? I would have thought it’d be ok in the old version…
Out of interest, are you viewing these pvr files in the new version of PVRTexTool? I would have thought it’d be ok in the old version…
Yes I am using a new version of PVRTexTool (4.1.3) to view the pvr files.
compress it to an OpenGL format and then back to the original format
I cannot do an additional compression and decompression, because as you said it will affect performance and I suspect it will reduce the image quality also.
you'll have to manually swap round the faces to get them in the correct order
I found another problem in doing it manually as you suggested.
If I use the latest "PVRTexToolCLI.exe" tool to create the legacy file ("PVR version2"), This will generate the cube map correctly. That means all the faces will be in correct order while viewing in the latest "PVRTexToolb (4.1.3) ".
But if I read the image using the "PVRTexLib 3.20" the faces are read like below
+X ---- 5
-X
6
+Y ---- 1
-Y
2
+Z ---- 4
-Z
3
Here the faces "+Z" and "-Z" are swapped in a different way(In the original question +Z was 3 and -Z was 4).
I cannot guarantee how the PVR images will be made. So I think I am left with only one option, to update the "PVRTexLib " :)
