CHRONO CROSS FILE EXPLORATION THREAD

[FaustWolf]

We've examined Section 1-2 and 1-3 so far, Cyb. Section 1-2 (what we're investigating in-depth at the moment) seems to be the UV map and something else (perhaps pointers); and Section 1-3 is most likely the vertex pool. In short, we've been stuck in Section 1 all this time!

Bone data and animation data, and perhaps some other data, should be found in Section 2, Section 3, Section 4, and Section 5. We've got a long ways to go yet!

- - - - -

UPDATE: This complicates things in my mind! This is what I did:

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

And here's the result:



Putting this all into English: I expected Quad 2 to be mapped in Quad 1's place, and Quad 1 to be nonexistent. However, it is in fact Quad 2 that is nonexistant and Quad 1 is still drawn, although flipped 90 degrees leftward!! Thus, my current hypothesis:

I have a pet theory, but it's too darn complicated, so I'm going to rely on Occam's Razor and hope that my next experiment will help me make sense of things. Feel free to speculate in the meantime on these resutls.

[Cyberman]

Perhaps I should have said "subsections" 1, 2, 3
FF7's models had a section 1 which had an HRC header that was used for the bones and then each bone came from it.  I am sure the data for CC is not much different. If you have UV and vertex data (1-2 and 1-3) respectively.  The poly information is likely grouped with the UV data (as it would be parity with it as Yaz0r pointed out).  I thought there were 6 subsections to section 1? The disjoint nature of things at the moment is a tad messy at the moment for me.  However I should be able to create some of the information for POVray output.  I just forgot what section held the TIM data.
Now it's likely you have around 600+ polygons right? Section 3 may have more than just vertex data.
The polygon data may be packed, which would make things kind of interesting.
I'm positive that they have models with more than 256 vertexs therefore 1 byte per vertex is not a likely fit.  FF7 used 1 word per vertex index but the words were *8 byte offsets into the vertex array.  The same is possible here, as speed is of the essence in using the PS1 hardware.

Cyb

[FaustWolf]

There are 6 Sections to the entire model itself; 4 subsections within the first Section. Hence, among all of us Sections 1-1, 1-2, 1-3, and 1-4 have been investigated, Sections 1-2 and 1-3 most thoroughly.

I still have to devise a way of dealing with Section 1-1 yet, and Section 1-4 doesn't seem to have any impact on Serge's model when it's changed. Wierdness!

The disjointed nature of things is my bad, Cyb. I'll direct you to the Chrono Cross File Structure wiki, which contains everything we know (or think we know) so far as a collective about the character battle models: http://www.chronocompendium.com/Term/Chrono_Cross_File_Structure.html#Character_Battle_Models

As a companion, here's a pack with Serge's and Kid's models. Don't worry about the ModelMine files for now; the characters sans textures and weapons should be in here:
http://www.chronocompendium.com/Forums/index.php?action=dlattach;topic=4770.0;attach=1987

On to one more experiment to devine the nature of the non-UV data that accompanies the UV maps for quads...

EDIT: UPDATE IN WORKS. WILL CLEAR UP SOME CONFUSION (mine at least). Be back in a few.

[FaustWolf]

First, the evidence. Open this pic in a new window; file size is prohibitive for 56k users, maybe:
http://img104.imageshack.us/img104/2037/prooflr4.gif

What's happened? Serge's rear end has been mapped to his belt buckle quads, and his belt buckle has been mapped to his rear end quads! Here's what I did:

BELT BUCKLE UV and NON-UV DATA:                                       REAR END UV and NON-UV DATA:

                                   -U1 V1 U2 V2 U3 V3 U4 V4                                                      -U1 V1 U2 V2 U3 V3 U4 V4     
aa aa aa aa aa aa aa aa-U1 V1 U2 V2 U3 V3 U4 V4                   xx xx xx xx xx xx xx xx-U1 V1 U2 V2 U3 V3 U4 V4
bb bb bb bb bb bb bb bb                                                         yy yy yy yy yy yy yy yy


NOW, SWITCH NON-UV DATA LIKE SO...

                                    -U1 V1 U2 V2 U3 V3 U4 V4                                                      -U1 V1 U2 V2 U3 V3 U4 V4     
xx xx xx xx xx xx xx xx -U1 V1 U2 V2 U3 V3 U4 V4                  aa aa aa aa aa aa aa aa- U1 V1 U2 V2 U3 V3 U4 V4
yy yy yy yy yy yy yy yy                                                         bb bb bb bb bb bb bb bb 

See what I did? Leaving the UV maps for Serge's rear end and belt buckle alone, I swapped the non-UV data corresponding to those pairs of quads. If doing this switched which texture pieces are mapped to which polygons, we have the following for Section 1-2's quad data structure:



So basically, there's a UV map followed by a pointer to the polygon that UV map "maps" to!

If this makes sense to others besides myself, it shall be added to the wiki.

HOWEVER -- we are not finished with Section 1-2 yet! We must figure out the purpose of the non-quad (possibly triangle, possibly something else) data that occupies offsets 0x358 ~ 0x0FB8 in Serge's model data! Thus will begin my next series of experiments.

ADDENDUM: 403 rows of data for 403 quads on Serge, by the way. The quad data occur between offsets 0x0FB8 ~ 0x28E7 for 6448 bytes in decimal. Divided by 16 bytes per quad (8 bytes for each UV map, followed by 8 bytes for each polygon pointer), that makes 403 rows and 1612 vertices, just as Luminaire said earlier.

[FaustWolf]

Folks who haven't read the post that immediately precedes this, please do so. Now for an addition so important it needs its own separate post:



Serge looks mean when he's missing half his mouth. Anyway, this is what happened when I 00'd out all the data at the beginning of Section 1-2, offsets 0x0358 ~ 0x0FB8. It appears that triangles are missing!

So those offsets apparently contain triangle data that is analogous to the quad UV maps and associated pointers!! I think I'm merely confirming what Luminaire has already stated about the contents of this offset range, but so much the better. I'll see if I can't figure out the exact structure of the triangle data as occurred with the quads.

[Sora]

"Why are you in the way? Are you mister in the way!?"

[FaustWolf]

I'm glad the pic was put to good use, Sora.

Time for an UPDATE:

The early part of Section 1-2 seems to be structured as follows:

                                     - U1 V1 U2 V2 U3 V3 xx xx
xx xx xx xx U1 V1 U2 V2 - U3 V3 yy yy yy yy yy yy
U1 V1 U2 V2 U3 V3 zz zz - zz zz zz zz

The structure is exactly the same as with the quads; the xx xx... string is a six-byte pointer to a triangular polygon stored somewhere else perhaps, and the UV coordinates preceding it map the appropriate part of the texture to the triangle indicated by the xx xx... string!

To boot, all FF values appear in the xx xx... ; yy yy...; and zz zz...-type areas. That means we're good to go! Only thing that bothers me is that the data doesn't retain a neat 32-byte alignment (or does it?) Cyb or Halkun, is this still okay?

Anyway, here's proof that the triangle data behave the same way as the quads:


Now we need to figure out where all these pointers are pointing at.

Also, I'm arriving at a figure of 264 triangles.  Offset range 0x358 ~ 0xFB8 contains 3168 bytes if counted in decimal, divided by 12 bytes for each triangle (6 for UV map, 6 for pointer) yields 264 polygons.

Therefore, we've got 403 quads and 264 triangles. Luminaire, IIRC that's what you said to begin with -- is this correct?

- - - - -

Anyway, we kicked some major ass and tore lots of model data up today, folks. Therefore, I shall leave you with a pic of Gally (from the manga Battle Angel)...kicking ass and tearing stuff up:

[attachment deleted by admin]

[yaz0r]

Only thing that bothers me is that the data doesn't retain a neat 32-byte alignment (or does it?) Cyb or Halkun, is this still okay?

that means you have a stride of 0xC (aka, 12). And that's perfectly fine

[halkun]

Therefore, I shall leave you with a pic of Gally (from the manga Battle Angel)...kicking ass and tearing stuff up:

I used to read Gunnm (Battle Angel) when I lived in Japan. At the time it was still being serialized in Shonen Jump. It's funny how absolutely twisted the translation got overseas. Especially when you realize was Gally's real name is. She was named after Edo's cat, which had recently died.... The Cat was Male.

It's name was Gary

That's why everyone tells her she has a "weird" name at the beginning. Her name is "Gary", not "Gally". When I see her, I *always* called her "Gary". It was the name I grew up with.

Don't even get me started on the whole "Alita" thing. She was *SUPPOSED* to have a weird name in the first place.

[FaustWolf]

Heh heh. I was completely unaware of the Gary => Gally messup. I suppose it makes sense when you pronounce "Gally" in Engrish. Some fansites say that "Gally" is short for "Gallium" so maybe that's where the translator was coming from.

Back to the models, do these findings seem plausible to everyone? A quad or triangle UV map followed by some sort of pointer to the polygon it's supposed to be mapped to?

Luminaire, when you created the UV map for Serge's battle texture in Blender, did you use the stride pattern yaz0r mentioned for the data in offset range 0x0358 ~ 0x0FB7?

[Luminaire85]

Yeah, the UV map I posted has both the triangles and quads represented. The best part is that the UV coordinates appear to span the entire texture.

It would be nice to figure out if there's some sort of header somewhere that tells us there are 264 triangles and 403 quads in Serge's 3D model.

[FaustWolf]

I suppose we could try looking for the hex equivalents of 264 and 403 in Little Endian. Would you expect this data to be signed or unsigned, Luminaire?

And if working with signed hex becomes necessary, do you know if there's any decimal -> hex converter utility that has signed/unsigned options? I think Windows Calculator only works with unsigned hex, but I could be wrong.

[yaz0r]

I suppose we could try looking for the hex equivalents of 264 and 403 in Little Endian. Would you expect this data to be signed or unsigned, Luminaire?

Signed or unsigned doesn't matter, it will still look the same in hex

[FaustWolf]

Is that right, yaz0r? So I could just search for 0x0108 (08 01 in Little Endian) for 264 triangles, 0x0193 (93 01 in Little Endian) for 403 quads, and 0x029B (9B 02 in Little Endian) if the header gives a total number of polygons (667) instead of triangles and quads separately?

EDIT: Ooh! Hang on! Toward the end of Section 1-1, at offset 0x029C in Serge's untextured model file, there's the value 60 0C, which is Little Endian for 0x0C60, or 3168 -- that's the number of bytes for the triangle map and pointer data. Could it be a clue?

It may just be a coincidence, because I'm not seeing 0x1930 (30 19 in Little Endian) for 6448 anywhere that would appear to be a suitable location for a header.

[yaz0r]

You have to search for 0x08 0x01 for 264 triangles, and 0x93 0x01 for 403 quads.
Unfortunatly I didn't find anything worth noting while searching those values in the model file. Maybe they are expressed in another way...