Welcome to Open Carnage

A resource for Halo Custom Edition and MCC modding, with unique means of rewarding content creation and support. Have a wander to see why we're worth the time! - EST. 2012

Zatarita

Ipak/Imeta - an incomplete specification

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 : constant = 1

    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 : unknown (usually 1, there are 5 exceptions, in all cases it's a power of two)

    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. 

Tucker933 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

Tiddy-bits:

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
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

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
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

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
  • Recently Browsing   0 members

    No registered users viewing this page.