CHRONO CROSS FILE EXPLORATION THREAD

[Luminaire85]

It seems like every time I figure something out, another issue arises.

Case in point: I think I've got all of the UV problems fixed, but I noticed that the number of faces in the imported models are lower than they should be, sometimes significantly. The problem is that the algorithm that determines the vertex indices appears to be assigning the same exact set of indices to multiple faces, and Blender is responding by deleting the extra faces.

The best example of this is at the tips on the bottom of Serge's shirt. The incorrect version is to the left in the attached image, while the correct version is to the right. Note that there are exactly two vertices with this mistake; Blender reports that there are only 668 faces where there should be 670.

Fortunately the offending faces are easy to find in Serge's face data, as they are at the start of the last section of quads. The four faces causing the issue are at 0x26E8, 0x26F8, 0x2708, and 0x2718. I am hoping the bug is in my interpretation of the method for converting pointers to vertex indices. It would probably be useful if someone would manually step through the pointer data for these faces. Meanwhile I will review my code.

[attachment deleted by admin]

[MDenham]

Fortunately the offending faces are easy to find in Serge's face data, as they are at the start of the last section of quads. The four faces causing the issue are at 0x26E8, 0x26F8, 0x2708, and 0x2718. I am hoping the bug is in my interpretation of the method for converting pointers to vertex indices. It would probably be useful if someone would manually step through the pointer data for these faces. Meanwhile I will review my code.

Raw data (after appropriate division by 2), where back-references are not shown in hex:

0x1008, 0x10F8, 0x10E8, 0x1100
0x1108, -4, 0x1150, -7
-5, -4, -8, -4
-1, -4, -8, -11

which gives real pointers of:
0x1008, 0x10F8, 0x10E8, 0x1100
0x1108, 0x10F8, 0x1150, 0x1008
0x1100, 0x10F8, 0x10E8, 0x1008 (same as first face, but opposite order, so back side)
0x1008, 0x10F8, 0x1150, 0x1108 (second face, back side)

So it's just an issue with how Blender deals with coincident faces - you're reading them correctly, it's just not behaving correctly.

[Ema]

Do you guys have any idea if it's possible to rip the pre-rendered backgrounds of CC?? o_o
Or if there's a website that has all of them.

[FaustWolf]

Ema, we've got our hands on all the prerendered backgrounds, believe it or not! The problem is assembling them. If you have a good working knowledge of 2D data, or would like to study CC's backgrounds, I'd be happy to post some of what we've got. The problems we've experienced so far are thus:

1.) The backgrounds are split into little rectangular chunks.
2.) One needs Photoshop to easily apply the palettes to the images. I have mixed success with TileMolester, but now that I know WAY more about 2D image data, I might just try exploring the hex in-depth to locate the palette addresses.

The major thrust of this thread is model data currently, but we can start another thread on 2D data to run concurrently with this one so we don't get all mixed up.

[Luminaire85]

I think I have a fix for the coincident faces issue coded up. I've also smoothed out most of the UV issues, although a face here or there seems to have its texture rotated incorrectly yet. For comparison with previous I've attached a picture of the latest output of Guile.

I've also attached version 0.2.2 of my script. I've done some refactoring along with the other bugfixes.


[attachment deleted by admin]

[FaustWolf]

That's looking pretty darn good. Since Glenn and Guile both have that weird issue going on with their feet, I'd guess both models share the same basic structure (i.e., an extra section). I've gotta get on that sometime to figure out what's up with that.

For what it's worth, at this point I'd like to post the Section 1 subheaders of Serge's model and Dark Serge's model for comparison purposes, since those both work perfectly or nearly so.

Serge's Section 1 Subheader:

SECTION 1 SUBHEADER...
OFFSETS  OFFSET VALUES
00000020 02 00 00 00 14 00 00 00-80 02 00 00 05 02 2B 04
00000030 F9 00 00 00 38 03 00 00-C8 28 00 00 28 42 00 00

Dark Serge's Section 1 Subheader:

00000020  02 00 00 00 14 00 00 00-34 01 00 00 17 02 4A 04  
00000030  F9 00 00 00 98 02 00 00-C0 28 00 00 D0 3C 00 00  

Now compare to Guile's Section 1 Subheader:

00000020 05 00 00 00 20 00 00 00-D8 00 00 00 C6 01 00 00
00000030 B8 01 00 00 5C 02 00 00-4B 03 9A 04 BE 02 00 00
00000040 3C 03 00 00 38 2A 00 00-D0 40 00 00 0D 00 00 00
00000050 00 00 00 00

Actually, I'm not sure just where the header stops and Section 1-1 begins on Guile just yet -- that's just what I've got in the wiki, which doesn't reflect anything we've learned since the very beginning because I've been documenting only Serge all this time. But certainly the structure is different to some degree. Also, while I'm at it, here's Glenn's Section 1 Subheader since he's got the same foot issue as Guile:

00000020  03 00 00 00 18 00 00 00-CC 00 00 00 5C 01 00 00
00000030  16 02 45 04 93 01 00 00-90 01 00 00 A8 28 00 00

Not sure what we can glean from these headers yet, or even if it's Section 1 that's causing the difficulties, but that's what I suspect. I've gotta unload a bunch of notes I've taken on character model locations and so forth, then I can get back into this to run tests on Guile's model.


Also, and probably more usefully Luminaire, I've attached the models for the Mystic Knights (i.e., Ozzie, Slash, and Flea). I'm wondering if Slash's will turn out normal whereas Flea's will have whacked-out feet like Glenn's and Guile's do; just a hunch based on the Section 1 Subheaders.

[attachment deleted by admin]

[MDenham]

Guile's Section 1 Subheader:

00000020 05 00 00 00 20 00 00 00-D8 00 00 00 C6 01 00 00
00000030 B8 01 00 00 5C 02 00 00-4B 03 9A 04 BE 02 00 00
00000040 3C 03 00 00 38 2A 00 00-D0 40 00 00 0D 00 00 00
00000050 00 00 00 00

Actually, I'm not sure just where the header stops and Section 1-1 begins on Guile just yet

The 0D 00 00 00 at 0x4C is the beginning of Guile 1-1.

I'm thinking that the 32-bit numbers preceding and immediately following the "gobbledygook" are counts for something, but I'm not quite sure what yet.

[FaustWolf]

Excellent, thanks for catching that flub M.

[Luminaire85]

Ozzie, Slash, and Flea for your viewing pleasure. The hunch about the feet of Slash and Flea appears to be accurate.

[attachment deleted by admin]

[FaustWolf]

Huge thanks for checking that out Luminaire! That settles it (maybe), something in the Subsection 1 header is screwing up the feet at least. Interesting that Kid's skirt and Flea's skirt are screwed up in similar ways, as well as their hair bangs. Flea's model could exhibit characteristics of both Kid's and Guile's.

In any case, I've gotta get a party of Guile, Flea, and Kid together (with some hacking, heh!) to help figure out what's going on.

[Cyberman]

Luminaire85 and FaustWolf
Examining Flea as you call her and Guile notice the torso and the legs to the feet both are esckew in terms of the rotation (assume the X axis goes from left to right viewing flea from the front and Y axis goes from bottom to top Z axis plugins into the image).  This means using the left handed rule flea's rotation is negative if the right hand rule applies then it's still the same problem (IE the direction the fingers curl).  So that portion is being rotated the wrong direction. Examine the neck (they look like they've been hung) and the feet stretching portion. The sections of the model above them (bones?), are going rotated positively (below the waist) my guess is the rotations of these two bones are FLIPPED (IE the one being used on the torso is being used on the tigh bones and visa versa).  If that's the case tracing where the wrong bone rotation is being assumed and that might lead to solving the problem (and understanding the data better too).

Cyb

[FaustWolf]

Thanks Cyb! I see what you mean, and that gives me some more direction. I'll get back to this project as soon as I put the finishing touches on another thing I've been working on, and once I've finally got everything we know so far wikified.

[Luminaire85]

I've finally made a little bit of headway into what I think is going on.

You may or may not recall a while back I was worried about bones with "translation" data of (0, 0, 0), of which there are five in Serge's armature data, including in all four of his appendages. I figured out that a pretty good solution seemed to be to give these bones the translation data of its child bone. It turns out that I should not have stopped there.

For example, take Serge's arm which is not holding the swallow. The translation data as read from the model file is (180, 2, -115), (0, 0, 0), (118, 0, 0), and (135, 0, 0), representing the shoulder, upper arm, lower arm, and hand, respectively. My correction explained above would adjust this to (180, 2, -115), (118, 0, 0), (118, 0, 0), and (135, 0, 0). Now I am thinking that it should be (180, 2, -115), (118, 0, 0), (135, 0, 0), and (?, ?, ?). The question remains of what to do with the last bone's length.

When you do it this new way Serge's forearm bone actually ends in his hand instead of at the tip of his glove, which makes more sense considering the way the vertices are assigned. Ditto for the other appendages; see picture.

EDIT: I am also starting to think that there are two issues to deal with. Remember that the joint data is, as I'm currently trying to use it, for both transforming the vertex data and generating bone information. I've found that I've had to make modifications to the joint data after transforming the vertices but before generating the bones. It seems that the rotations aren't being applied to the vertices or the bones correctly, but the translation data as provided is correctly translating the vertices to their correct positions, but giving wrong bone lengths.


[attachment deleted by admin]

[FaustWolf]

Makes me feel bad for not doing any work on this for awhile. I shall get back to it soon.

Luminaire, what's up with Serge's bandana in that pic? The bandana ties looked okay in the pic we released as part of the site update on model viewing, but here they're stretched way out and down.

[Luminaire85]

I wish I had not since forgotten, because I think it would solve a lot of the model problems.