CHRONO CROSS FILE EXPLORATION THREAD

[MDenham]

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.

Actually, this could probably be chalked up to gimbal lock (article not readily helpful, but it's a semi-common problem with angle systems in computer graphics).  How many of these where it looks like it's got two fields representing the same axis have a 90-degree rotation on any of the axes?

[FaustWolf]

I don't believe any of the bones I suspected of having doubled axis specification have a 90 degree rotation in their natural state. However, I'll read about this gimbal lock so I know what to watch out for. I still have to do some more experiments to make sure, but I've revised my understanding of the rotational specification order for the first few bones to the following:

Bone A (first root bone): Y -> Z -> X specifications
Bone B (second root bone): still indeterminate; more experiments needed
Bone C (waist articulation): Z -> Y -> X
Bone D (neck articulation): Z -> Y -> X
Bone E (bandana tie - left): Y -> X -> Z (but more experiments needed to confirm for sure)

This is too sketchy to draw certain conclusions from yet, but I'm hoping I can eschew the double-axis specification observation I made earlier as a mistake. At this point I'd like to float a theory by you guys and see if it sounds like a possibility:

Serge's waist and neck articulations are both specified in the order Z-axis; Y-axis; X-axis. These articulation joints are also on parallel planes. Thus, any articulation joint on a plane parallel to Serge's waist will have rotational specifications in the order Z -> Y -> X. The articulation joint through which bone "A" runs has differently-ordered axis specifications because that articulation point lies on a plane that's perpendicular (or otherwise at an angle with respect to) to those planes.

Such a model, if it were to pan out, would essentially mean that the X/Y/Z axis specifications are given relative to the plane upon which an articulation joint rests. But if this is the case, we'd probably have to assume that the angles of the articulation joint planes are somehow specified elsewhere in the model data.

I'm not sure that made sense; I'll be back later in the week with sketches and in-vivo evidence hopefully.

[MDenham]

I don't believe any of the bones I suspected of having doubled axis specification have a 90 degree rotation in their natural state.

I just started going through and checking simply because I'd noticed the 0xFC01 rotation in bone A (which is close enough to 90 degrees that any difference wouldn't be readily noticeable), and here's the bones that MAY have gimbal lock issues and the axis they have a 90-degree rotation on (and the sign of that 90-degree rotation as well):

A (Y, -)
E (Y, +)
F (Y, +)
G (Z, +)
H (Z, +; 0x03BF or ~84 degrees, so there may be some noticeable movement off-axis)
K (Z, +)
L (Z, +; see H's note)
O (X, +)
P (Z, +)
Q (Z, +)
T (Z, +)
U (Z, +)

As far as symmetric pairs, we have E-F, G-K, H-L, P-T and Q-U, with A and O not having a symmetric partner (main and weapon bones, respectively); no left-right pairs have one bone with a 90-degree rotation and the other without.

So: B should still be Z->Y->X; F should be Y->X->Z; O will probably be X->Z->Y, but may be X->Y->Z; and all of the others mentioned above will be Z->X->Y.

Hopefully this matches with what you end up finding.

[FaustWolf]

Alrighty, I'm gonna do multiple posts here to keep the update somewhat orderly. First off, some corrections to my earlier list of the joints. M, this doesn't affect your earlier analyses in any way; I just had some joints mislabeled in a minor way.

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:



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

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.

Now that we've got this down, let's take a look at the possible scheme for rotations...

[FaustWolf]

First, let's get our bearings. I'm going to use the following axes to describe 3D space from the player's point of view when Serge's belt buckle is facing the player:


That is, up-down is the Z axis; right-left is the X axis; and the Y axis is the line that would jut out toward you, the viewer.

Each joint lies on a certain plane. If you could tilt that plane such that its broad surface faces you, this appears to be the order in which the rotations are specified in general:



Which means, the first rotation occurs parallel to the plane itself; the attached appendage would sweep out an angle along the plane. The second rotation is perpendicular to the plane, but in a right-left direction with respect to the plane (that means the axis of rotation lies in an up-down direction). The third rotation is also perpendicular, but in an up-down direction (as if the axis lies along the plane going left to right).

That was confusing, so let's run through an example in 3D space with the X, Y, and Z axes specified first thing in this post. Let's say we're looking at Serge, and we want to predict how his head will rotate at the neck joint:


According to the model I'm basing things on, we should predict that the first rotation will be along the Z axis (Exorcist maneuver); the second should be along the Y axis (meaning the axis is straight away from you, producing a right-left rotation arc that digs the head into the shoulder); and the third rotation should be along the X axis.

Let's take a look at what really happens. I've definitely posted the first image before, but I'm not sure about the first and second. I apologize for the opposite camera angle, but you can still tell that the model describes what happens. Note that the changes are built upon one another in this example. Serge does his Exorcist thing first, then the Y axis rotation buries his head into his shoulder, then the X axis rotation turns his head so that the back of it faces us while it's buried in his shoulder:
http://s2.supload.com/gal/0802018214/0/

More examples coming up...

[FaustWolf]

Now let's take a look at Serge's right knee (bone "T" on the list) to see how that behaves. It acts as if it's on a plane that's parallel, or nearly so, to the neck plane:
http://s2.supload.com/gal/0802017429/0/

How about Serge's shoulders? There are two joints for the shoulders apparently, one that connects the arms to the body and one just above the elbow, right on the edge of Serge's shirt sleeve. We'll examine the upper shoulder joints, bones "G" and "K" on the list. They behave as if they are on a plane with the broad surface already facing us -- that is, the order of rotation is Y -> Z -> X, just following the normal 3D coordinate axes.
http://s2.supload.com/gal/0802012790/0/

The upper hip joints, bones "P" and "T", appear to behave the same way:
http://s2.supload.com/gal/0802016104/0/

I think I posted earlier regarding the rotations of Serge's bandana ties, and that description didn't fit with the possible variants produced by this model. I'll check the bandana ties again, and the model will hinge on those results.

If anyone needs clarification, let me know. I'm not sure how clear I've explained the rotation scheme model.

UPDATE: Hmm, interesting. The bandanna ties appear to behave as Z -> X -> Y. This indicates they operate on a flat plane, but usually that's supposed to be Z -> Y -> X. However, Z -> Y -> X would look like Z -> X -> Y if viewed from a 90 degree angle instead of head-on, so I'm pretty weirded out over this. My inclination is to still use the model, since it at least provides an adequate predictor of where the Z-axis rotation would be so far.
http://s2.supload.com/gal/0802016482/0/

In any case, a final analysis of the 3D coordinates given to the joint is next on the agenda. 

[Luminaire85]

I have finally gotten around to adding the triangles algorithm to my growing C++ model-parsing program. I believe the results speak for themselves (see attached picture).



[attachment deleted by admin]

[FaustWolf]

Woot, woot!! Superior work, Luminaire! The one thing I'm really worried about there are the hair pieces sticking out of the top of Serge's bandana wrap (*slaps head -- Oh, those aren't hair pieces! They're just Serge's trunks. Very good!). Since those aren't bones in-and-of themselves, adding Section 2 info may not solve the problem.   What concerns do you have about the models Luminaire, since you've got first-hand experience actually reproducing them? I can always go back and check stuff out, doing more experiments if need be.

It would seem that the bones have been shaped into their final forms via the vertex pool, but they still need to be snapped into place based on info from Section 1-1(?) and Section 2. Do you guys think we actually need to hunt for bone lengths still, or is it possible those are already taken care of with the vertex pool info?

I'm prepared to declare that the 3D joint coordinates given in Section 2 are consistent with regard to X, Y, and Z specifications. Looking at Serge with the model's belt buckle facing us, it appears the joint coordinate specifications are in Z -> Y -> X order. Take a look at Serge's neck joint again:
http://s2.supload.com/gal/0802013763/0/

The first specification changes the height of Serge's head on the Z axis; the second specification moves the head toward or away from us (that's what it would look like if the pic were taken from the belt buckle view, anyway); and the third specification moves Serge's head along the X axis with respect to the frontal belt buckle view.

Now here's where things get interesting. I believe I reported earlier on Serge's upper shoulder joints having a Y -> Z -> X order for the rotation specifications. But it appears that the joint coordinates still have Z -> Y -> X specification!
http://s2.supload.com/gal/0802013224/0/

In the first pic, Serge's shoulder joint is raised slightly (along the Z axis), causing his hand to miss his weapon handle; in the second, his shoulder joint is stretched away from us if you're viewing the model with the belt buckle facing you (Y axis specification); and in the third pic, Serge's arm is drawn along the X axis until he appears to look something like Goro of Mortal Kombat fame.

UPDATE: Just wanted to mention that, after changing the file structure wiki a bit, the 3D coordinate specification order in Section 2 conforms to the same order we saw in the vertex pool! Yay for consistency!

In honor of Luminaire's work, I'm posting a slick pic as per our custom. They're cheaper than cigars.

[attachment deleted by admin]

[MDenham]

I'm getting really, REALLY dubious about there being any further bone data besides translation-and-rotation, folks - which means that bone lengths are calculated upon loading the model.  The only problem is, how do we assign polygons to a bone?

Section 1-1 does not correspond in length, at all, to the bone count (for Serge, you get 10 bytes + 36 per bone excluding the root, while for Kid, you get 16 bytes + 22 per bone excluding the root...  not a good sign here).  Section 3 seems to be, guaranteed, 0x160 bytes, regardless of whose model it is.

Considering how Section 1's entire purpose is polygon-related, 1-1 is probably polygon assignments to bones, and that's all, which explains why it doesn't match up in any sort of manner that makes sense to the number of bones for the character in question.

Now comes the interesting problem: The first four bytes of 1-1 don't seem to match up with the number of bones for a character (17 vs. 23 for Serge, 23 vs. 39 for Kid, and ???? (possibly 13) vs. 36 for Guile).  This may or may not be irrelevant (considering doubled joints like the shoulders and hips, and the two root bones, Serge ends up matching up; but I don't see why Kid would have fourteen doubled joints + the two root bones).

Also, can anyone confirm that there is not any 16-bit number in Section 1-1 for Serge that is more than 0x029E (the polygon count)?  If we can confirm this, then 1-1 is almost certainly solely polygon->bone assignments, and as far as bone lengths go, well, we'll have to hand-calculate them just like the engine does.

[FaustWolf]

Before heading back to Section 1-1, I'm going to post Section 3, since it's a shortie:

000050C0                          B8 00 00 00 00 00 03 00
000050D0  28 00 B0 FF 00 00 03 00-10 00 00 00 00 00 03 00
000050E0  00 00 00 00 00 00 0A 00-00 00 00 00 00 00 06 00
000050F0  00 00 00 00 00 00 0C 00-00 00 00 00 00 00 08 00
00005100  28 00 00 00 F8 FF 0D 00-28 00 00 00 08 00 09 00
00005110  00 00 00 00 00 00 02 00-00 00 00 00 00 00 15 00
00005120  00 00 00 00 00 00 11 00-00 00 00 00 00 00 16 00
00005130  00 00 00 00 00 00 12 00-00 00 88 FD 00 00 00 00
00005140  30 FB 00 00 00 00 00 00-78 00 C0 FF 00 00 02 00
00005150  70 00 D8 FF 20 00 09 00-00 00 00 00 00 00 0E 00
00005160  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
00005170  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
00005180  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
00005190  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
000051A0  00 00 00 00 00 00 00 00-00 00 00 00 00 00 0E 00
000051B0  00 00 00 00 58 FF 0E 00-00 00 00 00 80 02 0E 00
000051C0  00 00 00 00 B0 FC 0E 00-80 80 80 00 80 80 80 10
000051D0  80 80 80 00 80 80 80 00-80 80 80 00 80 80 80 00
000051E0  80 80 80 00 80 80 80 00-00 00 00 00 00 00 00 00
000051F0  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
00005200  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
00005210  00 00 A0 FF 12 00 00 00-00 0C 00 0C E0 0F 00 00
00005220  00 00 00 00 07 00 00 00                        

It's very sparse. I assume it has something to do with animation, but I could be wrong. I'll try tweaking it and see what happens...

Ah, zeroing out Section 3 entirely appears to have various effects:




Interestingly, the animations themselves are still intact. That means Sections 4 and 5 have to house all the animation data.

Looks like a re-examination of Section 1-1 is in order.

[Luminaire85]

Well I realized as I was catching up on the bone search that my C++ program wasn't going to be much help in getting that info into Blender. For this reason I rewrote the program as a Blender plugin (i.e. a Python script). The idea is that, once the model is successfully imported into Blender, it can be exported to other formats for archiving, viewing with other 3D modeling software, etc. if desired. Currently the Python version produces the same image as I provided in my last post, which means it's more or less working. Next will be to read the bone info from the battle model file.

I have to say that the Blender Python scripting documentation is pretty bad.

[MDenham]

I have to say that the Blender Python scripting documentation is pretty bad.

I've never been terribly impressed with Blender at all, personally.

I'm also not much of a fan of the Maya UI, though - it seems like it should make sense, and then it throws something that ruins the whole "okay, I think I get it" experience.

Oh well.

[FaustWolf]

Wow, thanks for all the work you're putting into this, Luminaire!

M, I'm seeing a 0x4D6C @ address 0x2A8 in Serge's model, and a 0x3F50 @ address 0x2A4. 

Next weekend I'll do some more experiments in Section 1-1 and see if we can glean any info from that. I don't believe Section 3 is all that important for our purposes (though Cyb may be interested in knowing how that functions for Gears). I should mention that Section 4 is heterogeneous like Big Section 1 is, so it's slightly possible something else might be stuffed into Section 4 along with all sorts of animation data.

Here's a question for halkun or Cyb: In the FF7 HRC table structure, what "counts" toward the number of bones? Do root bones (the invisible ones that determine stance angle, etc.) count? As M has stated, if we subtract the double joints and root bones from the number of total "joints" listed in Section 2, we get the number at what might be the beginning of the HRC. We currently have that offset range (0x40 ~ 48 IIRC) listed as part of the subheader in the wiki, but that could be changed. The number there is 0x11, and Serge has 0x17 joints. If the root bone joints (0x2) and the second joints for the shoulders and hips (0x4) are subtracted, we get 0x11. BUT - Kid has a value of 0x17 in this potential HRC beginning v. 0x27 joints, and that would be an awful lot of double joints, as M has stated already.

[halkun]

One of the problems with FF7 was that we kept "missing" the root bone. It's really contextual. I don't think it was counted in FF7 until the render stage.

Also, we count bones, not joints. Bones have a few attributes that are universal

1) Parent
2) Child (if present)
3) Length
4) rotational data relative to the parent.
5) Vertex pool to move

The bone structure you are looking at now is probably a "default" postion before animation is added. This means the model is most likely standing in a "T" like formation with his arms out to the sides.

Now I've seen some games where there are two root bones, because they want to play the model against a sloped terrain. I don't think that's used here.

[FaustWolf]

Right, right -- I misspoke about the number of root bones; I should say that the root bone has two joints.

So far, in Section 2, we might have:

1.) Parent
2.) Child (I think it's the last four bytes in the bone data specifications).

4.) Rotational data relative to the parent. This is definitely there, of course.

We're definitely missing "length" and "vertex pool to move" on your list halkun. Section 2 also appears to have some specification for the 3D coordinates of the joint. BTW, if I zero out the "child bone" specification, would that theoretically have any impact on the model from your experience? I've done a few experiments where I zero out what I believe is the child specification, yet no noticeable impact on the model. If there should be an impact on the model when I zero out the child bone specification, then the last four bytes in each joint data section are for something other than what I suspect.