CHRONO CROSS FILE EXPLORATION THREAD

[ZeaLitY]

Once we decode Cross's model format, a viewer and exporter can be coded so Cross's models can be used in 3D stuff or, for the Compendium encyclopedia, archived. But once we get 3D out of the way, we're also going to look at the instructions the game uses to string together room graphics. Then a program can be coded to replicate that and output PNGs of rooms. No matter what, it'd probably take less time to research and code that program to rip backgrounds rather than use the painstaking VRAM method. Finally, once we document everything, we can get involved in Cross ROM hacking, which is really exciting.

[FaustWolf]

Thanks for all the encouragement, everyone! This project will succeed precisely because we've got great teamwork going on here, and great knowledge on the subjects involved.

Luminaire, thanks for figuring out the unexpected switchover from quads to triangles! It would appear that my experiment earlier tonight cut into some triangle data tucked amongst the UV quads, so now I don't have to lose any sleep over the strange results.

So there's one two-byte value per non-UV vertex pointer, then. Read as signed integers, what significance does the negativity of some of the values have? Is everything relative to some offset designated "0" somewhere else, perhaps?

Luminaire, try using the attached image for your revised UV map. If Serge's texture CLUT is included, it bumps the dimensions up to 128 x 256, so it's quite possible the UV maps are correcting for the presence of the CLUT. This will map totally correctly, hopefully.

Also, I believe Luminaire stated that a total of 12 triangles "snuck in" what we thought was uniform quad UV data and pointers. That means we should bump up the number of triangles by 12 for a total of 276 triangles, and decrease our quad count by 9 for a total of 394 quads.

This discovery shouldn't affect Cyb's suggestion that there's a pointer to the quad data start (though I've been unsuccessful in confirming with Kid's and Guile's models - but I was checking haphazardly and need to spend more time with those). This could mean, however, that there's a pointer to every "switchover" from triangles -> quads -> triangles -> quads, for a total of three "transition pointers" in Serge's model. This is only based on intuition.

[attachment deleted by admin]

[Luminaire85]

Okay here's the new UV map. I actually think the previous one is a little better, but you can decide for yourself.

I'm still not sure what to make of the pointer data. One thing I don't understand is why the values span a range of 9424 when Section 1-3 is only 6496 bytes. Incidentally, Section 1-2 is 9616 bytes.

Another interesting thing to note: I adapted my C++ code to count how many of the UV coordinates are unique (that is, how many dots are in the UV maps I've been uploading). The result is 704. It would be nice if that was the number of vertices, but I wouldn't be surprised if it wasn't.

Also, the poly count for Serge should be adjusted to 276 triangles and 394 quads, for a total of 670 polygons.

To answer one of your questions from before: the +/- button in the Windows calculator also works in Hex mode. You should change the button from QWord (8 bytes) to Word (2 bytes) first, of course. For example, -40 is 0xFFD8 as a signed 16-bit value. More on the conversion method at Wikipedia.

[attachment deleted by admin]

[FaustWolf]

Yeah, the UV map with CLUT didn't turn out as well as I'd hoped. I guess we should go with the previous version then, since we know it maps Serge's belt buckle the same way it's done in-game as far as I can tell. Thanks for checking that.

Ahahaha! Now I know how to work with signed hex! Thanks Luminaire!

Wow, nice job getting the number of unique vertices. Soo, I imagine it's possible there's 704 vertex entries in Section 1-3, or whichever section is the vertex pool. That's something we can check out as well.

Followup Questions: Hey Luminaire, how exactly did you detect the presence of triangle UV maps among the quads in Serge's Section 1-2? I'd always gone by the "FF" byte pattern (since I had thought those occurred only in the non-UV vertex pointers), but is there a better (i.e., more accurate) technique seeing as FF bytes appear to be in the "V" position of some UV map coordinates?

Cyb and Halkun, were there vertex indexes similar to these in Final Fantasy VII? Now that we have a count of polygons (276 triangles, 394 quads, and therefore 670 polygons)  and vertices (828 + 1576 = 2400 vertices in the UV maps altogether, with 704 unique - possibly), how do we go about comparing our suspected vertex pool, Section 1-3, to this information?

I suppose one possible next step would be to look for headers containing values like:

FOR # OF POLYGONS...
276 = 0x0114 or 14 01 in Little Endian
 (And since the triangles are split up, the corresponding values for 264 and 12)
394 = 0x018A or 8A 01 in Little Endian
670 = 0x029E or 9E 02 in Little Endian

FOR # OF VERTICES...
828 = 0x033C or 3C 03 in Little Endian
 (Not sure if the triangle split up would force smaller separate listings of vertices here)
1576 = 0x0628 or 28 06 in Little Endian
2400 = 0x0960 or 60 09 in Little Endian
704 = 0x02C0 or C0 02 in Little Endian

I don't remember seeing any sort of header in Section 1-3; I think the data starts right into the byte-progression pattern we noted a while ago. I'll dig up a few posts relevant to that:

An early report on the subject of Section 1-3
http://www.chronocompendium.com/Forums/index.php/topic,4770.msg84065/topicseen.html#msg84065

Cyb's observation -- possibly a vertex pool
http://www.chronocompendium.com/Forums/index.php/topic,4770.msg84084/topicseen.html#msg84084

A followup citing an oddity within Section 1-3
http://www.chronocompendium.com/Forums/index.php/topic,4770.msg84094/topicseen.html#msg84094

Hahaha, one more question: I have an idea for another experiment, but I need a bit of theoretical guidance first. Provided we've got a vertex pool, if I were to zero out an entire vertex's info in the pool, what would probably happen to its associated polygon? Would the polygon not draw at all, or would the GTE/GPU attempt to draw a triangle where a quad would be, and a line where a triangle would be? I was thinking we could wipe out a vertex or perhaps an entire polygon, trace its location back to its UV map based on Luminaire's mapped texture, and that way figure out how the non-UV data addresses point to the vertex pool.

[Cyberman]

If you zero out one point for example the qauda would have a weird point attached to it (and every polygon attached to that point would mutate accordingly).

I guess finding how the information is organized (other than what it is) will be the hardest step. It took me several months staring at the bone data to have a DUH moment with FF7.

Cyb

[Luminaire85]

There are three parts to identifying non-UV data from UV data. For a given 16-bit number, it is non-UV data if:

(1) The first byte ends is 0x?0 or 0x?8, signifying that the number is divisible by 8.

(2) The second byte is either very large (i.e. 0xF? or 0xE?) or very small (i.e. 0x0? or 0x1? or 0x2?).

(3) If three such 16-bit sequences exist adjacent to each other, then it's triangle data. If four exist, then it's quad data.

In addition, the UV data for a given poly tends to have very similar values for its three U and three V coordinates.

For example, the first triangle in Serge's UV data is 1a 63 1c 62 1b 63 70 0a 40 15 10 00. The UV coordinates are (0x1a, 0x63), (0x1c, 0x62), and (0x1b, 0x63), while the non-UV "pointers" are 0x0a70, 0x1540, and 0x0010.

Happy to clarify if any of that's unclear.

[FaustWolf]

Crystal clear, Luminaire, thanks!

Tonight's experimental results are in. See the attached image. At the top of the pic I've listed the hex code I zeroed out; offsets are immediately to the left. The offsets pointing to the various results are the ones I zeroed out per result. In the lower-left you can find a front and back view of Serge's poofy sock cuff when offsets 0x31A0 ~ 0x31A7 have been zeroed out. That's 8 bytes, and I figured based on the byte progression pattern that it might account for one vertex.

When the next four 8-byte strings are zeroed (for five 8-byte strings zeroed total), we get the result in toward the top-right. It would appear that the vertices affected have been dislocated by the same (or similar) amounts in 3D space.

Beyond that, I'm not sure what else to say. Does the vertex pool typically give coordinates in 3D space for the vertices? Would these results be theoretically consistent with messsing up the vertex pool?

Now we can relate the data in offsets 31A0 ~ 31C7 to the appropriate vertex pointers in Section 1-2. I've still gotta determine the vertices affected based on Luminaire's UV map for Serge's texture, but wanted to report this stuff first in case it's significant.

...Luminaire, you don't happen to have a copy of Serge's mapped texture that's 128x256 (or 128x252 if it's cropped to the visible texture) pixels in width and height, do you? If not, that's okay; I should be able to figure out the applicable UV coordinates still.

UPDATE: It would appear that offsets 0x31A0 ~ 0x31A7 define the spacial location of a vertex shared by polygons that create a border between Serge's sock cuff and the back of his leg. See the additional result attached below the first. This time I changed the non-zero bytes in that range from their original values to AA. Section 1-2's UV map seems to faithfully map the correct texture piece to this messed-up polygon, but because this one vertex's spacial coordinates are messed up, the texture stretches way out into space. I guess last night's results showed the same vertex crawling up Serge's leg, dragging the sock texture piece with it.

The really interesting thing is that, in Section 1-2, there's got to be a UV map for Serge's sock and a UV map for the back of his leg that share a vertex pointer. If we find something like that, we can figure out the mathematical relationship between that shared pointer in Section 1-2 and the data in this offset in Section 1-3 (vertex pool).

[attachment deleted by admin]

[Sora]

what the hell? this thread just insta-died o.O

[FaustWolf]

Finals week arriveth soon, bringing with it insta-death of forum threads. But the next step, in my theory at least, is to identify the quad in Serge's model affected in my latest experiment above, then identify the UV map that textures that quad in Section 1-2. That will take a bit of doing though because I'm not sure if Luminaire's able to create a 128x252 mapped texture for Serge with the program he's written; no biggie though. Once we identify the UV coordinates in Section 1-2 that map said polygon, we can analyze how the associated non-UV data points to Section 1-3. IF the non-UV data points to Section 1-3, that is. But I think it should...

Anyway, we are close to having both Sections 1-2 and 1-3 completely analyzed provided Section 1-3 is indeed the vertex pool as we suspect. Then, after a wiki update, we can search for skeletal data - the arms and legs, and various clothing pieces that move in accordance with animation data. Long ways to go yet! But this project could be truly groundbreaking; besides Final Fantasy VII, I'm not sure if any other PSX game model format has been ripped and viewed successfully.

Once the format is completely analyzed, it's just a matter of writing a plugin or standalone viewer to view the models. I wish I could help in that regard, but I'll only just be getting into Python scripting over winter break (seems like a good language for a hobby-hacker to start off with). I wonder, is Blender capable of 3D model animation (completely noob question there, but I haven't explored any such functions yet), or is animation typically done in other programs once you've got a model? Yaz0r was certainly able to decode Final Fantasy X's animation format, so at least we know it's been done.

[Luminaire85]

Yeah, it's probably just a surge in busyness for all of us. I know it is for me.

Blender can certainly do animation of 3D models, although I am just beginning to learn how. The trick will be understanding how the PSX does it and converting it to how Blender does it, if necessary. If it's bone data like some of the PSX gurus have alleged, then it shouldn't be too bad to do this.

The way I made the UV map doesn't easily allow me to make an exactly 128x252 UV map, unfortunately. I could probably code something up, but I am wondering if that's too much work for what you need to do.

[Cyberman]

This is quite active Sora as far as I can tell. Heck if there wasn't anything on it for a few weeks then I would think faustwolf might of run into trouble or is on a trip. No biggie though.

I would guess they used variable bit depth delta compression seems to be popular with Squaresoft

Cyb

[FaustWolf]

No prob Luminaire, and don't bother coding something up just for this small task -- I should be able to get the info I need by hand pretty easily. And wow, Cyb already knows about PSX animation compression! Do you have any general info on variable bit depth delta compression, Cyb? I assume we'll have to decompress for the animation to be "readable" by whatever viewing method we decide to go with.

Yaz0r, did they use the same compression technique in FFX, XII, and Kingdom Hearts? I know it's PS2, but I wonder if Square continued with the same (or similar) methods into it's next-gen projects.

[Cyberman]

URL for FF7 animation information it's a good reference
FF7's information and although it says PC it is the identical format to the PS1 version data.

Cyb

[yaz0r]

Yaz0r, did they use the same compression technique in FFX, XII, and Kingdom Hearts?

I don't know for FFXII, but FFX and KH are completely different when it comes to animation, mostly because FFX has motion captured animation while KH does not.

[Sora]

FFXII sucked. worst game ever! even 10-2 was better!