-
Notifications
You must be signed in to change notification settings - Fork 263
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
imageSize set incorrectly for unpacked cubemaps #40
Comments
It now looks like there's a difference between Basis interpretation of KTX format and Khronos' interpretation in libktx (and PVRTexTool interpretation). I had thought that Basis was only writing one image per cubemap. However having debugged the unpack process, I can see it is writing six images. However, libktx inerprets the 32 bit value before each texture as being the number of bytes per image (“faceLodSize” here https://github.com/KhronosGroup/KTX-Software/blob/master/lib/texture.c#L958) Basis on the other hand writes that value having multiplied the bytes per image by the number of faces https://github.com/BinomialLLC/basis_universal/blob/master/basisu_gpu_texture.cpp#L689 This is the format used in Khronos' own example cubemap KTX files, e.g. cubemap_yokohama_etc2_unorm.ktx The KTX spec says
This difference in interpretation results in libktx returning KTX_FILE_UNEXPECTED_EOF when it tries to read the data; it is reading 6x the data per image. I've an experimental fix to Basis (move the |
Hi - Yea, this looks like a bug. I wrote a KTX reader/writer class a few years ago, and did this the way you and the standard describe. |
I've checked in a fix for this: Please let me know if this doesn't fix the problem. I tested with PVRTexTool, and it still loads the cubemap .ktx files written with basisu.exe okay. |
Thanks Rich. With your patch the assertion at line 709 fails
See my pull request for how I handled it. |
Whoops! I made that fix half asleep, and missed that. I've checked in a fix (I just removed the assert). |
There's either a problem with my understanding and use of the tools or a problem with the KTX output by basis.
I am trying to use basis to convert six images into KTX files each containing a cubemap.
I have the six images (files from here https://github.com/ARM-software/opengl-es-sdk-for-android/tree/master/samples/advanced_samples/Skybox/assets converted into PNGs with imagemagick).
I run
basisu greenhouse_skybox-*.png -tex_type cubemap -output_file cubemap.basis
The output is:
I then run basis to unpack the file
basisu cubemap.basis
Output:
However if I load one of the KTX files (e.g.
cubemap_transcoded_cubemap_ETC2_0.ktx
) using libktx,ktxTexture_CreateFromNamedFile
withKTX_TEXTURE_CREATE_LOAD_IMAGE_DATA_BIT
, libktx returnsKTX_FILE_UNEXPECTED_EOF
.On inspection it appears as if, despite “numFaces” being 6 in the KTX file, only a single face image is present in the file. Similar results are seen using
ktxTexture_GLUpload
.I have tried adding
-tex_type cubemap
to the unpack call but that didn't change the output.Output from a libktx-based tool run on
cubemap_transcoded_cubemap_ETC2_0.ktx
shows the following header data. dataSize does imply there’s just one face image in the KTX.Could you either check my use of the tool, or comment on the suggestion there might be a problem with basisu generating KTX files with numFaces set to 6 but only one face image in the file.
Jim
The text was updated successfully, but these errors were encountered: