Miscellaneous Forums > Scripting and Reverse Engineering
FF8 Field Models - More information
myst6re:
Okay, it's added to the wiki.
--- Quote from: Vehek on 2012-07-02 03:48:39 ---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?
--- End quote ---
Maybe it's the number of animated texture only.
Cyberman:
--- Quote from: Vehek on 2012-07-02 03:48:39 ---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?
--- End quote ---
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 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: ---struct
{
u16 animationCount;
Animation[animationCount];
}animationData;
struct
{
u16 frameCount;
u16 boneCount
AnimationFrame[frameCount]
}Animation
struct
{
s16 coordinatesShift[3];
Rotation[boneCount];
}AnimationFrame;
--- End code ---
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: ---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;
--- End code ---
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.
--- Quote from: Cyberman on 2012-07-18 00:36:01 ---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.
--- End quote ---
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: ---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;
--- End code ---
=>
--- Code: --- 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)
--- End code ---
when i print 'rotations', it didn't look like degrees of rotation.
What should i do to get correct degrees of rotation?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version