This is what I've learned about the FF8 MCH format, to add on to the information already collected.
Model header
Offset Length Description
0x1C 0x02 Triangle count
0x1E 0x02 Quad count
Undescribed data between vertices and faces
This appears to be texture-animations e.g. eye blinks. Its entry in the first part of the model header appears to be the length of the section, rather than the count.
Guess at structure. My names are rather rough.
struct
{
byte unknown
byte total_textures?
byte unknown
byte uSize
byte vSize
byte replacement_section_count
UV_pair original_area_coords
byte unknown[2]
UV_pair replacement_coords[replacement_section_count]
}
Face data
Offset Length Description
0x08 0x02 When bit 0x04 set, face has semi-transparency
0x36 0x02 Texture index
Undescribed data between faces and skin-objects
Seems to split up the skin-objects, triangles, and quads.
(A guess)
struct
{
uint16 start_skinobject_index
uint16 skinobject_count
byte unknown[12]
uint16 start_triangle_index
uint16 triangle_count
uint16 start_quad_index
uint16 quad_count
byte unknown2[8]
}
Some models (d049, d053, d075, and p019) have two of this data type.
Animations
The first 6 bytes of each animation frame are the coordinates shift (3 signed 16-bit numbers). I am only sure of the last one being the Z-shift.
Player models actually do have animation data after all, just in a different form than the one I documented in the field chara.one files. They use a simple six bytes per bone.
--
Edit: updated texture animation info
In this post, I'm starting off with things that were written a long time ago, but didn't make it into the wiki.
The model-data header lists the last 32 bytes as "unknown". It's really only the last 4 that are unknown. The rest are offsets. (As Qhimm wrote back in 2003!)
Offset Length Description
0x20 4 bytes Offset of bones
0x24 4 bytes Offset of vertices
0x28 4 bytes Offset of texture animations
0x2C 4 bytes Offset of faces
0x30 4 bytes Offset of unknown data
0x34 4 bytes Offset of skin objects
0x38 4 bytes Offset of animation data
Animation data
Here, I'm not only repeating what's written in previous threads, I'm also repeating what I said earlier in this thread.
It doesn't have to be written this way; it's just my preference to divide it up like this.
struct
{
u16 animationCount;
Animation[animationCount];
}animationData;
struct
{
u16 frameCount;
u16 boneCount
AnimationFrame[frameCount]
}Animation
struct
{
s16 coordinatesShift[3];
Rotation[boneCount];
}AnimationFrame;
The format of the rotation data differs between the files in main_chr.fs and standard-format chara.one files. In main_chr.fs, they are 3 s16s (6 bytes) per bone.
The other format is 4 bytes per bone. I'm not sure how to explain how it works in words. Shift each one of the first 3 bytes left 2 bits and use 2 bits from the 4th byte as bits 10 and 11?
Here's a generalized example in code.
unsigned char rots[4];
s16 rotations[3];
for (int i = 0; i < 3; i++)
rotations[i] = rots[i] << 2 | (rots[3] >> 2 * i & 3) << 10;
In a Blender script I wrote, I read the rotations in as ZXY, and apply them in YXZ order. I read the coordinates shifting as YXZ. (Not including possibly taking the negative of some parts for either rotations or coordinates)
Newer info:
1.
Let me ask you about the 'textures' are you sure the 4th texture isn't one that's is partially used? IE the texture is used 2 times either with a different palllete or with just specific sections of UV data. If you believe it has 4 textures you probably should do a dump and the visual information to show it.
I said there were 4 because that's how many different texture offsets exist in its model header from the chara.one file.
2.
"verticies1" in the face data doesn't seem to be ever read, so it can probably just be ignored.
The last 4 bytes of the model-data header also seem to be ignored.
3. Unknown data between faces and skin-objects
This is about when there are multiple entries in the unknown-data section. When I try to import d075 (Squall carrying Rinoa) or p019 (Galbadian on motorcycle), they don't look correct. I did a test by modifying d075 in a hex editor and was able to get similar if not exactly the same results in-game.
(http://i239.photobucket.com/albums/ff83/TtravelrKev/Final%20Fantasy/FF8_ModelUnknownDatatest_zpsbcb078cd.png)
After an examination of d075.mch, I think I know why this happened.
d075.mch is basically a merger of the lo-def Squall and Rinoa models. It has all the vertices and faces from them. (Exactly the total vertices and faces.) The first 286 vertices are Squall's, the other 306 are Rinoa's. The faces aren't in the exact same order, but a brief examination of a few of them shows the UVs and vertex indices are the same as in the Squall and Rinoa models.
Since the vertex indices in the faces of the Rinoa section are still the same as in her normal model, they're now off by 286. So those vertex indices need to be adjusted, or else the wrong vertices will be assigned.
Don't know if this is how it knows how much to adjust the indices by, but the two entries split the skin-objects between the ones belonging to Squall and the ones belonging to Rinoa. I also don't know how it knows which faces it needs to adjust. Maybe this point is where it uses the triangle/quad indices and counts?
--
This isn't anything new or old, but could you fix the vertex format on the wiki's MCH page? I don't think anyone's work has been affect by this, but it's claiming that vertices are far bigger than the 8 bytes that they are.