KTX Cubemap export

[alisa101rs]

I believe, your KTX(1.0) exported for cubemaps has some bug.

According to the specification 2.16:

For most textures imageSize is the number of bytes of pixel data in the current LOD level. This includes all array layers, all z slices, all faces, all rows (or rows of blocks) and all pixels (or blocks) in each row for the mipmap level. It does not include any bytes in mipPadding.

The exception is non-array cubemap textures (any texture where numberOfFaces is 6 and numberOfArrayElements is 0). For these textures imageSize is the number of bytes in each face of the texture for the current LOD level, not including bytes in cubePadding or mipPadding.

But your exporter writes imageSize as number of bytes in 6 faces of the texture for the current LOD level.

[kopaka1822]

I think I tracked down the source of the "error". I use gli for importing and exporting ktx and dds files. The exporter does not check if its actually a single cubemap when writing the imageSize (and writes the number of bytes for all faces). Additionally, it doesn't even look at the value of imageSize during import (thats probably the reason why every cubemap import works, even if the meaning of imageSize may differ).

However, then I noticed that I always write either Texture2DArray, TextureCubeArray or Texture3D because a Texture2D is basically a Texture2DArray with a single slice and I was lazy. This means that the exporter actually writes "numberOfFaces = 6, numberOfArrayElements = 1" in which case the imageSize is correct.

Is writing a cube map array instead of a cubemap a problem for you? If yes, I can rework it, but it will take some time...

[alisa101rs]

I didn't notice that you write cubemap array with a single array element, then error is in my importer.

Thank you!

P.S. I looked at sources of gli, then don't check for a Cubemap imagesize, maybe they should rewrite exported? Or maybe I am the one who missunderstand the specification?