Author Topic: FF7 Crisis Core - File Format and Data Investigation  (Read 146765 times)

Satoh

  • Insane poster
  • *
  • Posts: 386
  • Karma: 6
  • Assuming this statement is correct, I'm alive.
    • View Profile
I awake..... from my slumber....

When I helped reverse the FF8/CC models, it was no unheard of for the programmers to put GPU opcodes in the model data.

Sadly, I only know how the GPU works in the PSX/PS2. I have not have any hands on experience with the PSP.

Keep in mind the models probably were made from object trees (waist, torso, head, left_upper_arm, left_frearm, left_hand, etc). You probably need to work on parsing one body part at a time as the vertex pools are usually grouped together by body part. The Mog head was a good start.



Halkun do you have any FF8 info that isn't posted anywhere? It would certainly help me out if you could add it to my Model Project thread, where I'm compiling model format info links.

All I want to say is - this is one great piece of work. I'm looking forward to this project being finished and able to fully render the models.

I think everyone that's posted here is eagerly awaiting the completion.

Yeah, it is possible that they just leave both blending and depth writing enabled, and have the verts that reference part of the uv that is actually transparent ordered after the non-transparent verts. However, they would still have to software-sort their models by distance to camera in this case, or you would have cases where you would not see another character model behind a transparent surface, as that kind of sorting can't be done on the hardware level (due to the fact that it would need to defer rasterization to support it). It also assumes the PSP GPU has blend optimizations to save fillrate on blend operations if the written depth fragment is previously clear, which it may, but I'm unsure.

In either case, it would make a lot more sense to me to, at the very least, have some kind of marker between vertices to signify a change in blend mode, unless they were very desperate to cut down on primitive batches, without regard to the cost of software distance sorting or potentially greater fill expense. However, it doesn't make a lot of sense to do a post-depth alpha blend pass if you have rendered your alpha surfaces to the depth buffer, and the information in the framebuffer is stomped on whenever a depth fragment passes, which is why the hardware itself can't support an alpha post-multiply.

I'll have a look around some of those verts that reference transparent areas of the texture map, and see if I can find anything that would be indicative of a change in blending between batches. It seems more and more like the verts are more like a "draw command list" of some sort, which would explain some of the seemingly arbitrary tagging values thrown in there. However, I don't know enough about programming for the PSP, particularly with commercial GPU interface libs, to know if there are any official display list formats this data could resemble.

I suppose you know a lot more about how alpha is rendered than I... I'll just let you handle that area XD;

halkun

  • Global moderator
  • No life
  • *
  • Posts: 2113
  • Karma: 23
  • NicoNico :)
    • View Profile
    • Q-Gears Homepage
I don't, I just remember seeing GPU packets mixed in with the UV data. The Packed discribed if the pool of vertexes were a triangle or a quad...

Hold on....

Hey, did you know that the GPU for the PSX could take a quads as primitive, along with triangles? The PS2 could take Tirangles, Quads, triangle fans, and triangle strips. Maybe that might help. You might be processing everything as if they were just triangles. (I'm blindly guessing here). Like I said, I don't know much about the PSP's GPU, but it could stand to reason that it may be similar to the PS2's...


koral

  • Guest
The more (people interested) the merrier!  :wink:

One of the first things I tried was rendering those vertices as quads, tri-lists and tri-strips (similar mechanism to rendering FF8 MCH files), but that didn't work because not all the vertices in these !-Files are vertices at all!
There are padding bytes, and distinct sub-headers of sorts, all garbled together.

The model "parts" are definitly categorised depending on the number of bones which influence them (TYPE1 being single weighted, TYPE2 being multi-weighted), but the ordering of these parts must be in-sync with how the PSP would render them, taking transparency into account. So heavy-transparent parts (like hair strands) we would expect to find towards the end of the vertex-data chunks. I haven't been able to confirm this yet.

Those "tags" are most definitly some kind of GPU opcodes (NeoCloudStrife has suggested this to me before).
For some reason (most likely because of improved efficiency) it looks like the mesh data is read directly from the UMD (or RAM) to the GPU for rendering, which is unlike how meshes usually get rendered on other consoles.
Maybe its a PSP thing, or maybe its just Crises Core?

What about Dissidia? Would that be worth looking into?


We really need to start by understanding how the PSP works I suppose!  :lol:
Are there any good documents available? I haven't been able to find anything detailed enough.

Its funny how FF7's file-format investigation had fueled better understanding of the PSX all those years ago, and now it seems like Crises-Core will do the same for the PSP  :-P

MrAdults

  • Guest
Yeah, I agree, having some PSP hardware/GPU documentation would make this a lot easier. Unfortunately, Googling is not turning up too many resources, but I don't think I'm searching for the right things. I keep getting this thread thrown back near the top of my search results. :)

I know that homebrew libraries have been able to utilize 3D features for some time. Unfortunately, I know those libraries work by loading official Sony kernel modules, so just looking at the homebrew devkit probably will not reveal low-level register info or GPU formats. I guess I'll keep Googling. Please anyone else who has some helpful links in this area, feel free to chime in. :) I'll report back if I find any applicable documentation.

Edit: I think I have just found almost everything we need to know in the source code for "Potemkin", a PSP emulator. It has vertex decoding/pipeline modules, and lists for all of the types and flags for vertex types, and it even shows how to handle the vertex weights within the vertex stream! :) The PSP appears to support up to 8 bones per command list, so meshes/command lists will no doubt be broken up for characters that use more than 8 bones. Now we just have to figure out the bone data. Each bone should be a 3x4 (or 4x3) matrix. From the emulator source, I believe it has to be floating point, but I may be missing a part where it does conversion.

Edit 2: I've verified that these vertex blocks are indeed a match to the PSP GPU formats and are decoded in the same way hardware decodes them. For "type 1" vertex blocks, there is a DWORD of value "0x00000723" usually 1 DWORD before the actual number of vertices. This value means:

Code: [Select]
int tc = 3; //2 floats
int col = 0; //no color
int nrm = 1; //x, y, z in bytes
int pos = 2; //3 shorts
int weighttype = 3; //float
int idx = 0; //none
int morphcount = 0;
int nweights = 0;

DWORD fmt = 0;
fmt |= tc;
fmt |= (col<<2);
fmt |= (nrm<<5);
fmt |= (pos<<7);
fmt |= (weighttype<<9);
fmt |= (idx<<11);
fmt |= (morphcount<<18);
fmt |= (nweights<<14);
//(fmt == 0x00000723)

When you get the sizes and offsets of the various components with that vertex type DWORD, padding and aligning along the way according to hardware spec, you get 24 byte vertex blocks with correct offsets to uv, position, and normal. Now that we have this knowledge, no matter what "type" a vertex is, we can know how it should be indexed (if at all), and where to get the essentials to render, such as position and UV. Now the only thing left to do is to figure out a reliable way to get those GPU control codes out between vertex batches. There is no reliable offset to the next control code/vertex number, from what I can find, and I'm not sure what the other bytes in between chunks mean yet.
« Last Edit: 2009-03-13 06:34:04 by MrAdults »

MrAdults

  • Guest
Success! :)



You guys can probably piece things together from what I've said so far, but I will nonetheless be writing up the spec details (to include the PSP-related info) once everything is a bit more automated. Still haven't located a place to read the exact number of segments, or bothered to see if there is a command-terminator (there probably is).

Aurenasek116

  • Crazy poster
  • *
  • Posts: 155
  • Karma: 0
    • View Profile
Holy damn. That's really great about findind how the GPU works.
However I'd like to ask if it's normal that some of the textures that I view with the 0.30 version appear to have noise or scanlines on them, making them impossible to tell what are they. I was looking for Sephiroth's and Hojo's texture, I swept through all the model files and couldn't find them in those that were viewable, so my guess is their must be in those that have noise/scanlines or them, any way to fix that??

MrAdults

  • Guest
Alright, got this working perfectly with all of the models I have.

There is a single WORD (2 bytes) value after every segment, which is conveniently just "1" all the way until the last chunk, where it is 0. :) Another WORD right after that gives you an offset to look for the beginning of the next vertex data. Can anyone send me some more models to try out? Ideally some more characters (Genesis, Tifa, Zack, etc). I would like to start looking for skeletal data soon in order to actually make use of the bone weights.

Edit: Here is a full blog write-up of my findings, skip to the bottom for the meat:
http://www.richwhitehouse.com/index.php?postid=28
Please feel free to directly or indirectly take any information or code snippets and assimilate it into this thread or the wiki.
« Last Edit: 2009-03-13 11:22:06 by MrAdults »

yoshi314

  • Insane poster
  • *
  • Posts: 319
  • Karma: 2
    • View Profile
i must say i am impressed with how fast this was figured out.

either the consoles are getting more intuitive, or the hackers are getting smarter ;-)

BlitzNCS

  • Freak
  • *
  • Posts: 891
  • Karma: 2
  • Master of nothing in particular
    • View Profile
    • My Youtube
HOORAY!!!!
WOOO!!!
haha! you guys did it! majorly awesome :D
really, thank you, all of you :D
i'm just sorry i couldnt help more!

koral

  • Guest
WOOHOOO!!!
Fantastic stuff Mr Adults!

I tried it out, and it worked absolutely brilliantly!

witness the Crises-Core Character Collage (sample):



Alpha-blending has been disabled temporarily because Irrlicht needs a little work to correctly sort out the polys. I was just being lazy  :-P

The two Clouds (infantry and SOLDIER costumes) and Sephi have some strange texture-map issues, but there is no doubt the geometry can be parsed and rendered fully using this method.
I now just need to find a way to correct the texture problem, and it should be good to go for another public release!

To be honest, bones and animations were never on my TODO list (unless they had been required to correctly render the meshes) so I may not go any deeper into these Model files.
If Mr Adults tools would want to incorporate those things, then it would make it easier for me to just move onto something else.

THANKYOU EVERYONE for helping me get so much done so quick!
I suppose all the right people just happened to be at the right place at the right time (doing the right thing) :lol:

Aurenasek116

  • Crazy poster
  • *
  • Posts: 155
  • Karma: 0
    • View Profile
Now if only someone could compile a viewer for those and release it since I have totally no experiance with coding whatsoever, only 3Ds Max, Maya and Photoshop.

spidergaby

  • Fast newbie
  • *
  • Posts: 22
  • Karma: 0
    • View Profile
Wow !!!  :-o
Awesome work !!  :wink:

Please continue  :-)
Now if only someone could compile a viewer for those and release it since I have totally no experiance with coding whatsoever, only 3Ds Max, Maya and Photoshop.

I'm agree with you Aurenasek116  ;)

BlitzNCS

  • Freak
  • *
  • Posts: 891
  • Karma: 2
  • Master of nothing in particular
    • View Profile
    • My Youtube
Just a question, is it possible to add a sort of "Convertor" type thing for the models like what biturn has? for instance to just turn these models into .OBJ or .3ds files, because i have vista, and 3DRipperDX seems to have trouble with vista as far as i can tell. it crashes the instant i try to dump with shader model 3.0, and when i use shader model 2.0, it doesn't do it right at all...
But you guys rock! apart from animations and bones, what else would there be to look into for this game?

ultima espio

  • No life
  • *
  • Posts: 1359
  • Karma: 20
    • View Profile
Neocloudstrife, 3d printscreen would work well with it i think. If we try with it first, it's less work for Koral/MrAdults.

NameSpoofer

  • Guest
Once again I would like to say thank you to koral and those others ( ignitz, mradults, x-dina ) for this awesome project.

The models from CC put be great for the mods Im working on.

Muchas gracias


BlitzNCS

  • Freak
  • *
  • Posts: 891
  • Karma: 2
  • Master of nothing in particular
    • View Profile
    • My Youtube
Neocloudstrife, 3d printscreen would work well with it i think. If we try with it first, it's less work for Koral/MrAdults.
That doesn't seem to want to work for me either (crashes on loading anything 3D)
STUPID VISTA  :cry:

koral

  • Guest
Don't worry, I will add in a .OBJ exporter as standard with the next release :wink:
It is such a simple format to work with, it wont be a problem for me to do and for you guys to get into Max, Blender or whatever

I am converting the project into a Win32 MFC form, so it should be easier to work with.
Or maybe if mirex could add support for these files into Biturn then I might not have to?


apart from animations and bones, what else would there be to look into for this game?

There are maps, missions, materia, and the Debug-Menu somewhere in there too!
I also believe this game may be quite easy to Mod because of how the files are layed out, although I am not sure how else this game could be improved  :-P

But I am trying to solve the Sephi and Cloud texture issue right now, because a lot of other characters suffer from this problem too (such as Angeal).
It wouldn't do to release a buggy version, would it?

BlitzNCS

  • Freak
  • *
  • Posts: 891
  • Karma: 2
  • Master of nothing in particular
    • View Profile
    • My Youtube
you're right, and as someone mentioned earlier, i think they're the ones with the weird scanline thingies. the textures are probably in a different format for some reason. they look like how the other textures started out, before you got them working.
lol, maybe it's just a joke from square or something. is it just a coincidence it happened to both cloud AND sephiroth? :P

Aurenasek116

  • Crazy poster
  • *
  • Posts: 155
  • Karma: 0
    • View Profile
I've worked with many console games before, and they all used .dds format for textures. It's common format used in games these days, it's very similar to .tga but smaller than it. It simply preserves high quality and alpha layer while maintaining smaller disk space than bloody .tga. I don't know if that helps but I'm trying to be helpful.

koral

  • Guest
I always use PNGs for texture-maps, lossless compressed textures with alphas. Not as good as DDS I will admit, but definitly easier to for windows (open with Paint etc to view them). TGAs are useless  :-P

Anyway, I just discovered that there are multiple Textures in some of these !-Model files!

Example, the Cloud [file: 02183.raw] contains three textures:

   

The way to access these other textures is to jump to the Texture-Offset (from the file header at 0x1c) then to read in 16-bytes until the first 0x77 byte.
Each of those 16-byte is a texture-map header which contains the image sizes and file offsets of where the pixel/pallete data are contained (ie, one 16-byte header per texture).

Ofcourse, this now suggests that the vertex data must also contain within it some kind of Texture-Index so the correct texture-map can be applied.
Seems like we are not quite done yet  :|

MrAdults

  • Guest
I was just coming here to tell you this, koral. :)

It seems you have already figured out how to get at the multiple textures. I'm certain there are also multiple models outside of the main segment buffer, that can probably be accessed as well at the end of the main segment list. Not sure how that is exactly set up yet.

But! We got very lucky, and are given a WORD that is a direct index into our texture list for which texture to use when rendering a given segment. :) Going along with the example code on my web site, to get at that word, you would do this:
Code: [Select]
WORD texIdx = ((WORD *)vinfd)[2];And then texIdx is a simple 0-based index into the texture list, in the order it was parsed. I have tested this across quite a few models, and it seems reliable.

Aurenasek116

  • Crazy poster
  • *
  • Posts: 155
  • Karma: 0
    • View Profile
Could you add option to extract the textures in .dds or .tga format though? PNG alpha layer isn't as good as dds/tga in jedi academy engine, which is modified quake 3 (For which I mod :P)

MrAdults

  • Guest
Haha, that is a funny coincidence, Aurenasek116. I was responsible for the multiplayer portion of Jedi Academy. :) And Jedi Knight II, actually.

Not sure what you mean by the alpha layer isn't as good, though. DXT5 compression is pretty far from lossless, and you should be able to export a png to a dds and retain the alpha channel. I personally use PNG for everything as well, and distribute both PNG (for lossless no-compression rendering) and DDS for all of my games. It should work great, unless I'm totally unaware of some png alpha limitation.

BTW, I forgot to mention. Once I'm done integrating this support into my toolset, it will be able to export the models as well, to my own model format as well as .smd (Valve's pre-processed model format, for which every modeling suite in existing has an importer). Which will be useful for retaining skeletal/weighting data, if we ever get that fully working. However, it's not in my immediately scheduled timeline to get that release out. It will probably happen sometime after I look more into the skeletal data, to make sure it isn't just an obvious/simple thing to get working. koral's obj export functionality should be quite suitable for exporting static meshes, so I'm not worried about getting that functionality out there.

Aurenasek116

  • Crazy poster
  • *
  • Posts: 155
  • Karma: 0
    • View Profile
In what way responsible for the multiplayer portion? Do/Did you work at Raven?

As for PNG I've noticed that atleast in jedi academy when using alphafunc with it on detailed half-transparent textures it seems to ignore the small radius around the alpha resulting in black/white outline while rendering. TGA doesn't have that problem.

Retaining weighting would be great since it could allow exporting models in poses using original animations instead of that "Jesus-stance".

apz freak

  • Insane poster
  • *
  • Posts: 411
  • Karma: 5
    • View Profile
Fabulous work guys! I look forward to exploiting this to further my low poly knowledge!