CHRONO CROSS FILE EXPLORATION THREAD

[halkun]

Halkun, did you and Qhimm actually view Chrono Cross models? Even if they're screwed up, that is totally awesome! Thank you both VERY much for your work on this! Is it possible to "decompile" binary model data back into text format?

Oops, no, I was talking about FF8, not CC

[halkun]

Here's a neat trick:

When in battle, make a savestate. Then match the model data you have found to the data that will most likely be in the savestate. This way you only need to mess with the savestate and see immediately what you are "screwing up" (all you have to do is pause the emulator, change a value in an already open hex editor, save, reload the savestate in the emulator, and see what you have done.

[FaustWolf]

That's an excellent idea Halkun! I'll give it a try when I get around to messing with the model data. This wouldn't have any effect on the hardcoded model data though, would it? In which case the game would probably "normalize" the model to its original state the next time it loads the model. I guess I'll see what happens.

EDIT: On another note, I've gone back and checked out Serge's battle model data again. Strangely, well after the model ends (according to the header table), there's some extraneous data before Serge's first weapon texture begins in the iso. That's why I said that the model file size was B047/B048 bytes originally. Strictly for completion, I'm attaching another version of Serge's untextured battle model that retains all the 00 bytes and the section of unknown data that lasts until relative address B048.

[attachment deleted by admin]

[Luminaire85]

It looks like sections 4 and 5 of Serge's battle model could also start with pointer tables of the same type as the overall file. They have 22 and 13 pointers, respectively, and in both cases the 4 bytes immediately after the pointer table is the total size of the section.

Interestingly, the section of data at the end of the file is also a pointer table of the same format, with 16 entries referencing a section of 62628 (0xF4A4) bytes, which I believe is pretty close to the total length of the weapon model and texture data. My guess is that this pointer table is a header for that data, which raises the question of what the eighth pair of pointers refers to.

It might be worthwhile to compare the pointer offsets to your ModelMine documentation to see how closely they agree. At any rate, this is more evidence that those bytes have little to do with Serge's battle model.

[Cyberman]

Sic et non, if there are pointers to the weapon models then the format is not too dissimilar to that of FF7's format.
Technically speaking the weapon models ARE part of the battle models, they are a special bone in essence. Notice the Serge/Kid merged version showed kids weapon held like Serges in the stance. The weapon was still a knife however instead of a two handed unit.  This does indicate that the weapons are treated like special bones and added into the total model.
This is also how FF7 dealt with models in the PS1.  Each character had there weapons in the battle model file along with all there animations as well.

Cyb

[FaustWolf]

Oh WOW, Cyb and Luminaire, that is incredibly interesting yet it complicates things somewhat. But I'm actually relieved, since the presence of an extra weapons header would explain the extraneous data that falls between the battle model file and the first weapon texture.

Well, here's Kid's ModelMine2 and her untextured battle model data to look at. Note that her battle model file will include the extraneous bytes that probably represent a header for the weapon models. I'll truncate and re-up once we agree on the boundaries of her battle model file.

As before, Kid's ModelMine2 contains an overall file including textures and models for herself and her knife weapons, as well as the individual textures and the notes I took. Here's an overall map of ModelMine2:

0000000 ~ 0000000F: 16-byte header
000001A ~ 0000823B: Kid Battle Model Texture
0000823C ~ 00009467: Kid Eyeball Texture
00009468 ~ 000097FF: 00 buffer bytes
00009800 ~ 0001683F: Kid Battle Model
00016840 ~ 00017DBF: Kid Weapon Texture 1
00017DC0 ~ 00018977: Kid Weapon Model 1
00018978 ~ 00019EF7: Kid Weapon Texture 2
00019EF8 ~ 0001AC3B: Kid Weapon Model 2
0001AC3C ~ 0001C1BB: Kid Weapon Texture 3
0001C1BC ~ 0001CDA7: Kid Weapon Model 3
0001CDA8 ~ 00013E27: Kid Weapon Texture 4
00013E28 ~ 0001EEDF: Kid Weapon Model 4
0001EEE0 ~ 0002045F: Kid Weapon Texture 5
00020460 ~ 00020E2B: Kid Weapon Model 5
00020E2C ~ 000223AB: Kid Weapon Texture 6
000223AC ~ 00023000: Kid Weapon Model 6

Below is a reproduction of the 32-byte header of Kid's model file, with subdivisions according to my understanding of the data:


My translation of this follows:
6 sections
First section begins at relative address 20
Second section begins at relative address 4DB4
Third Section begins at relative address 50C4
Fourth Section begins at relative address 5224
Fifth Section begins at relative address C6F0
Sixth Section begins at relative address (N/A)
File ends at relative address D000

Once again, I have only just recently learned how to count "Little Endians," so please correct me if my interpretation is off.

[attachment deleted by admin]

[Luminaire85]

Your interpretation is correct, and you're right that there's an extra header at the bottom of Kid's battle model file. I think her battle model stops at 0xD000. Oddly enough, Serge's file is padded with zeros to exactly 0xB000, and Kid's file ends at 0xD000, so no padded zeros are necessary.

I will compare the files more closely, but I immediately noticed that the last several bytes (at least 64) of the two battle model files (that is, prior to 0xABDC for Serge and prior to 0xD000 for Kid) are identical.

[FaustWolf]

VERY interesting Luminaire. Could that indicate a "footer" of some sort? I think I'll eventually do one last ModelMine3 (Guile) so we can tri-compare among the ModelMines.

Anyway, thanks to you and Cyb and Halkun, we have made extraordinary progress on decoding the battle model format, and in a single day no less. The next step is to just mess with the battle model data one section at a time to figure out which section handles which aspects of the models. I'll take care of that with my test iso over the coming days and post some more vids on Youtube to facilitate analysis.

This is exciting!

EDIT: Now that Luminaire's confirmed that the data tagged onto the end of Kid's battle model is extraneous (and most likely a header for the weapon models), I'm attaching her untextured battle model without the extraneous data. It ends at relative address D000. This is equivalent to SergeModel (the original, NOT version 2) attached on Page 5 of this thread.

[attachment deleted by admin]

[Cyberman]

That information likely pads the information to the nearest sector. Data sectors are 2048 bytes OR in hex 0x800h  As for why 0xD000 my guess is it has to do with memory location (in the PS1 2M of user memory).  This offsets whatever follows in the data to a convenient location.  If you have the time look in memory to see if that is what's going on.
I suppose I should find the information regarding ePSXe's save file format. I'm so lazy sometimes.

Cyb

[FaustWolf]

Without going through the whole process of providing another entire ModelMine, I can say that Guile's untextured, weaponless model is identical in its last 2112 bytes (!) to Kid's and Serge's. Looks like a common footer of some sort.

I'm attaching Guile's battle model data (no ModelMine this time; we'll worry about how the weapons work later). In addition, for simplicity's sake (hopefully), I'm attaching Serge's and Kid's equivalent battle model data alongside his for quick comparison.

Guile's model also has buffer bytes until it reaches a new sector, then the weapon model data header. So I think that confirms what Luminaire and Cyb suspected (D000 in Kid's model, of course, just happens to land on a fresh sector by chance).

@Cyb: What utility is best for examining PlayStation emulator memory? Would I just decompress a savestate?

[attachment deleted by admin]

[halkun]

Yea, I would just decompress the savestate. The emulator will restore uncompessed savestates so it saves you the hassle of compressing them again.

[FaustWolf]

Alrighty, thanks Halkun.

Now I've caught some more whacked-out video. This time I changed the values of bytes within the first section of Serge's battlefield model data:

http://www.youtube.com/watch?v=usSTi7mxwvM

It would appear that I've tweaked vertex values, but that's a guess. Anyone care to take a peak and confirm?

So, I guess the next question is: if the goal were to gather the knowledge necessary for writing a plugin for 3DS Max, Lightwave, Milkshape, or Blender, how in-depth do we need to go in each section of data? Should I start documenting which byte offset I changed to screw up Serge's bandana, for example?

And if the model format is in a binary form of RSD or some other format easily accessible to PlayStation hardware, would it be worth our while to run some of the data through a decompiler and see if it gives us anything recognizable?

[Cyberman]

RSD is likely compiled to your header information that you have.

The files that are referenced by the RSD data are more interesting.  The RSD file is like a web page that references numerous other pages.  There is the possibility that the model is not a single mesh but a bunch of parts like FF7 had. Unlikely though. 

You may have been changing vector indexes (anything is possible). I noticed the polygons shooting off into the distance (IE they were extremely large values).

Cyb

[halkun]

Looks to me like you got a vertex value for the very top of the head, and you zeroed it out. The dark artifacts appear to be the shadow unable to cope with the change. (division by zero?)

[FaustWolf]

I suppose the next step is for me to go through the original model data again, this time documenting which bytes I change. That might offer some clues as to which offsets affect which parts of the model. The major changes I noticed  in the vid were the large triangle/cone jutting out of Serge's head, a possible alteration of his glove cuff (hard to see in the video), and the giant spike sticking out from his leg(?). His texture includes some bluejean-like material for pants, so if the giant shadow-thingy is blue or dark blue, I believe I may have placed a vertex far away from the rest of the model and thus stretched the "bluejean" texture.

I'll repeat and get another vid upped tomorrow night. If anyone has advice on what to do next, I'm all ears. Maybe I'll get Serge to grow a few extra ears too.