CHRONO CROSS FILE EXPLORATION THREAD

[FaustWolf]

Now that I've already made one movie reference in this thread, it's time to make an analogy to Terminator 2. Specifically, when Section 2 (not to be confused with Section 1-2) of Serge's model data is overwritten, he looks quite a bit like the T1000 when it's been blown apart by the Governator's grenade launcher at the end of the movie:

http://www.youtube.com/watch?v=QgVi-lTspDY
http://www.youtube.com/watch?v=smXwjqrCjIM

In the first vid, only Section 2 has been overwritten with Kid's equivalent data. In the second, both Section 1 and Section 2 have been overwritten with Kid's equivalent data. It would appear that Section 1 is definitely responsible for UV mapping based on the observable difference.

Also, here's more evidence of vertex data in Section 1: http://img340.imageshack.us/img340/7960/section1proof1zl6.jpg

See that piece of hair that's identical in both Serge's messed-up model and Kid's? It would appear that Kid's vertices have taken the place of Serge's when his entire Section 1 is overwritten with hers, but the result doesn't resemble Kid completely because a.) her model shape is being molded onto Serge's skeletal structure; and b.) Serge's skeleton probably doesn't have enough "bones" upon which to map her hair braid, etc.

I think Section 2 does not have its own subsections (it's very small relative to the other Sections), but I still have to figure out the header. When I do, I'll post it here so others can double-check my interpretation before I throw it up on the File Structure wiki.

[halkun]

@Halkun: There's about 50 instances of 0x7F in Section 1-2 of Serge's model. They are spaced at widely varying intervals (anywhere from 8 ~ 100+ bytes apart). What else should I look for that could go along with 0x7F? Is it an opcode of some sort?

When I was taking apart FF8, that was kind of a "header" for a quad. I have a really good idea how to find the UV map.

1) Take kid's Texture map and load it in Gimp, or you favorite graphic editor. The editor must be able to display the current X,Y coords where the cursor is over. Now the map should not be bigger than 256x256. That gives a texture range of 0x00 to 0xFF both on the U(X) and V(Y) direction.

2) In the probable Texture map section of your model, find "pools" of data close to each other and put dots on the texture (x,y) where the pools tell you.

3) When you start to trace out the edge of the texture, that means you have found the UV map.

[FaustWolf]

Damn good idea, Halkun. I considered that, but wasn't sure how to implement it in my search. I have a couple questions as usual, and these will require Kid's battle texture as an illustration (128 x 252 pixels):



1.) My Paint Shop Pro interprets the the top-left corner as (0,0) and the bottom-right corner as (127,251). Does the PlayStation interpret things the same way typically, or would it identify the bottom-left corner as (0,0) and the top-left corner as (127,251)?

2.) Let's say I'm looking for the UV coordinate (8,9) on a given texture. Should I look for 0x08 followed by 0x09 or should I look for 0x09 followed by 0x08? I'd guess the latter based on your PSX doc, which illustrates things in the order (V,U) reading from left-to-right.

[halkun]

0,0 is the upper left hand corner.

Look for pools of the U,V pairs in sets of 3 (triangles) or 4 (quads)

I don't remember if the endian is switched or not. It was pretty easy to figure out when I was picking through it. Keep in mind, this was almost 8 years ago.

A little trial and error will get it, you will know when you hit an edge. When you do find it, it's pretty trivial to write a "mapper" program to draw the UV map to see what you have.

Even cooler; When you have the UV mapped, you can see how many polygons/vertexes the model uses. You can then use that information to find the other sections, such as vertex pools and polygon pools.

[FaustWolf]

Gotcha. Thanks Halkun! Hopefully we're on the verge of a breakthrough.

EDIT: Alrighty Halkun, I've got something that may be of interest. It might be a random coincidence, but the chances of it being random are very small IMO because it works out so beautifully.

First, the hex code I'm looking at:


I'm especially interested in the data values boxed in blue. Interpreted as (U,V), in decimal these would read:
(93, 206); (105, 206); (93, 220); (105, 217)
(81, 217); (81, 206); (93, 220); (93, 206)

Assuming (0, 0) coincides with the upper-left corner of the texture as you said Halkun, these values trace out the following points on Serge's texture; they're in yellow, with overlapping points in green:


The resulting quads are symmetrical, which I particularly like. There's loads of examples like this in Section 1-2 of the model (offsets 0x358 ~ 0x28E7) -- although the potential UV map data could be restricted to offsets 0xFB8 ~ 0x1E20. I could be wrong about that; it's only my first impression.

I believe this area is worthy of further investigation. Halkun, Cyb, Luminaire, et al, is it possible UV map data could be arranged in such a manner? The pattern seems to be:

xx xx xx xx xx xx xx xx - U1 V1 U2 V2 U3 V3 U4 V4

...where "xx" represents something I don't know at this point. Thoughts?

I'm attaching Serge's battle model texture so others can take a look if they wish.


[attachment deleted by admin]

[Gemini]

If I were you, I'd use pSX for finding the UV coordinates instead of trial&error. Use its debugger, capture 5 frames in the GPU module and, from the GPU menu, select Show VRAM. This will allow you to see ALL the primitives on screen as they are sent on screen, with all their attributes, including uv coordinates and the structure addresses in OTag (a list of primitives).

[FaustWolf]

I'll try that next Gemini, since pSX is my favored emulator. For now, what's your opinion on the data I highlighted above?

EDIT: Ooh, I'm starting to like this debugger. I'll be hunting down tutorials on how to use its GPU functions, so if anyone knows of a really good one offhand, let me know.

I'm starting to get the hang of using the debugger. It reports varying polygon formats as illustrated by the snippets below:


I'm liking the "polygt3" output way better than the other types, since its UV coordinates don't go all the way to 255 from what I've seen so far -- UV coordinates for the battle model textures should go from (U,V) = (0,0) to (U,V) = (127,251). I'm assuming that "polygt3" signifies a triangle that's shaded (as in gouraud shaded) and textured.

It would seem there's enough information to construct the GPU commands Halkun lists in his PSX doc. However, I'm up a creek without a paddle until I figure out which "texture page" value corresponds to which character texture. VRAM has texture pages for the backgrounds, character battle models, enemy battle models, and other objects I suspect. Any thoughts on this, Gemini or anyone else?

And folks, don't forget to look at my trial-and-error results above. I'd much appreciate some feedback on that post from veterans: http://www.chronocompendium.com/Forums/index.php/topic,4770.msg84497.html#msg84497

[Cyberman]

You may wish to dump the VRAM to an image (unfortunately with 8bit paletted textures this may look like garbage to you). It should show where the palettes are though.
You will need to dig through the documentation of halkun's PSX.pdf to find out how to compute the CLUT locations and texture pages.  Also you will likely have font data in the VRAM during battle scenes.  A lot of the space in the 1024x512 word VRAM is reusable (fonts for example).

Cyb

[yaz0r]

I believe this area is worthy of further investigation. Halkun, Cyb, Luminaire, et al, is it possible UV map data could be arranged in such a manner? The pattern seems to be:

If you want to make sure, just fill those UVs with 00. The model should still be fine, but the texture will be one color only.

Regarding the question about the VRAM localisation thing, as far as I know about CC inner working, texture for party members 1, 2 and 3 are always loaded at the same position in VRAM. As a consequence, you probably won't find it in the model file.

[FaustWolf]

  AWWW YEAH!

We've got UV maps, folks! The purpose of Section 1-2 has been revealed!

This is what happens when the data highlighted in my previous post is 00'd out as per yaz0r's suggestion. Serge's model no longer maps his belt buckle:
http://img103.imageshack.us/img103/5880/image1as5.jpg

The logical next step is to 00 out the range 0xFB8 ~ 0x1E20 to see if that contains all of Serge's UV map or only a portion of it. If his whole model isn't blacked out, then Section 1-2 likely contains the UV map and only the UV map.

[ZeaLitY]

Whew, we're carving a path through destiny here.

 

Uhoh, you're at 255 posts. Don't break the limit, hah!

[Gemini]

Nice work, dude.

PS: Long time no see you, yaz0r.

[FaustWolf]

Now that kickass Sephiroth fanart has been sanctioned on this thread...


We're getting there. Thanks once again to everyone!!

[halkun]

Ok, Next step:

Count how many vertexes are in the the UV map and use that to find the vertex pool. Do the same with the polygons.

I'll offer hints when you are done with that

[FaustWolf]

Provided that the UV map commands are all aligned in the same way, it should be just a matter of counting the 16-byte wide hex rows, multiplied by 4 vertices per row. We suspect Section 1-3 contains the vertex pool, so that will be the first target of comparison once I've got a number of vertices determined.

EDIT: Shoot, I just remembered many of the vertices defined within the model's UV map will overlap. Will that change things, I wonder?
Time for a thought experiment. Let's say we've got two quads sharing the same border as follows:


The UV map would tell me that there's 8 vertices (the two green vertices are shared) in this imaginary situation. Would the vertex pool also count 8 for these two quads, or would it only count 6 since two are shared? But if the UV map is redundant, maybe everything else will be too.