CHRONO CROSS FILE EXPLORATION THREAD

[Luminaire85]

Bitmap format is fine, although I usually use PNGs for images like that.

Well, I got Guile's battle model loaded with a few minor tweaks to my script. As you can see, it's also not bad, although there's plenty of issues to deal with, including but not limited to:

(1) Guile's ankles

(2) All of the faces with small versions of Guile's entire texture

(3) The armature doesn't match the vertices in a few places

But hey, at least you can tell it's Guile.

[attachment deleted by admin]

[FaustWolf]

Wow.   

If you can Luminaire, let us in on how your python script interprets the rotational specifications in Section 2 when you have some spare time; I listed my theory a couple pages back, but it was pretty shoddy and you've probably come up with something different and more consistent. When I return I'm going to try and bust out a wiki update with all the knowledge we've gained over the past few weeks.

[ZeaLitY]

GUILE RULES

[MDenham]

More news for Section 4!

The first frame of every animation - which was consistently 276 bytes for Serge - is consistently 432 bytes for Guile.  Now, Serge has 23 joints...   and 276/23 = 12.  Guile has 36 joints, and 432/36 is...  12 again.

What this means is that the first frame for each animation sets up all of the joints as needed...  in uncompressed fashion.  Six 16-bit numbers for each joint in order, just like Section 2 only without the (here unnecessary) joint/bone linkage information.  Furthermore, each following frame only updates information that isn't zeroed in the first frame - if a joint has no rotation in the first frame, the game assumes it won't have any rotation in any later frame, and likewise for translations.  While this shortens all of the later frames, it's still a bit of a mess to try and follow by eye, and it might not be correct (it could just be a coincidence that of the 72 transformation slots in the first frame of the first animation, 32 of them are non-zero, and all of the later frames for that animation are sized to fit 32 slots - stranger things have happened, ).

And in other news, I'm trying to piece together a tool that, at this point, would be able to "summarize" a model into a more human-readable format, and is meant to (eventually) be able to do edits of pretty much everything in the game data (either "exploded" into separate files, or from disc images).  More updates on that as the situation warrants, though I will recommend that anyone interested in the tool be prepared to learn C# if they don't already know it.  It'd make it easier to keep it up to date if all interested parties are capable of adding features as necessary.

[Luminaire85]

Good to see progress into the animation data. As you might imagine I will probably focus first on fixing up the base models for Kid, Guile, etc. before attempting animations.

In the meantime I have attached version 0.2.1 of my Blender plugin. (It's compressed only because .py isn't an allowed file type.) I wrote some instructions for how to use the plugin, which are embedded in the source, for anyone who wants to try it. I tried to write them for someone who's never used Blender, but I expect there are parts that are not clear, and I would be happy to clarify.

The second attachment contains Serge's battle model data and texture (which the plugin will prompt for), plus a .blend file that is what should result from following the plugin instructions. This file is more for anyone who hasn't been following along and therefore doesn't have the files.

[attachment deleted by admin]

[MDenham]

After looking through your script, I think I can safely say what the "minor problems" with the resulting models have been.

You're going to need to apply the weights from Section 1-1 to the two-slot vertices (they're in 4.12 format and add up to 1 [0x1000 or 0x0FFF] as it is) to determine what the actual values for the final vertex are.  Since you've got it just dumping one half of it instead, it ends up being "off" by some odd amount every time...  and pretty much always right near a joint, too.

Hopefully that helps correct some of the oddities you've noticed with the models.  (I'm sort of wondering if it'll fix the whole "ponytail sticking straight out" thing as well.)

[Luminaire85]

Okay, I changed things to work that way. Turns out I pretty much just had to change it so that the two-slot vertices are combined after they are transformed rather than vice versa, which in hindsight makes a lot more sense anyway. For some reason the bones and weights for the two-slot vertices still need to be switched in order for things to work.

The good news is that the parts of Serge, Kid, and Guile that were right before are still right. The bad news is that the parts that are wrong are still wrong, although probably not as wrong as before.

I am thinking that the issue may be in the way the bone rotations are handled. As I recall I wasn't completely happy with the way I was doing it, so I will probably take another look at that next.

[halkun]

I'm not one to bump, but we've fallen off the front page.

Progress?

[MDenham]

I'm not one to bump, but we've fallen off the front page.

Progress?

It's the weekend, of course not!

I'm wasting time listening to Vocaloid-based music on YouTube, personally.

[FaustWolf]

I'm finally back, so I'll get to work on wiki-fying the progress soon. That will take a few days, then it will be time to do testing (if needed) or begin excising character models and textures to make sure everything works across the board.

[Cyberman]

Ah Wiki documentation. That is music to my ears.

Cyb

[Luminaire85]

I'm overdue for a progress report, but unfortunately there's not much progress to report.

My current procedure for placing bones and adjusting vertex locations is probably best illustrated with an example. Firstoff, Serge's joint data:

Code: [Select]

Joint Parent Rotation (deg) Displacement Last
0 -1 0.0, -89.9, 0.0 0, -528, 6 -1
1 0 0.0, 0.0, -90.4 0, 0, 0 0
2 1 0.0, 0.0, 6.2 112, 0, 0 1
3 2 0.0, 0.0, 0.0 231, 0, 0 2
4 3 -82.5, 89.9, 0 66, 53, 0 3
5 3 -82.5, 89.9, 0 66, 53, 0 4
6 2 0.0, 0.0, 90.0 180, 2, -115 -1
7 6 0.0, 22.5, 84.3 0, 0, 0 5
8 7 0.0, 0.0, 0.0 118, 0, 0 6
9 8 0.0, 0.0, 0.0 135, 0, 0 7
10 2 0.0, 0.0, 90.0 180, 2, 115 -1
11 10 0.0, -22.5, 84.3 0, 0, 0 8
12 11 0.0, 0.0, 0.0 117, 0, 0 9
13 12 0.0, 0.0, 0.0 136, 0, 0 10
14 13 90.0, 112.5, -0.8 459, 16, -420 -1
15 1 0.0, 0.0, 90.0 0, 0, -56 -1
16 15 0.0, 1.1, 90.0 0, 0, 0 11
17 16 0.0, 0.0, -4.0 167, 0, 0 12
18 17 0.0, 0.0, 0.0 291, 0, 0 13
19 1 0.0, 0.0, 90.0 0, 0, 56 -1
20 19 0.0, -1.1, 89.9 0, 0, 0 14
21 20 0.0, 0.0, -4.0 167, 0, 0 15
22 21 0.0, 0.0, 0.0 291, 0, 0 16

To my understanding the joints with a -1 in the last 2 bytes (corresponding to the last column of the table above) are "origin joints" (my terminology) in the sense that all bones that are children of that joint are translated and rotated using that point as the origin. This column probably represents bone number, with -1 entries meaning that no bone exists between that joint and its parent.

For each joint, a position vector is formed by summing the displacements of all joints between the origin joint and the current joint, inclusive. This vector is then rotated around its origin joint by the sum of the rotations of all joints between the origin joint and the current joint, inclusive. The rotated vector denotes the actual position of that joint.

As an example, take joint 8. Its parent joint is joint 7, whose parent joint is joint 6, which is an origin joint. The unrotated position vector would be (180, 2, -115) + (0, 0, 0) + (118, 0, 0) = (298, 2, -115), and the rotation would be around the origin joint of (180, 2, -115) by the angles (0.0°, 0.0°, 90.0°) + (0.0°, 22.5°, 84.3°) + (0°, 0°, 0°) = (0.0°, 22.5°, 174.3°).

This interpretation seems to work great for all of Serge's joints/bones except joints 4 and 5, corresponding to the tips of his bandana. In the attached image you can see neither the vertices nor the bones are anywhere close to their proper locations. (They are, however, close to one another, which is good considering I apply the transformation described above to both joints and vertices.) I haven't had much luck figuring out what the problem is.

I hope at least some of that makes sense, and I hope someone has advice.

[attachment deleted by admin]

[halkun]

The knees bending forward is a little distressing. Maybe if you checked the rotation in the knees first (The goal being either straight or slightly bent th other way.) There is a small enough error induced there to see what the number should be if you "corrected" it.

Word of note. The GTE did have rounding errors that Sony didn't fix because many applications relied on them . This was corrected in software  by the Psy-Q lib itself. It might be that you aren't account for the GTE bug. FF7 had that problem when were were trying to align the walkmesh to the background graphics.

[Luminaire85]

Attached is an image of what happens if you simply take the negative of the z rotations before applying them. (I also took the negative of the x rotations to produce the images, but that does not affect the legs at all.) Both Serge's and Kid's impossible knee action appear to be fixed. Also, Kid's ponytail is now pointed behind her head rather than through her skull. There's still a problem with Guile's shoes, however they were wrong even before this change.

The attached also provides a nice visual summary of what's wrong with Serge, Kid, and Guile's models. Right now I'm only worrying about vertex and bone positions and saving the UV issues for later.


[attachment deleted by admin]

[FaustWolf]

Shoot, Luminaire, earlier you asked if everyone's textures were 128x252 pixels. I've located Glenn's battle model, and his texture appears to be 128x256. Is this a large problem?

Glenn's texture and model data are attached as I did with Dark Serge.

[attachment deleted by admin]