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

FaustWolf

  • Guru of Time Emeritus
  • Arbiter (+8000)
  • *
  • Posts: 8972
  • Fan Power Advocate
    • View Profile
Re: CHRONO CROSS MODEL PROJECT THREAD
« Reply #15 on: January 16, 2009, 12:26:43 am »
Technically, we could probably make sprites out of screencaps I guess...I mean, once coloration is dumbed down to 12 (more if we make the enemy part of the background), insertion and assembly would be a simple matter.

utunnels

  • Guru of Reason Emeritus
  • Zurvan Surfer (+2500)
  • *
  • Posts: 2797
    • View Profile
Re: CHRONO CROSS MODEL PROJECT THREAD
« Reply #16 on: January 16, 2009, 12:49:41 am »
Wow, after a few hours' absence, I can't believe my eyes. Really beatiful models.

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. 

Yeah, I'm a noob in 3d animtion. I wanted to [/S] this line that day but just left it alone since I couldn't think out a better expression. LOL
« Last Edit: January 16, 2009, 06:46:50 am by utunnels »

yaz0r

  • Architect of Kajar
  • Porrean (+50)
  • *
  • Posts: 65
    • View Profile
Re: CHRONO CROSS MODEL PROJECT THREAD
« Reply #17 on: January 16, 2009, 12:17:14 pm »
For example, Serge's idle animation(the first animaion) has a value of "5665600015150000".
It is like this in binary string:
01010110011001010110000000000000 00010101000101010000000000000000

Just wanted to say that this is rather close to the way FFX manage it's own animations.

HyperGeek

  • Architect of Kajar
  • Earthbound (+15)
  • *
  • Posts: 24
  • The "Hare Hare YuKid" guy
    • View Profile
Re: CHRONO CROSS MODEL PROJECT THREAD
« Reply #18 on: January 16, 2009, 06:52:06 pm »
Double edit: Parts of this post no longer appear valid to me.  In particular, the "table" of bits is wrong, and my gripes about the leading zero are unnecessary.  See my later post for the corrections.

Arrrgh, I think I may be on the right track to understanding those eight bytes of unknown data now, but I can't figure out exactly how I did what I did.  (I was using a program I threw together in Java to handle the numbers for me and now I can't make it work when I do it by hand!)  Basically, you have to consider the binary form of the eight bytes as two rows, alternating digits on the top and bottom.  If you line these up with the letters A-W (representing the 23 movable parts of Serge), then a 1 in one row indicates that translational data should be applied to that part, and a 1 in the other indicates that rotational data should be applied to that part.  Mine looks like this, with translation being the top row and rotation being the bottom row:  (I think I reversed the bit order to make it look like this.  I think it should look roughly the same if you don't flip it and put the letters in reverse order instead.)


ABCDEFGHIJKLMNOPQRSTUVW
 1000001000100000000000
 1111101000100001110111


Clear as mud, right?  The fact that it doesn't line up unless I ignore A bugs me as well, but I think I might be getting close-ish.  If someone can understand it from that, feel free to give a better explanation.  If nobody beats me to it, I'll post one as soon as I can figure out how exactly I got there.

For a demonstration of what I managed to make happen, though, look at this and this.  The first video is the result of me mucking around with the rotational data in Serge's idle animation and changing the rotations that are applied to the model as a whole and his waist in particular.  (I believe these are articulations B and C from the old thread.)  It may be worth noting that there were no translation commands for his waist, just the rotations.

The second video is the fun part.  I changed one of the bits in the eight bytes of unknown data from a 1 to a 0 like so:


ABCDEFGHIJKLMNOPQRSTUVW
 1000001000100000000000
 0111101000100001110111


If my hypothesis is correct (or at least on the right track), the bit I changed was the bit that told the game that the entirety of Serge's model can be rotated.  Doing this should cause Serge to stop spinning because he's no longer affected by rotational commands.  Additionally, the rotational commands that were supposed to be applied to the body should now fall through to the waist articulation, the waist articulation's commands that cause it to face backwards should now fall through to the head, etc.  The waist and head definitely seem to be acting as predicted.  The interesting part for me is that Serge's arms are now screwed up.  This would, I assume, be the result of rotation commands falling through and being interpreted as translation commands.

It's entirely possible that I'm way off track here, but I'm gonna keep fiddling with it and see what I can come up with.

EDIT: Ok, I think I can duplicate what exactly I did, but I'm still having problems with either a spare 0 or one 0 too few (depending on how you look at it), which means I don't think it's right yet.  I'm almost certain it has to be something sort of along these lines, though.

For Serge's idle animation, the eight bytes we're concerned with are "5665600015150000."  The PlayStation reads the bytes "backwards," right?  So it interprets this as "0000151500606556."  Convert this to binary and you get "0000000000000000000101010001010100000000011000000110010101010110."

I reverse the bits here so that I don't strain my inferior mind.  It's probably not necessary.

"0110101010100110000001100000000010101000101010000000000000000000"

Now, here's the part that doesn't work.  We need to line this binary string up with the set of Serge's articulations.  (I was using the set here, which may or may not still be accurate.  I'm clearly way off if it's not.)  See that leading zero on the binary string?  It throws everything off.  If you delete the zero, you have to ignore A for the part that follows.  If you ADD another zero, you can still use A.  Anyways, from here you divide the binary into two rows, with the first digit on the top row, second digit on the bottom, third digit on top, and so on.  It should look something like this (Note that I opted to add a zero.):

010000010001000000000000000000000
01111101000100001110111000000000

Now we put Serge's articulations on top of it:

ABCDEFGHIJKLMNOPQRSTUVW
010000010001000000000000000000000
01111101000100001110111000000000

See how that works?  Any articulation with a 1 in the top row will be translated at some point in the animation, and any articulation with a 1 in the bottom row will be rotated.  Now I'm going to do what I did for the second video and change one bit.

ABCDEFGHIJKLMNOPQRSTUVW
010000010001000000000000000000000
00111101000100001110111000000000

Now to convert back to hex.  The first step is to get the modified binary string.  Again, one must add or remove a leading zero depending on what you did to make it fit the table.  Here's the binary:

0100101010100110000001100000000010101000101010000000000000000000

Now I reverse the bits again to undo the reversal I did at the start:

0000000000000000000101010001010100000000011000000110010101010010

And now I convert back to hex:

0000151500606552

Last order of business is to reverse the order of bytes so it can be read correctly:

5265600015150000

And there ya go.  I stuck that into my game and it went from my first video to my second.
« Last Edit: January 16, 2009, 11:12:06 pm by HyperGeek »

FaustWolf

  • Guru of Time Emeritus
  • Arbiter (+8000)
  • *
  • Posts: 8972
  • Fan Power Advocate
    • View Profile
Re: CHRONO CROSS MODEL PROJECT THREAD
« Reply #19 on: January 16, 2009, 08:34:29 pm »
Excellent stuff Hyper! Huge thanks for your work!!

HyperGeek

  • Architect of Kajar
  • Earthbound (+15)
  • *
  • Posts: 24
  • The "Hare Hare YuKid" guy
    • View Profile
Re: CHRONO CROSS MODEL PROJECT THREAD
« Reply #20 on: January 16, 2009, 11:02:43 pm »
Ah, I think I have to correct myself here.  Somewhere along the line I seem to have gotten myself backwards and started expecting translational data to come first, when it's actually rotational that does.  In light of that, I don't think the way I'm interpreting the eight bytes makes sense.  My earlier post has been modified with a note to that effect, and I'm gonna see if I can figure this out.

EDIT: Ah, wait, I seem to have confused myself again.  This may be easier than I expected it to be.  If we leave the leading zero on the binary string above, we end up with this in the table: (This is with the trailing zeros snipped.  They'll need to be put back when I convert back to hex.)

ABCDEFGHIJKLMNOPQRSTUVW
01111101000100001110111
10000010001000000000000

In this case, rotation is the top row and translation is the bottom.  This interpretation solves the problem of the leading zero nicely, but also ensures that (for the idle animation, anyways) no one joint can be both translational and rotational.  Can somebody more familiar with 3D modeling tell me if that makes any sense?  At any rate, the modification I made to this earlier (removing the second 1) still works.  Instead of the above, we get this:

ABCDEFGHIJKLMNOPQRSTUVW
00111101000100001110111
10000010001000000000000

Which still prevents the body from rotating and allows the fall through to occur as predicted.
« Last Edit: January 16, 2009, 11:09:42 pm by HyperGeek »

Vehek

  • Errare Explorer (+1500)
  • *
  • Posts: 1756
    • View Profile
Re: CHRONO CROSS MODEL PROJECT THREAD
« Reply #21 on: January 16, 2009, 11:56:10 pm »
I think I may have found some of the attack animations. At least one of Serge's attack animations should be in a file on sector 2527F.

Here's the eight bytes at the beginning.
56 65 65 85 95 15.

FaustWolf

  • Guru of Time Emeritus
  • Arbiter (+8000)
  • *
  • Posts: 8972
  • Fan Power Advocate
    • View Profile
Re: CHRONO CROSS MODEL PROJECT THREAD
« Reply #22 on: January 17, 2009, 12:31:28 am »
Damn, the results just keep flowing in!

Sector 0x2527F is address 0x1293F800, which is somewhere after all the battle models. Probably in range MISC = 3760-3978 as opposed to MISC = 3979-5597 (Elements and Techs, graphical aspects) as I'd previously hoped, but the fact that those two sections abut is probably still promising in terms of logical data storage.

Vehek

  • Errare Explorer (+1500)
  • *
  • Posts: 1756
    • View Profile
Re: CHRONO CROSS MODEL PROJECT THREAD
« Reply #23 on: January 17, 2009, 12:41:11 am »
0x94F70 seems to be called when an attack is made; it reads the frame length of the attack. Set a breakpoint on it, go to the address r5 contains, and see if you can find the data there in the CD.
« Last Edit: January 17, 2009, 01:14:51 am by Vehek »

justin3009

  • Fan Project Leader
  • God of War (+3000)
  • *
  • Posts: 3296
    • View Profile
Re: CHRONO CROSS MODEL PROJECT THREAD
« Reply #24 on: January 17, 2009, 01:35:29 pm »
I'm really not sure where to even post this, but would it be too much to ask if someone would rip the Time Devourer?

FaustWolf

  • Guru of Time Emeritus
  • Arbiter (+8000)
  • *
  • Posts: 8972
  • Fan Power Advocate
    • View Profile
Re: CHRONO CROSS MODEL PROJECT THREAD
« Reply #25 on: January 17, 2009, 01:38:25 pm »
Should be in the model pack I gave Luminaire. Unfortunately I don't actually have the means to produce a converted file...

Luminaire85

  • Guru of Time Emeritus
  • Chronopolitan (+300)
  • *
  • Posts: 311
    • View Profile
    • Chrono Cinema
Re: CHRONO CROSS MODEL PROJECT THREAD
« Reply #26 on: January 17, 2009, 02:12:58 pm »
Happens to be the very file I was using to test my batch script.

My current collection (root folder ~):

~/alternate: 5 overworld models (from OAM: 3 cats from S.S. Zelbess, Dragoon Viper Manor disguise, Korcha's boat)
~/enemies: 146 battle models (from MISC 3211-3707)
~/other: 5 overworld models (mermaid, young Serge, Miguel, Wazuki, Toma)
~/playable: 52 overworld models (from OMCM) + 52 battle models (from MISC 3054-3210)

My naming scheme is as given in the example, for Serge:

~/playable/Serge/SergeBattleModel
~/playable/Serge/SergeBattleTexture.png
~/playable/Serge/SergeOverworldModel
~/playable/Serge/SergeOverworldTexture.png

Another example, the Time Devourer:

~/enemies/TimeDevourer/TimeDevourerBattleModel
~/enemies/TimeDevourer/TimeDevourerBattleTexture0.png
~/enemies/TimeDevourer/TimeDevourerBattleTexture1.png

The textures for the double-textured models are numbered in the order they should be chosen by the plugin, starting from 0. Also, in all texture files I have set pure black (rgb 0, 0, 0) to fully transparent.

There are a lot more models to be found. We have to go through the NPCs from the room folders (as noted here). I'm thinking there are some models only on Disc 2 (the Lunar Dragon, for example).

Now for some good news: my import script is performing extremely well in the robustness testing. Should be able to release very soon.



[attachment deleted by admin]

justin3009

  • Fan Project Leader
  • God of War (+3000)
  • *
  • Posts: 3296
    • View Profile
Re: CHRONO CROSS MODEL PROJECT THREAD
« Reply #27 on: January 17, 2009, 02:15:19 pm »
Wow.  Thank you very much D:

FaustWolf

  • Guru of Time Emeritus
  • Arbiter (+8000)
  • *
  • Posts: 8972
  • Fan Power Advocate
    • View Profile
Re: CHRONO CROSS MODEL PROJECT THREAD
« Reply #28 on: January 17, 2009, 10:52:12 pm »
Luminaire, if you wouldn't mind, I've found a strange double-texture model while processing the field model folders Vehek created earlier. I just can't place it, and I'm not seeing it in the enemy battle model archive I made, though it's perfectly possible I missed this one. Could you try to load it so we can identify it maybe?

[attachment deleted by admin]

Luminaire85

  • Guru of Time Emeritus
  • Chronopolitan (+300)
  • *
  • Posts: 311
    • View Profile
    • Chrono Cinema
Re: CHRONO CROSS MODEL PROJECT THREAD
« Reply #29 on: January 18, 2009, 12:27:44 am »
I believe that is the Salamander summon.

[attachment deleted by admin]