1
FF9 Tools / Re: [PSX] FF9 Blender Importer (0.2)
« on: 2024-06-03 18:49:09 »
Thank you very much! I'm only now catching up on the work you've done on FF9 and it's insanely impressive
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: [1] 2
2
FF9 Tools / Re: [PSX] FF9 Blender Importer (0.2)
« on: 2024-05-25 20:24:44 »
Version 0.2 is now available, now with field and map models texture support based on tasior2's informations!
3
FF9 Tools / [PSX] FF9 Blender Importer (0.2)
« on: 2024-05-20 07:41:50 »
Hello, it's been a while!
Remember that thread with a C# FF9 viewer I never released? Well, 15 years later, I've finally ported the code to a Blender 4.x add-on:
https://github.com/Chevluh/FF9_Blender_Importer
Note that it is in the exact same state it was back then. That is, support for battle and party models is fine, but field and overworld models will importtextureless and with haphazardly matched animations, and spell/summons aren't supported at all.
https://i.imgur.com/M3NnEwt.mp4
Over the years there have been other options for viewing FF9 models, but hopefully this can be of use to some people.
Remember that thread with a C# FF9 viewer I never released? Well, 15 years later, I've finally ported the code to a Blender 4.x add-on:
https://github.com/Chevluh/FF9_Blender_Importer
Note that it is in the exact same state it was back then. That is, support for battle and party models is fine, but field and overworld models will import
https://i.imgur.com/M3NnEwt.mp4
Over the years there have been other options for viewing FF9 models, but hopefully this can be of use to some people.
4
FF9 Tools / Re: [PSX] Online viewer / exporter - Rɘverse FF9 (0.0.4b)
« on: 2018-07-13 10:44:50 »
Given my past interest in FF9 models I do happen to have a copy of the offline version:
https://mega.nz/#!fXhVlKKB!WAUGdXvrdwG3K9igmvA3OEFk5UDKqjbiyQ41QAN1YYw
Make sure to make and upload some copies of your own so it may never again be lost.
https://mega.nz/#!fXhVlKKB!WAUGdXvrdwG3K9igmvA3OEFk5UDKqjbiyQ41QAN1YYw
Make sure to make and upload some copies of your own so it may never again be lost.
5
Scripting and Reverse Engineering / Re: FFIX - A question about locating data for weapons and abilities
« on: 2011-12-18 09:29:36 »
It's most certainly in directory 8, the one with the weapon models, each weapon chunk has 2 files (types 8 and 20) that don't contain graphical data. Would make sense since stuff like monster stats also isn't in the kernel but in the monster directories.
6
Scripting and Reverse Engineering / Re: ff9 bone structure
« on: 2011-12-16 19:47:53 »
Noesis works fine with FF9 models, there's a plugin for it, IIRC it now does everything my viewer used to do.
I haven't lost my viewer, time was the resource I started to lack, it still works as it used to, with a few extra little things (partial crappy support for map models) and slightly cleaner code.
The larger project is completely unrelated to FF or game model viewing, it's just convenient to reuse it for viewers because it has all the 3D and UI stuff already set up.
I haven't lost my viewer, time was the resource I started to lack, it still works as it used to, with a few extra little things (partial crappy support for map models) and slightly cleaner code.
The larger project is completely unrelated to FF or game model viewing, it's just convenient to reuse it for viewers because it has all the 3D and UI stuff already set up.
7
Scripting and Reverse Engineering / Re: ff9 bone structure
« on: 2011-07-23 11:25:24 »chev, will you release a beta of your software? or will there any release anytime soon?There won't be any anytime soon. There's tons of things to clean up, it has little to no interface and you need to recompile it to change directories. Plus it's really part of a bigger, unrelated program so it'd have to be isolated first, not to mention it's been two years since I made it so there's bit I'd have to rewrite just to understand them. And I don't have much time for personal programming nowadays, so I'm not really considering it.
Plus, well, the specs are known and available, so it's not like nobody can just do what I did. It took me one week full time to make it and half of it was figuring out what I'd read wrong, so I encourage others to do the same.
8
Scripting and Reverse Engineering / Re: ff8 monsters : .dat files analysis
« on: 2011-05-30 22:14:30 »Quote
Unfortunately, there doesn't seem to be a count of how many different texture animations the model hasWhile there is no count, that kind of list usually marks its end with a zero offset, so you could check for those if you haven't already.
For the coordinate transformation, I don't know. The closest thing I can think of is that in FF9 you have to shift the UV for the weapon textures because in-engine they're not loaded at the beginning of a texture page, but that would only account for translating the coordinates, not scaling them.
9
Scripting and Reverse Engineering / Re: ff9 bone structure
« on: 2011-04-18 19:49:30 »
Personnally I never figured out where the textures for dir 4 or dir 3 (map models) are, but then again I didn't have a good way to browse the directories.
10
Scripting and Reverse Engineering / Re: ff9 bone structure
« on: 2011-04-17 15:03:05 »
Good work!
11
Scripting and Reverse Engineering / Re: ff9 bone structure
« on: 2011-04-17 08:21:28 »
Root bone length is indeed irrelevant. Your bone structure is right. Even though it may not intuitively look like the same skeleton as mine when it's unfolded like that, it is, down to the very byte. It'll make more sense once you solve your angle problem.
For the animation I have different numbers, but that's probably because I am looking at a different anim. Hopefully what you need to correct i exactly what I did back then, the transformation order. In XNA it was yaw*pitch*roll*translation(0,0,bonelength) *parentTransform, so if my basic opengl isn't too bad it should be the reverse, and probably with a translation axes switched around. So something like:
glPushMatrix ();
glTranslatef (root-> length, 0.0, 0.0);
glRotatef (root-> roll, 0.0, 0.0, 1.0);
glRotatef (root-> pitch, 1.0, 0.0, 0.0);
glRotatef (root-> yaw, 0.0, 1.0, 0.0);
More or less. Basically translate first and switch the angles/coords around, and it'sprobably not gonna make sense visuall until you hit just the right order.
For the animation I have different numbers, but that's probably because I am looking at a different anim. Hopefully what you need to correct i exactly what I did back then, the transformation order. In XNA it was yaw*pitch*roll*translation(0,0,bonelength) *parentTransform, so if my basic opengl isn't too bad it should be the reverse, and probably with a translation axes switched around. So something like:
glPushMatrix ();
glTranslatef (root-> length, 0.0, 0.0);
glRotatef (root-> roll, 0.0, 0.0, 1.0);
glRotatef (root-> pitch, 1.0, 0.0, 0.0);
glRotatef (root-> yaw, 0.0, 1.0, 0.0);
More or less. Basically translate first and switch the angles/coords around, and it'sprobably not gonna make sense visuall until you hit just the right order.
12
Scripting and Reverse Engineering / Re: ff8 monsters : .dat files analysis
« on: 2011-03-24 21:27:50 »
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)
and in the counterclockwise one there's, with the same offsets,
Now, if you just take bits 14 to 25 (leftmost bit being 1), 12 bits in total, you have
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.
Code: [Select]
0 0 C 7 6 E 1 0 0
0000 0000 0011 1110 0110 0111 1000 0000 0000and in the counterclockwise one there's, with the same offsets,
Code: [Select]
0 0 C B 9 1 0 0 0
0000 0000 0011 1101 1001 1000 0000 0000 0000Now, 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 endian
111100110011 in big endianwhich is 3891, aka -205, about -18 degrees with 12 bit anglesCode: [Select]
101 1001 1000 0 in little endian
000011001101 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.
13
Scripting and Reverse Engineering / Re: ff8 monsters : .dat files analysis
« on: 2011-03-22 21:53:40 »
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.
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.
14
Scripting and Reverse Engineering / Re: ff8 monsters : .dat files analysis
« on: 2011-03-21 23:27:49 »
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.
15
Scripting and Reverse Engineering / Re: ff8 monsters : .dat files analysis
« on: 2011-03-21 20:17:47 »
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.
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.
16
General Discussion / Re: FF7 Map Analysis & Prerenders
« on: 2011-01-23 13:13:03 »
Fascinating stuff! Two things RE part 1:
The truck in the tower lobby isn't a model, it is the truck used for the midgar escape sequence. Have a look at the relevant cutscene, that's indeed where they get it from. Similarly, the bike's two floors up, on the left, and once again the cutscene confirms it since Cloud drives it back the two sets of stairs, and then when they drive back up you can see the empty stand on that floor. Conversely, the window on the right is the one they drive through to flee.
The truck in the tower lobby isn't a model, it is the truck used for the midgar escape sequence. Have a look at the relevant cutscene, that's indeed where they get it from. Similarly, the bike's two floors up, on the left, and once again the cutscene confirms it since Cloud drives it back the two sets of stairs, and then when they drive back up you can see the empty stand on that floor. Conversely, the window on the right is the one they drive through to flee.
17
Scripting and Reverse Engineering / Re: Kingdom Hearts 358/2 days - model hacking.
« on: 2010-09-25 18:05:51 »The only thing I don't get (and I have searched everywhere) is how to open those .P2 files and the KAPH files inside them.
Can anyone give me some help?
It's been a while, but what I remember:
KAPH's a simple archive format, ie several files glued together with a header. Dunno the whole of the header's contents, but then again, you don't need the whole of the header's contents, just the subfiles' offsets. so right after the "KAPH" in the file, jump 40 bytes, then read 4 bytes for a UINT32 offset to the beginning of the first file, then skip 8 bytes and read the second offset, and so on. If the offest you just read equals 0 you're at the end of the offset list. Offest are relative to the beginning of the archive file, ie the beginning of "KAPH". The files are identified by the first four bytes, the model's BMD0. From then on it looks like a normal DS model file, though there are oddities in the skeleton.
P2 files are irrelevant, the character models are in the /mi/ch folder, the .z files. Those are compressed KAPH files, you'll need DSDecmp or something similar to decompress the .z files into .kaph files.
Modding a model would be real tricky though, unless someone's written a program that can output DS models already, because of the way DS model geometry is stored as GPU opcodes rather than lists of vertices/faces.
18
Scripting and Reverse Engineering / Re: A few questions... mostly techy stuff
« on: 2010-03-06 10:02:34 »
To put it simply, you could say it treats the CD as one huge file.
19
Scripting and Reverse Engineering / Re: Final Fantasy IX editing battle data?
« on: 2010-02-18 11:57:56 »
When I made my model viewer I just copied the FF9.img file from the disk/Iso to my HD and it worked fine. As long as you're not reading the iso directly but just accessing that file through whatever utility can read an iso filesystem, once you open ff9.img you can assume a sector size of 2048 without problems.
Or ah, wait, are you talking about putting the data back on the iso. Then yeah, I dunno anything about that.
Or ah, wait, are you talking about putting the data back on the iso. Then yeah, I dunno anything about that.
20
Scripting and Reverse Engineering / Re: Vagrant Story Animations
« on: 2009-10-29 17:28:37 »
You may try to have a look at FF9's animation format, since that's from around the same time (even though they don't seem to have much in common engine-wise). What they did is, they only stored tracks for the variant quantities (also per-byte, ie separate tracks for high and low bytes). So you'd have a first frame with root position and angles, but only those that didn't vary would directly be the values, and for the others there'd be pointers to the relevant tracks, you could identify whether you had a pointer or a value through flags written right after each value.
Well, dunno if that'll help.
http://wiki.qhimm.com/FF9/File/0x03
Well, dunno if that'll help.
http://wiki.qhimm.com/FF9/File/0x03
21
Scripting and Reverse Engineering / Re: FF9 models: how to match the right anims and textures?
« on: 2009-10-14 16:18:32 »
Yeah but I mean, it's like saying using DirectX necessitates some changes. Sure, it does, but they're unrelated to ease of use of the final application. Here the only practical difference is people need to get the XNA runtime to run XNA apps, just like they need the directX runtime to run DirectX apps. Every problem here stems from the fact I've been experimenting more than turning the experiment into a final product.
22
Scripting and Reverse Engineering / Re: FF9 models: how to match the right anims and textures?
« on: 2009-10-14 05:08:08 »
XNA is standard C#. I reiterate, all that stuff is a consequence of the way I did things, not the way XNA makes you do things.
23
Scripting and Reverse Engineering / Re: Kingdom Hearts: 358/2 Days Models
« on: 2009-10-12 21:32:23 »
I had already mostly figured out all directories but if the file formats are following a known standard this is all gonna be a hell of a lot easier 
seems like this and this should be just what I need. And compression's just the same as in FF7, apparently
I guess there's good chances it'll work with FF3 and 4 DS too.
seems like this and this should be just what I need. And compression's just the same as in FF7, apparently
I guess there's good chances it'll work with FF3 and 4 DS too.
24
Scripting and Reverse Engineering / Re: Kingdom Hearts: 358/2 Days Models
« on: 2009-10-12 16:25:18 »
Ok, so I hope you guys won't mind me bringing this back from the dead.
I needed a distraction from my lack of progress on FF9 so I had a look at this. Didn't get much from the sample files at first so I dumped the whole game's contents using a program called dsbuff, to get a broader idea of how the thing's structured. Turned out to be pretty interesting for a whole lot of reasons since by looking at the directory names you can get clues as to what you're searching for ( for example your 3E sample file is from the mission NPCs directory, so since there's "ven" in the model name and it uses Roxas' bones I can already guess it's Ventus' character model), but one of the most interesting things is that there are debug models in the ms (monsters) directory which, though they don't contain the bone info you're interested in, are simple and clearly identified and thus seem like a good starting point.
It looks like the chunks are using pleasantly readable IDs, like MDL0 for model data, TEX0 for texture, JNT0 for bones. The bones, material and model names are in there too.
What puzzled me at first was that at times the strings are cut by an unrelated character, including those that serve to identify chunks, but then I realized some LZS-like compression's at work, and those interruptions are control bytes. Also seems the compressed files always have "KAPH" as an ID, but that's already in the compressed part (so it's at offset 0x05, after one integer for data length and the first control byte) so it may just be a parent chunk that's often used.
I've also found a file, shadow.nsbmd, which turned out to be a noncompressed version of a model chunk (probably the flat round shadow you get below characters)
The beginning seems to be:
and then for the shadow file, the list, containing one subchunk
the subchunk starts as
Aaaaand that's all for now. I don't have much more info to offer yet, since I'm pretty new at reverse-engineering file formats, and for FF9 I was mostly following the wiki. It's all rather interesting, mind you. For now I need to refresh my rather rusty compression knowledge, so I can have more samples to look at. Still, it's a start, and since the names seem to be self-explanatory it shouldn't be too hard to decipher.
This link has the compressed cube and sphere debug meshes, and the noncompressed shadow.nsbmd, if anyone wishes to add his two cents while I'm working on a decompressor.
http://www.megaupload.com/?d=BLTZAJ6X
I needed a distraction from my lack of progress on FF9 so I had a look at this. Didn't get much from the sample files at first so I dumped the whole game's contents using a program called dsbuff, to get a broader idea of how the thing's structured. Turned out to be pretty interesting for a whole lot of reasons since by looking at the directory names you can get clues as to what you're searching for ( for example your 3E sample file is from the mission NPCs directory, so since there's "ven" in the model name and it uses Roxas' bones I can already guess it's Ventus' character model), but one of the most interesting things is that there are debug models in the ms (monsters) directory which, though they don't contain the bone info you're interested in, are simple and clearly identified and thus seem like a good starting point.
It looks like the chunks are using pleasantly readable IDs, like MDL0 for model data, TEX0 for texture, JNT0 for bones. The bones, material and model names are in there too.
What puzzled me at first was that at times the strings are cut by an unrelated character, including those that serve to identify chunks, but then I realized some LZS-like compression's at work, and those interruptions are control bytes. Also seems the compressed files always have "KAPH" as an ID, but that's already in the compressed part (so it's at offset 0x05, after one integer for data length and the first control byte) so it may just be a parent chunk that's often used.
I've also found a file, shadow.nsbmd, which turned out to be a noncompressed version of a model chunk (probably the flat round shadow you get below characters)
The beginning seems to be:
Code: [Select]
0x00 byte4 chunk_type, "BMD0"
0x04 byte4 unknown
0x08 uint chunk_length //chunk_type included
0x0C ushort subchunk_list_pointer //from the beginning of the chunk
0x0E ushort subchunk_countand then for the shadow file, the list, containing one subchunk
Code: [Select]
0x10 offset to MDL0 chunkthe subchunk starts as
Code: [Select]
0x14 byte4 chunk_type "MDL0"
0x18 uint chunk_length //chunk_type includedAaaaand that's all for now. I don't have much more info to offer yet, since I'm pretty new at reverse-engineering file formats, and for FF9 I was mostly following the wiki. It's all rather interesting, mind you. For now I need to refresh my rather rusty compression knowledge, so I can have more samples to look at. Still, it's a start, and since the names seem to be self-explanatory it shouldn't be too hard to decipher.
This link has the compressed cube and sphere debug meshes, and the noncompressed shadow.nsbmd, if anyone wishes to add his two cents while I'm working on a decompressor.
http://www.megaupload.com/?d=BLTZAJ6X
25
Scripting and Reverse Engineering / Re: FF9 models: how to match the right anims and textures?
« on: 2009-10-12 16:12:38 »
It's XNA-based (so yeah, DX9 behind it), grafted on another application of mine which isn't quite meant for distribution because it had a lot of things useful for a model viewer, with a custom WIP GUI system, has to be recompiled when you want to change the active model directory and will crash on any machine but mine because the FF9 resource file location is hardcoded. That's what I call user-unfriendly. It's all small details stemming from the fact it was originally a hack job.
Not really hard to fix apart from the fact it needs a decent UI (a lot of the necessary functions are there already, implemented for other parts of the program), but those fixes take time, and I got in somewhat of a slump while searching for the missing textures and turned my attention to other subjects for a bit.
Not really hard to fix apart from the fact it needs a decent UI (a lot of the necessary functions are there already, implemented for other parts of the program), but those fixes take time, and I got in somewhat of a slump while searching for the missing textures and turned my attention to other subjects for a bit.
Pages: [1] 2