CHRONO CROSS FILE EXPLORATION THREAD

[FaustWolf]

The discovery continues! 

I present as an attachment to this post all of Section 1-1, with an outline of Section 1-1-1!. Luckily, I haven't seen any sub-sub-sub sections yet, so I think three numbers is as deep as we'll have to go.

Section 1-1-1 is periodic, with a stride of 4 bytes (hope I'm using technical language correctly here  ). The last two bytes in any "slot" would seem to be a bone or joint index. Here's an example of how they work...

The value 0x0003 is the index number for Serge's head bone or neck joint. The bytes 03 00 @ address 0x52 tell the powers that be to assign the rotational and other data of joint D from Section 2 to Serge's head/neck. In addition, animation from an as-yet unknown source (Section 4, most likely) is also assigned.

So what happens when we change the bytes @ address 0x52 from 03 00 to 04 00? Serge's head is ripped right off his neck, given the rotational data for joint E (bandana-right), and starts jerking just like Serge's bandana tail does! Here's a pic to give everyone a proper impression:


Now let's take a look at the pattern in the last two bytes of each "slot" in this sub-subsection. The indices run in this order:

00; 01; 02; 03; 04; 05; (06 excluded); 07; 08; 09; (0A excluded); 0B; 0C; 0D; (0E excluded); (0F excluded); 10; 11; 12; (13 excluded) 14; 15; 16.

Five joint specifications from Section 2 are excluded, bringing this down to 17, or 0x11, slots -- our theoretical number of bones (18 bones, actually, if you count starting at 1 and not 0). But we were mistaken about which joints should be excluded. Let's take a look at which joint specifications from Section 2 are excluded here...

A (unseen in diagram): Root bone articulation; runs through center of model.
B: Root bone articulation; runs through center of model.
C: Waist articulation.
D: Neck articulation.
E: Bandana tie - left.
F: Bandana tie - right.
G: Upper Shoulder - left.
H: Lower Shoulder - left.
I: Elbow - left
J: Wrist - left.
K: Upper Shoulder - right.
L: Lower Shoulder - right.
M: Elbow - right.
N: Wrist - right.
O: Weapon.
P: Upper Hip - left.
Q: Lower Hip - left.
R: Knee - left.
S: Ankle - left.
T: Upper Hip - right.
U: Lower Hip - right.
V: Knee - right.
W: Ankle - right.

The weapon and extra shoulder and hip joints are removed, leaving us with the number of bones on the character model itself perhaps. That would leave us with two root bones, which I'm not particularly happy with, but it could be what's going on.

So what do the first two bytes in each slot do? Hell if I know. Here's the typical results of changing them...
http://s2.supload.com/gal/0802086837/0/

In order, the experiments conducted in this gallery were...

1st: @ address 0x48, changed 02 -> 03
2nd: @ address 0x48, changed 02 -> 04
3rd: @ address 0x4C, changed 08 -> 0A
4th: @ address 0x50, changed 53 to 5A

I don't think it's bone length that's being affected; what are your opinions? Something having to do with vertex assignments, perhaps? Note that symmetrical appendages (Serge's bandana ties, for example, the fifth and sixth slots) have identical values for the first two bytes.

EDIT: BTW, this is what happens when I give Serge's head slot the first two bytes shared by his bandana tie slots. It doesn't simply turn Serge's head into a bandana tie, which is what I was hoping for.


I really have no clue what's up with the first two bytes in each slot of Section 1-1-1.


[attachment deleted by admin]

[MDenham]

Five joint specifications from Section 2 are excluded, bringing this down to 17, or 0x11, slots -- our theoretical number of bones (18 bones, actually, if you count starting at 1 and not 0). But we were mistaken about which joints should be excluded. Let's take a look at which joint specifications from Section 2 are excluded here...

A (unseen in diagram): Root bone articulation; runs through center of model.
B: Root bone articulation; runs through center of model.
C: Waist articulation.
D: Neck articulation.
E: Bandana tie - left.
F: Bandana tie - right.
G: Upper Shoulder - left.
H: Lower Shoulder - left.
I: Elbow - left
J: Wrist - left.
K: Upper Shoulder - right.
L: Lower Shoulder - right.
M: Elbow - right.
N: Wrist - right.
O: Weapon.
P: Upper Hip - left.
Q: Lower Hip - left.
R: Knee - left.
S: Ankle - left.
T: Upper Hip - right.
U: Lower Hip - right.
V: Knee - right.
W: Ankle - right.

The weapon and extra shoulder and hip joints are removed, leaving us with the number of bones on the character model itself perhaps. That would leave us with two root bones, which I'm not particularly happy with, but it could be what's going on.

This is pretty close to what I said, aside from it being the weapon that's skipped instead of one of the two root bones.

Anyway:

So what do the first two bytes in each slot do? Hell if I know.

From the looks of things, it controls how the assignment of polygons to a bone is, along with (part of) the rest of Section 1-1 - whether it's 1-1-2 (starting at 2A 00 00 00 @0x8C and running for I don't know how long - probably either 84 or 168 bytes, putting its end at either 0xE4 or 0x138; note that if there's only one section, then the rest of this is either compressed in some odd manner, or it really does have a stride of 17 bytes) or 1-1-3 (unsure of the starting point, but runs until the end) that it's referencing, I'm not entirely sure.  I think it's working from 1-1-3, however.

[Luminaire85]

The attached picture is to show the bone connectivity my Blender importer is finding in the Serge battle model. I don't have the bone positions/orientations/scales yet, as I played with those to produce the image. It's supposed to look kind of like a person in that, based on your earlier notes:

- Bone.0 and Bone.1 are the root bones
- Bone.2 and Bone.3 are the spine
- Bone.4 and Bone.5 are the bandana ends in the head
- Bone.6 through Bone.9 are one arm, Bone.10 through Bone.13 are one arm, and Bone.14 the swallow
- Bone.15 through Bone.18 are one hip and leg and Bone.19 through Bone.22 are the other hip and leg

That makes 23 bones in total. Now if we could only figure out which vertices go with each bone...



[attachment deleted by admin]

[FaustWolf]

I'm not sure if it makes a difference Luminaire, but it's 23 joints and 17 bones in Serge's model. Your specifications are what I've got in my notes though; just need the word "joints" instead of "bones." There's definitely some bone info in Section 1-1-1, but I won't be able to do an in-depth exploration of the rest of Section 1-1 for a while yet. Hopefully the vertex assignments are somewhere in there...

[Luminaire85]

I am wondering if the vertex pool is in some sort of order with respect to their associated bones/joints, and that the mysterious bytes in Section 1-1-1 are simply vertex counts. So when I look through Section 1-1-1, I assign 0 vertices to bone 0, 2 to bone 1, 8 to bone 2, 83 to bone 3, etc. If I select only vertices 10-93 as specified by this procedure, I get the decapitation in the attached picture.

Two problems (at least) with this idea:

(1) What happens with the bones/joints with no entry in Section 1-1-1?

(2) If you add up every other two-byte sequence in Section 1-1-1 (what I'm proposing could be vertex counts), you get 301, not 559 or 812.

[attachment deleted by admin]

[FaustWolf]

Nice work!

The weapon will be defined in its own section seperate from the model (except for rotational data, which must somehow be lifted from Section 1-2), but I'm not sure what's up with the extra hip and shoulder joints. Is it physically possible for the bandana ties to have only a single vertex each? Am I understanding that right?

[MDenham]

I am wondering if the vertex pool is in some sort of order with respect to their associated bones/joints, and that the mysterious bytes in Section 1-1-1 are simply vertex counts. So when I look through Section 1-1-1, I assign 0 vertices to bone 0, 2 to bone 1, 8 to bone 2, 83 to bone 3, etc. If I select only vertices 10-93 as specified by this procedure, I get the decapitation in the attached picture.

Two problems (at least) with this idea:

(1) What happens with the bones/joints with no entry in Section 1-1-1?

(2) If you add up every other two-byte sequence in Section 1-1-1 (what I'm proposing could be vertex counts), you get 301, not 559 or 812.

This also ruins it for them being polygon counts (which, honestly, would make a little more sense).

As far as the rest of 1-1 (which seems to only be one section, now that I look at its organization), interesting things that are fairly common:

0xNN33, where NN is 07;
0xNN66, where NN is 02, 0A, or 0E;
0xNN99, where NN is 01, 05, or 0D;
0xNNCC, where NN is 08;
0xNN00, where NN is 00, 04, 08 or 0C; and
Numbers that are 0x00??

Interestingly, everything in the first five groups is immediately preceded by something in the last group.  For example, 0x0733 is preceded by (in order) 0x0010, 0x0014, 0x0015, 0x0011, 0x0001, and 0x0001.

Also interesting is that any "entry" that starts with a number 0x0020 or larger is (apparently) 8 bytes, while everything else is 4 bytes.  This gives a total of 172 entries - 7 long ones and 165 normal.  The long entries are at the beginning (0x008C), and otherwise mostly in the middle (0x0290, 0x0298, 0x02A0, 0x02A8, 0x0348, 0x0350).  It's possible that the first four bytes are a count of something...  but I can't make 42 entries of ANY length work out properly, so I'm disregarding it at this time.

[Luminaire85]

Well I guess I'm not sure if assigning vertices or faces to bones makes more sense. Blender does it with vertex groups and weighting, for what it's worth.

At any rate, I am still thinking that Section 1-1-1 should be read as follows:

   Assign 0 vertices to Bone.0
   Assign 2 vertices (vertex index range 0-1) to Bone.1
   Assign 8 vertices (2-9) to Bone.2
   Assign 83 vertices (10-92) to Bone.3
   Assign 1 vertex (93) to Bone.4
   Assign 1 vertex (94) to Bone.5
   Assign 10 vertices (95-104) to Bone.7
   Assign 20 vertices (105-124) to Bone.8
   Assign 6 vertices (125-130) to Bone.9
   Assign 10 vertices (131-140) to Bone.11
   Assign 20 vertices (141-160) to Bone.12
   Assign 6 vertices (161-166) to Bone.13
   Assign 15 vertices (167-181) to Bone.16
   Assign 36 vertices (181-217) to Bone.17
   Assign 16 vertices (218-233) to Bone.18
   Assign 15 vertices (234-248) to Bone.20
   Assign 36 vertices (249-284) to Bone.21
   Assign 16 vertices (285-300) to Bone.22

Just looking at what vertices are in those positions in the vertex pool, it makes a ton of sense for them to be assigned to bones as stated above. The catch is that I doubt those are the only vertices belonging to those bones.

Take, for example, the ends of Serge's bandana. FaustWolf is correct that the two bones should have more than one vertex each assigned to them. But in the vertex pool the other bandana edge vertices are not adjacent to vertices 93 and 94.

This trend becomes easier to see when looking at what Section 1-1-1 assigns to Serge's arms and legs, as they end up about half-attached to the appropriate bones. This post's attached image is the UV map corresponding to the vertices assigned to Bone.20, Bone.21, and Bone.22 by the above interpretation. You can see that all vertices are in the "leg" portions of Serge's texture, but that many of the vertices are missing.

Also, the vertices assigned to Bone.16, Bone.17, and Bone.18 overlap those in the picture exactly, and the vertex overlap also occurs analogously in the arm bones.

So, does Section 1-1-2 deal with the remaining vertices (either 559 - 301 = 258 or 812 - 301 = 511)? And why not just do it the same way as Section 1-1-1?

[attachment deleted by admin]

[FaustWolf]

Awesome. I haven't had a good block of time to check out Section 1-1-2 at all, so anything's possible as far as I know. The only thing is that the numbers after Section 1-1-1 don't seem to fit a reasonable pattern (the third and fourth bytes in each "slot" are typically 00 00 there, and sometimes CC 00) -- though I really have no clue what's going on there until I test. I wonder if the entries are variable length somehow after Section 1-1-1 as M suggested above?

It'll be a while before I can test, certainly not till next weekend. In the meantime, I'll certainly take requests for experiments if it will help test out any theories you guys have.

[MDenham]

I just decided to look back a way through the thread, because 301 was rattling around back there.

HEY GUESS WHAT!

READ THIS POST.

The first run of 301 vertices is exactly how many there are before it runs into double-mode vertices.  The first two bytes after the 0x0000002A starting the next run is 0x0968, which offsets us exactly to the beginning of the first set of double-mode vertices.

Unfortunately, trying to get a count in the same fashion here gives us a total of 450, instead of 210 or 420, slots, so this second run doesn't behave quite how we'd expect.  I think it runs out to 0x02AC, at which point we have a sequence that gives all of five vertices - which happens to be the remaining block of single-mode vertices.

HOWEVER!

The double-mode vertices use longer entries here than the single-mode vertices do!  In fact, the entries here are 12 bytes instead of just 4 - the first four bytes are the number of vertices to count, and the remaining 8 don't just refer to a bone number, but also (I think) include weighting amount for the first and second parts of each vertex, thereby explaining the predominance of the numbers noted in my previous post.

This leaves two ranges of indeterminate purpose, which are fairly close in appearance (but not identical):

0x0294-0x02AB, and 0x0344-0x0357.

So, organization of Section 1-1 is just alternating segments of Type S and Type D:

Type S - Single-mode vertices.
Header: 4 bytes, number of entries minus 1.
Entries: 4 bytes -
* 2 bytes: Number of vertices.
* 2 bytes: Bone # to attach to.

Type D - Double-mode vertices.
Header: 8 bytes -
* 4 bytes, number of entries minus 1.
* 4 bytes, offset to move counter ahead by from last Type D section in this model. ^*
Entries: 12 bytes -
* 2 bytes: Number of vertices.
* 2 bytes: Zero.
* 2 bytes: ??
* 2 bytes: Weighting value #1?
* 2 bytes: ??
* 2 bytes: Weighting value #2?

Type X - Who knows?
* May simply be a "footer" for Type D sections to resync the counter for the following Type S section.

^*I'm not entirely sure if this is actually used, or if it's a throwback to an earlier version of the model loader that required it.  If it is used, it's related to the two "Type X" sections more likely than not.

Now we just have to figure out what else is being kept track of in the Type D entries, and why they aren't kept track of with the bones (I have my suspicions here - I think they're for interpolation between bones...).

EDIT: After looking at things in there, I'm an idiot for hedging my bets.  Modified version of the Type D entries follows:

* 2 bytes: Number of vertices.
* 2 bytes: Zero.
* 2 bytes: Bone 1 and slot 1.
* 2 bytes: Weighting value for Bone 1 and slot 1.
* 2 bytes: Bone 2 and slot 2.
* 2 bytes: Weighting value for Bone 2 and slot 2.

Note that EVERY pair of weighting values adds up to 0x10000 or 0xFFFF.  NO exceptions.

[FaustWolf]

*Cries tears of utter joy.* I'll be damned, that looks great. Luminaire, is this enough info for you to go off of with your model viewing plugin?

[Luminaire85]

Absolutely. That makes perfect sense.

I can add a point of clarification, too. By MDenham's logic, Section 1-1 now has four subsections. Section 1-1-3 is from 0x028C to 0x02B7, and is identical in structure to the section from 0x0020 to 0x008B. So whatever the "header" from 0x0020-0x0039 does is what the "header" from 0x028C-0x02AB does.

So the first entry in the Type S and Type D headers is the number of entries, not the number of entries minus 1. In both cases you just skip the next four bytes before you begin counting entries.

[FaustWolf]

YEE-HAW~! 

What other info do we need at this point? Do we still need bone lengths, or do the vertex assignments magically handle that issue?

[Luminaire85]

My Blender import script now assigns each vertex to at least one bone. Huzzah!

Unfortunately the model still looks like a mess because the bones aren't in the proper positions yet. The trouble is that I don't know what bone positions are the ones that result in the jumbled mess. Once I know what those are, I should be able to move the bones to a more humanlike arrangement and thereby reveal our silent protagonist. I was hoping Section 2 would contain that information, but I need to study your previous findings in more detail, as the quick implementation I did last week isn't working at all.

[FaustWolf]

The descriptions for bone rotations we came up with in the previous few pages could be off since I never did conclusively prove how the rotations are ordered. The 3D coordinates for the bone roots/joints should work like the 3D coordinates for the vertices (the X, Y, and Z specifications shoule be in the same order for both). If you need clarification on any point in Section 1-2, just ask. I can do some further experiments with that data if needed.

We're getting close! Woot-woot! Huge thanks guys!

For quick reference, our discourses on Big Section 2 start with this post and continue at great length:
http://www.chronocompendium.com/Forums/index.php/topic,4770.msg87683.html#msg87683