Author Topic: CHRONO CROSS MODEL PROJECT THREAD  (Read 13990 times)

FaustWolf

  • Guru of Time Emeritus
  • Arbiter (+8000)
  • *
  • Posts: 8972
  • Fan Power Advocate
    • View Profile
CHRONO CROSS MODEL PROJECT THREAD
« on: January 14, 2009, 02:14:15 am »
This will help us centralize investigation of CC models in its own thread.

So far, Luminaire's latest Blender plugin (written in Python) is attached, as will further updates made to it in the future. All wikified model knowledge is here:
http://www.chronocompendium.com/Term/Chrono_Cross_File_Structure.html

Pertinent subsections are "File and Data Types" for both the battle model format and TIM textures. Where models are on CD1 can be found under the "Yazoo's Tool Output Folders" heading.

The next step in Chrono Cross model research is to figure out the animation format. One hilarious (as in excruciating) factoid is that attack animations are not part of the model data. You read that right. As proof, here's quasi-playable Slash and Dario with perfect model data transplantation and repointering. All animations are there with the exception of the attack animations.

It's my suspicion that attack animations are stored in the same area of the CD as tech animations, which are also applied to the models externally. This external attack animation also presumably gives each character his or her own weapon trail color.

But first, the animation format. Here's what MDenham and I reported on it a long time ago.

Quote from: FaustWolf
Section 4 seems somewhat promising, however.  It starts off with a header - 0x16 entries (so 22), and pointers for each of them into Section 4.

However, it's a little interesting as far as what happens between the header and where the first entry is...


Code:
01 00 00 00  00 00 00 00  00 00 00 00  10 00 00 00
00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00
00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00
00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00
00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00
00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00
00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00
00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00
00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00
00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00
00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00
00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00
00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00
00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00
00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00
00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00
00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00
00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00
00 00 00 00
Awful lot of blank space in that particular spot for them to be worrying too much about whether or not the animation data is compressed, I'd say - however, I could be wrong (it's happened before).

Animations are in the following format:

* Frame count (4 bytes)
* Unknown (8 bytes)
* Frame pointers (4 bytes each)
* Frames (variable length - first frame is longer than all others, but all others are generally of the same length; the first three animations use 96, 114, and 102-byte frames.  THE FIRST FRAME SEEMS TO CONSISTENTLY BE 276 BYTES.)

The fact that frames are landing at a multiple of 6 bytes does nothing to help my suspicion that rotation data isn't compressed.

Quote from: 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, ).



[attachment deleted by admin]
« Last Edit: April 12, 2009, 11:39:05 pm by FaustWolf »

Schala Zeal

  • Radical Dreamer (+2000)
  • *
  • Posts: 2127
  • 7th Elemental Innate, and vtuber
    • View Profile
Re: CHRONO CROSS MODEL PROJECT THREAD
« Reply #1 on: January 14, 2009, 02:34:48 am »
We really need this stickied, mainly for the attached file of course *smiles*

utunnels

  • Guru of Reason Emeritus
  • Zurvan Surfer (+2500)
  • *
  • Posts: 2797
    • View Profile
Re: CHRONO CROSS MODEL PROJECT THREAD
« Reply #2 on: January 14, 2009, 02:04:23 pm »
Quote
* Unknown (8 bytes)

These bytes must have something to do with the frames after the first frame.
I assume they define the movable joints. You can zero them all and the animation will be still, if you try to swap some bytes, the animation is changed.

FaustWolf

  • Guru of Time Emeritus
  • Arbiter (+8000)
  • *
  • Posts: 8972
  • Fan Power Advocate
    • View Profile
Re: CHRONO CROSS MODEL PROJECT THREAD
« Reply #3 on: January 14, 2009, 02:11:52 pm »
Rockin', thanks utunnels. I've noticed that the first frame is always larger than all the proceeding frames, and all proceeding frames are of consistent size within the model IIRC.

utunnels

  • Guru of Reason Emeritus
  • Zurvan Surfer (+2500)
  • *
  • Posts: 2797
    • View Profile
Re: CHRONO CROSS MODEL PROJECT THREAD
« Reply #4 on: January 14, 2009, 02:38:25 pm »
For example, Serge's idle animation(the first animaion) has a value of "5665600015150000".
It is like this in binary string:
01010110011001010110000000000000 00010101000101010000000000000000

So there're 16 1s. The first frame is 23x12 = 276 bytes, and all other frames are 8 x 12 = 16 x 6 = 96 bytes.

Serge's run animation:

Hex:
5645450115150000
Bin:
00101011001000101010001010000000100010101000101010000000000000000
Count of 1s: 17
Number of bytes of a frame: 102 = 17 x 6


So maybe we can assume the first 32bits of the 8 bytes data are used for marking rotatable joints, while the later 32 bits are used for marking movable joints.

--------------------------------

Edit*

Wait, but someone said Guile has 36 joints?

----------------------------------
Edit Again*

Yeah, so Guile has 12 bytes...

Hex
56501545515D554575000000
Bin
010101100101000000010101010001010101000101011101 010101010100010101110101000000000000000000000000

There are 32 1s, and each frame of his animation(except the first one) has 192 bytes (32 x 6).
« Last Edit: January 14, 2009, 03:08:08 pm by utunnels »

MDenham

  • CC:DBT Dream Team
  • Chronopolitan (+300)
  • *
  • Posts: 330
  • Glowsticks are not a weapon.
    • View Profile
    • Java IRC - konata.echoes-online.com
Re: CHRONO CROSS MODEL PROJECT THREAD
« Reply #5 on: January 15, 2009, 05:11:15 am »
 :picardno

That's too goddamn obvious for my own good. :-D

Luminaire85

  • Guru of Time Emeritus
  • Chronopolitan (+300)
  • *
  • Posts: 311
    • View Profile
    • Chrono Cinema
Re: CHRONO CROSS MODEL PROJECT THREAD
« Reply #6 on: January 15, 2009, 08:29:21 pm »
We really need this stickied, mainly for the attached file of course *smiles*

If you think that's cool, wait until you see what the latest version can do (see attached). I hope to release it soon, but first I need to test the script's robustness.

To that end, I'm looking for a large collection of battle model files and their associated textures. Does anyone have such a collection yet? If not I will look into ripping them myself.

[attachment deleted by admin]

HyperGeek

  • Architect of Kajar
  • Earthbound (+15)
  • *
  • Posts: 24
  • The "Hare Hare YuKid" guy
    • View Profile
Re: CHRONO CROSS MODEL PROJECT THREAD
« Reply #7 on: January 15, 2009, 08:44:08 pm »
Greetings, all.  I'll be the first to admit I don't know much of anything about hex hacking, so if any of this is redundant or just doesn't make sense, feel free to yell at me and I'll stay on the sidelines.  I figured I might as well post the results of a bit of tinkering, just in case it's actually helpful to someone.

utunnels, looks to me like those eight bytes likely define the movable joints, but I don't think it's 32 bits rotatable and 32 bits movable.  It seems to me like the whole eight bytes simply define the joints which animate at all.  For example, if you change those bytes in Serge's idle animation to 0000000015150000, you end up with a Serge whose upper body is paralyzed and whose legs sort of dangle and twitch around a lot.  I would guess that this is the result of the upper body's animations being applied to the lower body's joints.

As an experiment, I restored the eight bytes of unknown data to their original values and decided to try zeroing out the first 0x3E bytes of each frame of the idle animation after the first.  (This is a bit more than half because 0x30 leaves one of his arms animating, but don't ask me where I got that exact number, because it made sense at the time and I don't really remember why I chose it.)  What happens then is that for most of the frames of his idle animation, Serge's upper body stops moving, but his legs seem to be operating pretty much as they should.  Now, change the unknown bytes to 5665600000000000 (Zeroing out the 0x1515, basically.) and (with the exception of the first frame) Serge will stop moving entirely.

My guess is that those last four bytes identify which joints in the lower body to apply the last part of the animation to.  If that's the case, the first part of each frame of the animation is applied to the upper body (but doesn't move it because I zeroed those parts of the frames out) and it simply discards the last part of each frame because it has no joints to apply it to.  Then again, I really don't know what I'm doing, so I could be entirely on the wrong track.

Luminaire85

  • Guru of Time Emeritus
  • Chronopolitan (+300)
  • *
  • Posts: 311
    • View Profile
    • Chrono Cinema
Re: CHRONO CROSS MODEL PROJECT THREAD
« Reply #8 on: January 15, 2009, 10:17:15 pm »
I would also like to point out that the next release of my script will be called the Chrono Cross Battle Model Importer, because it also works for the overworld models!

Continuing my thought from my last post, I've got all the raw files, but precious few textures converted to PNG. It looks like the overworld textures are viewable in PSicture, but not the battle textures, of course. Has someone converted these already? If not, how do I do it?

The ultimate goal is to write a script that converts all of the models in batch and saves them as .blend files (and maybe other formats if possible) for the encyclopedia.

[attachment deleted by admin]

FaustWolf

  • Guru of Time Emeritus
  • Arbiter (+8000)
  • *
  • Posts: 8972
  • Fan Power Advocate
    • View Profile
Re: CHRONO CROSS MODEL PROJECT THREAD
« Reply #9 on: January 15, 2009, 10:30:31 pm »
Luminaire, I will gladly take care of the model collection provision aspect. I've got all the battle models and a few field models ready -- give me an hour and I should be back with all the textures converted to .PNG and the raw model files.

Huuuuge awesomeness!! Thanks Luminaire! ZeaLitY, stand by with some Grimmjow pics...

ZeaLitY

  • Entity
  • End of Timer (+10000)
  • *
  • Posts: 10795
  • Spring Breeze Dancin'
    • View Profile
    • My Compendium Staff Profile
Re: CHRONO CROSS MODEL PROJECT THREAD
« Reply #10 on: January 15, 2009, 10:42:58 pm »
Standing by!

The ultimate goal is to write a script that converts all of the models in batch and saves them as .blend files (and maybe other formats if possible) for the encyclopedia.


FaustWolf

  • Guru of Time Emeritus
  • Arbiter (+8000)
  • *
  • Posts: 8972
  • Fan Power Advocate
    • View Profile
Re: CHRONO CROSS MODEL PROJECT THREAD
« Reply #11 on: January 15, 2009, 11:25:41 pm »
Set condition 1SQ! The use of Chrono Cross models has been authorized!
http://www.sendspace.com/file/gnhaaq

Luminaire85

  • Guru of Time Emeritus
  • Chronopolitan (+300)
  • *
  • Posts: 311
    • View Profile
    • Chrono Cinema
Re: CHRONO CROSS MODEL PROJECT THREAD
« Reply #12 on: January 15, 2009, 11:59:54 pm »
Thanks FaustWolf! I can add the field models for all the playable characters to that as well.

As a token of my appreciation I give you a taste of the personal heaven I am in looking through these things. The static images hardly do them justice.

More tomorrow. (What a perfect time for a long weekend!)

[attachment deleted by admin]

FaustWolf

  • Guru of Time Emeritus
  • Arbiter (+8000)
  • *
  • Posts: 8972
  • Fan Power Advocate
    • View Profile
Re: CHRONO CROSS MODEL PROJECT THREAD
« Reply #13 on: January 16, 2009, 12:02:49 am »
*Sniff*...they're so beautiful!

HyperGeek, thanks for your observations. Please continue and record your further experimental results, as it'll probably be a week before I scratch together enough time for my own. At the very least, you're giving the rest of us ideas to try out and confirm or disprove.

justin3009

  • Fan Project Leader
  • God of War (+3000)
  • *
  • Posts: 3296
    • View Profile
Re: CHRONO CROSS MODEL PROJECT THREAD
« Reply #14 on: January 16, 2009, 12:16:27 am »
I'm wondering.  If we can do this, could we use that program that they posted in the secret project and make sprites out of these? D: