chrrox wrote:I have looked at some of the textures it looks like the textures are only getting half extracted.
If you add a normal DDS header on the images you will see the image go in and out like only half is there. Maybe there is some more compression on the textures. But I am also not the best on image formats so I am not sure.
I'm looking at a texture about which the H-cache PNG file says max. res. = 2048 pixels.
Assuming this indicates a square size this would result in a DXT1 file of 2,796,344 bytes (with full MipMaps).
A DDS header size is 128 bytes, and adding the size of the B-cache PNG file, plus the size of the F-cache PNG file, results in the same number. Still the image is mixed up: it's kind of 'interlaced', structures can be recognized but are repeated twice horizontally.
Looking at the model's UVs, it looks like indeed the image should be repeated twice (for left and right), only the image rows should be reordered. Such reordering strongly suggest a non-DXT1 encoding per MipMap, although it seems similar.
The file size of the F-cache PNG file strongly suggests 4bpp, which only leaves the options of (1) DXT1 or (2) RGB with a 16-color palette. Another option (3) might be 2048x1024 (non-square) 8bpp with full MipMaps.
Taking the last 2,097,152 bytes from an F-cache PNG file, and adding a BMP header with a 4bpp 256-color palette, results in a mixed up image: it's kind of 'interlaced', structures can be recognized, and there is no repetition.
Another example is an F-cache PNG file of 1,376,256 bytes, about which the H-cache PNG file says: "Compression=COLOR_SMOOTH_ALPHA". So I'm guessing this must be a square 1024 pixel DXT5 image, and again the file size fits the bill: 128 + 21872 + 1376256 = size of DXT5 1024 pixels square with full MipMaps. Again the image is mixed up: structures can be recognized but are repeated horizontally.
The size of B-cache PNG files suggests that they actually hold some of the smaller MipMaps.
In case of the above supposed DXT5 file, the size of the B-cache PNG file corresponds to a DXT5 image of 128 pixels square with full MipMaps. Putting a header on it produces a garbled image.
In the contents of H-cache PNG files there are indications about max. res., compression and color space.
At the end of such a file I'm typically seeing ~22 floats, quite often equal to 1 or ~0.5. Maybe these numbers indicate gamma correction / color correction per MipMap. This all suggest that the textures have been saved with a tool that offers much more control over the pixel format. Looking at a tool like PVRTexTool you can see that there are much more options for creating a MipMapped texture than the relatively simple (!) NVidia plugin for Photoshop.
Warframe uses a DLL called 'libEGL.dll', which provides support for OpenGL ES 2.0.
With PVRTexTool it's possible to encode for this pixel format.
Encoding and MipMapping with 'OpenGL ES 2.0 ETC1' results in a file size that corresponds to a Warframe texture size, only now there is an 148 bytes header.
I can add such a header to Warframe files, but now I have no program to view the result..
Anyway, maybe "Game Format Scanner" can solve this (
viewtopic.php?f=18&t=12224 ).