ff8 monsters : .dat files analysis

[myst6re]

Hello!
I currently working on the dat files of Final Fantasy VIII. So I put everything on the wiki I found on theses files:
http://wiki.qhimm.com/FF8/FileFormat_DAT (thanks to JWP and Mirex)
But... the model animation section is hard to understand, and without it, my 3d models are... incomplete:

Anyone know how to interpret this section? help...

 

[obesebear]

I know Mr Adults (aka Rich Whitehouse) over at richwhitehouse.com has cracked the FF8 model format.  Might be good to see if he can give you some pointers.

 

[random_npc]

I can't help for the model section, but if you need some informations about the AI section, you can ask me.

 

[ultima espio]

MrAdults blew it open months ago

His new model viewer can view them, with animations too. Just ask him

 

[myst6re]

Okay, thank you for your replies, I watched Mr. Adults' tools, and "mesh2rdm" supports battle models. I also saw that "Noesis" read them very well.
I'm going to ask how MrAdults did it.

I can't help for the model section, but if you need some informations about the AI section, you can ask me.

I'm interested, I will think when the time comes because I want to completely fill the page on the wiki.

 

[random_npc]

Just to avoid confusion : I just look at the wiki, the part I meant is section 8 ('Battle scripts'), not section 5.

Some informations here looks a bit weird. It says section4 : unknown, section5: Ai scripts?; section10=sounds and section 11=textures, but if you take the common galbadian soldier for example, headers 4 & 5 are the same, and so are headers 10 & 11.

I wonder about sounds. If you replace the whole pampa .dat file with Ifrit's, on pampa island you'll met some Ifrits that will still use pampa sounds...

 

[myst6re]

Thank you for the clarification, I wasn't sure for these sections.



Edit: section 7 completed!

Edit 2:

Some informations here looks a bit weird. It says section4 : unknown, section5: Ai scripts?; section10=sounds and section 11=textures, but if you take the common galbadian soldier for example, headers 4 & 5 are the same, and so are headers 10 & 11.

Although section 4 starts at the same position as section 5, there are still 11 sections. It simply means that section 4 is empty.

 

[random_npc]

Nice work!

Just one thing I'd add - for abilities :

May be 0x02 (= magic) or 0x08 (= monster ability).

...or 0x04  (=item).

 

[myst6re]

Damn, I had not seen this case. Raijin I suppose? I'll check that there is no other cases. thanks!

 

[random_npc]

Yes, Raijin it is   

(or my edited galbadians, which are using several items as well)

 

[myst6re]

I don't know if Mr. Adults answer me someday...

 

[Chev]

I hope it's not necro bumping that one up since it's still on the first page. I started implementing the specs written on the wiki and the vertices seem to come out fine, but I get some weird values for the triangles and quads (like index 32000 or so for one of the vertices), so I still need to find the flaw in my geometry reader, but after that I'm gonna try my hand at the animation data.

EDIT: in fact yeah, that's really weird, the values always seem to be off by 0x8000 in the first index of each face/triangle.

 

[sl1982]

I hope it's not necro bumping that one up since it's still on the first page. I started implementing the specs written on the wiki and the vertices seem to come out fine, but I get some weird values for the triangles and quads (like index 32000 or so for one of the vertices), so I still need to find the flaw in my geometry reader, but after that I'm gonna try my hand at the animation data.

EDIT: in fact yeah, that's really weird, the values always seem to be off by 0x8000 in the first index of each face/triangle.

We are taking a soft stance to necro'ing these days. If it seems that there is useful information in your post it will be allowed.

 

[Chev]

OK then. Well, I finally decided to just substract 0x8000 from each triangle/quad's first index and they all seem to make a lot more sense now, so I'll take a shot at assembling a mesh tomorrow. It's sorta really weird how much space seems to be wasted in .dat models though, with the huge empty stretches in bones or those seemingly useless bits. Ah well, what's important is that it works.

 

[Dark_Ansem]

what about animations, chew?

 

[myst6re]

OK then. Well, I finally decided to just substract 0x8000 from each triangle/quad's first index and they all seem to make a lot more sense now, so I'll take a shot at assembling a mesh tomorrow.

I had forgot to talk about this substraction. You can do "poly3.vertex_indexes[0] &= 0x7FFF;". I have edited the wiki page.

 

[Chev]

OK! I was wondering if maybe that bit being set was a psx-specific thing and they'd gotten rid of that on PC or something, but I guess it's not the case.

Dark_Ansem> well, one thing at a time, I'll have a much better shot at seeing if I'm on the right track with anims once I get the mesh displayed. I'm still going over the mesh assembling code I originally made for the FF9 viewer, I've had an exhausting day so it's not progressing very fast. While I'd love to start on anims tomorrow the weekend's probably a more realistic target. Plus I can't yet be sure it'll amount to anything, since So far all of my work has mostly been following existing specs. But fingers crossed.

All I can say for now is the anim section starts just like the texture section, ie there's a uint32 anim count, then anim_count uint32 offsets from the beginning of the block to each anim, but that's already on the wiki.

EDIT: I used the already existing (though not quite getting everything right) model viewer from kvaks to spot a few potentially interesting files, namely c0m080, one of NORG's orbs (two bones, one anim that's not moving at all) and c0m125, one of Ultimecia/Griever's spirals (first two anims are respectively rotating clockwise around the vertical axis and counterclockwise), which hopefully ought to simplify figuring out the format quite a bit. Well, we'll see.

 

[myst6re]

EDIT: I used the already existing (though not quite getting everything right) model viewer from kvaks to spot a few potentially interesting files, namely c0m080, one of NORG's orbs (two bones, one anim that's not moving at all) and c0m125, one of Ultimecia/Griever's spirals (first two anims are respectively rotating clockwise around the vertical axis and counterclockwise), which hopefully ought to simplify figuring out the format quite a bit. Well, we'll see.

Yes I have the same approach.

 

[Chev]

Ok, so let's take the spiral rotations as an example, both 20 frames animations of rotations on a single axis. In the clockwise one there's a 36 bit pattern that goes (in little endian, and the start may not actually be at that bit so the whole thing could be shifted)

Code: [Select]

0    0    C    7    6    E    1    0    00000 0000 0011 1110 0110 0111 1000 0000 0000

and in the counterclockwise one there's, with the same offsets,
Code: [Select]

0    0    C    B    9    1    0    0    00000 0000 0011 1101 1001 1000 0000 0000 0000

Now, if you just take bits 14 to 25 (leftmost bit being 1), 12 bits in total, you have
Code: [Select]

110 0110 0111 1 in little endian111100110011  in big endian

which is 3891, aka -205, about -18 degrees with 12 bit angles

Code: [Select]

101 1001 1000 0 in little endian000011001101  in big endian

         
which is 205, about 18 degrees

20 frames animation, 18 degrees by frame, so full revolution per anim cycle, delta stored. We're on the right track! Since the animation really only rotates on a single axis the three preceding bits, 0x7, must be some kind of flag. And, well, 0x7 followed by a 12 bit angle, that really looks like FF7's compressed rotations thingie. So I'm gonna choose, as a work hypothesis, that it indeed works kinda like that and see where it gets me.

I'm rather unhappy with the 21 remaining zeros though, with a FF7-like system if I understand correctly I should be getting a lot less of them.

 

[Vehek]

I think that section 4 is texture-animation data (for example, eye-blinks).

The section begins with a list of 16-bit offsets into the section for the different animations. Unfortunately, there doesn't seem to be a count of how many different texture animations the model has. Many models have 0000 as their first offset. I assume that this is for models that don't always have a texture-animation running.

This is what I have so far for an individual texture-animation. It's all guesswork and I haven't checked it ingame yet.
Code: [Select]

struct texAnim{ uint8 textureNum; uint8 originalUCoord; //All UV coords here are for the upper left corner uint8 originalVCoord; uint8 regionUSize; uint8 regionVSize; uint8 copiedRegionCount; //1 less than the actual number uint8 unknown1; uint8 unknown2; //Insert remaining UV coords here};

I always have to double the "U" part of the UV coords and region-size to get a reasonable U coord/size. Maybe it has something to do with how the TIM format works?