FF8 Field Models - More information

[Vehek]

This is what I've learned about the FF8 MCH format, to add on to the information already collected.
Model header

Offset   Length   Description0x1C   0x02   Triangle count0x1E   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.
Code: [Select]

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   Description0x08   0x02   When bit 0x04 set, face has semi-transparency0x36   0x02   Texture index

Undescribed data between faces and skin-objects
Seems to split up the skin-objects, triangles, and quads.
(A guess)
Code: [Select]

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

 

[myst6re]

Wow, thank you for this supplementary informations, It must be added to the wiki!

Edit: I am currently editing the wiki: for face data the offset 0x36 is already in use by Vertex UV, it is a mistake?

 

[Vehek]

The information in the wiki entry is misaligned due to its creator not knowing about/not making use of the section offsets in the model header, and therefore not being able to skip around the unknown sections. Faces are supposed to begin with the Polygon Type. This affects the skin objects as well, which actually start with the start vertex.

Edit: Mixed up what the skin-objects start with. Fixed.

 

[myst6re]

You should give me the complete structures for Face and Skin-Object data, I may write errors ^^.

 

[Vehek]

Faces
Here's JWP's version, with my additions:

struct face {
   u32 opcode; 0x07060125 = triangle, 0907012d = Quad
   BYTE unk[4];
   SHORT unknown; //When bit 0x04 is set, sets semitransparency
   BYTE unk[2];
   u16 verticies[4]; //vertex id's
   u16 verticies1[4]; //Edge data???
   u32 Vertex_Colours[4];
    TextureMap TextureData[4]; //haven't tested yet
    u16 Padding;
    u16 textureIndex;
    u32 padding[2];
   //64 bytes
};

Here's the structure I keep in my notes
Code: [Select]

DWORD gpu_opcodeBYTE unk[4]SHORT unkTransp //if this AND's with 0x04, sets semitransparencyBYTE unk2[2]SHORT vertices[4]SHORT vertices2[4]DWORD Vertex_colors[4]BYTE u1BYTE v1BYTE u2BYTE v2BYTE u3BYTE v3BYTE u4BYTE v4SHORT unused1?SHORT textureNumSHORT unused2?SHORT unused3SHORT unused4SHORT unused5

Skin Objects

I don't think mine is any different than what Qhimm wrote many years ago, but here it is anyway.
Code: [Select]

?short vertexNum??short numOfVertices??short bone-index??short unknown?

--
I've found that the model known as "n028" (Red Giant, in fejail1) has a value of 3 for its second bye of its texture animation data, but has 4 textures. Does this disprove my idea of it being the texture count? Out of 232 field models with texture animations, this is the only one that doesn't match up.

Anything else I should post about the format?

 

[myst6re]

Okay, it's added to the wiki.

I've found that the model known as "n028" (Red Giant, in fejail1) has a value of 3 for its second bye of its texture animation data, but has 4 textures. Does this disprove my idea of it being the texture count? Out of 232 field models with texture animations, this is the only one that doesn't match up.

Anything else I should post about the format?

Maybe it's the number of animated texture only.

 

[Cyberman]

I've found that the model known as "n028" (Red Giant, in fejail1) has a value of 3 for its second bye of its texture animation data, but has 4 textures. Does this disprove my idea of it being the texture count? Out of 232 field models with texture animations, this is the only one that doesn't match up.

Anything else I should post about the format?

Post anything you find it hopefully will end up in the wiki.
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. More eyes looking at the data will help.

Last but not least thank you for posting the information I have been in my "spare time" started back to working on the FF8 data. It is appreciated to not have to rediscover a wheel (over and over again).

Cyb

 

[Vehek]

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 bones0x24    4 bytes    Offset of vertices0x28    4 bytes    Offset of texture animations0x2C    4 bytes    Offset of faces0x30    4 bytes    Offset of unknown data0x34    4 bytes    Offset of skin objects0x38    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.

Code: [Select]

struct{u16 animationCount;Animation[animationCount];}animationData;struct{u16 frameCount;u16 boneCountAnimationFrame[frameCount]}Animationstruct{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.
Code: [Select]

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.

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.

 

[red_evilspirit]

Can you explain more about bone and animation data?

 

[red_evilspirit]

I got offset of animation data in d024.mch (low Rinoa model)

I do something like this
Code: [Select]

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;

=>
Code: [Select]

 rots1 = readUByte() rots2 = readUByte() rots3 = readUByte() rots4 = readUByte() rotation1 = (rots1 << 0x02) | ((rots4 << 0x0A) & 0xC00) rotation2 = (rots2 << 0x02) | ((rots4 << 0x08) & 0xC00) rotation3 = (rots3 << 0x02) | ((rots4 << 0x06) & 0xC00)

when i print 'rotations', it didn't look like degrees of rotation.
What should i do to get correct degrees of rotation?

 

[Vehek]

Been a long time, but I think you divide it by 4096 to get the percentage of a full revolution, then convert it to whatever angular measure unit you're using. But the MCH models in main_chr.fs (like d024.mch you're viewing) don't use that packed system I described. They use simple 16-bit (2-byte) integers. All the real animations anyway aren't in those model files, but part of the chara.one files in the archives for each field.

 

[red_evilspirit]

Following your post, i knew the animations are stored in chara.one files. I just thought i can get T-pose with that code.
----------------------------
I found this in an old topic.

My guess on how the chara.one files work. Might be incorrect because I didn't do any disassembly or testing in-game.

Code: (Chara.one Header Hypothesis) [Select]

0x00: Number of PC and NPC models (32-bit). Might not count for calculating offsets.0x04: First model's header (detailed below)PC Model chara.one header:0x00: Pointer to animation data? (32-bit)0x04: Size of the animation data or whatever it is. (32-bit)0x08: Size again.0x0C: MCH number? (32-bit? Upper 16-bits might determine whether header refers to PC or NPC)0x10: 4 bytes0x14: MCH name? Not sure if used. (4 bytes)0x18: 4 unknown bytesNPC header:0x00: Pointer to first TIM (32-bit)0x04: Size of TIM & Model data (32-bit)0x08: Size again.0x10: MCH-type header possibly starts here. Offsets are relative to the TIM image.After the model data pointer: 8 unknown bytes.Both types usually end with the hex bytes "EE EE EE EE" after the unknown bytes, though there may be exceptions.

Edit: The next to last section (the section pointed to by the DWORD at 0x38 of the model data header) of the MCH model data looks similar to what I guessed to be the animation data in the chara.one files. So that might be the pose information.

Code: (Animation Section hypothesis) [Select]

Section Header:WORD Number of animationsAnimation Header:WORD Number of framesWORD Number of joints (Koral labeled them bones.)In that old thread, Qhimm said the animations were stored using 4 bytes per node. By counting I think there might also be an additional 6 bytes per frame, but I'm not absolutely sure.

Is it the structure of char.one ?
It look like http://wiki.ffrtt.ru/index.php/FF8/FileFormat_ONE, but i can't check when it is npc or main field model

===========================

32-bit? Upper 16-bits

Does it like this?
Code: [Select]

type = readUInt()type >> 16