CHRONO CROSS FILE EXPLORATION THREAD

[Cyberman]

No it would not.
To find the vertexes themselves all you need to do is dump what you think are vertexes into a 3d program such as POV or blender. If they form bits on a shape then they are vertexes.  Vertexes are likely stored as 8 byte records because the PS1 requires 32 bit alignment.  They may have used the 'extra' 4th column for something else.

I couldn't find a recent Serge Model dump so I poked a bit around
If 1-2 is the UV data here is a good way to approach things.
First you find how many UV pairs you have (shock) second you know how large the section is.
9616 bytes in size this means you have at least 4808 UV pairs let's say there are 3 UV pairs per polygon.
Ok it means 16 bytes might be used for something else (likely) and 4800 UV pairs that makes 1600 (exactly) polygons needed (assuming they are all triangles that is ). Assuming they are all quads makes 1202 or 1200 polygons.  Your polygon space needs to use between 9600 and 12800 bytes.  This is because you have 4 words per primitive irregardless of the number of vertexes in the primitive (due to 32 bit alignment issues).
That should give you a clue of what to look for in terms of the size of the index.

Have you determined what section 1-1 is yet?

I think 1-3 is the vertex pool (not positive but it's 6496bytes and this divides to a 812 vertex count, this is always smaller than the polygon count usually it's 1:1.5 to 1:2 in ratio ) unless I'm mistaken (wouldn't be the first time) as the data appears to be signed etc. It's likely in the ODD PS1 format (wee) IE 1:3:12 Likely you can calculate the vertex by dividing it type cast as a short int by 4096.0 so FFE7 could be -0.0061.

Cyb

[justin3009]

Not to completely change anything, but what program are you guys using to dump that stuff?  I've recently been interested into starting a project that deals with PSX hacking but I need something that can dump data and I haven't been finding anything anywhere ._.

[FaustWolf]

Lately I've just been snatching data with a hex editor, Justin, but I can only do that because I know exactly where the files are. That info, in turn, was made possible by Yazoo's (yaz0r's) dumper (made specifically for Chrono Cross), which rips individual files from the game image and thus gave me a good idea of Cross' file structure when it comes to models and such.

If you can't see the file archives on your PSX game disc when you pop it into your CD drive, you're in the same boat we are with Chrono Cross. When that happens, you have to rely on an index file that should be first thing on the game CD (although the PlayStation logo model and some other bootup stuff may come before -- I think that's the way it is with Cross). As far as how to read an index file, you'd have to ask yaz0r; I think his dumper might operate by stepping through the index file and dumping raw data based on the offsets reported by that file. yaz0r, is that basically how it works, or am I totally off?


Now back to the Cross models. I haven't figured out what Section 1-1 is yet, but I can say it's extremely sensitive to tweaking; usually causes the game to freeze when I overwrite Serge's Section 1-1 with another character's. I need to go back and carefully alter some of the bytes, and see if I can find out what's up there.

But first, I'll get a count of the (U,V) pairs in Section 1-2 and we can go from there. The UV map seems to trace out quads, and the UV map data are arranged as follows:

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

I'll look into it more tonight to determine if every row of hex code contains (U,V) coordinates, which I think is the case. A complicating factor will be whether Section 1-2 contains other data besides the texture map. There's a nice pattern in Section 1-2's ASCII signature, but it doesn't last throughout the entire subsection.

[justin3009]

Ah....Mmk thanks.

[FaustWolf]

I can cheerfully say that Serge's UV map probably ends at offset 0x28DF. It *may* end at 0x28E7, in which case:

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

would become:

U1 V1 U2 V2 U3 V3 U4 V4-U1 V1 U2 V2 U3 V3 U4 V4 (*NOTE: FORGET THIS. SEE BELOW)

But I'm going to check on that right now. Update in the works.

EDIT: Okay, THIS was unexpected, but I probably should have seen it coming. Within Section 1-2, the following scheme:
                                   -U1 V1 U2 V2 U3 V3 U4 V4  (QUAD 1)
xx xx xx xx xx xx xx xx-U1 V1 U2 V2 U3 V3 U4 V4  (QUAD 2)
yy yy yy yy yy yy yy yy

...operates as follows. The row labeled QUAD 1 maps out a quad on the texture as expected. The 8 bytes labeled xx xx... actually determine color or perhaps shading. When all 8 bytes in the xx xx... range are set to 00, QUAD 1 becomes transparent! Rinse and repeat for QUAD 2 and its associated yy yy...

Here's visual evidence:


In the context of my exposition above, QUAD 1 is labeled "1" in red, both on the magnified texture and Serge's rump (I didn't choose this on purpose, you know. Just business...) while QUAD 2 is labeled "2" in both pics. I essentially changed the yy yy range to 00 bytes, leading to QUAD 2 becoming an open window through Serge's model! QUAD 1 is blacked out because I changed the UV map values to 00 bytes without altering the xx xx... range.

So what does this tell us? It appears that each quad on the texture map is followed by 8 bytes that define that quad's color/shading/transparency on the model. So if we count this "color" data as part of the UV map, then the UV map data terminates upon reaching offset 0x28E7, or the end of Section 1-2.

That came out more complicated than I had hoped; if anyone would like clarification on my findings tonight, just ask. I'm a bit confuzzled at the prospect of 8 bytes defining color, because I'm used to thinking of colors in terms of 3 bytes: 1 for Red, Green, and Blue each. Why would a color value possibly need 8?

Another thing that's discombobulating my brain at the moment: within the UV map data, some values in the "V" column are FF. Yet the battle textures are 128x252 pixels in WidthxHeight, meaning the max value in the V(Height) direction should be "FB" at the most (for 251 in decimal). Another piece of food for thought: when an FF does occur in a row of UV data, there seems to always be one other FF in another "V" column. Which leaves 6 bytes - enough to map one triangle on the texture. Is it possible that:

xx xx xx xx xx xx xx xx-U1 FF U2 V2 U3 V3 U4 FF

actually means:

xx xx xx xx xx xx xx xx-U1 N/A V1 U2 V2 U3 V3 N/A?

i.e., the "FF" is essentially a "skip me!" value allowing the data alignment to be preserved while directing the GPU to map triangles instead of quads? Is it possible that a single texture could be mapped alternately as quads and triangles?

[FaustWolf]

Okay, drop the FF = "skip me!" idea. I've seen up to three FF values in the UV map for a quad, all in the "V" columns. In fact, the range where I'm seeing "FF" in the V position may not even be UV map data at all! The phenomenon seems to occur within a range in Section 1-2 I was on the fence about in the first place. Only way to tell is to mess with some more data - but that won't happen till tommorow evening I'm afraid.

Yet another monkey wrench -- the model has to map a model texture, sure, but it also has to map an "eyeball blink" texture on top of that. I'm guessing there's got to be data defining a texture page at some point, and that tells the processor which texture in VRAM it's looking at - body or eyeball.

In the meantime, advice and feedback is most welcome. My top objective is to get Section 1-2 completely figured out. I know the UV map data ends at offset 0x28E7 now, but I do not know where it begins just yet for the above-cited reason ("FF" values toward the beginning of Section 1-2).

[Luminaire85]

I think Section 1-2 contains both triangle and quad data.

Note that Section 1-2 starts with apparent 6-byte sequences. I think you can describe the triangles with the structure

aa bb cc dd ee ff ?? ?? ?? ?? ?? ??

where (aa, bb), (cc, dd), and (ee, ff) are the UV data. In the early part of Section 1-2, all FF values are found in the ?? ?? ?? ?? ?? ?? sections. I bet this continues in the quad part of Section 1-2. Also, if the question mark bytes are read as three 16-bit integers, all three are always divisible by 8. This is often a sign of pointer data, but pointers to what?

Based on your notes and the hex pattern, I bet the triangle-quad transition occurs at 0x0FB8. If this is true, then there are exactly 264 12-byte sequences and exactly 403 16-byte sequences in Section 1-2. 264 + 403 = 667.

[FaustWolf]

A transition from triangles to quads makes very good sense, Luminaire. I haven't done much investigating toward the beginning of Section 1-2 yet, but I did notice a stark change in the data structure's ASCII signature around that offset (0x0FB8).

667 polygons is our preliminary count then, right? With 264 triangles and 403 quads?

EDIT: Yes, offset 0x0FB8 is definitely the point at which the "FF" values disappear from the texture map data. The FFs still occur among the data that define color/shading/transparencies of the quads, but that's not problematic to me. In my investigation for tomorrow, I'll focus on finding out which bytes affect transparency, which affect shading, and which affect color of the quads in the range 0xFB8 ~ 0x28E7, if indeed those functions can be separated.

[Luminaire85]

A picture of the UV data mapped roughly onto Serge's battle model is attached. Seems to be decent at least.

There are about ten or so exceptions in the quad data, where FF bytes are present in the wrong locations. My immediate thought is that, for some reason, the UV and non-UV data might be reversed. Seems weird though.

At this point what we're still missing is which vertices correspond to each face. I'm hoping this is what the non-UV data in Section 1-2 refers to. I guess I'd be surprised if the non-UV data is color/shading/transparency information, but we'll see.

[attachment deleted by admin]

[FaustWolf]

 

Did you code a program to do that, Luminaire? That is freaking awesome! Does your program map out the potential triangles as well as quads, or just the quads?

I now disavow the possibility of the non-UV data referring to colors and shading, because it just theoretically doesn't make sense to me anyway, seeing as the non-UV data occurs in 8-byte chunks anyway. Your idea is much better.

Later on I'll pick a specific quad, then mess with its corresponding non-UV data a few bytes at a time to see what happens. If the non-UV data tells the GPU/GTE(?) which vertices correspond to each face, would it make sense that the polygon would become entirely transparent if the data were 00'd out, as occured in my example above?

[Luminaire85]

I have a C++ program going that I use to experiment with various ways of reading the data (bits per number, signed/unsigned, etc.) One of the things I like to do is spit out sets of numbers to a text file, and I've been adapting my code to generate output in a form I can read into Blender (Wavefront OBJ). That's how the picture above was made.

The picture above spans all of the data in Section 1-2 (so both triangles and quads), using the parts of it we believe are the UV data.

If the non-UV data is what I think it is, it would make sense that zeroing the non-UV data out would cause the corresponding face to not be drawn. I will be interested to see what happens when the non-UV data is changed but left nonzero.

[FaustWolf]

Gotcha. A non-00 change to the non-UV data will be the next project for me then. I'll most likely overwrite a quad's non-UV data with straight CC's or some consistent value.

[yaz0r]

Just a small note, the PSX handle color stored on 16bits. That's probably what you have here.
I don't have the specs with me, but I think it can be found in the GTE section of that PSX.pdf document.

Anyway, glad to see progress

[yaz0r]

According to the spec:
Mask = 15th bit
Blue = 10-14th bits
Green = 5-9th bits
Red = 0-4th bits

[FaustWolf]

Yes, thanks for all the help again yaz0r! Now, there's actually 8 bytes we need to worry about in the non-UV data scheme I posted above (I posted xx xx... meaning there was an 8-byte series, not just the two bytes, so my bad if that's why you posted the color specs for 16 bits/2bytes  ).

The quad data (I still have to investigate what are potentially UV map triangles earlier in Section 1-2) are arranged as follows:

                                   -U1 V1 U2 V2 U3 V3 U4 V4  (QUAD 1)
xx xx xx xx xx xx xx xx-U1 V1 U2 V2 U3 V3 U4 V4  (QUAD 2)
yy yy yy yy yy yy yy yy

...with the xx xx... 8 byte series controlling "SOMETHING," or perhaps a set of "SOMETHING"s for QUAD 1 and the yy yy... 8-byte series controlling that same set of "SOMETHING"s for QUAD 2. All I can confirm at this point is that when the entire 8 byte series is 00'd out, the quad disappears entirely and becomes a "window" right through the model.

So if color can be handled with 16 bits (2 bytes), that can't account for the entire xx xx... and yy yy... series, correct? Unless I'm missing something in your explanation?