Chrono Compendium
Kajar Laboratories - Fan Works and Submissions => Chrono Cross Modification => Topic started by: FaustWolf 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 (http://www.youtube.com/watch?v=KT6qemexlJ0) and Dario (http://www.youtube.com/watch?v=Y1Paj0r_DLw) 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.
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.
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]
-
We really need this stickied, mainly for the attached file of course *smiles*
-
* 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.
-
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.
-
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).
-
:picardno
That's too goddamn obvious for my own good. :-D
-
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]
-
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.
-
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]
-
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...
-
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.
(http://www.sparkplugging.com/kids-activities/wp-content/uploads/2008/02/valentine-heart.gif)
-
Set condition 1SQ! The use of Chrono Cross models has been authorized!
http://www.sendspace.com/file/gnhaaq (http://www.sendspace.com/file/gnhaaq)
-
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]
-
*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.
-
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:
-
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.
-
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
-
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.
-
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 (http://www.youtube.com/watch?v=C18c_T-QXes) and this (http://www.youtube.com/watch?v=Tk5mUdBG0wA). 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 (http://www.chronocompendium.com/Forums/index.php/topic,4770.msg88099.html#msg88099), 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.
-
Excellent stuff Hyper! Huge thanks for your work!!
-
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.
-
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.
-
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.
-
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.
-
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?
-
Should be in the model pack I gave Luminaire. Unfortunately I don't actually have the means to produce a converted file...
-
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 (http://www.chronocompendium.com/Forums/index.php/topic,6699.msg131185.html#msg131185)). 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]
-
Wow. Thank you very much D:
-
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]
-
I believe that is the Salamander (http://www.chronocompendium.com/Term/Red_Elements.html) summon.
[attachment deleted by admin]
-
Well I'll be damned, thanks. I wonder why the heck it was on the field...?
-
Because it's on the Field at first. When you first fight it, there's that little baby salamander thing that walks around that you have to fight. And the bigger Salamander is on the back stuck in the floor.
Edit: I can't remember the area's name...It's like..the last place where you fight Salt and peppor or w/e I believe..
-
I think that's the Fire Dragon though, isn't it? Or am I totally mixed up here?
-
No, I think you've got it. As I recall, the salamander's head sticks through in the area of Mt. Pyre where the Fire Dragon is. I believe it goes away after you get the red relic.
-
Ohhh, I get it now, I just watched a Youtube vid of the Fire Dragon fight. Yeah, it's sitting right there after all. Well, that solves my confusion, thanks everyone.
-
Paydirt. Check this (http://www.youtube.com/watch?v=ZN66Fqkjj_g) out. What does this look like to you? If you answered "Kid spazzing out," award yourself a cookie. That's exactly what's happening. Anyone care to guess why? For once, the answer isn't "HyperGeek was messing around with the animation data." Not directly, anyways.
As mentioned in the video description, I believe Kid's model is trying to use Serge's attack animations. Yes, she's also really freaking out, but my guess is that she has more joints than Serge (Her animations seem to have more than eight bytes to identify which joints animate.), so the game is interpreting the data in a really weird way. I'll let you guys be the judge of exactly what's going on there, since I may just be seeing what I want to see, and there's some odd side effects from this that I wouldn't expect to happen if I'd done this right. Here's what I did to make it happen.
Short version: I changed the data at address 0xFF70 from 0xD45202BC to 0x7F520296. Try it and see for yourself, it'll save you a lot of trouble reading the next few paragraphs if I'm (very likely) wrong about what I'm looking at.
Long version: Vehek located the sector where at least one of Serge's attacks should be, along with the eight bytes that start it. The attack in question (based off searching for those eight bytes) seems to begin at 0x129470C8. Working backwards from here, there's something that looks like a standard animation header (number of animations and pointers to them) at 0x12946A30. Some fiddling with the animation here confirmed that this does point to the animations for Serge's attacks. Now, work backwards from there. Somewhere in the neighborhood of 0x1293F800 is what looks like either another header, or at least some pointers, one of which seems to be pointing at the animation header. (I think they start at 0x1293F808 or 0x1293F80C, but I'm not exactly sure.) 0x1293F800 is the start of sector 2527F, which Vehek identified as being where Serge's attack animations are. I can pretty much verify that the animations themselves are not there, but the fact that path to find them begins in that sector makes me pretty sure that either this whole mess is lining up or it's a whole bunch of coincidences, I'm not sure which.
Anyways, if you do a hex search for 7F 52 02 (Which should be how that sector number would be referenced in the hex, right?) the first result should be at 0xFF6C, which looks to me (As usual, I'm operating more by feel than any sound scientific principle.) like it's part of the table of contents. If you repeat the whole working backwards process for one of Kid's attack animations, I believe the sector where the pointer to the animation header occurs for her is 252D4. As luck would have it, the next entry in the ToC references this sector. Changing that entry to 0x7F520296 (In other words, making it point at Serge's data instead of Kid's.) caused the results you see in the video.
Today's experiment also revealed some issues with the above, even if I really did manage to trip over the attack animation pointers. Changing the entry in the ToC for Serge to match the one for Kid causes Serge to lose the ability to attack. You can still select attack and choose a target, but there's no cursor to allow you to choose your attack level, so you can't actually select any of them. Trying to change Serge's entry to either of the two after Kid's (These would presumably be Guile and Norris) causes the game to crash and burn when you select a target for his attacks. It wouldn't surprise me if this was the case for the other entries as well, but I haven't tried yet. Changing the entry for Kid to match the next entry (Again, I'd assume this is Guile, but I haven't checked that.) causes her to lose the ability to attack, but strangely allows Serge to attack if his entry has been changed to what hers normally is.
-
Awesome stuff Hyper! So according to your and Vehek's findings the pointer to Serge's attack animation data is in sector 252D4, and the animation data itself is in sector 2527F, is that correct?
-
Ah, sorry, I think my phrasing was a bit ambiguous in that last post. This is what happens when I get excited. I'll see if I can fix that.
Anyways, that's not quite right, FaustWolf. The pointer to the header for the animation data appears to be near the start of sector 2527F. This is what the ToC seems to be referencing. The animation data itself is quite a bit later (Header starts at 0x12946A30), looks like it's in sector 2528D, I think. Check me on that, I'm still not entirely sure what I'm doing. Sector 252D4 is where the pointer to Kid's animation header is, with the header itself occurring at 0x1296B7B4. (That would be sector 252D6 if I'm not mistaken.)
EDIT: Cleaned the last post up a little to try to be more clear. Let me know if it's still confusing.
-
Oh, I should have caught myself, of course you were referring to Kid and Serge and I thought it was just Serge. So it's like this?
Serge Attack Animation Pointer: Sector 2527F
Serge Attack Animation Data: Sector 2528D (header start at sector boundary)
Kid Attack Animation Pointer: Sector 252D4
Kid Attack Animation Data: Sector 252D6 (header start at sector boundary)
-
Sorry, I guess I'm still not being clear. I'll have to ask you to forgive me; as I said, I'm still pretty new to this.
I don't believe either animation header is at the start of the sector boundary. Both sector 2527F and sector 252D4 start off with something that looks like a mass of pointers, one of which points to the animation data. For example, here's what's at 0x1293F800 (which should, by my math, be the very start of sector 2527F):
6472 7000 0000 0000 000A 0000 AC00 0000
4401 0000 F001 0000 7C02 0000 1403 0000
8003 0000 F403 0000 7007 0000 EC10 0000
201B 0000 041E 0000 8027 0000 AC27 0000
782D 0000 7433 0000 B842 0000 E442 0000
804B 0000 C45A 0000 2472 0000 00A6 0000
8CA6 0000 E0A6 0000 2CA7 0000 94A7 0000
04A8 0000 28AC 0000 7024 0100 1464 0100
4064 0100 CC64 0100 5465 0100 0024 0200
2C36 0200 5848 0200 845A 0200 B066 0200
DC78 0200 088B 0200 2491 0200 0000 0000
I have no idea what most of that is supposed to do, but that 0x2472 around midway through is what seems to be pointing at the animation data, which is apparently 0x7224 bytes away. I can't pick out exactly where the pointer table starts (I'm almost certain that 0x647270 at the start isn't part of it.), or if it's supposed to be pointing directly to animation header or something just before it, but jumping 0x7224 bytes forward from 0x1293F800 puts you 0x0C bytes before the animation header, so I can't imagine that could be referencing anything else. In both cases, the animation data simply seems to start where ever what came before it ended, which isn't on the sector boundary in either case I've checked.
EDIT: Just wanted to apologize because it finally hit me that I'm not being very helpfully precise here. Honestly, right now I'm mostly trying to pick stuff out that seems significant so that those more talented than me can have a closer look. The sheer lack of precision in my research (and the fact that I'm simply assuming the pointers will all line up without figuring out exactly how to make it work) at this point means I probably wouldn't have posted about this if it weren't for the fact that my experimental results (the video) seem to indicate that there might be something to it. If nothing else, hopefully what I've got so far will give someone else a decent idea of where to start looking.
-
Naw, it's about as precise as can be for an initial investigation. What really matters is that we know which sector/file to look at in general, which you've uncovered handily. This will make further investigation go much more smoothly!
I'm really excited by all this. I'm strapped for time at the moment, but I think I'll take a look at this before even testing the animation format just so we can get a feel for where the attack animations are stored. This should provide us capability to use enemy models perfectly in the near future.
-
For the record (Why didn't I bring this up earlier? I guess I got distracted when I started chasing pointers.), the attack animations themselves are actually fairly easy to find. If you sic a hex search on the hex values 61 74 30 00 (In the text at the right of most hex editors I've seen, this displays as "at0.", minus the quotes, naturally.), the first result should be just before the header for Serge's animations, the second result is just before Kid's, and I would assume it runs in standard character data order from there, given that I was able to use it to find Fargo's animations without having to try every character before him. In both Serge and Kid's case, searching in reverse from there for 64 72 70 ("drp") found the pointer table which contained the pointers to the animation (which made locating Kid's much less painful than it should have been), but I haven't tried this with anyone else, so I can't verify that it always works.
I think tech animations may have a similar identifier, 74 65 63 68 ("tech"), but I haven't experimented with this enough to be sure.
-
Hmm, I suppose this is technically a double-post. Sorry about that.
Anyways, I had some spare time between classes today, so I decided to see what I could do with Dario. Basically, I cleared out Guile's model, moved Kid's backwards, and then put Dario's model in the space where Serge's was and repointed everything in the table of contents. FaustWolf, this is what you did (or is at least similar) to make your DarioTest video, right? I took it a step farther after that and overwrote the the mass of data containing Serge's attack animations (Among other things. I think the attack sounds may be in there, too...) with the equivalent mass for Dario. The results are here (http://www.youtube.com/watch?v=DZ5h6aN4LLo). I think I did something nasty to the system graphics and the background, but if you ignore that, we have an almost-playable Dario. This would confirm that the stuff I tripped over earlier does indeed contain the attack animations. Also, in case anyone's interested, the OUTs that contain the attacks seem to start at 3760.out, (This file contains Serge's attack animations, among other things.) and proceed in the same order as the battle models from there. This is how I found Dario's data.
-
No issue with double-posting when they're constructive! Especially in this forum. Feel free to drop in any thread you wish, and thanks. Dario there is sort of awesome...
-
Sorry I didn't see this before, Hyper, and thanks ZeaLitY for bumping it. I must have accidently purged this from my unviewed threads list.
Man, this is awesome! You've confirmed our theory and even given us an .OUT number to start with. Lots of results will flow from this. Superb work!!
(http://img115.imageshack.us/img115/6721/image1ng3.jpg)
-
Slightly better video (http://www.youtube.com/watch?v=3eTT9hPW1-8) up. This one was recording on my desktop, so there's sound and it's faster. I also threw in Dario's element casting animation, which I managed to forget in the last one. Since I recorded that one, I've fixed the problem with the background and menus being destroyed. Turns out that I slipped up when I was putting together Dario's texture header. Whoops.
Naturally, nothing's ever TOO easy. Using Dario with anyone else in the party can have some...interesting results: (Click for larger image.)
(http://img144.imageshack.us/img144/6540/awesomecapesb2.th.jpg) (http://img144.imageshack.us/my.php?image=awesomecapesb2.jpg)
Well, heck, I'D wear a cape with Kid's face on it! :D
-
Hehe, cool cape anyway.
-
Oh, shit. I wonder if Dario's dual texture is at fault; maybe there isn't enough space allocated in VRAM for Dario's texture and the textures of other party members, causing overlap.
However, the ability of Sprigg to doppelgang into Dario without a hitch goes against that logic, so hopefully we'll get this figured out.
Once I do some things to help out the Crimson Echoes team, I'll take a look at this stuff with you Hyper.
-
I figured it had to be the dual texture taking up too much memory and being overwritten that was causing it. Maybe doppelgang loads the texture differently somehow? I don't know how much sense THAT would make, but it's all I can come up with.
-
What we'll do, then, is make VRAM dumps when Dario is manually inserted through repointering and when he's in the party due to doppelganging. That will shed some serious light on the situation.
-
Unfortunately, I'm not much good for VRAM dumps at this point. I've been doing all my modifications in 2048 byte/sector isos, and I can't get anything but pSX to run them. ePSXe and PCSX (as well as the debugger based on it) seem to choke and die even if I mount the iso on a virtual drive. They run the 2352 byte/sector dump I made just fine, but I haven't been tinkering with that one.
Naturally, if there's a way to make pSX cough up the VRAM, I've never managed to find it. I hate to be unhelpful, but there's not a lot I can do right now. I'll keep fiddling with it and see if I can make anything happen, but I can't do much more than hex edit and run the game for the moment.
-
Yup yup, you can cough up VRAM dumps in pSX! Just do the following:
*Debug > Monitor > r3000
*Debug > Break (to freeze the game's processes at the point you want stuff to stop moving in memory)
*GPU > Save VRAM
Voila!
There's a program called PVV3 made by my favorite German, Creaothceann over at Romhacking.net, that's the downright best PSX VRAM viewing utility out there. I think it's still in some kind of non-public beta phase, so I'll have to dig up the download link Creaothceann gave me in some long-forgotten Romhacking.net thread sometime. For now, if you can post zipped VRAM files, I'd be more than happy to take a look at them.
-
Or you can hack a savestate directly.
Just rename the save file with a .zip extension and unzip it.
You don't have to re-compress since the emulators support un-compressed format.
About the offsets:
pcsx ram 9020 vram 2996c0
epsxe ram 1ba vram 2733df
-
utunnels, I actually tried that, but it seems that pSX's savestates don't decompress nicely like ePSXe's and PCSX's do. It would be the frustrating emulator that works for me, wouldn't it? :D
Faust, I've attached a zip with a pair of VRAM dumps in it, one with Dario alone and one with Kid in the party. I don't have a save far enough along to even have Sprigg at this point, so I'm going to go hunting around online and see what I can dig up. What I've got right now should at least verify or discredit the theory that Dario's texture is taking up space that's normally used for the second party member's.
Come to think of it, is there a trick to making Dario doppelgang-able? He doesn't show up on any of the lists I've looked at, although it's possible they're incomplete.
-
It seems Dario model uses more than just a
256x256 texture. His cape and sword takes another texture, and I believe each normal PC uses only a 256x256 texture area and their weapons are counted separately
So when another PC's texture is loaded, it will override Dario's.
:picardno
Sorry, it is 128*256 _ _
-
Thanks Hyper. Man, this is like the overlap we have in Chrono Trigger when we try to insert a Size 1 character sprite into the party.
It'll be interesting to see how Doppelganged Dario is handled though. I'll see if I can make a VRAM dump of that today.
-
Well, son of a --
Get a load of these everybody. Four tests, with the following specs:
Test 1: Dario doppelganged, third party slot
(http://img7.imageshack.us/img7/3002/test1dariothirdjp4.th.png) (http://img7.imageshack.us/my.php?image=test1dariothirdjp4.png)
Test 2: Dario doppelganged, second party slot
(http://img7.imageshack.us/img7/5851/test2dariosecondcf1.th.png) (http://img7.imageshack.us/my.php?image=test2dariosecondcf1.png)
Test 3: Two texture enemy reference
(http://img7.imageshack.us/img7/1551/test3timedevourerrefereqv1.th.png) (http://img7.imageshack.us/my.php?image=test3timedevourerrefereqv1.png)
Test 4: Two texture enemy reference with Dario doppelganged
(http://img7.imageshack.us/img7/5820/test4timedevourerrefereef7.th.png) (http://img7.imageshack.us/my.php?image=test4timedevourerrefereef7.png)
Looks like there's room for up to five full 128x256 textures in VRAM. The first three slots are allocated to the player's party, the last two to the enemy party. When Dario is placed in the third party slot, his texture erases the enemy's texture. When he's placed elsewhere in the party, his cape annihilates a team member's texture.
I think there's hope here -- as I illustrate in the fourth test pic, there may be a sixth texture slot that can be written to in battle, with some tweaking to whatever code tells the game engine where to read and write in VRAM. In Test 3 I didn't show it, but the Dream Devourer's texture overwrote some overworld stuff in VRAM. If the sixth slot is also overworld or otherwise non-battle stuff, it should be possible to move the read/write position for enemy textures over one slot, making four for the party and two for the enemy. The upshot is, it would probably be impossible to have more than one dual texture character in the player's party at any time once the game code were altered. For playable Dario, this type of alteration to the game code will be necessary unless it's just Dario on a solo mission (or possibly with one other character, haven't tested that yet).
Here's the actual VRAM dumps (http://www.sendspace.com/file/ly4u69) if anyone wants to examine them firsthand.
-
Is Dario doppelgangable? Or you just hacked the skill?
I think there's hope here -- as I illustrate in the fourth test pic, there may be a sixth texture slot that can be written to in battle, with some tweaking to whatever code tells the game engine where to read and write in VRAM. In Test 3 I didn't show it, but the Dream Devourer's texture overwrote some overworld stuff in VRAM. If the sixth slot is also overworld or otherwise non-battle stuff, it should be possible to move the read/write position for enemy textures over one slot, making four for the party and two for the enemy. The upshot is, it would probably be impossible to have more than one dual texture character in the player's party at any time once the game code were altered. For playable Dario, this type of alteration to the game code will be necessary unless it's just Dario on a solo mission (or possibly with one other character, haven't tested that yet).
If there's any hope, the 6th slot is in the same line as the others (y<256).
The areas below that are used for battle stuff:
Left most: battle field texture
middle: the swirling effect buffer when entering the battle field
right most: font/dialogue/hit gfx, althought not all of them are used, but it is hard to hack out a usable area.
-
Yeah, you can only doppel Dario with GameShark codes.
-
Are those textures used by Doppelgang stored in memory?
-
The textures used in the actual doppelgang animation are apparently stored in the second row of VRAM, along with the other spell effects. Dario's need for two textures there is what screws up the magic circle under Sprigg when she's doppelganging I think.
-
That makes sense.
But before Sprigg does Doppelgang, the texture used must have not been in VRAM?
So the texutre will be uploaded in VRAM and replace Sprigg's original texture?
-
Hey, hey. Can we get a proper Dark Serge model in here now? And FATE? I've been waiting for this forever.
Awesome job so far. Seriously, history is being written right here.
-
There's still some horrible problems with Dark Serge's model. I imagine we'll figure it out eventually, but unfortunately it's still a longterm goal. For some reason the game screams bloody murder when Dark Serge is equipped with any weapon (though I'm not sure about fists, I think that might be possible actually, but it would look odd).
You're correct utunnels, the game actually overwrites other textures once Dario is doppelganged. In the pics I posted above, enemy Harle, Serge, and the Time Devourer were fine, then after the doppelgang finished, Dario's second texture overwrote them.
-
Your pictures are interesting, they shows that the eye-blinking animation is applied directly to the texture instead of changing UV values(see Doppelganged Dario's cape, there's an eye on it).
I'm just curious: actually Sprigg can change to a lot of monsters, so it is unlikely the textures and models are stored in memory. So there will be a in-game disc reading? Never thought a game loads gfx in battle.
-
Confirmed: Dark Serge works just fine if you give him gloves instead of a real weapon. Fear the power of my imaginary scythe, you fiends!
(http://img442.imageshack.us/img442/8599/darksergeky9.th.jpg) (http://img442.imageshack.us/my.php?image=darksergeky9.jpg)
-
Oh, sweet, you've even got his animations working correctly. Hmmm, Hyper, could you actually try giving him another weapon and see if he behaves properly? Maybe it was something about his animations not being applied before, though I'm not sure why that would cause the red screen of death.
-
The trick to the attack animations was figuring out where they are. Now that we know that, getting them to work properly is really just moving a bit more data and fixing one more pointer.
Unfortunately, the proper animations being applied doesn't fix Dark Serge. It's still red-screening when I try to give him his weapon.
-
Confirmed: Dark Serge works just fine if you give him gloves instead of a real weapon. Fear the power of my imaginary scythe, you fiends!
(http://img442.imageshack.us/img442/8599/darksergeky9.th.jpg) (http://img442.imageshack.us/my.php?image=darksergeky9.jpg)
Ahah, imaginary scythe. That's rich :D
Anyway, love the progress. Maybe I'll be able to help later after I study some programming. For now, keep it up :)
-
Thanks for checking it out Hyper. What I need to do next is identify which .OUT files go with which models. They just follow the same order as the models themselves, right? I can whip that up pretty quickly in that case.
-
I've only actually tested that for Serge, Dario, and Dark Serge, but I was able to predict where Dario and Dark Serge's files would be by doing some fast math based on the order of the models ( (Target's model file - Serge's model file) / 3 + 3760) so I would assume the pattern holds for pretty much everyone, including the dummies. I can do some more checking on that to be double sure if you want.
EDIT: Ah, I'm gonna have to be away from my computer for a few hours, so I can do bit more checking to make sure the pattern holds, but it'll have to be later. Sorry.
EDIT 2: Alright, sorry that took so long. I did some more random testing and the correct .out was always where I predicted it would be. I think it's safe to say that the attack drps (what I'm calling those files for the moment, given that at least part of the data in them seems to be related to attacks and they all start with "drp," same as the first file of each element/tech) follow the same order as the models.
Here's something weird, though. You know how some of the model files are just "It's CD Make Dummy!"? The attack files that correspond to those aren't dummies themselves. I can't figure out what that means.
-
Hey, the attachments are gone. Anyone still have the ripped models we had of the Black Dragon, White Dragon, and Salamander Summon?
-
Hey, the attachments are gone. Anyone still have the ripped models we had of the Black Dragon, White Dragon, and Salamander Summon?
Not sure how well organized it is, but Zeality backed up some of the attachments here
http://chronofan.com/Black/Other/Attachments/Kajar%20Laboratories.7z
-
A lot of interesting stuff, and I found some good models, but I'm still missing the sky and black dragon, and really need em'. Does someone still have them?
-
Here you go.
-
What application do you use to open those files?
-
Use my model import script (http://chronofan.com/Black/Other/import_ccmodel_v0.4.0.zip) (version 0.4.0) in Blender. If that's troublesome then I can upload the .blend files, but not until at least this evening.
-
I can't really get it to work, so I'll wait for the Blender files
-
Not sure if I saved them right, but try these, Dark Serge.
-
Darn. I've re-attached Luminaire's script to the first post for better visibility. Thanks for the models Hyper. I'm going to return to this in May and help figure out the animation format. Then we can hopefully compile an archive of all the Chrono Cross models.
-
Not sure if I saved them right, but try these, Dark Serge.
Seems to be working, at least I get the shape in pink in Blender.
I'm not really a Blender wiz, so I wanna ask, how do I take pictures of the model like those that were posted here?
-
I think I've just about got the animation format whipped. (Actually animating...not so much. :)) The format doesn't actually seem very complicated, but it doesn't look like anyone's posted a full explanation yet, so I'll do that tomorrow. Sorry, I'd do it tonight, but it's late and I'm likely to mess up if I'm this tired. For now I'll leave you with a little demo I spent the last couple of days working on. It was supposed to be something silly and simple to see how well I really understood the animation format...and it ended up eating three days whole and not looking half as good as I'd have liked. Well, at least it's something. Enjoy. (http://www.youtube.com/watch?v=wQijntNFD0g)
-
You, sir, get the kickass award for the day. And it was a pretty kickass day overall, so that's saying lots. Definitely post your understanding of the animation format after getting some rest. I wasn't going to get around to it till sometime in May.
(http://img504.imageshack.us/img504/3012/dryst001af1.jpg)
(http://img257.imageshack.us/img257/4223/donquixotexk6.gif)
-
Alrighty, then. After a good night's sleep and with my blood/caffeine ratio well on its way to zero, I'm ready to try writing up what I know about the animation format. Some of this has already been mentioned in this thread, but I'll go ahead and write it up again (or use copy and paste, hehe) so it's all in one place. Let me know if any of this is unclear, contradictory, needs further explaining, etc. Here goes.
Animation format:
Number of frames (4 bytes)
Pretty self-explanatory
Animated articulation identifier (? bytes)
Just a placeholder name since I don't know what to call these. The length of this part seems to be dependent on the model, possibly the first multiple of 4 that allows it to contain two bits for every articulation in the model. (I'll look into that. I didn't notice that it was different for Serge and Kid until just now.) Serge has 8 bytes here, Kid has 0xC. This set of bytes tells the game which of the character's articulations will be animated by commands in frames after the first. I'll use Serge's idle animation (which has 5665600015150000 for this segment) as an example of how to read them.
First read the bytes in little endian order, so they become 0000151500606556. Then convert them to binary, which makes them
0000000000000000000101010001010100000000011000000110010101010110.
This is much easier to work with if you reverse the order and put the least significant bit on the left, making it
0110101010100110000001100000000010101000101010000000000000000000.
From here, I generally split them into two rows, with even-numbered bits on top and odd-numbered bits on bottom. The set we're working with looks like this:
ABCDEFGHIJKLMNOPQRSTUVW
01111101000100001110111000000000
10000010001000000000000000000000
The letters I've placed above the binary there represent which of Serge's articulations each column applies to. A 1 in the top row indicates that that articulation will be given rotation commands in later frames of the animation, while a 1 in the bottom row indicates that it will be given translation commands. In other words, articulations B, C, D, E, F, H, L, Q, R, S, U, V, and W will be rotated in the animation, and A, G, and K will be translated.
Frame pointers (4 bytes each)
The pointers are relative to the start of the animation header. Not much else to be said about them.
Frames of animation (Variable length. See below.)
Would you believe this is the easy part? The commands given to articulations in the animation are basically identical to the way that the model's "skeleton" was set up in Section 2. Each command will be 6 bytes long, 2 bytes for each axis. The order of the axes is probably XYZ, as it was in section 2, but I have a hard time thinking in 3D, so anyone's welcome to double check that. The values the command can take range between 0xF000 and 0xFFF, or -4096 to 4095. In the case of rotations, 4096 means 360 degrees.
First frame of animation ( (0xC * # of articulations in the model) bytes)
The first frame of the animation gives two commands to each articulation of the model, presumably in the order that the articulations were defined in Section 2 of the model. Each articulation has 0xC bytes of commands given to it here - 6 bytes of rotation commands followed by 6 bytes of translation commands. The rotations and translations are relative to the model's "default" position as it was set in Section 2.
Other frames of animation ( (6 * # of 1s in the binary of the animated articulation identifier) bytes each)
For each frame after the first, the animation contains only the commands that were defined in the animated articulation identifier, starting with articulation A's rotation, then its translation, then B's rotation, then its translation, etc. For the example of Serge's idle animation given above, the first command in each frame in this section will be the translation command for articulation A, the second command will be the rotation for articulation B, the third command will be the rotation for articulation C, and so on. Note that each command is still relative to the positioning of the articulation in the model's default position (how it was set in Section 2). They are NOT relative to the position of the model in the first frame of the animation or the previous frame of the animation.
Assorted notes
The animations in game don't ever seem to give an articulation both rotations and translations in a given animation. In addition, it seems that any articulation that was translated or rotated at all in the first frame of an animation is always marked in the animated articulation identifier, and therefore always appears in frames of animation after the first. Both of these appear to be quirks of either convention or whatever program Square was using to animate the models. The game's engine doesn't seem to have a problem with articulations receiving both rotation and translation commands, and it's very possible to set an articulation's position in the first frame of animation and lock it there for the duration of the animation by not marking it in the animated articulation identifier. I used the second trick pretty frequently in my demo video.
EDIT: I accidentally gave my explanation of the articulation identifier as though Serge's was 0xC bytes long, when it's actually 8. Way too many zeroes in there. Corrected.
-
Great Scott, that's amazing! You're a hero Hyper. Now I can get straight to putting this in the Chrono Cross File Structure wiki later.
-
Hahah awesome vid dude.
+9000
-
Hahah awesome vid dude.
*bow* Glad you enjoyed it!
Alright, here's something (http://www.youtube.com/watch?v=M40UjCmsJFw) just a tad more practical than (if, perhaps, not as much fun as) my last video. I decided to try moving a couple of animations from Serge over to Kid. Aside from copying the data, this required inserting additional commands into the first frame so that the commands from Serge would be applied to the proper articulations on Kid's model. (For example, Kid's hair, including the braid, has nine articulations which have no corresponding part on Serge's model. 0xC bytes of extra commands for each articulation had to be inserted at the correct spot in the first frame to prevent these articulations from getting commands intended for the arms.) I also had to modify the animated articulation identifier (which needs a name that's easier to type, dang it!) so that the commands in later frames would apply to the proper parts of Kid's model. This generally meant sticking extra zeroes in the binary anywhere I had to put extra commands in the first frame.
This experiment falls fully under the heading of "stuff I do because I want to see if I can do it," but I feel like it's a decent demonstration of the sort of stuff we can do with our current knowledge of the animation format anyways.
-
OMG, Hyper, what you've got to try doing next is apply Enemy Lynx's or Dark Serge's standing and weapon animations to Guile's model. That would be a huge addition to the Magus/Magil patch. You are truly the animation mastah!
-
I'll certainly give it a shot!
-
The Compendium has a "Magus Unmasked" patch you can apply to your ISO on the Fan Projects page, though don't worry about it if it's incompatible with the format of your game image. It shouldn't really matter for testing because the weapon models seem to be practically generic sticks for purposes of animating. If you can get Guile to swing his staff like Lynx does his scythe, that should transfer over perfectly to a scythe-armed Guile.
-
I liked how Kid held the dagger in that video , it was cool xD
-
Hahah awesome vid dude.
*bow* Glad you enjoyed it!
Alright, here's something (http://www.youtube.com/watch?v=M40UjCmsJFw) just a tad more practical than (if, perhaps, not as much fun as) my last video. I decided to try moving a couple of animations from Serge over to Kid. Aside from copying the data, this required inserting additional commands into the first frame so that the commands from Serge would be applied to the proper articulations on Kid's model. (For example, Kid's hair, including the braid, has nine articulations which have no corresponding part on Serge's model. 0xC bytes of extra commands for each articulation had to be inserted at the correct spot in the first frame to prevent these articulations from getting commands intended for the arms.) I also had to modify the animated articulation identifier (which needs a name that's easier to type, dang it!) so that the commands in later frames would apply to the proper parts of Kid's model. This generally meant sticking extra zeroes in the binary anywhere I had to put extra commands in the first frame.
This experiment falls fully under the heading of "stuff I do because I want to see if I can do it," but I feel like it's a decent demonstration of the sort of stuff we can do with our current knowledge of the animation format anyways.
You're my hero man, seriously. This stuff is so awesome. I can't wait what more the future's gonna bring.
-
HyperGeek was working on getting Magil/Magus some real scythe animations last he uploaded a video on Youtube. Which is extremely awesome -- it would necessitate an update to the "Magus Unmasked" patch when he finishes with that.
-
Sorry progress on that has been scarce recently. With the end of the semester coming up, my professors have been piling on a lot more than they did previously.
I'm gonna try to get some decent work done this afternoon. So far I have the idle, ready to attack, and attack animations done. I need to clean those up, but are there any other animations I should move while I'm at it?
-
Yeah, we're all sidetracked with Finals approaching, no worries. It wouldn't even be effective to release a "Magus Unmasked" update until late June or July, otherwise it would just drown in Crimson Echoes publicity. This way we can make it look like there's just no end to Compendium projects.
The only other animation I might suggest changing is the spell-casting animation, but I think it looks okay the way it was originally too; your call there, I guess.
-
*watches hyper's video*
Wow ! Magus looks really good with lynxs animations .
-
Have we broken open section 3 of the models yet? It's not in the wiki (other than the fact that it affects shading and model positioning), and a quick search over the forums didn't turn up anything useful, so I did some poking around in there over the last couple of days. I think I've managed to figure out a fair bit of this section from examining Serge, Kid, and Guile's models. Here's what I've got. (If we DO already have this and I just missed it, let me know so I can delete this post. It's kinda long, probably due to my tendency to ramble.)
Section 3 is 0x160 bytes long, no matter how complex the model is. It seems to have three distinct segments of constant lengths, so it doesn't have any sort of header.
The first 0x100 bytes of it define points around the model. Each point is made up of 8 byte long chunks which look something like this:
XX XX YY YY ZZ ZZ AA AA
The X's, Y's, and Z's define a coordinate in 3D space like we've already seen in section 2 (as well as pretty much the same thing in section 4). As I've said before, I have problems thinking in 3D, so I may have the axes out of order. (I'm guessing it's the same order as section 2, but I could be wrong.) The A's contain the ID of whatever articulation the coordinate is relative to.
A few of these are in roughly the same position on all the models I've looked at. (Remember that I'm getting this from Serge, Kid, and Guile. These are, notably, humanoid models. Non-humanoids like Poshul or Pip might differ.) Here are the indexes of the coordinates, which are useful in the third segment. Multiply them by 8 to get the actual offsets into section 3:
00 - Top of head
01 - Front of face
02 - Neck
03 - Right shoulder
04 - Left shoulder
05 - Right elbow
06 - Left elbow
07 - Right hand
08 - Left hand
09 - Waist
0A - Right knee
0B - Left knee
0C - Right ankle
0D - Left ankle
0x0E defines the height the camera sits at when it rotates around the character during their idle animation. Only the vertical component of this one seems to matter.
0x0F defines the distance between the character and whatever enemy they happen to be attacking at the time. Only one of the horizontal axes seems to matter here, and only the magnitude of the distance, not its direction, so you can't do something funny like have the character go charging past their opponent in preparation for an attack. Um, not that that was the first thing I tried or anything. :)
0x10 is located on the upper center of the model's torso.
0x11 is relative to the right hand on Serge, Kid, and Guile, but seems to sit a distance off from it, and I can't tell if it's roughly the same distance or direction. This seems so out of place that part of me wants to believe that this defines a distance like 0x0E and 0x0F, but I haven't been able to determine what it affects, if anything.
The indexes from here are dependent on the model and seem a tad chaotic. On Serge's model, 0x12 sits directly on the weapon articulation. Guile has an entry exactly like this, but it's the very last one in the section at index 0x1F. Kid has no corresponding entry, as she has no weapon articulation. (Or at least, none that I could find. She's got an articulation directly after the right hand where the weapon is on Serge, Guile, and Lynx, but it doesn't seem to actually affect anything.) There's a lot of entries made up entirely of 0s here, with some other entries tossed in towards the end. Only the one Guile has at 0x1F has any significance that I've figured out yet.
I'm going to jump the second segment here and come back to it in a minute. The third segment is fairly short, anyways.
The third segment begins somewhere around 0x120 bytes in. I can't make this segment's length make sense no matter how much I look at it, so I might be missing something, but what I've got seems to make sense. This segment is made of 8 byte long coordinates pretty much exactly like the ones in the first segment, in the form XXXX YYYY ZZZZ AAAA with the exception that the AA AA bytes are now indexes into the list of coordinates defined by segment one. For example, if one coordinate here was 0000 0000 0000 0700 then it would sit directly on the right hand coordinate.
The only part of the third segment that I've managed to assign any importance to is the coordinate that begins 0x1A bytes from the end of section 3. The game attaches the character's weapon to the coordinate defined here. By changing what coordinate in segment 1 this points to, we could, say, make Kid a lefty (http://img413.imageshack.us/img413/4892/leftykid.jpg).
Alright, back to the second segment, which defines the model's shading. Segment 2 is 0x20 bytes long, divided into 0x4 byte chunks. There are 8 chunks, but the amount that actually do anything is dependent on the model. For each that's actually used, it controls the shading to a specific part of the model. For example, Serge only uses two of them, one of which affects the area of his shirt below the belt, and one of which affects everything else. Kid is similar, having one chunk for her skirt and one chunk for the rest of the model.
Each chunk is of the form
RR GG BB EF
where RR, GG, and BB define how red, green, and blue, the model should be. The neutral value for these is 0x80. Higher values tint the model more of that color, lower values tint the model less of that color.
E and F are the fun parts. It's one byte, but the 4 highest order bits and the 4 lowest order bits (in other words, the first digit and second digit) control different things.
E controls what texture (if any) gets drawn over the model's normal one. Here's what the individual values do: (A lot of these look the same to me. There may be subtle variations between some of the "identical" ones, but I didn't see them.)
0 - Normal
1 - Normal
2 - Highly reflective (http://img134.imageshack.us/img134/1864/shinyserge.jpg)
3 - Highly reflective
4 - Reflective (http://img134.imageshack.us/img134/3087/partiallyshinyserge.jpg)
5 - Reflective
6 - Reflective
7 - Reflective
8 - Normal
9 - Normal
A - Weird texture application (http://img230.imageshack.us/img230/3311/weirdserge.jpg) (Looks like this could be Serge's normal texture, just applied in a weird way.)
B - Weird texture application
C - Garbage texture (http://img230.imageshack.us/img230/2360/garbageserge.jpg) (This one isn't static, it changes every frame. If I had to guess, I'd say it's supposed to point to a texture loaded by an attack or tech, but which is simply garbage normally.)
D - Garbage texture
E - Garbage texture
F - Garbage texture
F controls the model's transparency and a related effect or two. Here comes the list:
0 - Solid
1 - Invisible (http://img246.imageshack.us/img246/2814/invisibleserge.jpg)
2 - Transparent (http://img246.imageshack.us/img246/6236/transparentserge.jpg)
3 - Invisible
4 - Solid
5 - Invisible
6 - Transparent and bright (http://img228.imageshack.us/img228/1638/brightserge.jpg)
7 - Invisible
8 - Solid
9 - Invisible
A - Transparent and inverted (http://img228.imageshack.us/img228/1978/antiserge.jpg)
B - Invisible
C - Solid
D - Invisible
E - Transparent and very faint (http://img222.imageshack.us/img222/6969/faintserge.jpg)
F - Invisible
Combining these can be interesting. For example, here's Serge made of glass (http://img222.imageshack.us/img222/789/glassserge2.jpg).
And wow was THAT longer than I anticipated. Let me know if I'm being redundant by posting this or if anything needs clarification.
-
Oh, baby, that is awesome Hyper. No, we didn't know very much about Section 3 at all but we do now!
We can do some really cool stuff with ghost models and maybe even liquid metal enemies and the like now.
-
nice job...
...and what video are they speaking of? I wanna see it.
-
IAmSerge, you can take a look at all of Hyper's experiments here (http://www.youtube.com/user/HyperGeek7).
-
IAmSerge, you can take a look at all of Hyper's experiments here (http://www.youtube.com/user/HyperGeek7).
Is there anyone who can explain some animation related stuff? It's clear that HyperGeek knows a lot, but I don't know a way to ask him.
-
https://www.chronocompendium.com/Term/Mdl.html
https://www.chronocompendium.com/Term/Anim.html
The informations are already on the wiki, though it is a bit hard to use without examples.
-
Well, I thought if someone did things like in the video, then someone know about .cpts and other things inside drp (animations sequence sets) — .0010 and .001A type files.
https://www.youtube.com/watch?v=wQijntNFD0g
-
Now it is possible to rip animations from the game (http://cc.ffsky.cn/image/gif/Kid_2206_0001_0446.gif) with some blender script mentioned in this topic, though I haven't been able to create usable bone animations. But editing the animations is another thing, without a working tool it is not a pleasant job to do.
(http://cc.ffsky.cn/image/gif/sergelaughter.gif)
Guess the spam bot blew this topic out of water.
-
But editing the animations is another thing, without a working tool it is not a pleasant job to do.
Well, you know, to create a working tool you have to understand a format.
There are operators and parameters in .001A. I am trying to disassemble it, but haven't done much except some cute camera actions.
Also, .001A files is primarily used for the effects when attack TOUCH the enemy.
For example, engine will read file only one time for the basic attack, but 3 times for Fireball element, because it touches enemy 3 times.
-
(http://i.imgur.com/mM2y03e.png)
Ha, sometimes they did the animations the brutal way.
I never knew the flag was a mesh sprite.
-
Hi, just wanted to post some of the things I was toying with with the tools from this thread. I wanted to talk more about the models but not sure if I should make a new thread.
Good news is, the animations work pretty well across models.
http://www.dailymotion.com/video/x5fhc5n_cc-2_videogames
http://www.dailymotion.com/video/x5fhh0e
Me messing around. I just sort of littered them accross a room.
-
Sweet stuff lockgar! Feel absolutely free to make more threads to address specific questions about the model format.
-
I apologize if this it the wrong topic to post in but its about using Garai with the Doppelganger technique.
I know that Garai has two textures because he's a boss which prevents him to being used glitch free. I know Utunnels had fixed Dario's texture problem by converting the two into a single texture. After going through the files I have found that Untunnels had also made single texture for Garai too.
Does anyone know what needs to be done to apply the single texture to Garai and what is requred to plug that into the CCenemy edit just like Dario?
-
i'd also like that! Also "fix" his defending animation!
Can't believe it has been almost 1 year.
:picardno
A small gif animation made by rendering 23 frames (supposed to be Garai's idle animation, but it looks a bit different, guess I made some mistakes).
----
Edit*
Garai's dodge animation.
----
Edit again*
Garai's defend(?) animation.
cruel torture utunnels. to not add this to ccenemyedit...