Posted July 15, 2020 (edited) OK, so I'm running into some stress dealing with importing ipak/imeta into SuP. I decided to take a break, and write this up. IPAK/IMETA First of all. Why are they included together? ipak, and imeta are BASICALLY the same thing, the only difference is the ipak contains the actual texture data. Preface To start, just like with s3dpak, you need to decompress the data with ceaflate. The file format is little endian, and this data is close to complete; however, not 100% The Header The header for is very simple, just 8 bytes. 4 bytes : Child count 4 bytes : padding The Imeta The data present in the Imeta is in both the ipak, and the imeta. I'm assuming the reason for this is so the game doesn't have to load every texture in the ipak, and instead can grab only what it needs. This will make more sense in a min. This makes modding the file a little more difficult, as you need to edit two different files. Think of the ipak as a giant gallery of paintings, and the imeta as the directory. You have a directory for each floor (the imeta for each level) but you can also have an over view of everything in the entire building (the ipak's imeta) The format is as follows: string (256 bytes): texture name with no extension 8 bytes : padding 4 bytes : constant = 1 4 bytes : width 4 bytes : height 4 bytes : depth 4 bytes : mipmap count 4 bytes : face count (only 1 face, or 6 faces for cubemaps) 4 bytes : type (see below) 8 bytes : pad 4 bytes : size 4 bytes : pad 4 bytes : size 4 bytes : offset 4 bytes : pad 4 bytes : size 4 bytes : pad Why the size is there three times, I dunno. From what I've seen poking around, I haven't noticed any variation. This engine seems to be rather redundant in many different ways. The offsets must start at : 0x00290008. meaning there is only enough space for 8192 (0x2000) imetas in an ipak (with 8 bytes of padding). the "type" is a hex enumerated representation of the dxt format used. 0x0a : "AI88" - No block compression. 0x30 : "AI88" (for whatever reason "part plasma" uses this, and that's basically it) 0x46 : "AXT1/OXT1" - BC1 0x49 : "XT3" - BC2 0x4c : "XT5" - BC3 0x4f : "XT5A" - BC4 0x52 : "DXN" - BC5 0x5a : "ARGB8888/XRGB8888" - No block compression The Ipak The Ipak data starts at offset 0x00290008 as stated above. Each entry has it's own header, and the data contained in these blocks are simply just .dds textures stripped of their header. The header is as follows: signature : f0 00 ff ff ff ff 54 43 49 50 02 01 ff ff ff ff 4 bytes : Image Width 4 bytes : image height 4 bytes : depth 4 bytes : face count singature2 : f2 00 ff ff ff ff (4 bytes unknown) f9 00 ff ff ff ff 4 bytes : mip map count start of data: ff 00 ff ff ff ff .... .... footer : 01 00 ff ff ff ff There are a few unknowns in here I'm working to figure out, but for the most part the things labeled "signature" are fairly consistent (except the 4 bytes of unknown in the middle) Most of this is pretty self explanatory. (You can reconstruct the .dds header using the known information using : https://docs.microsoft.com/en-us/windows/win32/direct3ddds/dds-header) The Ipak also has padding tacked onto the end of each file. It's literally just 2,097,151 (0x1fffff) bytes of null data. Edited October 18, 2020 by Zatarita Takka and Vaporeon like this Specifications: S3dpak - format - Imeta/ipak - format - Fmeta - format Programs: H2a-inflate - SuP Share this post Link to post Share on other sites
Posted July 15, 2020 Nice job figuring this out. Have you noticed any correlation between bitmaps that match the tagdata in size and ones that do not? Share this post Link to post Share on other sites
Posted July 15, 2020 Just now, Vaporeon said: Nice job figuring this out. Have you noticed any correlation between bitmaps that match the tagdata in size and ones that do not? I don't know what you mean, I haven't noticed any discrepancies. I ran into an issue originally with SuP, and I found out the issue was rawtex. It didn't extract mipmap, and face data so it would be cut off. Specifications: S3dpak - format - Imeta/ipak - format - Fmeta - format Programs: H2a-inflate - SuP Share this post Link to post Share on other sites
Posted July 15, 2020 Some bitmaps in the ipak are larger in resolution compared to what the Halo cache file tag data says. Mainly the HUD bitmaps. Share this post Link to post Share on other sites
Posted July 15, 2020 1 minute ago, Vaporeon said: Some bitmaps in the ipak are larger in resolution compared to what the Halo cache file tag data says. Mainly the HUD bitmaps. Interesting, I actually haven't looked into the blam side of things yet; however, I'll look into it see what I can figure out. That could explain the other "size" variables Specifications: S3dpak - format - Imeta/ipak - format - Fmeta - format Programs: H2a-inflate - SuP Share this post Link to post Share on other sites