Author Topic: FF8 Field Models - More information  (Read 13625 times)

Vehek

  • *
  • Posts: 215
    • View Profile
FF8 Field Models - More information
« on: 2012-07-01 04:32:21 »
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.
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   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)
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
« Last Edit: 2012-07-01 10:21:29 by Vehek »

myst6re

  • *
  • Posts: 639
  • Light King of the Savegame - Field Master - FF8.fr
    • View Profile
    • FF8.fr
Re: FF8 Field Models - More information
« Reply #1 on: 2012-07-01 12:20:47 »
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?
« Last Edit: 2012-07-01 14:36:03 by myst6re »

Vehek

  • *
  • Posts: 215
    • View Profile
Re: FF8 Field Models - More information
« Reply #2 on: 2012-07-01 17:42:37 »
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.
« Last Edit: 2012-07-01 18:15:39 by Vehek »

myst6re

  • *
  • Posts: 639
  • Light King of the Savegame - Field Master - FF8.fr
    • View Profile
    • FF8.fr
Re: FF8 Field Models - More information
« Reply #3 on: 2012-07-01 19:09:39 »
You should give me the complete structures for Face and Skin-Object data, I may write errors ^^.

Vehek

  • *
  • Posts: 215
    • View Profile
Re: FF8 Field Models - More information
« Reply #4 on: 2012-07-02 03:48:39 »
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_opcode
BYTE unk[4]
SHORT unkTransp //if this AND's with 0x04, sets semitransparency
BYTE unk2[2]
SHORT vertices[4]
SHORT vertices2[4]
DWORD Vertex_colors[4]
BYTE u1
BYTE v1
BYTE u2
BYTE v2
BYTE u3
BYTE v3
BYTE u4
BYTE v4
SHORT unused1?
SHORT textureNum
SHORT unused2?
SHORT unused3
SHORT unused4
SHORT 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

  • *
  • Posts: 639
  • Light King of the Savegame - Field Master - FF8.fr
    • View Profile
    • FF8.fr
Re: FF8 Field Models - More information
« Reply #5 on: 2012-07-02 10:49:51 »
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

  • *
  • Posts: 1572
    • View Profile
Re: FF8 Field Models - More information
« Reply #6 on: 2012-07-18 00:36:01 »
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

  • *
  • Posts: 215
    • View Profile
Re: FF8 Field Models - More information
« Reply #7 on: 2013-03-17 06:13:29 »
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.

Code: [Select]
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.
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

  • *
  • Posts: 41
    • View Profile
Re: FF8 Field Models - More information
« Reply #8 on: 2018-03-29 18:43:38 »
Can you explain more about bone and animation data?
« Last Edit: 2018-05-07 09:47:53 by red_evilspirit »

red_evilspirit

  • *
  • Posts: 41
    • View Profile
Re: FF8 Field Models - More information
« Reply #9 on: 2018-05-30 18:46:10 »
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

  • *
  • Posts: 215
    • View Profile
Re: FF8 Field Models - More information
« Reply #10 on: 2018-05-30 19:21:31 »
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

  • *
  • Posts: 41
    • View Profile
Re: FF8 Field Models - More information
« Reply #11 on: 2018-06-01 18:18:17 »
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 bytes
0x14: MCH name? Not sure if used. (4 bytes)
0x18: 4 unknown bytes

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

Animation Header:
WORD Number of frames
WORD 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

===========================
Quote
32-bit? Upper 16-bits
Does it like this?
Code: [Select]
type = readUInt()
type >> 16
« Last Edit: 2018-06-03 02:53:52 by red_evilspirit »