Compressed Texture formats vs Container File Formats

[JCPalmer]

I am probably talking to myself, but I have coded a solution for the 4 pvrtc texture formats inside a pvr container (file format).  It is based on Brandon Jones work (as is the dxt / dds code already in BJS).  When looking at the pvr file format spec, I noticed that there is a format element in the header (page 5) that has many more texture formats than just the 4.  It includes pretty much everything even dxt & astc.

Now, I think it would be a bad idea to use a pvr file container to hold dxt textures.  It does seem possible to use a pvr container for any of the rest.  Reason is that these WebGL texture extensions do not even know what a container file format is.  You or your framework is responsible for the sucking of the faces (for cube textures) & mipmap levels out of the file.  WebGL just has a compressedTexImage2D call where you pass it the data and a code for the format.

I know astc has it's own file container format (in addition to dxt), but not sure about etc1/2 & atc.  Anyone have a workflow for generating any of these texture formats, & know what container format is used?  Used PVRTexToolGUI  or PVRTexToolCLI, maybe?

The intelligent texture selector is enabled by calling engine.setTextureFormatToUse() with the extensions of the formats you have to pick from on the server prior to loading any textures.

/**
 * Set the compressed texture format to use, based on the formats you have,
 * the formats supported by the hardware / browser, and those currently implemented
 * in BJS.
 * 
 * Note: The result of this call is not taken into account when texture is base64 or when
 * using a database / manifest.
 * 
 * @param {Array<string>} formatsAvailable - Extension names including dot.  Case
 * and order do not matter.
 * @returns The extension selected.
 */
public setTextureFormatToUse(formatsAvailable : Array<string>) : string {

Since I do not have .astc exposed on any of my hardware (Apple A8's do support it though), I will table any decision whether to use it's container format or pvr.  I am going to rework into a PVRContainer class and a PVRTCTools class that is a subclass.  Separating will make things a little more modular.  If I can come up with a way to figure out the how to detect the container type, even dxt could be separated from it's native container.  The big plus would be you could use either the GUI or CLI tools above for all, I think.  Would need help to do that though for dxt, @Deltakosh.