CHRONO CROSS FILE EXPLORATION THREAD

[yaz0r]

Ha, sorry, you are right, this don't makes sens, I looked into that a bit too fast

Anyway, those info you are looking into are per-vertices information. The next big step now is figuring out how they are connected together.
Usualy what happens is that there is a table somewhere giving the position of the vertices of each triangle (quads in that case) and an UV index that link to the UV table you're currently looking into. The reason to separate the position from the UV is that position (and usualy normals) have to be transformed, while the UV does not (I may be wrong on that point, but I lack info on the PSX hw).
To figure that out, I suggest you count the number of entries in you UV table. That will help you  find in the other sections a value that range from 0 to the number of entry you have.

[Sora]

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? 

AARRGGBB
or Alpha 0 - 255
red - 0 255
green - 0- 255
blue 0 - 255
Alpha is how tranparent it is.

Edit: Example:  8800FFFF is half transparent cyan.

[FaustWolf]

I can tally up the quads that we know for sure exist tonight (Luminaire's already come up with a figure of 403 quads, which equals 1209 vertices for the quad data altogether, or 1209 UV coordinates). I'll end up with the same result I'm sure. So let's go with 403 quads, and I'll reconfirm later.

yaz0r, now that you've brought up the existence of a table full of quad locations, I wonder if that data at the beginning of Section 1-2 is actually such a table, and not triangle UV coordinates? Luminaire, didn't you say you saw potential pointers in that section of data?

@Sora: THANK YOU very much for the info on color/transparency. Now, if the first two bytes in the xx xx... sequence (or maybe the last two, depending on whether the Endian is reversed) represent transparency, then a 00 00 value would make the quad clear, whereas FF FF would make it completely solid, is that right? The only difficulty is, I don't *think* the xx xx... and yy yy... sequences ever had two FF bytes adjacent to one another. Is it possible that the value doesn't have to be FF FF to make the quad solid?? Or if the value wasn't FF FF but say, AA DD, would the difference be perceptible to human eyes?

Whatever the case, Sora's input tells me how to proceed in testing the non-UV data. I'll start by zeroing out ONLY the first two bytes or the last two bytes in a quad's non-UV data and see what happens. If that makes the quad disappear, it's possible that this is, after all, some sort of color/shading/transparency data. If not, I'll alter the data in a different way to test Luminaire's hypothesis.

Let me say thanks again to everybody! We are totally kicking some ass here!

[Sora]

I can tally up the quads that we know for sure exist tonight (Luminaire's already come up with a figure of 403 quads, which equals 1209 vertices for the quad data altogether, or 1209 UV coordinates). I'll end up with the same result I'm sure. So let's go with 403 quads, and I'll reconfirm later.

yaz0r, now that you've brought up the existence of a table full of quad locations, I wonder if that data at the beginning of Section 1-2 is actually such a table, and not triangle UV coordinates? Luminaire, didn't you say you saw potential pointers in that section of data?

@Sora: THANK YOU very much for the info on color/transparency. Now, if the first two bytes in the xx xx... sequence (or maybe the last two, depending on whether the Endian is reversed) represent transparency, then a 00 00 value would make the quad clear, whereas FF FF would make it completely solid, is that right? The only difficulty is, I don't *think* the xx xx... and yy yy... sequences ever had two FF bytes adjacent to one another. Is it possible that the value doesn't have to be FF FF to make the quad solid?? Or if the value wasn't FF FF but say, AA DD, would the difference be perceptible to human eyes?

Whatever the case, Sora's input tells me how to proceed in testing the non-UV data. I'll start by zeroing out ONLY the first two bytes or the last two bytes in a quad's non-UV data and see what happens. If that makes the quad disappear, it's possible that this is, after all, some sort of color/shading/transparency data. If not, I'll alter the data in a different way to test Luminaire's hypothesis.

Let me say thanks again to everybody! We are totally kicking some ass here!

well, okay. for hex, FF is one byte, that is two characters represennt 1 byte FF FF is 2 bytes.

in my example i say 8800FFFF makes twitransparent (i think thats a word, as twi is a prefix meaning half) cyan.
88 - the Alpha aka transparency
00 = red
FF = green
FF = blue

in hex FF means 255, because you count like 1,2,3,4,5,6,7,8,9,a,b,c,d,e,f,10
so its really [88][00][255][255]

so to be transparent, it just needs one 00 value, and to show up, it just needs one FF.

also, it doesnt HAVE to be FF to show up, it just has to be > 00.
for example, if i wanted serge to look like a ghost, i'd set his transparency to 55. he'd show up, but you'd be able to see through him. if the value was say FE, i bet it'd be hard to tell the differance between FE and FF.

man, if i keep helping i'll lose my rep as an annoying and spamming member >.< lol

[Luminaire85]

If the non-UV data is color data, then it's almost certainly three or four 16-bit colors (for triangle and quad data, respectively), as yaz0r said. One color per vertex is not unheard of in 3D model data. However, there is the multiples-of-8 pattern I found to consider. Color data would be highly unlikely to do that.

Interestingly, some of the non-UV values (read as 16-bit) are 0xFF??. Actually, it looks like the most-significant byte is always very near zero or very near 255, which is a sign of signed data. But pointer data is not signed, so I'm a little confused about that.

----------

If color is stored as four-byte data, it could be stored as A8R8G8B8 (like Sora's example), R8G8B8A8, A8B8G8R8, etc. So you can't just assume the first byte is the alpha data.

Also, 0x88 is 136 in decimal. Half-transparency would be achieved by setting the alpha to 0x7F, or 127.

[FaustWolf]

Wow, okay. The color discussion is getting more complex by the minute! I misread Sora's post, thinking the semitransparent cyan example read AA AA RR RR GG GG BB BB when it was only four bytes.  Silly brain.

Unless there's also gouraud(?) shading in there as well, with one byte per vertex of the quad. I don't know how likely that would be, but I guess it would account for all 8 bytes. I guess I'll still proceed as I had planned, changing the first and last byte pairs of the non-UV data to see if that invokes transparency.

Luminaire, what do you think of this observation made by yaz0r?

Usualy what happens is that there is a table somewhere giving the position of the vertices of each triangle (quads in that case) and an UV index that link to the UV table you're currently looking into. The reason to separate the position from the UV is that position (and usualy normals) have to be transformed, while the UV does not (I may be wrong on that point, but I lack info on the PSX hw).

The table he refers to -- could that be the vertex pool in Section 1-3?

[Luminaire85]

That's what I'm hoping. If we can figure out how the non-UV data points to the vertex data (if that's what it indeed does, of course), then I can have my program output the vertex data, how the vertices are connected into faces, and the UV data in such a way that I can import it into Blender. Hopefully the result will look at least somewhat like Serge.

[FaustWolf]

Ahh, so going back to the byte string:

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

Is it possible the xx xx... series could point to QUAD 1's position in the vertex pool? Am I understanding that right? Or is it the mysterious (possibly triangle?) data early on in Section 1-2 that points to the vertex pool?

[Luminaire85]

My guess would be both. Each 16-bit sequence in the non-UV data would point somehow to the location of one vertex.

The point of having both a vertex pool and a "face pool" is that each vertex belongs to multiple faces, so it's cheaper storage-wise to store a pointer to the vertex (2 or 4 bytes) rather than another copy of the vertex itself (6 or 8 bytes).

Does that make sense?

[FaustWolf]

Crystal clear -- I think. If I'm understanding that correctly, then in the scheme:

                                   -U1 V1 U2 V2 U3 V3 U4 V4 (QUAD 1)
aa bb xx xx xx xx xx xx-

"aa bb" would point to the first vertex's location in Section 1-3?

If so, the pointer would be relative, but relative to what, I wonder? The beginning of Section 1-3?

[yaz0r]

I'm going to slightly change the topic, but I have noted a few things that might interest you...

In Serge model mine file, I looked into the very last weapon model, and I noted the following:
data arround 22E10 is most probably the texture palette. The texture seems to be in 4bit mode, so that can be checked easily.

Next to that, there is 3 distinct blocks:
block 1: starts at 22E40, stride is 0x1C, num entries is 0x24
block 2: starts at 23230, stride is 0x24, num entries is 0x39
block 3: starts at 23A30, stride is 0x8, num entries is 0x4D

There is a few things we can make out if this.
block 1 and block 2 share similar design, but after a bit of inspection, block 1 is obviously the triangle table and block 2 the quad table.
Block 3 will be discussed later

A few block 1 entries:

7070 6034 8080 7D00 6060 6000 534D C03F 5147 1600 4E4A 4C00 3B00 3700
6060 6034 8080 7D00 7070 6000 4E4A C03F 5147 1600 534D 3800 4C00 3500
6060 6034 6060 6000 6060 6000 534D C03F 4A4D 1600 534D 3800 3B00 4C00
6060 6034 6060 6000 8080 8000 454F C03F 454F 1600 4C4F 4600 3B00 3800

A few block 2 entries:

6060 603C 6060 6000 A0A0 A000 8080 8000 583D C03F 513A 1600 5E3A 5635 3900 4A00 4700 4300
8080 803C 6060 6000 A0A0 A000 6060 6000 5635 C03F 513A 1600 5E3A 583D 4300 4A00 4700 3900
7C80 703C 7080 7000 9090 8800 8080 8000 341B C03F 461B 1600 3810 4913 2800 2B00 2600 2D00
8080 703C 8080 8000 6A70 5000 7080 7000 5614 C03F 4913 1600 501B 461B 2E00 2D00 2C00 2B00
7080 703C 8080 8000 6A70 5000 8080 7000 461B C03F 4913 1600 501B 5614 0C00 0B00 0900 0100

As said, the sequence are similar, with 3 vertices for block 1, and 4 for block 2 (hence the triangle vs quad).

The actual format is:
for each vertice {
    3bytes (usualy similar and most of the time alligned on 16)
    1byte
}
1 float (around 1.5f, is that scaling ?)
1 32bit value (is that an offset ?)
2 8bit values in case of block 1 and 4 8bit values for block 2
for each vertice {
    a 16 bit value
}

Additionaly, the last table of 16 bit data (one for each vertice) seems to range from 0 to the max number of entry in block 3.

Now what is block 3 ? But the vertex data off-course !
Block3 is just a table of 16bits X, Y, Z values padded with a blank 16bit of data.

I do not pretend all this to be completly accurate. Anyway, the point of all this is that when working on a file format, you should always start from the smallest dataset you have, and look at different models at the same times, as one model might give you clues that another would not...

Hopes this help.

[FaustWolf]

Wow, thanks yaz0r! So the weapon models seem to combine triangles and quads then? Perhaps the same is true for the character models as well after all.

[yaz0r]

This should give you an idea of what you are looking for in serge model. In case of a skinned model like serge, there should be a section that describes bones, and an additional entry for each vertice giving the bone it is bound to.
The other issue with skinned models is that vertices may be in bone-space, and not in model-space like that would be the case for an unanimated object.

[FaustWolf]

...in which case there should also be pointers to the bone section? We haven't identified that yet; I'm not sure if it's Section 2 (not to be confused with Section 1-2) or not. But I'll say tihs -- wrecking Section 2 makes Serge go all squiggly, and if all of Section 1 is "in sync" with Section 2 (meaning, if I overwrite both Section 1 and Section 2 with Kid's data) then the texture seems to map "properly" to Serge's "squiggly-ness." I'll summon up some previously posted Youtube vids to illustrate that:

Section 2 of Serge's model overwritten by Kid's data:
http://www.youtube.com/watch?v=QgVi-lTspDY

Sections 1 and 2 of Serge's model both overwritten by Kid's data:
http://www.youtube.com/watch?v=smXwjqrCjIM

I'm not sure if that provides us any clues regarding bone data.

- - - - -

Alrighty, first result of the evening:



This is significant. I targeted the two quads that map Serge's belt buckle in the following fashion:

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

This means that we aren't looking at color data, but something that needs to be fully intact in order for the quad to be drawn. In short, a pointer as Luminaire hypothesized before. I'm going to 00 out a middle byte in one of the quads just to be sure.
- - - - -

UPDATE:

Lookie here:


Those little sparklies circled in the left-hand pane mean part of Serge's belt buckle texture is mapped. I'll provide an illustration of how I changed the data this time. Here's how it originally looked, with bolded bytes the ones I 00'd out:

                                    -U1 V1 U2 V2 U3 V3 U4 V4  (QUAD 1)
90 13 E0 13 68 09 90 09 -U1 V1 U2 V2 U3 V3 U4 V4  (QUAD 2)
50 13 10 14 E0 FF C8 FF

Sooo...The portion of Serge's belt buckle that was still mapped this time is in QUAD 1 based on my notes. The intact triangle seems to be defined by three bytes bolded 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

Grr, I'm not sure what it means yet. Confuzzling. My next move will be as follows: transfer the xx xx... string values to the yy yy... string and zero out the xx... string. If we are correct in assuming we're looking at pointers of some sort, then the result should be QUAD 2 mapped to QUAD 1's position on the model. That is my belief! At least for now...

[Cyberman]

Are there not more sections than 1 2 and 3?

Cyb