CHRONO CROSS FILE EXPLORATION THREAD

[FaustWolf]

  YEE-HAW! 

So let's go through the "almighty shoe" exercise with this basic rule set. First, the code:

The highlighted section at the bottom is Quad B's non-UV data. Pointers and the byte pairs I believe they point to are in color-coded boxes, so the red pointer points to the other red box, etc.

So we need to get from the pointers located at 0x1950 ~ 0x1958 to the correspondingly-colored boxes. Let's follow the rules:

First Pointer: address 0x1950, value 0xFFE0.
0xFFD0 = -48; because it's the first position, /16 = 3 positions back...
->address 0x1942, value 0xFED0 = -304; because it's the second position, /16 = 19 positions back...
-->address 0x18F4, value 0xFFE8 = -24; because it's the third position, /8 = 3 positions back...
--->address 0x18E6, value 0x0880. Because it's in the fourth position, 0x0880 is, indeed, the true positive pointer.

Second Pointer: address 0x1952, value 0xFEB0.
0xFEB0 = -336; because it's the second position, /16 = 21 positions back...
->address 0x1900, value 0xFFF0 = -16; because it's the first position, /16 = 1 position back...
-->address 0x18F6, value 0xFF58 = -168; because it's the fourth position, /8 = 21 positions back...
--->address 0x18A4, value 0x0858. Because it's in the third position, 0x0858 is, indeed, the true positive pointer.

Third Pointer: address 0x1954, value 0xFFE8.
0xFFE8 = -24; because it's in the third position, /8 = 3 positions back...
->address 0x1946, value 0x08B8. And because it's in the fourth position, 0x08B8 is, indeed, the true positive pointer.

Fourth Pointer: address 0x1956, value 0xFF58.
0xFF58 = -168; because it's in the fourth position, /8 = 21 positions back...
->address 0x1904, value 0x0888. And because it's in the third position, 0x0888 is, indeed, the true positive pointer.

So far, so good. I'll go through some other examples as tests, then we'll quickly get the triangle pointers nailed down before moving onto the bone data.

[MDenham]

After a tentative look at what should be triangle data, triangles seem to be a little odd in their metapointers:



Starting at 0x2658 (8 spaces from the right end of the second row; the pointers start just to the right of the cursor in the image. And yes, I run 32 bytes/row in my hex editor), we have the first of a string of triangles:

* Triangle 1's metapointers: 1080, 2050, 21D0
* Triangle 2's metapointers: 1150, 2270, (FFD0)
* Triangle 3's metapointers: 10D8, 2190, 2100
* Triangle 4's metapointers: 10D0, (FFD0), 20F0
* Triangle 5's metapointers: (FFE0), (FFD0), 21A0
* Triangle 6's metapointers*: (FFA0), (FF80), (FFD0)
* Triangle 7's metapointers: 1070, 2160, 2120
* Triangle 8's metapointers: 1068, (FFE0), 2130
* Triangle 9's metapointers: 10A0, (FFE0), (FFC0)
* Triangle 10's metapointers*: (FFD8), (FF80), (FF40)
* Triangle 11's metapointers: (FF38), (FE80), 2180
* Triangle 12's metapointers: 10B8, (FF40), (FF50)

First, note that triangles 6 and 10 consist solely of backwards references (we've seen this before with a few quads, but it looks like it'll be more common with triangles), and that the second and third metapointers are divisible by 16 every time, while the only metapointers that are divisible by 8 but not 16 are in the first slot.  So: the format is (N, D, D), as compared to (D, D, N, N) for quads [where N is "normal" and D is "divide by 2"], and the pointers for triangles are much later in the list than most of the pointers we've seen so far.

The "fixed" list of triangle pointers in this block:

* Triangle 1's metapointers: 1080, 1028, 10E8
* Triangle 2's metapointers: 1150, 1138, (-3)->10E8
* Triangle 3's metapointers: 10D8, 10C8, 1080
* Triangle 4's metapointers: 10D0, (-3)->10C8, 1078
* Triangle 5's metapointers: (-4)->1080, (-3)->(-3)->10C8, 10D0
* Triangle 6's metapointers: (-12)->1150, (-8)->1080, (-3)->10D0
* Triangle 7's metapointers: 1070, 10B0, 1090
* Triangle 8's metapointers: 1068, (-2)->1090, 1098
* Triangle 9's metapointers: 10A0, (-2)->1098, (-4)->(-2)->1090
* Triangle 10's metapointers*: (-5)->(-2)->1090, (-8)->1090, (-12)->(-3)->10D0
* Triangle 11's metapointers: (-25)->(-3)->10E8, (-24)->10C8, 10C0
* Triangle 12's metapointers*: 10B8, (-12)->(-2)->1090, (-13)->(-2)->1090

Note that triangles 10 and 12 seem to refer backwards such that they use the same vertex twice, so there may be something else going on here, but this is, at least, a decent preliminary list of how the triangles break down.

Consolidated list of vertices used by these triangles:
1028, 1068, 1070, 1078, 1080, 1090, 1098, 10A0, 10B0, 10B8, 10C0, 10C8, 10D0, 10D8, 10E8, 1138, 1150

Note here there are a few major runs:
* 1068-1080 (4 consecutive)
* 1090-10A0 (3 consecutive)
* 10B0-10D8 (6 consecutive)

I wouldn't be too surprised if the reason this block of triangles appears in the middle of things is because the region they're at used to be made up of quads that were broken apart (by moving one or two vertices out of the plane they were all in) prior to finishing the model.

[FaustWolf]

Excellent, excellent, M! I won't have a chance to test the N,D,D scheme out for a few days due to pre-Christmas festivities (ahem, shopping ). Thanks a million for your help; I never would have figured this pointer stuff out, that's for sure.

When I get some time, I'll pick a few quads and triangles at random and see if we can map them manually based on the schemes you've developed. Then, it's onto searching for bone data -- it's either in Section 1-1, Section 2, or Section 3 I believe. Depending on how long it takes to code a plugin or standalone viewer (whichever is easiest for the coders who would like to take a crack at it), we could be viewing models quite soon!

[MDenham]

Oh, and if anyone wants to track me down at any sort of random time that they've seen me post to ask a question that MUST BE ANSWERED NOW , the best way is to check if I'm playing poker (badly) or blackjack (less badly) through UltimateBet.  I'll try to answer any sort of quick questions there, and if it takes longer I'll just tell you to expect a PM with your answer.

Slight edit before I get some sleep, which is thoroughly unrelated to this thread as well: I'm probably going to be spending the next couple of weeks (well, after Christmas ) mostly working on my "sort of like RPG Maker, only not nearly as limited or annoying to use" project.  If anyone's up for either tossing suggestions at me, writing code (it'll probably be about half Managed C++, half C# - VS2k5 Express for the, uh, not quite a win but not a loss), or otherwise possibly being useful, e-mail/PM/track me down.

[FaustWolf]

Whoah, it's an actual game-maker, M? Sounds awesome. Is it a 2D engine, or can it do 3D as well -- maybe we can put all these battle models to use ? My, my, between you and Cyb, we game creation / hacking enthusiasts are going to have all sorts of new programs to fuel our projects. Thanks a million guys!

I might just be able to squeeze in the necessary tests for the pointer schemes tonight or tomorrow. Then it's on time to sift through the hex for bone data!

[MDenham]

Whoah, it's an actual game-maker, M? Sounds awesome. Is it a 2D engine, or can it do 3D as well -- maybe we can put all these battle models to use ?

It definitely will have a 2D mode, and 3D's in the cards for, at the very least, "later" - pulling off PC ports of as many of the Square/SE games [with the exception of FF11 - there's already a perfectly good PC version of it, ] as possible is one of the main reasons for the project.

[FaustWolf]

Oh-hoh-hoh! I'm looking forward to it. Then the Compendium can get together and do some hair-brained scheme like collecting every SNES RPG sprite out there and making some huge CT-themed fangame.

I'll be doing some tests this evening with the Cross models finally, and I'll get the results up tonight to confirm your General Theory on Chrono Cross Model Pointers!

[MDenham]

Oh-hoh-hoh! I'm looking forward to it. Then the Compendium can get together and do some hair-brained scheme like collecting every SNES RPG sprite out there and making some huge CT-themed fangame.

If that happens, please leave the Disney characters out of it, okay?

[Sora]

*Triangle 10's metapointers*: (-5)->(-2)->1090, (-8)->1090, (-12)->(-3)->10D0
* Triangle 12's metapointers*: 10B8, (-12)->(-2)->1090, (-13)->(-2)->1090

ummm...these don't look like triangles to me.
unless 12 and 10 are used to create 1 triangle, but why would they do that?

[FaustWolf]

You're referring to the "overlapping" values, Sora? It's a fairly prevalent phenomenon -- my guess is these "points" and "lines" in the triangle and quad data are used for some aesthetic purpose on the models. Maybe to fill in gaps that occur due to texture folding? They do seem to behave correctly though -- I tested one quad somewhere in the posts above that consists of a single point on the UV map, and sure enough when I blacked it out this affected neighboring quads.

Shoot, something's come up and I most likely won't be able to post the test results for MDenham's pointer scheme tonight. The few results I have at this point look promising, though.

When MDenham gets finished with his uber RPGMaker, we'll have...CHRONO HEARTS!!

[Sora]

well, these are the points listed between both triangles.


now, the first one seems to be making a line by referring to 1 point twice.


and even with both of them, they aren't making a triangle together like i thought, but just a ^, as seen here:


for a correct triangle, you would need.
1090, 10D0, and 10B8 to be listed in 1 triangel.

[FaustWolf]

Hmm, I'll take a look at it during the experiments, whenever I get around to them. Thanks for bringing it up.

[MDenham]

*Triangle 10's metapointers*: (-5)->(-2)->1090, (-8)->1090, (-12)->(-3)->10D0
* Triangle 12's metapointers*: 10B8, (-12)->(-2)->1090, (-13)->(-2)->1090

ummm...these don't look like triangles to me.
unless 12 and 10 are used to create 1 triangle, but why would they do that?

They're only referred to as triangles because they're in with the triangle data.

Likewise, even if a quad uses the same vertex twice, or three times, or even all four times, I'm still going to refer to it as a quad and leave a note about it because it's in with the quad data.

Besides, I did mention that I might be off in my math as to where they land, so the repeated 1090s may not be correct.

[Luminaire85]

You guys rock. I don't think I would have ever thought of a scheme like that for the pointer data.

I've been working on adding the progress you've made to the C++ program I have going. The results aren't perfect yet, but they are encouraging. Perhaps most important is that when I applied the pointer scheme you developed to all of the "quad" data appears to yield values for the vertex offsets that suggest there are 559 vertices, as predicted.

My C++ program currently outputs a Wavefront OBJ file that I can import into Blender. I figured out how to add texture data and the texture image to the files needed by the importer. The results are summarized in the attached images.

The first image is of the model with only the quad data (I tried the triangle scheme you had but it looks bad at the moment). It doesn't look too much like our co-favorite silent protagonist yet, but it's cool to see the vertices connected in a coherent way. Both parts of this image are from the same camera position.

The second image is of the UV coordinates of the quads unwrapped on the Serge texture. I had to flip the vertices vertically to get this image, but it fits quite well if you ignore the vertices hanging off the bottom.

The third image is when I try to apply the texture coordinated to the 3D model. The left-hand image is from the same camera position as in the first image, while the right-hand image is from a camera angle on the other side of the model. I don't know if this is useful for anything other than a laugh, but here it is.

The last attachment contains the Blender file the above images were taken from, for those interested.

I should add that for the "16-byte mode" vertices I arbitrarily used the second set of 8 bytes for the vertex.

[attachment deleted by admin]

[FaustWolf]

    

HOLY COW!!

Luminaire, that is freaking awesome! I assume we'll still need bone data. From what I've seen the vertices are given 3D coordinates with respect to the bones (perhaps the bone "root"), so your results may be near-perfect when that's factored in. MUCHAS gracias for taking the initiative to do this! It's a standalone program and not a plugin then?

I still have some things to take care of outside the world of Chrono Cross, so in-depth testing on the General Theory of Chrono Cross pointers has to wait for a few more days. I'm hoping to have the pointer scheme finalized and bone data located before the first of 2008 though. Great job team! WOOT-WOOT!!