CHRONO CROSS FILE EXPLORATION THREAD

[halkun]

Ok... This looks good, let me help you guys by giving out some advice bout the model structure.

Somewhere in that mess are discrete "parts" that are "pinned" to bones. There are objects like "head" "neck" "torso" "left_upper_arm" "left_forearm" "left_hand"... etc etc

You need to find the location where these parts start and look *backwards* to see if you can find the hierarchy that points to each of them. This will be the compiled HRC/RSD. (Or structure like it)

The head will most likely be first.

It appears that each "part" in the pictures above are mushed together, with the center of each part at 0,0,0. That center point is where the bone node is going to attach.

[FaustWolf]

Sweet. Thanks again Halkun. I think Section 1-1 is probably the HRC structure, given how sensitive it is to modification and how much the model gets screwed up when it's tweaked in the slightest. So if Section 1-1 is the HRC structure, would it essentially contain a collection of pointers to everything else, or just to the bone data?

[halkun]

The bone data is defined in an HRC.  Each "Body part" is an RSD object (ReSource Data). You make a list of RSD objects that make up the hierarchy. The RSD is made up of ploygons (PLY) and textue images (TIM). It looks like you found the RSD pool, but you missing the header for it.

Most likely there is an RSD lookup table, that's where you will find the pointers that "break down" the model into it's components.

The HRC format is defined in the Qhimm Wiki, but because I wrote it, I'll just copy it here.


An HRC file is product of the original Playstation Psy-Q 3D development libraries. They describe the bone hierarchy of a 3D model. Most of the time they originally start as a plain text file exported from 3D editing software, or from a 3D file converter. From this they can be "compiled" into binary form more usable for the PSX.

On the PC version of Final Fantasy 7,  a text HRC file is used to define the skeletal hierarchy of the field models. The Battle Models use the compiled Format.

But I think that since you read this document, you've got some knowledge 'bout 3D models and skeletons. Let's just start, this format's quite simple! ^_^

HRC file format

Since the HRC files are simple plain-text files, you can open them in notepad or any other text editor. Here are the first four bones of "abjb.hrc" (Yuffie's Hierarchy)

:HEADER_BLOCK 2
:SKELETON sd_yufi_sk
:BONES 24

hip
root
2.9662
1 ABJC

chest
hip
4.0621967
1 ABJE

head
chest
5.017107
1 ACAA

joint
head
3.5236073
0

ribon_a
joint
8.52051
1 ACAF
....

The other bones look the same as the ones listed here. These are the parts of the file.

Header

As most files, also the HRC files have got a kind of header. That are the first three lines.

:HEADER_BLOCK 2

This seems to be a simple "ID". As far as I know, this is the first line in all HRCs...

:SKELETON sd_yufi_sk

This tells you the name of the skeleton, in our example "sd_yufi_sk".

:BONES 24

Tells you how much bones are stored in this skeleton.

Bones

Every bone consist of 4 Lines, which look like this. Let's first take a look at the lines of the first bone:

First Line: ("hip")

This is the name of the current bone.

Second Line: ("root")

This is the name of the parent bone. The parent bone must be already listed above in the skeleton file,or it can be "root" (origin).

Third Line: ("2.9662")

That's the Length of the bone.

Fourth Line #1: ("0")

Fourth Line #2: ("1 ABJC")

Fourth Line #3: ("2 ABJC ABJD")

This line consist of 2 or more different values. First, there is a number telling many RSD files are aligned to this model. If it has no RSD File, the number is 0. If the number is 1, there is a string after the number telling you the name of the Resource Data File (RSD). The RSD file tells you which .p Model to use.

There may be even more than 2 RSD Files on 1 Bone, however this has yet be be seen.

Notes

There are no bone angles, just bone lengths. The HRC file only contains hierarchy data. To build a skeleton, animation files are required.

[FaustWolf]

Wow, thanks Halkun. Since only bone lengths are defined in the HRC, we'll need some animation data after all to put the models together then? I.e., to give the bones their proper angles? So we've still got lots of work to do then -- the animation data, once found, will have to be processed and applied to the bones.

[halkun]

The compiled version of the HRC is going to probably be in this format


number of bones (a variable, probably an int)  <--header

pointer to first bone (address)
pointer to parent bone (address)
bone length (float)
number of RSD objects (int)
pointer to an RSD pointer (address)
(repeat for number of RSD objects)

RSD files are also recorded. I won't duplicate that there. I do have a link..Here you go

[MDenham]

So, how was everyone's Christmas?  (Best present for me this year was a three-foot tube of unpopped popcorn - black, yellow, and red - from World Market. )

Haven't really had a chance here to try looking for anything in the way of bones data recently (computer's been flaky since I replaced the mobo and processor around the beginning of December, and my RPG Maker-alike, Thunderclap, is hollering at me "hey, why aren't you working on me" - which reminds me: Emacs-style key commands, or more like normal Windows programs, folks?  I'm leaning somewhat towards Emacs-style myself just because there aren't enough number keys to wedge all of the layers onto them ), though assuming I can get more than just an interface mockup done for Thunderclap over my 5-day weekend, I'll check if Section 1-1 is in fact the HRC.

[FaustWolf]

That would be great, M. I've been sidetracked with certain other things recently, so I guess this means more downtime for the thread. First thing I'll do when I get another project out of the way is test out the pointer scheme for triangles, and maybe by that time someone will have found the bone data.

For Christmas I got an official copy of Cygnus Hex Editor. Now I can finally do a copy-paste of hex code as opposed to posting all these screencaps!  The shareware version doesn't allow copy & paste as text, which was Cygnus' only huge drawback.

Halkun, thanks as always for putting more wrinkles in my brain!

[halkun]

Did everyone die

[FaustWolf]

Still alive, halkun, and I'm hoping to finally jump back into vertex code (it'll probably be Thursday Friday). I've been sidetracked with another hacking project, grad school applications, and a funeral all this time, but it's all winding down now.

[Cyberman]

Did everyone die

Just my sleep.  I have GTE related questions for you, however that will have to be else forum as it's currently unrelated to Chrono Cross.

Still alive, halkun, and I'm hoping to finally jump back into vertex code (it'll probably be Thursday). I've been sidetracked with another hacking project, grad school applications, and a funeral all this time, but it's all winding down now.

Sorry about the funeral. You might wish to visit Qhimm and look at some of the posts in tech if you haven't recently.


Cyb

[FaustWolf]

I thank you kindly for your condolences, Cyb. Ooh, and thanks for the Qhimm reminder!

[FaustWolf]

This post is more a "proof of life" than anything else, but will allow me to implement a new means of presenting test results while getting back into the swing of Cross exploration. For now, I'm doing another confirmation test on the nature of the quad pointers. Nothing exciting just yet, since we've been through this already.

Here's some hex code from Section 1-2, the UV map and vertex pointers.

000026E0                          3B A5 3B AD 39 AF 3A B2
000026F0  10 20 F0 21 E8 10 00 11-3B B2 3B AD 3D AF 3B A5
00002700  10 22 C0 FF 50 11 C8 FF-63 FC 5D F6 67 FB 5D EB
00002710  B0 FF C0 FF C0 FF E0 FF-5D EB 5D F6 56 F9 56 FA
00002720  F0 FF C0 FF C0 FF A8 FF-34 EA 3A F1 37 F5 3E F1
00002730  40 22 60 22 40 11 48 11-3C F1 3E F1 56 F9 5A EF
00002740  F0 FF C0 FF C0 FF 38 11-51 F2 4F F0 36 F4 34 EA
00002750  E0 21 70 20 10 11 40 10-69 EC 7F E7 67 FB 7F F0
00002760  50 20 C0 FF 60 FF C8 FF-3E F1 3A E0 5A EF 51 E3
00002770  50 FF C0 22 A8 FF 58 11-32 E0 3B E0 34 EA 3A F1
00002780  D0 22 C0 FF 50 FF C8 FF-5A EF 51 E3 5D EB 5D E1
00002790  A0 FF A0 FF 10 FF 18 10-3A E0 3B DB 51 E3 51 D9
000027A0  90 FF 00 21 D8 FF C8 10-51 D9 5D DC 51 E3 5D E1
000027B0  F0 FF 10 21 E0 FF C0 FF-32 E0 33 DC 3B E0 3B DB
000027C0  00 FF F0 20 B0 FF B0 FF-69 E0 7F E0 69 EC 7F E7
000027D0  C0 20 A0 20 10 FF 10 FF-4F F0 44 DF 34 EA 30 E0
000027E0  F0 FF C0 FF 40 10 48 10-5D E1 69 E0 5D EB 69 EC
000027F0  30 FF 70 FF 40 FF B8 FF-6A D9 7F DA 69 E0 7F E0
00002800  60 21 E0 20 D8 FF B0 FF-5D E1 5D DC 69 E0 6A D9
00002810  80 FF 80 FE E0 FF C8 FF

Each pointer is given a color, and the final positive pointer into the vertex pool is underlined. Our current quad pointer scheme as theorized by MDenham is as follows, in English...

Rule for Positive Pointers
*If you're in one of the first two columns, divide the byte pair value by 2. This value is the positive pointer into the vertex pool.
*If you're in one of the last two columns, the byte pair value is the positive pointer into the vertex pool.

Rule for Negative Pointers
*If you're in one of the first two columns, divide the byte pair value by 16. Go backward that number of positions into the non-UV data.
*If you're in one of the last two columns, divide the byte pair value by 8. Go backward that number of positions into the non-UV data.

The rule for negative pointers works like a charm. I'm still investigating the rule for positive pointers -- I got weird results last night, but that may be due to sleepiness. I did a positive pointer test with the quads earlier before this thread's temporary death, and it worked out fine then. I plan on having a final verdict tomorrow morning.

[suri]

nice work gents!

I am very happy that poking around in console files is not dead.
I devoted most of my fleeting youth to it.

[FaustWolf]

Hey, welcome aboard suri! I hope we can determine enough about how these models work for Luminaire85 to convert them into a usable format, and then one day we can see Serge, Kid, and Guile walking on those maps you're creating!

I've gotta do some final randomized tests to confirm the nature of the quad and triangle pointers yet. Gah, thanks to my nitpicking it seems this thread has gone backwards upon my return, since we had already started discussing bone data in depth right before I left. Suri, if you've got any input on Chrono Cross model exploration, by all means join in! I'm glad to have additional insight.

[suri]

I hope you guys succeed! Id like to help if I could.
I dont know if i can help much because the only formats ive done where the file actualy had pointers in it was nights into dreams.  and being you can emulate it I worked from a memory dump and all the pointers were real ^^.
Lattely ive been doing alot of nextgen extracts like sonic 2006,eternal sonata,enchanted arms, doa4, and doax2.  those formats are gravy compared to the ultra compacted no info you dont need to live formats of psx era. also saturn didnt have mapping cordinates 1 texture per 1 quad, corners are  1 to 1 maped.  I did document the nights bone animation format though, I could post some details on it if you think it might be simular.  (i got it from finding the function that interpolates between keyframes and following the code over and over until i made sense of how it stored each keyframe and how it mapped to the model)

btw are you guys working from psx emulator dumps? from psx emulator debugger? or just from files?