So for all compressed data the layout is a little different, though still effectively the same. All compressed data formats have a “minimum width/height” which is the lowest number of pixels than can be represented by any given block/region in a compressed image. There is a function in our tools, “PVRTGetFormatMinDims” which lists these dimensions for each format if you need a reference.
The first step is to align the width and heigh values to these minimum width/heights, so for a min width/height of 4, a 511x511 image becomes 512x512. This constitutes any texture padding done to meet the compression format’s requirements, and is essentially garbage data, but it needs to exist for the format to be valid. All you then need to do is work out the number of blocks/regions from this, and copy that many. At this point there are only 2D compression formats, so depth will function as a number of individual slices, and can for now be treated normally.
For each individual block/region, the bits per pixel are listed in another function; “PVRTGetBitsPerPixel” which helps determine the block/region size.
So to update the specification, it looks like this:
for each MIP-Map Level in MIP-Map Count
for each Surface in Num. Surfaces
for each Face in Num. Faces
for each Block/Region by aligned Depth (Based_On_PixelFormat)
for each Block/Region by aligned Height (Based_On_PixelFormat)
for each Block/Region by aligned Width (Based_On_PixelFormat)
I hope that makes sense?
Let me know if you need further clarification. I’ll also file a bug to update the documentation with an explanation.