CHRONO CROSS FILE EXPLORATION THREAD

[Luminaire85]

I have figured out the purpose of the "16-byte" sections in Section 1-3. Recall that these are the vertices assigned to two bones. It's actually pretty simple:

* The first eight bytes represent the vertex's location relative to the first bone it is associated with.
* The second eight bytes represent the vertex's location relative to the second bone it is associated with.

Boy, am I glad to have that figured out.

Since I'm not having much luck with arranging the bones yet, I think I'm going to try using just the above information to arrange the vertices and see what happens. Hopefully I will have some good-looking pictures soon.

EDIT: There appear to be two caveats to this:

* The distance between the two vertices appears to differ slightly among vertices attached to the same pair of bones (for example, those in Serge's neck, which belong to Bone.2 and Bone.3).
* Sometimes the difference is a simple translation, but other times it's a combination of translation and rotation.

The good news is that the distances correspond well with the bone positions as suggested in Section 2.

[FaustWolf]

Consider it in the wiki. Take all the time you need, and let us know if you need any more experiments run. I'm still quite unsure about the veracity of the scheme I posted earlier about rotations (as far as how to tell which byte position specifies X, Y, and Z rotation), so if it's producing incorrect models, I can delve back in sometime and do more investigation.

[Luminaire85]

At this point there are two things that puzzle me about the bone data in Section 2:

(1) Bones 1, 7, 11, 16, and 20 have the vector (0, 0, 0) for their position data, suggesting a bone of length 0. Besides the fact that Blender doesn't like bones of length 0 (and correctly so), looking at what vertices are attached to each bone suggests that they are in fact not zero. I don't understand yet what to do with these bones.

(2) At this point I haven't used the rotation data in Section 2 at all, so I haven't had to worry about whether I understand it right. I suspect at some point I will need it, perhaps in regards to above, or perhaps to move Serge into his rest position before applying the animation transformations.

Also, I believe that, from the point of view of the vertices, the x-axis is "up", the y-axis is "forward", and the z-axis is "left/right". This swaps the x-axis and z-axis from your earlier definition, which is not really a big deal. It does make the bone position data come in the order xx yy zz rather than zz yy xx, which makes more sense.

Finally, I have attached two progress pictures: with and without bones.


[attachment deleted by admin]

[FaustWolf]

An X-Z swap is no biggie, and would probably improve the logical-ness of things. I'm not sure it makes any difference, but I figured the vector coordinates (0, 0, 0) mean the specified joint is located at the center of the model (joints, not bones, are specified in Big Section 2). Let's see if there's any logical sense to the weirdness of these joints...

Joint 1 is a root bone joint.
Joint 7 is the upper shoulder joint, right.
Joint 11 is the upper shoulder joint, left.
Joint 16 is the upper hip, left.
Joint 20 is the upper hip, right.

I'm using the list of joints from this post, with A = 1: http://www.chronocompendium.com/Forums/index.php/topic,4770.msg88099.html#msg88099

Hmm, so the vector 0,0,0 doesn't mean they're at the origin in 3D space. The root bone joint might be at that location though. As for the rest, it is interesting that these are also skipped over in Section 1-1-1. The joints labeled "upper shoulder," etc., seem to be different in some way.

In any case, perhaps an experiment in changing these (0,0,0) specifications would yield some insight?

[FaustWolf]

Before an experiment to test, I want to be sure I'm reading you right Luminaire. When you say "Bone 1", "Bone 7", etc., are you referring to the first, seventh, etc., 20-byte sections in Section 2?

For the seventh 20-byte run in Section 2, I've got:
02 00 00 00 00 00 00   00 00 04 B4 00 02 00 8D FF FF FF    FF FF

That is, the first four bytes tell us something I can't recall at the moment, like a joint ID or parent joint ID; the following three sets of bytes are for axis rotation (and read 00 00 00 00 00 04); and the three sets of bytes following that are for joint 3D coordinates (and read B4 00 02 00 8D FF).

I'm not looking at the same thing you are, am I?

[Luminaire85]

No, "Bone 7" is the eighth bone. I'm starting my counting from zero.

That particular sequence is 06 00 00 00 00 00 00 01 - bf 03 00 00 00 00 00 00 - 00 00 05 00, and the bolded bytes represent the position data. My current interpretation is that the data represents a displacement rather than a position, meaning the bone is of length zero rather than having one of its ends at the origin.

[MDenham]

Ah, the joy of weird things going on.

Section 2 isn't bones, it's joints, Luminaire.  It's got references to bone numbers, as children of each joint (these are the last two bytes of each entry; no idea what the two prior to that are, unless they're stored in mixed-endian order [2 3 0 1]), but the first four bytes are the parent joint number.

So there's 17 bones (-1 means "no bone") and 23 joints (-1, which only appears on the first joint, means "no parent joint").  The joint paths are as follows, from most-dependent to least:

W > V > U > T > B > A
S > R > Q > P > B > A
O > N > M > L > K > C > B > A
J > I > H > G > C > B > A
F > D > C > B > A
E > D > C > B > A

So, a few of the early bones are mislabeled (I think):

A: Root bone articulation; runs through center of model.
B: Root bone articulation; runs through center of model.
C: Waist articulation.

A: Root joint.
B: Waist joint.
C: Spine joints (well, it's a single joint, but in a real person it's multiple joints).

All of the joints with zero translations happen to have, as their parent joint, a joint without a bone.  (However, the "weapon" joint has no child bone for other reasons, including the fact that the weapon is a separate model.  I assume the engine first consolidates things, then positions the weapon based on the sole remaining childless joint, in which case you could confuse the engine.  This is, at present, beyond the current scope of what we're doing. )  This explains why there's no translation or displacement - there's no bone on the parent joint!

Hopefully that helps.  A little.

[FaustWolf]

I'll re-submit this evidence as to what joints B and C could be:


Joint (B) seems to affect the whole model, which is why I labeled it a second root. Is it possible to determine from these experimental results one way or the other that joint C is for the spinal column v. the waist?

Let me get a list of which joints have (0,0,0) 3D coordinate specifications now that I'm on the same page with Luminaire:

Joint 1 is a root bone joint (according to the old list; it's joint B in any case).
Joint 7 is H: Lower Shoulder - left.
Joint 11 is L: Lower Shoulder - right.
Joint 16 is Q: Lower Hip - left.
Joint 20 is U: Lower Hip - right.

Which is interesting; what I call the "upper" joints have 3D coordinates, but the "lower" and root joint B (possibly, depending on how we decide to label it) have 00 00 for all coordinate specifications. I wonder what would happen if Luminaire gives these "secondary" joints the same coordinates as the "upper" joints. Although I distinguished between an "upper" and a "lower" for these, they're still very close together I think. Maybe I was just wrong on that. I'm going to do some experiments to clarify the nature of these 3D coordinates.

In the meantime, I'm going to regurgitate some previous experimental results that occur when all Section 2 data for joints 10 and 11 are zero'd out (meaning the right arm from the shoulder down is going to be assigned to the root bone as parent, regardless of the 3D specifications, which will be zero'd in both cases as well):

Clearly from this, it is impossible to even distinguish between an "upper" and a "lower" joint visually...I might have screwed up in using a physical description like that.

Which gives me an idea. Is it possible that bone lengths are calculated as the difference between one joint's 3D coordinates and the next joint's 3D coordinates? Joint 10 would have 3D coordinates of some magnitude and Joint 11 has zero magnitude, meaning the joints coincide perhaps. But I'm sure there will be difficulties with this upon further examination and it will have to be eschewed. I'm just throwing this out there to see what you all think of it.

[Luminaire85]

Yeah, the bone lengths are embedded in the position/displacement data in Section 2. It turns out the vertices were already properly scaled in the vertex pool, so they just need to be properly translated and rotated. That's part of what Section 2 is for.

I'm this close to having it. Once I get Serge's arms to be the correct length rather than drooping past his feet, I will be attaching a most kick-ass picture.

[FaustWolf]

 

[Luminaire85]

I'm not quite sure I've got everything 100% correct quite yet, as there is at least one wayward vertex in one of his bandana ends, the root bone(s) aren't visible yet, the texture is a little off in some places, etc. Pictures with and without the armature visible are provided.

Also, in regards to the "bones of length zero" I was worried about, a good solution appears to be to use the same displacement as its first child bone. These bones are the ones in his upper arms and his thighs. We'll see if this holds up as we go on, but for now it's fine.


[attachment deleted by admin]

[ZeaLitY]

All right, since we're almost there...









Aaroniero is also floored!



Now, ever major achievement is marked with a ton of encouraging, disturbing character explosions!

BUT LETS NOT FORGET GRIMMJOW JEAGERJAQUES







Congratulations to all parties.

[FaustWolf]

AAAWWWW YEAAAH!!

It would appear Luminaire's got a good semi-T pose. This is even better for anyone who wants to do some character animation in Blender or whatnot; the user doesn't have to un-bend the character from the normal battle pose.

Luminaire, the only thing that looks awkward is the lower half of Serge's overcoat, below the belt. See how the part of his belt that hangs from the buckle is interrupted? Is it possible to fix that, you think? It was correct in an earlier iteration IIRC, before any bone data was applied.

*goes bonkers and throws Luminaire into a mosh pit*

This is a major achievement for the Chrono community and PlayStation fans in general. I'd like to say thanks to MDenham, halkun, Cyb, Gemini, and yaz0r for their advice, without which this wouldn't be possible.

Once Serge's model is perfected, the next step is to get all our knowledge into the wiki, see if Kid's model can be run through Luminaire's plugin without a hitch, then figure out Guile's model -- there's an extra section in his, but I still have yet to identify it; it might just be extra animation data or something.

Oh, and Luminaire -- did you actually apply the joint rotations indicated in Section 2, or does the model start out like this without those rotations?

[Luminaire85]

Yeah, I used the Section 2 rotation data. It was giving me fits all evening until I figured out the trick.

The texture map below Serge's belt has always looked like that. I think it has to be something in the UV data because the vertices are correct. You can see a problem in Serge's wrists as well.

As for Kid's model...it's a start. You can see her skirt's all wrong, and the textures are off in several places, but it's not bad.


[attachment deleted by admin]

[FaustWolf]

Kid's looking pretty good; that could become a new hairstyle. The fact that she's in that good shape without any extra investigation into her model is extremely promising.

I can't tell for sure, but the last pic you posted while you were still using C++ suggested to me that the belt was okay:


I can see more of Serge's belt in that pic than in the current version, where only the very tip of the hanging belt texture can be seen. I think?