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 dataHere, 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.
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.
