CHRONO CROSS FILE EXPLORATION THREAD

[MDenham]

I'm interested in any observations people might have on this. Just to be clear, there's absolutely no significance to the colors I've assigned the various "objects." I just wanted to make them stand out from one another. Also, I'm not sure that each "object" is an entire bone, since my experiment last night altered only bone angle it seems; so M's observation of 8 or so bones could still pan out. At least this gives me some structure to work with; I'll need to find out what each byte does in a given "object," and how many objects make up a bone.

Interesting to note is that, with the exception of the first 0xFFFFFFFF (at the beginning of Entry 0), all of the others terminate an entry.

Within each "group" of entries, then, the first four bytes seem to indicate an index (note: I'm converting out of hex):

Group 0: -1
Group 1: 0, 1, 2, 3, 3, 2
Group 2: 6, 7, 8, 2
Group 3: 10, 11, 12, 13
Group 4: 1
Group 5: 15, 16, 17, 1
Group 6: 19, 20, 21

4, 5, 9, 14, 18, and 22 don't appear in this list for whatever reason; 22 may be implied by the -1 in Group 0, however (though I doubt it).

Presumably, this gives the child bone list for each bone, in which case Groups 1-6 are Bones 4, 5, 9, 14, 18, and 22 respectively.

Alternatively, follow the last two bytes of each entry (again, by group):

Group 0: -1
Group 1: 0, 1, 2, 3, 4, -1
Group 2: 5, 6, 7, -1
Group 3: 8, 9, 10, -1
Group 4: -1
Group 5: 11, 12, 13, -1
Group 6: 14, 15, 16

...and also note that the two preceding bytes are 0 unless the last two bytes are 0xFFFF.

This narrows it down to a total of 12 bytes per entry of "real" data - probably X, Y, Z, rotX, rotY, rotZ in some order.

Therefore, I can pretty safely say that there are no bone lengths here - just rotations and translations.  Section 3 probably has the remaining interesting bone data, namely "what polys are attached to which bone, and (maybe*) how long the bones are".

* Assuming that the bone lengths aren't calculated upon loading the model, which is entirely possible but slower.

[FaustWolf]

THANK YOU M, that's very enlightening and gives me more ideas on what to target in further experiments. Yes, I'm definitely getting the impression from my investigations so far that only orientational data is in Section 2. When I did that first unguided experiment yestereve I fooled myself into believing I had found bone lengths when in reality I was simply telling Serge's head and some other appendages to connect to the central point in his model or something.

When I get done identifying which 20-byte runs affect which appendages and joints, I'll get a gallery up somewhere so everyone can see the effects on the models. It's quite interesting.

I'd like to report at the moment that range 0x4F4C ~ 0x4F5F is the orientation of Serge's left bandana tail, and 0x4F60 ~ 0x4F73 is Serge's right bandana tail (but I'm directionally dyslexic, so I could be off on which is which  )! Since these pieces are identical, we might be able to tell from the data where the rotational, etc., data is!

[MDenham]

I'd like to report at the moment that range 0x4F4C ~ 0x4F5F is the orientation of Serge's left bandana tail, and 0x4F60 ~ 0x4F73 is Serge's right bandana tail (but I'm directionally dyslexic, so I could be off on which is which  )! Since these pieces are identical, we might be able to tell from the data where the rotational, etc., data is!

I'd guess that the breakdown is as follows:

Bytes 0-3: Parent bone, not child bone.  In standard order.
Bytes 4-5: rotX
Bytes 6-7: rotZ
Bytes 8-9: rotY
Bytes 10-11: X
Bytes 12-13: Y
Bytes 14-15: Z
Bytes 16-19: ID # of next entry for this bone.  NOT in standard order - the upper and lower 16-bit numbers are swapped from standard order.

-1 in the parent field indicates the root bone.  -1 in the "next entry" field indicates the end of a bone.

Now for the question some of you may have - "Why are you so sure the rotations are in the first six bytes of 'real data'?"

This has to do with the "debug menu" - rotations are given as being in a 0-4095 range there.  Since it's a reasonable assumption to make that they would also be stored here in that same range (or possibly -2048 to 2047), we have to look at the range given for values in the first three numbers vs. the range given for the last three:

First three: 0xFBFB (-1029) through 0x0500 (1280).
Last three: 0xFDF0 (-528) through 0x01CB (459).

Notable is the relatively frequent presence of values near 0x0400 and 0xFC00 in the first three numbers - which correspond to 90-degree rotations - and of small numbers in general in the last three.

[FaustWolf]

Huge thanks again M. I've got a gallery up of what bones/joints are affected by which offset ranges, in order, so maybe we can gain some more insight by having this evidence in front of us all:

http://s2.supload.com/gal/0801273355/0/

If each 20-byte offset range after the Section 2 header is labeled with a letter, we have the following map of joints, or articulation points, in the model:



I start with "B" because the offset range corresponding to "A" appears to have an extremely special purpose of some sort, judging from the game hanging when I zero it out. In any case, here's a list of articulation points:

Starting from 0x4F10 and going through 0x50C7, with each letter being a run of 20 bytes...

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

It's interesting to note that some joints seem to need two "slots" of articulation data. Also, weapon articulation is completely handled within the character model itself, so no animation data would theoretically be needed in the weapon model section that directly follows Serge's battle model.

Next step is to test out M's General Theory of Chrono Cross Model Articulation. We can already tell that a root bone specification is involved from Serge's Yoga Workout in the gallery linked above.

[halkun]

The root bone connects to where the shoulders meet the spine. There are two sets of shoulder bones because two bone hierarchies come from it.

1) Root bone -> shoulder center -> neck - > head -> ....

2) Root bone -> shoulder center -> torso -> waist -> ....

[FaustWolf]

That makes good sense. Would this reasoning apply to the knees? But I could simply be confusing the knees for the hips; sometimes it's hard to judge from the views I was able to get in-game.

UPDATE: Here's the result of an experiment testing the assumption that the first four bytes represent the parent bone. By changing the value 0x03 @ address 0x4F60 to 0x11, I told one of Serge's bandana ties to attach to his knee. I think. The ankle begins with 0x11, so I figured 0x11 represents the bone to which that articulation point is attached.



It would appear that the experiment was successful, but Serge's bandana tie, now misplaced, still stretches toward its original root at the back of Serge's head. Perhaps it's necessary to change other data (maybe in the vertex pool?) to get this experiment to work such that it places a correctly-shaped bandana tie on Serge's knee. I also noticed earlier that when Serge's wrist is detached from his arm and placed on the "root" bone, the arm texture similarly stretches so that it still connects the wrist to the arm. Any thoughts on this phenomenon and how it relates to the parent bone assumption?

But at least we know that the value at the beginning of the 20-byte run (first three bytes or so) have something to do with the articulation point to which each bone attaches.

Rotations are next. I'll see if I can get Serge to do the Exorcist maneuver...

[halkun]

I think that's how it's supposed to work. Bones influence the movement of vertexes. With Psy-Q you can define a bone to an RSD object, but it's not much of a jump to assign a bone to a vertex pool. I'm guessing that that information is in section 1-1

[FaustWolf]

  The next two bytes after the parent bone definition are apparently for Z-axis rotation, or however we should define this type of rotation. I'm not sure what will happen if I try this with Sege's arm.

Note that to get Serge to do an Exorcist manuever, I had to change the rotation bytes from 00 00 to FF 03. I wonder how degrees are defined in hex? 0x3FF is obviously doesn't equal 360, and I haven't even gotten his head all the way around yet.

Yeah, as much as I dread it, we'll have to re-visit Section 1-1 after we get this done in search of missing info. Section 3 could still hold some interesting things too. Sections 4 and 5 are probably devoted specifically to battle animations.

[MDenham]

Note that to get Serge to do an Exorcist manuever, I had to change the rotation bytes from 00 00 to FF 03. I wonder how degrees are defined in hex? 0x3FF is obviously doesn't equal 360, and I haven't even gotten his head all the way around yet.

0x07FF, or 0xF800, will be a 180-degree rotation.

It's using the "4096 = 360 degrees" system the debug menu uses, so, for interesting angles:

0 degrees = 0x0000
30 degrees = 0x0155 or 0xFEAA
45 degrees = 0x01FF or 0xFE00
60 degrees = 0x02AA or 0xFD55
90 degrees = 0x03FF or 0xFC00

and so on.  I wouldn't suggest trying anything between 0x1000 and 0xEFFF, though; it may work properly (and just act like it's continuing through more rotations) but it might crash things instead.

[FaustWolf]

Thanks! Now I can try this with some precision. BTW, the next two bytes after the Z rotation are for Y Rotation, if you count the Y axis as the axis that points away from you on an X-Y-Z axes model. I'll do another gallery for this stuff when I've gathered all the experimental evidence.

I'll be pushing to get all 20 bytes figured out by the time I clock in tonight.

[Cyberman]

It appears to be following PS1's 0-4095 (0x000 - 0xFFF) range of rotation. This is directly fed into the GTE as is. This makes sense too me.

Cyb

[FaustWolf]

Egg-cellent. I've been doing rotations of 0x3FF all this time, and I think 90 degrees would have a value of 0x400 on the 0~4095 system if my Windows calculator was correct.

M, everything is just as you had theorized earlier -- only Z rotations and coordinates come first, followed by X and Y (or Y and then X, depending on one's perpective). For the coordinates, there's a byte that can either be 0x00 or 0xFF, a directional switch byte like we say earlier in the vertex pool. There's a few instances with 0xFE though, and I'm not sure what that does. I'll have to test that as well as the purpose of the last four bytes, and then we'll have Section 2 pretty much covered.

Figuring out the last four bytes of the twenty-byte run may give us some insight into the first range following the header that freezes the game and makes the model disappear when zero'd out, since that has two FF FF... runs. These may be related in meaning to the FF FF... runs we see at the end of succeeding 20-byte ranges.

[MDenham]

Egg-cellent. I've been doing rotations of 0x3FF all this time, and I think 90 degrees would have a value of 0x400 on the 0~4095 system if my Windows calculator was correct.

Since any change of 1 unit is roughly 0.08 degrees (5.7 minutes), 0x03FF and 0x0400 aren't really distinguishable.

M, everything is just as you had theorized earlier -- only Z rotations and coordinates come first, followed by X and Y (or Y and then X, depending on one's perpective). For the coordinates, there's a byte that can either be 0x00 or 0xFF, a directional switch byte like we say earlier in the vertex pool. There's a few instances with 0xFE though, and I'm not sure what that does. I'll have to test that as well as the purpose of the last four bytes, and then we'll have Section 2 pretty much covered.

There's also at least one 0x01 if memory serves, which just indicates that these are signed numbers.  Treat them as such and you'll be fine there.  (I'm suspecting fixed-point math here, BTW, unless they aren't in "standard" half-precision format as shown on Wikipedia.)

[FaustWolf]

*slaps forehead* Signed numbers! Of course! I need to specify that in the wiki entry for the vertex pool. Sweet simplicity. I needn't bother with the FE coordinate values then.

So for the 20-byte runs I've got this so far:

PB PB PB PB ZR ZR YR YR - XR XR ZC ZC YC YC XC XC
?? ?? ?? ??

Where...

PB = Parent Bone index.
ZR = Z-axis rotation.
YR = Y-axis rotation.
XR = X-axis rotation.
ZC = Z-axis coordinate.
YC = Y-axis coordinate.
XC = X-axis coordinate.
?? = the four bytes of unknown functionality at the tail end of these things.

The X, Y, and Z axis coordinates in 3D space seem to be relative to the attachment point with the parent bone, which I hope makes sense theoretically.

UPDATE: Pics confirming this stuff will be up tomorrow. In case anyone wanders in here before then, I'd like to report that the first run of 20 bytes is ALSO related to the model's root bone. So the root bone, like the shoulders and possibly the knees, has two "slots" devoted to it apparently. The model disappears entirely and the game easily crashes if I delete the first four bytes of this first "slot." But the others seem to affect rotations and coordinates.

Something really interesting -- when I checked out the rotations and coordinates for the first root bone "slot," the bytes were out-of-order with respect to what I posted above. Instead of Z -> Y -> X axis specifications, it has Y -> Z -> X specifications apparently. It will be interesting to see if this is the way all double-"slot" articulations work.

[FaustWolf]

Just so you guys can see what I've been looking at:
http://s2.supload.com/gal/0801289979/0/

The pics are in order of experiments and thus in order of the various specifications given for the bones. The rotations and coordinate axes have only been confirmed for the neck bone though.

Pic 1: A demonstration of parent bone attachment. I've shown this before I think.
Pic 2: Z rotation of the neck bone.
Pic 3: Y rotation of the neck bone (added to the Z rotation)
Pic 4: X rotation of the neck bone (added to the Z and Y rotations)
Pic 5: Z coordinate change, new value 0xFFAA
Pic 6: Z coordinate change, new value 0x00AA
Pics 7, 8, and 9: I had labeled the first two Y coordinate changes and the third an X coordinate change, but now that I look at them I'm not sure that different axes are being affected here. They might both be X axis specifications.

The bone having two X axis specifications is weird to think about, but truth be told, the first root bone specification after the header ("A" in the letter scheme, the one that causes freezing when its first four bytes are zero'd) seems to have two X rotation specifications and one Z rotation specification (no Y). Grr. It'll take a bit to figure out the scheme being used here. It appears from my findings so far that the specifications are not consistent among the various bones.

But in any case, the 20-byte runs can be broken down like so, in general terms:

PB PB PB PB R1 R1 R2 R2 - R3 R3 C1 C1 C2 C2 C3 C3
?? ?? ?? ??

Where the first four bytes are a bone or articulation point ID; the next six bytes are devoted to rotations, which can be in just about any order; the next six bytes are devoted to coordinates in 3D space; and the last four bytes are related to the bone ID in some way, but are functionally neutral -- changing these bytes to wacky values has no visible effect on the model or battle animations.

Since we know the ins-and-outs of Sections 1-2 and 1-3 in intimate detail, it would perhaps be best if I spent the next week or so figuring out the scheme by which the rotations and coordinates are ordered into X, Y, and Z axis-related info.

After that, I'm going to move on to Section 3 and see what wonders may be hidden there. It could be stationary battle animations, but that's a wild guess. Section 1-1 may be the HRC structure to which Halkun refers, and there we may find bone lengths if they exist. I think?

In any case, we are this close to having enough info for model viewing in static poses.