Chrono Compendium

Kajar Laboratories - Fan Works and Submissions => Chrono Cross Modification => Topic started by: FaustWolf on October 21, 2007, 08:57:47 pm

Title: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on October 21, 2007, 08:57:47 pm
In light of the day's wondrous turn of events, I'm starting a new thread dedicated to our findings regarding the files that the Ramsus/Yazoo dumper has produced. I can't very well recap everything that happened, so if you're reading this for the first time, check out the posts that start here: http://www.chronocompendium.com/Forums/index.php/topic,4729.msg83034.html#msg83034

This thread shall be dedicated to the basic findings that flow out of Ramsus' wonderful work. I've attached a number of files to this thread:

1st: The Ramsus/Yazoo dumper, which is what Zeality, Luminaire85 and I have used successfully to dump ALL of Cross' files. It's a tool originally created by Yazoo of Terminus Traductions that Ramsus modified so that it works more efficiently (and at all, in my case). Beware though, Ramsus will be making continual improvements to this program to make it even better!

2nd: More tools I received from Sephiroth 1311 in Italy. I'm not sure what's in here just yet, but there may be new tools we can use. Remember though, if there are any new tools in here, they haven't been optimized by Ramsus.

3rd: The rest of Yazoo's tools, written in C++ and compiled by Ramsus. The beauty of this is people don't have to compile themselves to check everything out since Ramsus has done that work for us. Inside you'll find all sorts of goodies including decompression utilities. To use them, run from the command line or (in my case, since I suck at command lines) simply drag the pertinent file over the .exe.

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on October 21, 2007, 09:05:27 pm
As far as findings are concerned, I'd like to post this:

After doing some hex investigation, I can say exactly what happened with the ripped .STRs, and it bodes well for the rest of the files the Ramsus/Yazoo dumper created.

The .OUT files are just raw data the dumper snipped from the CD image - no extra headers added or anything. At least, this is the case with the video files (found in the "V" folder after dumping). As for why the PSX media players can't seem to play the files, your guess is as good as mine. I do know that PSXMediaPlayer (the proggie I used to rip .STRs) injects its own file header and some other data into the .STRs it rips from Cross, and perhaps the media players aren't recognizing the .STRs for lack of that header. But that doesn't explain how PSXMediaPlayer and other players are able to read the .STRs in the first place.

At least I can say confidently that the .OUTs are exactly what's on the CD. This will make datamapping very easy, as it's just a matter of finding each OUT file's hex signature in the iso. Maybe we'll be able to tell from the way the files are arranged what's model data, what's pre-rendered background data, etc.

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on October 21, 2007, 09:09:29 pm
And if anyone is totally lost regarding anything that's happened with Cross exploration over the past few days, I can take questions over PM.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Ramsus on October 21, 2007, 09:16:14 pm
This program from the More Tools package seems to do a lot more, but it's interactive and the options are all in French, so you'll have to play with it. I'm not sure about the usage at all...

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Ramsus on October 21, 2007, 09:18:25 pm
And here's the other program from that package, called ExtractVid.exe


[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: ZeaLitY on October 21, 2007, 09:26:16 pm
Might those be an incarnation of the Chrono Cross Translation Tools (not to be confused with Chrono Cross Tools by Yazoo)? The CCTT have script-extracting BATs and one to extract videos.

Update: I tried playing them with PSXTulz, and they worked fine. The comments on Zophar.net about STR players suggest that some players are simply incompatible with certain STRs.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on October 21, 2007, 09:41:14 pm
Looks like "Yazoo's.rar" in the More Tools attachment is simply what Ramsus has compiled already.

I've never seen the stuff that's in 01_Programmes_CD1.rar, though. (More Tools attachment, yet again). Once I get some time on my hands, I'll definitely check out those tools Ramsus compiled from this archive. Thanks Ramsus!
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: ZeaLitY on October 21, 2007, 09:45:12 pm
Okay. I'll start the page tonight and move the update to tomorrow. Hopefully you'll have time to stop by tomorrow and check if the page is up to standard and date.

I edited my last post in this thread concerning the video files.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Azure on October 21, 2007, 10:12:37 pm
French?  If you ever need help with french I can do my best.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Ramsus on October 21, 2007, 10:15:48 pm
It's pretty straightforward, but my Korean language codepage settings butchered the accents.

Anyway, here's some descriptions (the parameters/arguments for each command are in parenthesis):

Dump_Init-> Initialisation des dumps      ()
Dump-> Dump de fichiers            (num?os des Rooms ?extraire)
Dump_Sup-> Suppression de fichiers         (num?os des Rooms dump?s)
Iso_Ouvre-> Ouverture de l'iso            ()
Iso_Ferme-> Fermeture de l'iso            ()
Dump_Ptr-> Dump des pointeurs de fichiers   ()
Dump_Entete-> Dump de l'entete de l'iso      ()
Script_Exec-> Execution de script            (nom du fichier)
Rein-> R?nsertion de fichiers         (num?os des Rooms)
Rein_Init-> Initialisation de la r?nsertion()
Rein_Ptr-> R?up des pointeurs   de fichiers   ()
Iso_Mode-> Mode d'ouverture de l'iso      (lecture|?riture)
Tim2Bmp-> Conversion TIM->BMP            (fichier)
Bmp2Tim-> Conversion BMP->TIM            (fichier)
Drp_D-> D?ompression   DRP   (dossier|fichiers)
Drp_C-> Compression   DRP   (dossier|fichiers)
Copie_I-> Copie   de   fichiers   entrants   (fichiers)
Copie_O-> Copie   de   fichiers   sortants   (fichiers)
Coord_Rein-> Dump   de   coordonn?s   graphiques   (dossier|fichier)
Coord_Dump-> R?nsertion   de   coordonn?s   (dossier|fichier)
Cpt_D-> D?ompression   CPT   (dossier|fichiers)
Cpt_C-> Compression   CPT   (dossier|fichiers)
Txt_Dump-> Extraction   de   textes   (dossier|fichier)
Txt_Rein-> R?nsertion   de   textes   (dossier|fichier)
Brut_Dump-> Extraction   de   donnees   brutes   (dossier|fichier)
Brut_Rein-> R?nsertion   de   donnees   brutes   (dossier|fichier)
Rooms_Dump-> Dump   des   Rooms   ()
Rooms_Copie_I-> Copie   entrante   des   Rooms   ()
Rooms_Cpt_D-> Extraction   des   Rooms   ()
Rooms_Lzss_D-> D?ompressions   Lzss   du   script   ()
Rooms_Extr-> Extraction   du   sc?ario   ()
Rooms_Infos-> Chargement   des   infos   des   Rooms   (fichier)
Part_Regroupe-> Regroupement   des   scripts   (fichier)
Part_Partage-> S?aration   des   scripts   (fichier)
Scenar_Dump-> Dump   d'un   texte   de   sc?ario   (dossier|fichier|table)
Scenar_Rein-> R?nsertion   d'un   "sc?ario"   (dossier|fichier|table)
Perso_Regroupe-> Regroupement   des   descriptions   ()
Accent_Regroupe-> Regroupement   des   accents   ()
Repart_Partage-> Partage   par   personnages   (fichier)
Repart_Regroupe-> Regroupement   du   script/persos   (fichier)
Repart_Infos-> Informations   de   r?artition   (fichier)
Rooms_Rescn-> Reinsertion   des   Rooms   ()
Rooms_Lzss_C-> Recompression   Lzss   des   Rooms   ()
Rooms_Cpt_C-> Recompression   Cpt   des   Rooms   ()
Script-> Ex?ution   d'un   script   (script)
Rooms_Copie_O-> Copie   sortante   des   Rooms   ()
Rooms_Rein-> R?nsertion   des   Rooms   ()
Repart_Retours-> Correction   des   retours   de   ligne   (fichier)
Accent_Partage-> R?nsertion   des   accents   ()
Rein_Ptr_M-> Modif   des   pointeurs   de   fichiers   ()
AutoA_Suppr-> Suppression   des   Accents   Auto   ()
AutoA_Ins-> Insertion   des   Accents   Auto   ()
Listing_Genere-> G??ation   des   listing   du   patch   (fichier)
Listing_Persos-> G??ation   des   listing   persos   ()
Lzss_D-> Compression   Lzss   (dossier|fichier)
Lzss_C-> D?ompression   Lzss   (dossier|fichier)
Perso_Partage->
Str_Insert-> Insertion   de   video   (numero   de   room)
Listing_Fichs-> G??ation   des   fichiers   patch   ()
Raw2Bmp-> Conversion   TIM   sans   palette   BMP   (room|fichier|palette|masque)


And don't blame me if they don't line up correctly... I didn't do it by hand.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: ZeaLitY on October 21, 2007, 11:13:46 pm
I guess we could use a translation. Ramsus has looked at these utilities and it seems as if they're better, more complete versions of what Yazoo started. However, I'm having issues getting it to work or finding out if there really is a "Dump everything" thing like Yazoo's disc_main_dump or whatever.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on October 21, 2007, 11:35:23 pm
Question for Zeality, Luminaire85, and whoever else has dumped their Disc 1 by now:

How many files are you getting total? I end up with 5605 files altogether, and that's counting the .tbl file. Does that number seem quite low to anyone else? I mean, we regularly pulled 9000 or so .TIMs with PSicture and TIMViewer. Granted, that's without taking duplicate removal into consideration, but I assumed all duplicates were pulled from different sections of the CD image.

But I dunno; on the other hand, we've got enough data to fill an entire Disc 1 iso ripped the "new" way (meaning it ends up 600 or so MB, and is an exact copy of the physical CD). Weird. Well, in any case, mapping out where the files are on the CD will probably help us figure out what we've got and what we might not have. Thanks for setting that page up Zeality. I'll update it as I find snippets of time over the week.

EDIT: Though it's entirely possible lots of files are locked up into archives of some sort, I suppose. Like, if 5000 of the files the Ramsus/Yazoo dumper produced are .TIMs, then all the models, battle textures, and pre-rendered backgrounds could be compressed into .LZSs or other file containers.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on October 22, 2007, 12:01:08 am
Looks like I get 5618 .out files plus the file.tbl file. The difference comes from the C:\disk1 folder I just found; it has another 14 .out files that all say "It's CDMAKE Dummy !". I seem to recall you mentioning those earlier today.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: ZeaLitY on October 22, 2007, 12:06:13 am
I've got 5618 too.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on October 22, 2007, 12:11:02 am
Ah, the dummy files. I've got 'em again now, so we're all on the same page at 5618 files. Thanks guys!
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Chrono'99 on October 22, 2007, 06:12:14 am
Here's a rough translation of what Ramsus posted. Keep in mind that I don't know much about those technical terms; I just translated literally.

Dump_Init-> Dump initialization      ()
Dump-> File dump            (number of the Rooms to extract)
Dump_Sup-> File deletion         (number of the Rooms dumps)
Iso_Ouvre-> Iso opening            ()
Iso_Ferme-> Iso closing            ()
Dump_Ptr-> File pointer dump   ()
Dump_Entete-> Iso heading dump      ()
Script_Exec-> Script execution            (file name)
Rein-> File re-insertion         (number of the Rooms)
Rein_Init-> Re-insertion initialization()
Rein_Ptr-> File pointer "R?up"   ()
Iso_Mode-> Iso opening mode      (reading|writing)
Tim2Bmp-> Conversion TIM->BMP            (file)
Bmp2Tim-> Conversion BMP->TIM            (file)
Drp_D-> Decompression   DRP   (folder|files)
Drp_C-> Compression   DRP   (folder|files)
Copie_I-> Inputted   files   copy   (fichiers)
Copie_O-> Outputted   files   copy   (fichiers)
Coord_Rein-> Graphic   coordinates   dump   (folder|file)
Coord_Dump-> Coordinates   re-insertion   (folder|file)
Cpt_D-> Decompression   CPT   (folder|file)
Cpt_C-> Compression   CPT   (folder|file)
Txt_Dump-> Text   extraction   (folder|file)
Txt_Rein-> Text   re-insertion   (folder|file)
Brut_Dump-> Raw   data   extraction   (folder|file)
Brut_Rein-> Raw   data   re-insertion   (folder|file)
Rooms_Dump-> Rooms   dump   ()
Rooms_Copie_I-> Rooms   inputted   copy   ()
Rooms_Cpt_D-> Rooms   extraction   ()
Rooms_Lzss_D-> Script   Lzss   decompression   ()
Rooms_Extr-> Scenario   extraction   ()
Rooms_Infos-> Room   infos   loading   (file)
Part_Regroupe-> Scripts   gathering   (file)
Part_Partage-> Scripts   separating   (file)
Scenar_Dump-> Dump   of   a   scenario   text   (folder|file|table)
Scenar_Rein-> Re-insertion   of   a "scenario"   (folder|file|table)
Perso_Regroupe-> Descriptions   gathering   ()
Accent_Regroupe-> Accents   gathering   ()
Repart_Partage-> Separating   by   characters   (file)
Repart_Regroupe-> Script/characters   gathering   (file)
Repart_Infos-> Informations   on   distribution   (file)
Rooms_Rescn-> Rooms    re-insertion   ()
Rooms_Lzss_C-> Lzss   rooms   recompression   ()
Rooms_Cpt_C-> Cpt   rooms   recompression   ()
Script-> Execution   of a   script   (script)
Rooms_Copie_O-> Rooms   outputted   copy   ()
Rooms_Rein-> Rooms   re-insertion   ()
Repart_Retours-> Line   break   correction   (file)
Accent_Partage-> Accents   re-insertion   ()
Rein_Ptr_M-> File   pointers   modification   ()
AutoA_Suppr-> Auto-accents   deletion   ()
AutoA_Ins-> Auto-accents   insertion   ()
Listing_Genere-> Patch   list   generation   (file)
Listing_Persos-> Character   list   generation   ()
Lzss_D-> Lzss   compression   (folder|file)
Lzss_C-> Lzss   decompression   (folder|file)
Perso_Partage->
Str_Insert-> Video   insertion   (room number)
Listing_Fichs-> Patch   files   generation   ()
Raw2Bmp-> TIM   conversion   without   BMP   palette   (room|file|palette|mask)
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Akari on October 22, 2007, 01:35:19 pm
Can some one put here one field file with screenshot of what it looks like in game. I want to find walkmesh for the field.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on October 22, 2007, 02:29:49 pm
Welcome to the Compendium, Akari! Glad to see you here.

When you say "walkmesh" are you referring to character models?

@Chrono'99: That REALLY helps. Thanks a million for the translation.

EDIT: Oh, a walkmesh is actually what the game characters walk over, right? Like in towns and dungeons? So you just need a screenshot of a specific location and the field file for that location then, is that right Akari?

I'm not sure whether we can tell which field file goes with which location yet. Anyone know of a good way to do that? From your experience Akari, do you know if walkmesh data would be included in a savestate or in VRAM?

EDIT: Now that I think of it, we might be able to get field file information from the utility translated by Chrono'99. I'll check it out when I get a chance.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Akari on October 22, 2007, 03:35:39 pm
Welcome to the Compendium, Akari! Glad to see you here.

When you say "walkmesh" are you referring to character models?

@Chrono'99: That REALLY helps. Thanks a million for the translation.

Walkmesh is 3d data on which models move. It's not visible and only use to calculate movement of model. Usually this called trimesh or triangular mesh. Walkmesh is Qhimm'f forum terminology. 3d models drawn togather with 2d background tiles sorted by depth. This create illusion of movement in 3d on 2d backgrounds (you can walk around pillar for example).
Walkmesh is one of the most important thing in field files. And I want to know format or at least try to found it. Cause Engine that I want to create suppose to handle all data... and chrono cross as well.

It can't be in savestate, because savestate is dynamic data holding structure, but walkmesh is static and doesn't need to be saved. It suppose to be in field files or in field group of files. They can be concatenated togather or not (most likely not). Tileset for background can be separated cause it needs to be uploaded in vram instead of ram. Field.dat file usually contains scripts, camera data, walkmesh, encounter data, different kind of triggers data, screen settings and background tiles descriptions. I don't know if it compressed or not (ffvii and xeno - compressed used lzs, but ffix are not compressed at all).
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on October 22, 2007, 09:44:00 pm
@Akari: I'm going to check out whatever field files we have, and hopefully I'll be able to help you out with that.

@Everyone: I'm now going to qualify the statement I made earlier about the Ramsus/Yazoo dumper cutting the data files without injecting any stuff of its own. It appears that with some TIMs, the dumper isn't quite as accurate as we'd like. For example, in Guile's eyeball TIM, (#133 when exploring the CD image with PSicture), the dumped version (CD\0077) contains all sorts of other stuff prior to the proper TIM file. Allow me to illustrate:

(http://img502.imageshack.us/img502/3261/eyeballoddityey9.gif) (http://imageshack.us)
THIS stuff and lots of other data (all referring to Guile, I presume) come before the TIM header in CD\0077. Not sure what this all means quite yet, other than that we shouldn't count on each of the .OUT files holding only one file. I just lucked out with the OUT equivalents to the STR videos.

Zeality, I'll add the STR and TIM headers, and whatever other file headers I can identify, to the wiki file on datamapping when I get some time to spend with that entry.

Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Gemini on October 22, 2007, 09:52:05 pm
That file with ASCII strings in it is just an archive containing the Status menu data. Each of those files contains a copy of the battle model, textures, and an ASCII description of a character. There isn't really anything relevant in there.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on October 22, 2007, 09:55:45 pm
Wait a minute, wait a minute - Gemini, you're saying CD\0077 contains Guile's battle model? That is extremely relevant! Do you know how to view the models? Or can you give me an idea of what the battle model file header looks like in hex? We might be able to separate out all the various files in the CD directory based on hex signatures.

My goodness, thanks for walking in here Gemini!
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Gemini on October 22, 2007, 10:05:38 pm
Wait a minute, wait a minute - Gemini, you're saying CD\0077 contains Guile's battle model? That is extremely relevant! Do you know how to view the models?
I said it's a copy of the battle model, not the real thing. It has even a different format, in fact what you guys call "dynamic" textures aren't dynamic at all in the status menu, while they are in battle (eyes are updated in real time).

Quote
Or can you give me an idea of what the battle model file header looks like in hex?
I can't seem to recall any magic word or signature for models.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on October 22, 2007, 10:11:08 pm
Ah, I see. Thanks for clearing that up Gemini. Would you be able to point me to where the battle model copy is in CD\0077? Would it prove useful in finding the real thing in any way, do you think?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Gemini on October 22, 2007, 10:24:49 pm
Ah, I see. Thanks for clearing that up Gemini. Would you be able to point me to where the battle model copy is in CD\0077? Would it prove useful in finding the real thing in any way, do you think?
The archive uses this format for the subfiles (which can be extracted using Yazoo's CD decompress):
-0: description
-1: unknown 4 byte data
-2: as above
-3: 3d mesh+animation data
-4: eye tim texture
-5: custom format 8 bit texture, palette starts at 0x1C, pixel data starts at 0x22C

Arf's texture extracted using Tile Molester (works great with non-standard formats):
(http://img341.imageshack.us/img341/8603/arfdm3.png)
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on October 22, 2007, 10:35:19 pm
Thank you very much, Gemini!! :mrgreen:

EDIT: HOLY COW!! WE DON'T HAVE THOSE YET!!

EXTRA SPECIAL THANKS, GEMINI!!

Zeality, let's divide the CD\ files between the two of us and whoever might want to join in, and let's get these battle textures ripped as time allows. I'm going to explore CD\0077 with Tile Molester and see if I can reproduce Gemini's results in this area.

Gemini, did you run CD decompress on these files and use Tile Molester on the result? Or did you run Tile Molester directly on CD\0077?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Gemini on October 22, 2007, 10:39:22 pm
Gemini, did you run CD decompress on these files and use Tile Molester on the result? Or did you run Tile Molester directly on CD\0077?
On the extracted segment, but you can do it on the OUT file anyway, since it's not compressed or post-processed.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: ZeaLitY on October 23, 2007, 12:03:15 am
Well, I'm still going down the debug menu for maps on disc one. I think I broke 400 tonight, and I'll probably reach 600 before tomorrow. The absolute limit is 999.

I've already added the menu options and the digits I've found so far to the Chrono Cross File Structure Page in the encyclopedia. For any who don't know it yet:

http://www.chronocompendium.com/Term/Chrono_Cross_File_Structure.html

Big welcome to Akari and Gemini. We (or at least I) hardly know anything about PSX hacking. Our overall goals are to rip all the battle models and textures. Looking at the programming will probably be long-term, too.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on October 23, 2007, 01:06:32 am
Nice job on the file structure page, Zeality! Do we even need to worry about the datamap now? It seems we've superceded the need to know where all the files are on the disc, perhaps.

I'm checking out how to produce the battle textures in Tile Molester. If I have any luck, I'll rip as many as I can while I've got time.

EDIT: Battle textures ripped. Thanks Gemini for paving the way! I never would have been able to do that without knowing where the CLUT was.

@Akari: Sorry I haven't gotten a chance to help you with the walkmesh issue yet. I think the most helpful files are probably those in the "Rooms" directory after dumping with Ramsus/Yazoo, but I don't think those OUTs can be dcompressed yet. Does anyone have a room decompressor executable?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on October 23, 2007, 06:25:20 pm
Okay, I've spent a little time with Nemesis' tools. I think I'm on the verge of getting the room files dumped with that, perhaps, but I get the following screen of death when the dumping starts:

http://img218.imageshack.us/img218/169/sodgc3.gif

Anyone have any success yet with Nemesis' Chrono Cross.exe? I'm attempting to rip from the same .bin that worked with Yazoo's tools. It's the correct file size, but I'm wondering if things would work better if I converted my .bin to an iso somehow. But before I try that, I thought I'd gather other reports of success or failure with this utility so we can better tackle the problem.

EDIT: Zeality, I'm attaching the latest of what Sephiroth over at sadnescity has given me.

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: ZeaLitY on October 24, 2007, 07:54:31 pm
Something ominous...the videos produced by Yazoo's tools seem to cut out one second before they should. For instance, in the Dragon Tear scene, the Time Crash explosion doesn't reach its full breadth before the video stops.

Can anyone extract the videos with Nemesis's tools and see if this also happens?

Because...it might just be PSXTulz. But I don't really have a standard of comparison here.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on October 24, 2007, 08:06:35 pm
I can squeeze in a few minutes to investigate. Which video is the dragon tear scene again?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: ZeaLitY on October 24, 2007, 08:09:46 pm
5605.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on October 24, 2007, 08:45:16 pm
I wouldn't worry about it. #5605 checks out when I do a hex comparison between the 600+MB iso and the ripped .OUT file. It's exactly what's in the CD image; same file length and same content too, judging from a few offsets sampled at random.

My PSXMediaPlayer doesn't seem to have a functional "scan file" feature; if it did, I'd sic it on the .OUT file and we'd be able to tell for sure. But for now, I'd ascribe the fault to PSXTulz and not Yazoo's tools.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on October 25, 2007, 12:30:17 pm
I'll not be around for the next few days, but I wanted to attach some potentially new stuff I received from Sephiroth 1311 at sadnescity.it. Zeality, you should already have these I think.

Contained within is a version of roomdecompress2 source code, written in C++ (the version Ramsus compiled previously was written in plain C, contrary to any false indications I gave before due to my lack of programming knowledge). There's also an alternate roomdecompress.exe that goes up to room 536 before it quits. It's possible that roomdecompress.exe was compiled from roomdecompress2.cpp, but I'm unsure.

With so many different versions of stuff floating around now, perhaps I can sift through everything when I get back and make a list of a.) what's out there and b.) what works best.

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Ramsus on October 25, 2007, 08:31:22 pm
I'll not be around for the next few days, but I wanted to attach some potentially new stuff I received from Sephiroth 1311 at sadnescity.it. Zeality, you should already have these I think.

Contained within is a version of roomdecompress2 source code, written in C++ (the version Ramsus compiled previously was written in plain C, contrary to any false indications I gave before due to my lack of programming knowledge). There's also an alternate roomdecompress.exe that goes up to room 536 before it quits. It's possible that roomdecompress.exe was compiled from roomdecompress2.cpp, but I'm unsure.

With so many different versions of stuff floating around now, perhaps I can sift through everything when I get back and make a list of a.) what's out there and b.) what works best.

Don't get your hopes up too much. It's the same exact source. It's the same exact file. And it's still really just C. In fact, every "version" of it I've seen is exactly the same.

So far I've only seen two different programs/groups of source code. The Yazoo/chronotools stuff, which is all exactly the same, and the Terminus Traduction tool, which was posted both as isolated source code and as part of some big Chrono Cross translation tools package.

Also, the other roomdecompress.exe was probably just built with a different compiler, which is why it behaves slightly differently. However, the program is hardcoded to only go up to 536, so if it's not crashing at the end, then it's running properly.

That my version crashes early suggests that there's a bug that only appears when the code is built with certain compilers (i.e. there's a real bug, but under the right conditions nothing happens because of it), but I haven't tried reproducing the crash under a debugger yet.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Ramsus on October 25, 2007, 11:36:36 pm
Also, here's why it's only going up to "Room" 536. There's out files 0356.out to 1966.out. That's 1310 .out files. However, they come in groups of three per room, so 0356.out is the files that get dumped into the room's "code" file, 0357.out is what goes in the "unknown" folder, and 0358.out is what goes into the "GFX" folder. Then it repeats with the next three. 0359 is code, 0360 is unknown, and 0361 is GFX.

So don't freak out that it's not going past "Room" 536, because that's all there is apparently.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on October 28, 2007, 09:05:15 pm
Thanks again, Ramsus. That clears lots of things up for me. Strangely, it appears we've picked up about 1MB of data with the roomdecompress.exe (approx. 214MB for the folders as opposed to approx 213MB for the raw .OUT files in the Rooms\ directory). I'm not sure why that would be; perhaps one of the filetypes contained within the .OUTs was decompressed? I should be able to figure that out on my own when I get a chance to do some in-depth hex viewing.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: ZeaLitY on October 29, 2007, 12:25:13 am
This started as a PM to FaustWolf, but it's too important:

Radical_R recalls seeing a note on Gamefaqs long ago suggesting that the Hydra Marshes location I found really is a bona fide debug room. What perplexes me about this is that it seems wiser to have that debug menu available to every location and not just that room, since it contains commands for modifying model sizes.

But the real implication here is that the debug menu's internal map selector and the Gameshark room modifier code may be mutually exclusively ("maps" versus "rooms"). I'm not really buying it, because up to what I've done so far, the maps match (although the room modifier crashes more than the map selector). What I can't figure out is how Nemesis numbered his rooms in the script...

~

Disregard all that. They match up. Nemesis starts 001 at the title / ending screens, which is like 009 or something with Cross's internal selector. Let's get down to inquiries:


Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Ramsus on October 29, 2007, 01:12:48 am
Thanks again, Ramsus. That clears lots of things up for me. Strangely, it appears we've picked up about 1MB of data with the roomdecompress.exe (approx. 214MB for the folders as opposed to approx 213MB for the raw .OUT files in the Rooms\ directory). I'm not sure why that would be; perhaps one of the filetypes contained within the .OUTs was decompressed? I should be able to figure that out on my own when I get a chance to do some in-depth hex viewing.

If you're comparing file sizes, remember that the room file extractor doesn't just split up the files and output them. It also generates all the ACT files from the CLUT information from the 1palette files. You have to delete all of those before you try doing any file size comparison, because they aren't part of the original data.

Other than that though, the program isn't generating any new data or modifying anything other than the palettes. So trust me, there's no decompression going on.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on October 29, 2007, 02:43:28 pm
It also generates all the ACT files from the CLUT information from the 1palette files.

That'll do it. Makes perfect sense now.

Darnit, I need to get some time to take a look at all this debug room stuff! Zeality, is there any kind of function in there that lets you see dungeon/in-battle character models for all the characters and enemies?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: ZeaLitY on October 29, 2007, 03:26:16 pm
Nah, just lets you change model size or something. And since the location I got the debug room menu in didn't load any models, I couldn't really test it out.

So, once we get Yazoo's output mapped, we can rip the assets?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on October 29, 2007, 05:45:42 pm
Yeah, I imagine we can just rip anything Yazoo's tools aren't giving us with a hex editor (someone let me know if I'm wrong on that - I think a simple copy+paste of the raw data should do, though viewing will be slightly problematic until we can figure out what format the missing files are in). I think only 5MB or so is missing from the Yazoo tools dumps when compared with the 600+MB iso image. It's entirely possible that we've already got everything and that the "missing" 5Mb is just filler 00 bytes - essentially buffers between files that Yazoo's tools avoid.

Mapping the output of the Ramsus/Yazoo dumper looks fairly easy so far. Hopefully I can add the dumped directory starting & ending offsets to the wiki this weekend. Only the MISC folder will prove problematic, as I'm not sure that stuff's arranged in game CD order.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: ZeaLitY on November 05, 2007, 02:24:30 am
I've checked out folder BF, which has files containing all the battle field TIMs. I extracted the TIMs from a sample and compared file sizes, and there's definitely something other than textures in there. I mean, that's obvious, of course, but...

Anyway, I've searched the TIMs inside the sample OUT and removed them. Before each TIM is some kind of label. Bah, I accidentally did something I didn't want to...I'll have to resume tomorrow.

We can probably make some kind of qualitative judgment based on these tags. They include stuff like "deg", "degu", "gk"...and they each preface a few TIM files in sequence. In fact, all the textures are lined up in one part of the file.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 05, 2007, 02:39:30 am
Ooh, good find Zeality! Maybe the other data is battlefield model data, perhaps.

Can you describe the label that precedes the TIMs in the BF directory? I'm seeing a <...h label in ASCII just before the battle model textures located in MISC\OUTs 3055-3707.

I'm going to link to some suspected battle model data here and at Qhimm once I get it isolated, which will occur sometime this week. Within the range of the CD image that corresponds to MISC\OUTs 3055-3707, I've stumbled upon an area that's structured as follows:

Character Battle Texture <---> Character Weapon 1 Texture <---> Character Weapon 2 Texture...

Where the "<--->" is unknown data sandwiched between the textures. Might be models, hopefully. Perhaps the BF OUTs are structured in a similar fashion?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: ZeaLitY on November 05, 2007, 02:43:50 am
Ah crap, it'll have to be tomorrow. But I'm curious if the <---> data comes in varying sizes...like, if a block of data after the battle texture dwarfs the data after the weapons textures. We can establish a rhythm of what comes before what if it plays out like that.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: ZeaLitY on November 05, 2007, 02:27:04 pm
Code: [Select]
Headers
                                    00 00 00 00 64 65 67 75              ....degu
04 00 22 01 00 00 00 00 64 65 67 31 04 00 22 01 00 00 00 00  ..".....deg1..".....
64 65 67 32 04 00 22 01 00 00 00 00 64 65 67 33 04 00 22 01  deg2..".....deg3..".
00 00 00 00 64 65 67 34 04 00 22 01 00 00 00 00 64 65 67 35  ....deg4..".....deg5
04 00 22 01 00 00 00 00 65 6e 6b 65 04 00 22 08 00 00 00 00  ..".....enke..".....
65 6e 6b 31 04 00 22 04 00 00 00 00 67 61 6b 65 04 00 22 01  enk1..".....gake..".
00 00 00 00 67 61 6b 31 04 00 22 01 00 00 00 00 67 61 6b 32  ....gak1..".....gak2
04 00 22 01 00 00 00 00 67 61 6b 33 04 00 22 01 00 00 00 00  ..".....gak3..".....
67 61 6b 34 04 00 22 01 00 00 00 00 67 61 6b 35 04 00 22 01  gak4..".....gak5..".
00 00 00 00 67 61 6b 36 04 00 22 01 00 00 00 00 67 61 6b 37  ....gak6..".....gak7
04 00 22 01 00 00 00 00 67 61 6b 38 04 00 22 01 00 00 00 00  ..".....gak8..".....
67 73 30 31 04 00 22 01 00 00 00 00 67 73 30 32 04 00 22 01  gs01..".....gs02..".
00 00 00 00 67 73 30 33 04 00 22 01 00 00 00 00 67 73 30 34  ....gs03..".....gs04
04 00 22 01 00 00 00 00 67 75 30 31 04 00 22 01 00 00 00 00  ..".....gu01..".....
67 75 30 32 04 00 22 01 00 00 00 00 67 75 30 33 04 00 22 01  gu02..".....gu03..".
00 00 00 00 67 75 30 34 04 00 22 01 00 00 00 00 6a 69 6d 65  ....gu04..".....jime
04 00 22 01 00 00 00 00 6a 69 6d 31 04 00 22 01 00 00 00 00  ..".....jim1..".....
6a 69 6d 32 04 00 22 01 00 00 00 00 6a 69 6d 33 04 00 22 01  jim2..".....jim3..".
00 00 00 00 6a 69 6d 34 04 00 22 01 00 00 00 00 6b 75 6d 6f  ....jim4..".....kumo
04 00 22 02 00 00 00 00 6b 61 6e 6b 04 00 22 04              ..".....kank..".

There are the headers. Each is 3 bytes long. I'll now make a chart of the corresponding textures and see if we can establish some logic. Each header ends with .."., but as you can see in the hex, the " is sometimes 01, 02, or 04. Nonetheless, this might give us something to search. I've attached the OUT file with the headers still in there (at the bottom) but with the TIMs removed.

Edit: I've also attached the corresponding textures and names. They follow a set pattern, which is encouraging. If someone wants to guess translations for those, it'd be very welcome. For instance, a simple search yields kumo = clouds, as expected. Anyway, the good thing is that the entire OUT file starts with our famous "DRP" header, so I'm assuming whats left is the battle area box model and texturing instructions.

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 06, 2007, 12:10:02 am
Now for my report on the potential battle model / weapon model data.

Firstly, I've attached a zip containing a chunk of data from the CD image that I have named "ModelMine1." It's just raw hex data, and its beginning corresponds to a fresh sector (2048 bytes/sector as always) in the CD image. The data fall in this order: A header; Serge's battle model texture; Serge's eyeball texture; unknown data; Serge's first weapon model texture; unknown data; etc. Also inside the zip is a copy of my datamap for "ModelMine1," which I reproduce below. The chunk seems to be 11 sectors long even, if that means anything.

Also included in the zip are Serge's battle model texture, eyeball texture, and the seven weapon texture TIMs that occur within the ModelMine.

DATAMAP: All offsets given in hexadecimal notation.

00000000 ~ 0000000F: 16 byte header
00000010 ~ 0000823B: Serge Battle Texture
0000823C ~ 00009467: Serge Eyeball Blink Texture (NOTE FOR COMPENDIUMITES: slight differences from "4" in CD\Serge)
00009468 ~ 000097FF: 00 Buffer Bytes
00009800 ~ 00014847: Unknown Data (NOTE FOR COMPENDIUMITES: slight header differences from "3" in CD\Serge, but way larger file size)
00014848 ~ 00015DC7: Serge Weapon Texture 1
00015DC8 ~ 00016BE7: Unknown Data
00016BE8 ~ 00018167: Serge Weapon Texture 2
00018168 ~ 00018C5F: Unknown Data
00018C60 ~ 0001A1DF: Serge Weapon Texture 3
0001A1E0 ~ 0001AF0F: Unknown Data
0001AF10 ~ 0001C48F: Serge Weapon Texture 4
0001C490 ~ 0001D2EF: Unkonown Data
0001D2F0 ~ 0001E86F: Serge Weapon Texture 5
0001E870 ~ 0001F687: Unkknown Data
0001F688 ~ 00020C07: Serge Weapon Texture 6
00020C08 ~ 00021897: Unknown Data
00021898 ~ 00022E17: Serge Weapon Texture 7
00022E18 ~ 00023FFF: Unknown Data

SUSPECTED MODEL FILE INFO: The offsets and file lengths may actually be one byte too "short" depending on whether I'm interpreting the hex code correctly. For example, the First "Weapon Model" listed below is described as 3615 bytes long. If it makes more sense, feel free to interpret the file size as 3616 bytes.

First "Model" : 45127 bytes long. Header begins "06 00 00 00 20 00 00 00"
First "Weapon Model" : 3615 bytes long. Header begins "01 00 00 80 48 00 5E 00"
Second "Weapon Model" : 2807 bytes long. Header begins "01 00 00 80 39 00 46 00"
Third "Weapon Model" : 3375 bytes long. Header begins "01 00 00 80 43 00 58 00"

The weapon "models" are consistent in their first 8 bytes, which may constitute a model file header; the first 8 bytes for the weapon "models" read:  01 00 00 80 xx 00 xx 00

My notes on the data were hastily scribed, so if anyone wants clarification on any point, please ask. Once again, the "ModelMine" for Serge's (suspected) battle and weapon models and all the associated textures are in the attached zip if anyone would like to investigate.

EDIT: Ah, and yes, to make a long story short Zeality, the "Battle Model" does dwarf the "weapon models." This is encouraging. The "weapon models" seem to vary slightly in size, which I suppose would be understandable considering Serge's weapons are shaped slightly differently, no?

Looks like you've probably found the 3D battlefield data as well, since it seems to follow a similar sandwiching pattern (model data sandwiched between textures I mean).

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 07, 2007, 09:18:23 pm
Hopefully someone will be able to analyze what Zeality and I have found regarding potential model data and give us some feedback.

Moving on, I've found some very interesting ASCII blocks in Chrono Cross' SLUS file. First up...
(http://img165.imageshack.us/img165/8956/filepathsim9.gif) (http://imageshack.us)
Seems to be file paths. Is it possible that this is a signature left from the disc burning process, meaning there's MDE, FID, FND, and PRG files on the game CD? Anyone know what these file extensions even refer to?

Next up...
(http://img292.imageshack.us/img292/3513/possiblemodelopcodeskp1.gif) (http://imageshack.us)
If I had to take a wild guess, I'd say these might be assembly language opcodes that tell the Playstation GPU how to handle model data, but keep in mind that "I R a NooB" at this sort of thing. Now, this isn't functional opcode data -- just ASCII evidence that the opcodes are in the SLUS. I expect I'd find these elsewhere in the SLUS when I investigate with a disassembler such as PS2Dis.

Anyone have any input on this?



Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: halkun on November 08, 2007, 02:21:19 am
If you need any help with PSX internals, I'm here ^_^. Think of me as a free guide to that one PSX doc that's on the internet. I hear that the guy who made at and myself are really close...

--->||<---

Like that even.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 08, 2007, 02:42:35 am
Holy cow, Halkun's here!  :lee:

Yes, I'll definitely be asking you questions as time goes on. I'd better read your PSX doc so I know the right questions to ask. :mrgreen:

I suppose for the time being, I'm wondering what the "kz_modelGetNormalPolygon()" and similar functions shown in the above pics ARE exactly. I'm seeing these things when I view the SLUS file in the PS2Dis disassembler. If it's part of the PsyQ library, I won't bring it up again since Sony means to keep a tight lid on that info. I'm just wondering if it'll help us view model data in any way.

And regarding the GPU quad opcode subject you brought up earlier over at Qhimm, where would that data occur in the typical PlayStation game CD? Only in the SLUS, near the model data, both, or am I completely clueless?

For anyone who doesn't know yet, Halkun's the most knowledgeable person on PlayStation architecture outside of Sony itself - and he probably knows even more than they do.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: halkun on November 08, 2007, 04:10:33 am
In FF8, I found the quad data right after the UV (texture) TIM. It was a partial opcode list that collected the UV information for later aggregation into the OT sequence.

Little help with vocabulary:
UV Map : Another way to say "Texture map" It's called UV because U and V are used to represent the 2D coordinates on the texture map.  X,Y, and Z are used for 3D coordinates.

OT Sequence : The Ordering Table Sequence : The big list of opcodes that get linked together to be sent to the GPU


The layout was something like this:

(quad opcode)
(blank)
(U point 1)
(V point 1)
(U point 2)
(V point 2)
(U point 3)
(V point 3)
(U point 4)
(V point 4)

That's what I remember.

The tris were the same way, but only three points as opposed to four.

Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 08, 2007, 12:13:18 pm
Ah, that helps immensely! So Halkun, is there quad opcode after every character model texture in FF8, regardless of whether they are field models or battle models? If so, I can load my FF8 game image into a hex editor, find a texture for Squall or something, and see what the opcodes look like in hex perhaps.

Though in FF8, like in Chrono Cross, PSicture and TIMViewer seem to detect a lot of "clone textures," some of which I suspect are present extraneously and not applied to any model at all. Or maybe I'm wrong?

But anyway, this may help us determine for sure whether Zeality and I actually *have* model data.

EDIT: I've just done some investigation of the data following Zell's battle model texture(s) in my disassembler (because viewing data through a disassembler makes me feel cool 8)), and it appears the data immediately following Zell's texture starts with the following assembly language instructions:

dsrav zero, zero, zero
sync
dsllv  zero, zero, zero

Halkun, does this provide any clue as to whether or not I'm looking at quad opcodes? Or, an alternative question, how is one able to tell that he/she is even looking at quad opcodes? :oops:

And I've got a few quick questions about your PSX doc, which I am still reading through (rather haphazardly, as time allows):

1.) In your GPU packet command list, "0x2c" constitutes a packet command for a textured 4-point polygon. What would that look like in hex? Just "2C"? And would that appear in a quad opcode?

2.) You differentiate between "monochrome" and "textured" polygons. Would I be correct in stating that Final Fantasy 7 uses monochrome polygons, whereas Final Fantasy 8 (and, by association, Chrono Cross) uses textured polygons? This is an obvious NooB question, but I just want to make sure.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: halkun on November 08, 2007, 10:16:27 pm
1.) In your GPU packet command list, "0x2c" constitutes a packet command for a textured 4-point polygon. What would that look like in hex? Just "2C"? And would that appear in a quad opcode?

2.) You differentiate between "monochrome" and "textured" polygons. Would I be correct in stating that Final Fantasy 7 uses monochrome polygons, whereas Final Fantasy 8 (and, by association, Chrono Cross) uses textured polygons? This is an obvious NooB question, but I just want to make sure.

I'm going to answer #2 first, because that will answer #1.

First a little more vocabulary.

Triangle - A shape with three sides.
Quad - A shape with 4 sides
Vertex - a "corner' of a shape. A triangle has three vertexes (or vertices). A quad has four.


Let's pretend that I want to tell the GPU that I want to draw a red square (quad) where the vertex points were (0,0) (0,10) (10,0) (10,10). I will want to make the data something like this.

28 00 00 ff 00 00 00 00 00 00 00 0a 00 0a 00 00 00 0a 00 0a

Then send that off to the GPU.

It breaks down like this.
===============
28 = The GPU command for a Monochrome (single color) 4 point polygon

00 = blue value
00 = green value
ff = red value

00 00 = y0, vertex 0
00 00 = x0, vertex 0
00 00 = y1, vertex 1
00 0a = x1, vertex 1
00 0a = y2, vertex 2
00 00 = x2, vertex 2
00 0a = y3, vertex 3
00 0a = x3, vertex 3
===========

You see how it goes? Remember, the GPU only draws in 2D. The GTE is responsible for the projected 3D maths.

FF7 used gradated 3-point polygons (one color at each vertex). It's format is different.

Any other questions?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 08, 2007, 10:58:04 pm
THAT...is amazing.  :lee: Thanks Halkun!

I'll ask a series of questions as a followup to your post:

1.) So does

28 00 00 ff 00 00 00 00 00 00 00 0a 00 0a 00 00 00 0a 00 0a

constitute a monochrome quad opcode in hex then?

The structure will look very different when textures are wrapped around a model I expect(?), but at least I can look out for byte strings that start out with values like "24"; "2C"; and "34"; and "3C" which would give me an idea that I'm looking at data pertaining to textured triangles, textured quadrilaterals, gradated-textured triangles, or gradated-textured quadrilaterals respectively (reading from your PSX doc).

2.) Going back to your "28 00 00 ff ..." byte string example, would the "28" occur on a fresh line if I'm looking at game data with 16 bytes per line in a hex editor? Or could this instruction occur anywhere?

3.) Is there any way to tell, looking at a model texture, that the corresponding model is gradated-textured versus "plain" textured? I can see why the Final Fantasy 7 models are gradated triangles and not monochrome triangles now that you mention it.

4.) I take it that I should just put away the disassembler for now and look for opcodes in a hex viewer? :mrgreen:

5.) One more question just for my curiosity: is color data sent to the GPU byte-order-reversed then? I'm used to thinking in terms of Red-Green-Blue, but the PSX GPU thinks in terms of Blue-Green-Red if I understand correctly.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: halkun on November 08, 2007, 11:27:41 pm
THAT...is amazing.  :lee: Thanks Halkun!

I'll ask a series of questions as a followup to your post:

1.) So does

28 00 00 ff 00 00 00 00 00 00 00 0a 00 0a 00 00 00 0a 00 0a

constitute a monochrome quad opcode in hex then?

The structure will look very different when textures are wrapped around a model I expect(?), but at least I can look out for byte strings that start out with values like "24"; "2C"; and "34"; and "3C" which would give me an idea that I'm looking at data pertaining to textured triangles, textured quadrilaterals, gradated-textured triangles, or gradated-textured quadrilaterals respectively (reading from your PSX doc).

This sequence....

28 00 00 ff 00 00 00 00 00 00 00 0a 00 0a 00 00 00 0a 00 0a

That is a GPU *command*. The opcode is just the 28 at the beginning (operation code).

Quote

2.) Going back to your "28 00 00 ff ..." byte string example, would the "28" occur on a fresh line if I'm looking at game data with 16 bytes per line in a hex editor? Or could this instruction occur anywhere?


GPU data will only relly show up with UV maps and only in the model data. It will be too hidden in the game execuatable. Different GPU commands are different lengths. The commands are all broken down in my doc.

Quote

3.) Is there any way to tell, looking at a model texture, that the corresponding model is gradated-textured versus "plain" textured? I can see why the Final Fantasy 7 models are gradated triangles and not monochrome triangles now that you mention it.

Most textured polys are actually gradated. The colors under the texture is what's used for lighting. The opcode hunt is good for looking for the UV maps. (The lines that trace out the polygon boundries on the TIM file). These will have the 2D UV coordinates, but the polygon data will be blank or missing.The Poly data will be around that area though.

Quote
4.) I take it that I should just put away the disassembler for now and look for opcodes in a hex viewer? :mrgreen:

You will not find code in the data files. Looking through the executable is kind of a waste of time. Hex viewing and seeing patterend is how you will find things. Load up an uncompessed data file as an image (using a RAW loader where you can define X,Y and colordepth) you will see patterens change where the data is a different kind. That helps a lot. Also, look for tables that go up. the tables point to offsets and that marks data boundries.

Quote
5.) One more question just for my curiosity: is color data sent to the GPU byte-order-reversed then? I'm used to thinking in terms of Red-Green-Blue, but the PSX GPU thinks in terms of Blue-Green-Red if I understand correctly.

The PSX is a MIPS computer, so it's reverse-edian in relation to a PC.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Cyberman on November 09, 2007, 12:48:30 am
Quote
5.) One more question just for my curiosity: is color data sent to the GPU byte-order-reversed then? I'm used to thinking in terms of Red-Green-Blue, but the PSX GPU thinks in terms of Blue-Green-Red if I understand correctly.

The PSX is a MIPS computer, so it's reverse-edian in relation to a PC.
Actually halkun the R3k processor used on the PS1 thinks either way. MIPS has a patent on out of order little/big endian transfers that is quite annoying to many would be micro processor designers.
In simple terms it can read it either way. However all the byte ordering I've seen in Square soft's software thus far on the PS1 and up are little endian, which is the same as that of the PC.

Cyb
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 09, 2007, 02:57:38 pm
Cyberman's here too!  :lee:

Thanks again to the Qhimm folks for their guidance and their willingness to migrate over here for this discussion. It is MUCHO appreciated.

Now that I know the byte values "3C" and "34" are the GPU opcodes pertaining to gradated-textured quadrilaterals (quads) and gradated-textured triangles respectively, I can sniff around the model texture data to make sure that what Zeality and I have are, indeed, models. This is because the textures should be accompanied by commands that tell the GPU how to "wrap" those textures around the models. Halkun and Cyb, please critique my understanding of this matter if I've misinterpreted.

By the way, awhile ago I replaced one of the Chrono Cross character's "overworld" models with a solid color and thereby had a chance to see the shading/lighting applied to the model: http://img134.imageshack.us/img134/815/kidoverworldyd3.jpg
Looking at this, would it appear that the shaded aqua-colored model does, indeed, use a gradated texture?

Looking back to that simple exercise, I wonder if we can "test" the supposed model data Zeality and I have found by altering the supposed model code in a hex viewer. Like, if we changed a few random bytes and a character's face gets all screwed up, we should be able to tell that we're fooling with model data, right? Secondly, by noticing the effect on the model, perhaps we can tell which "regions" of the model data pertain to bone structure, animation, etc, by trial and error. Then we could use this knowledge to help decode the model format Square used for this game. Does this seem like a plausible idea?

Ooh, that's tonight's project! 8)


For anyone who wants to find out about GPU instructions and such, you can find Halkun's PSX doc at Zophar.net:
http://www.zophar.net/tech/psx.html

Zophar's version says it was last revised in 2000 (v. 1.0), Halkun. Is that the latest version you've released?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Cyberman on November 09, 2007, 07:06:34 pm
On Page 40 you will see the format of the data sent to the GPU for Triangles and Quads of the kind you are refering too.
Texture pages are 256x256 pixel sections on the display. the u and v values are points on that page and CLUT is the clut that is being used for it.  So I suggest you use that information and tweak the vertex locations on the page and find out.

Cyb
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 10, 2007, 01:26:53 pm
Thanks for the tip Cyb!

Now's the time to start getting excited, folks:

http://img229.imageshack.us/img229/8201/chimerafu9.gif

This is what happens when I overwrite Kid's model geometry with Serge's model geometry in my test iso. It's sorta like Silence of the Lambs, only without the fava beans.

This means several things:

1.) We can now be 100% sure that we've located the true battle models. Otherwise, what I attempted wouldn't have had any effect.

2.) It will probably be just as easy to confirm that we've found the battlefield environment models. What we'll need to do is find two battlefields that have wildly different geometries, then do the copy&paste and see if one of them gets really messed up like this.

3.) We can rely on sheer trial and error if necessary to determine which byte strings in the model files correspond to geometry, animations, and whatever other data is incorporated into the larger model files. My gameplan is to employ what I call the "halfies" approach. We segregate a given model file into two parts, drastically change one of those parts, and see if, say, animations are screwed up in game. If so, we split that portion of the model in half, rinse and repeat until we've honed in on the animations.

But I worry that the "halfies" approach will screw up opcodes and such if they happen to be spread throughout the model files. Halkun, Cyb, Luminaire, jono, Vehek, Zeality, Akari, Ramsus, Gemini -- hell, everybody, is there a more powerful and efficient way of reverse-engineering model data?

I'd like to update this thread with some Youtube vids illustrating the chimera Serge/Kid so that everyone can see it in motion and view what's happened to Kid's animations. If other eyes besides mine look at it, we can collect insight from various hackers and modelers.

So -- does anyone know of any really good open source/freeware/shareware video capturing programs I could use?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on November 10, 2007, 03:17:12 pm
That's awesome that you've found model data.

A cursory search of Sourceforge gives CamStudio (http://camstudio.org/) and Taksi (http://taksi.sourceforge.net/), among others. The former seems to be more mature, while the latter explicitly mentions being able to capture DirectX/OpenGL. I don't really know if either of these are good, but they might be worth a try.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 10, 2007, 03:33:34 pm
CamStudio looks good. Thanks Luminaire! I'll get some video clips upped tonight on Youtube, along with some other helpful visuals to give everyone a good idea of the effects of the model data transfer.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: ZeaLitY on November 10, 2007, 06:19:03 pm
Wow, what an exciting development! I'm not on the forefront of the model work, but...what's the anatomy of a file once you remove the textures? Are all the different-purpose portions and components preceded by a header, like the TIMs in the battle field OUTs I examined earlier?

Yeah, the hacking idea is enticing. Can't wait for tonight. For a rough count of how many individual models we might be dealing with...

http://www.chronocompendium.com/Term/Monsters_%28Chrono_Cross%29.html: 152
http://www.chronocompendium.com/Term/Characters_%28Chrono_Cross%29.html: 106

258 plus a few more for general NPCs and other stuff like fish. But speaking of that, fish and other details of battle models (for instance, the Lizard Rock battle field contains fish) might be contained in its actual /BF file instead of MISC/ with all the character models.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 10, 2007, 07:27:59 pm
Thanks for the battle model count, Zeality. That will come in handy when I begin in-depth mapping of the battle model data. As far as the file structure of models once textures are removed, I haven't got any info that's more in-depth than the skeletal map I posted earlier (for "ModelMine1"). Now, however, all the "Uknown Data" can be referred to as "Model Data." :D

Here's tonight's update. The vid quality is less than I would have liked, but hopefully we can find some insight within its grainy-ness. No sound either; I'll report later as to whether the "Chimera" uses Kid's or Serge's sounds in battle, because I've forgotten. :mrgreen:

The first video is just a demonstration of how the characters Serge and Kid look in battle. Folks already familiar with Chrono Cross battle models can probably skip to the second vid, but this provides a useful reference:
http://www.youtube.com/watch?v=uxts0pisnI0

Now the fun begins. As boring as it will be at times, please watch this in its entirety to get a full impression of what's going on with the model data. The final 30 seconds are especially important:
http://www.youtube.com/watch?v=YSHIT-thL5Q

I apologize for the expletive in the second video's file name. Youtube's web address generator has a filthy mouth. :roll:

As you can see, the "Chimera" is Serge's model data with Kid's battle texture. Serge's standing, running, and spell-casting animations have carried over, but not his physical attack animations for some reason. But a complicating factor is the significant difference in file size between Serge's and Kid's model data. Specifically (and surprisingly), Kid's model takes up 8184 bytes more in the game CD than Serge's! It could be that Kid's animations are more complex than Serge's or something, and therefore need more space.

I'll illustrate graphically what I did exactly. Below is a representation of Serge's battle model data (sans skin & eye blink textures). In ModelMine1, the unskinned model lasts from hex offsets 00009800 ~ 00014848:
(http://img233.imageshack.us/img233/4286/sergemodeluo7.gif) (http://imageshack.us)

The following is a representation of Kid's unskinned battle model data. I will release her battle data set - ModelMine2 - tomorrow evening, once I jot down some datamapping notes on it. Then we can find potential model file headers.
(http://img264.imageshack.us/img264/948/kidmodelrr6.gif) (http://imageshack.us)

Now, with Serge's model data written over Kid's:
(http://img264.imageshack.us/img264/5765/chimeramodellq5.gif) (http://imageshack.us)

So some of Kid's model data is still left over. At some point I'll wipe the rest of the "red" (Kid) part out with 00 bytes and see how that changes things.

At least this shows that we've got battle models. Now, the question is how to go about deciphering the model format.

Frivolous Edit: Youtube says these vids are related to Area 51 and Illuminati videos. But I assure you all, the Chimera vid is the real deal. :D


Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Molotov on November 10, 2007, 09:16:26 pm
So -- does anyone know of any really good open source/freeware/shareware video capturing programs I could use?

I'll be honest: this topic confuses me and that's part of the reason I don't follow it all that closely. The other reason is perhaps that nobody has found sequence breaks because of this stuff. :P

Anyway, if you're using ePSXe or something with plugins, use Pete's Soft GPU 1.17 for video capture. No sound, but it can record without any watermarks. That way, you can record to Huffyuv and compress it to something good later. Your choice though, obviously.

If I'm saying something not even remotely related, I'm sorry. Blame the lack of attention. :)
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Blackcaped_imp on November 10, 2007, 09:29:26 pm
OMG!! Omnipresent shadow attacking in the second video!!! Damn Japanese people LOL!!!
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Cyberman on November 10, 2007, 10:07:00 pm
At least this shows that we've got battle models. Now, the question is how to go about deciphering the model format.

Frivolous Edit: Youtube says these vids are related to Area 51 and Illuminati videos. But I assure you all, the Chimera vid is the real deal. :D
Well FF7's stuff was a bit easier however I suggest you look up skeletal animation information and begin learning how it works. This way you will understand what data you are looking for and how to use it.
You need vertexes, you don't need uv coordinates since those are mixed in with the GPU data.  If the animation moves the bones and the vertexes are 'weighted' to those bones then you need an idea of how they moved the vertexes with the bones (in simple terms I suppose).
Anyhow it will help you to learn about data like that which you look for!

Gamed Dev Net To your rescue however.
First Look at this article (http://www.darwin3d.com/gamasutr.htm) and then at this article (http://www.darwin3d.com/gdm1998.htm#gdm0598). The first part of Article one is how FF7 handles things. The second part is similar to how CC likely handles things.

Cyb
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 10, 2007, 10:22:29 pm
I wonder if the folks who deciphered Final Fantasy 8 and Final Fantasy 9's model formats left documentation anywhere as to how they went about it. That would be critically useful, seeing as how FF8 and FF9 both used texture models.

I think either Zande or Zidane 2 (maybe both) figured out how to view FF9 models. Cyb or Halkun, do you have any idea who figured out the FF8 format? Was it anyone at Qhimm?

Ooh, I just saw the articles you posted Cyb. Thanks!

@Molotov: Thanks for the vidcapture plugin tip. I'll try that if I'm ever in need of less-grainy videos (or vids with sound perhaps).
Title: A twist of the nose makes blood pour ...
Post by: Cyberman on November 10, 2007, 11:35:30 pm
I wonder if the folks who deciphered Final Fantasy 8 and Final Fantasy 9's model formats left documentation anywhere as to how they went about it. That would be critically useful, seeing as how FF8 and FF9 both used texture models.

I think either Zande or Zidane 2 (maybe both) figured out how to view FF9 models. Cyb, do you have any idea who figured out the FF8 format? Was it anyone at Qhimm?
More specifically it was Qhimm who did it. Search is your friend. There are a few threads regarding that.
I suppose I must break down and actually compile PCSX and then beat on it's GTE engine. Since none has been willing to add the information to the wiki (I tried but all things noted I don't know anything about FF8's format although I didn't meddle with it some experimentally mostly).

My guess is CC is similar to FF8 and FF9 in how they are structured.

Now FF7 used the format they did (see article one part one) because it compressed well.  FF8 is the way it is because they realized they only needed certain things for each data set and disk.  Unlike FF7 which had a lot of redundant information (it was hastily put together to say the least).

My guess is they used bone deformation and weighting of selected vertex for transformation.  IE most of the parts were transformed normal relative to the bone they were associated with and ones that had more than one bone association were stretched accordingly. This is easy to say.  Well a hint about vertex information on the PS1 it's likely stored as 4 16 bit signed values in a row. So if you see a lot of 8 byte values with 0000 as the last word. Likely that's your vertex information.  To be honest you should start there (find that data first) then it's likely index sets are the next victim.

3d data has to be organized in some way to transform it for the polygon information.

A simple explanation:
On the PS1 3d data is set up in memory for the model. The GTE then transforms the 3d data as specified by the animation information. That data is then married to the GPU opcodes you were looking for.  The GPU opcodes contain the UV information with them so the only information the GTE needs to provide is the x0, y0 x1, y1 x2, y2 information after it performs the perspective transformation on the data (this is a GTE function if you look at the functions the GTE performs lighting and perspective transformation is one of it's duties).  The data then just needs to be sent to the GPU. This is repeated for each model in the display as well as the background information.  Granted they likely do depth sorting etc. on all that data as well.

Cyb
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 11, 2007, 02:49:40 am
Thank you very much for that guidance, Cyb! Vertex data first, then. And I'll read up on the documentation you provided.

I think Halkun had stated earlier back at the Qhimm forums that the model data may be a binary form of RSD or HRC format for ease-of-use by the PlayStation hardware, so I'll be on the lookout for characteristics of those as well.

I was under the impression Qhimm reverse-engineered the original battlefield model viewer for FF8 and improved upon it so that it viewed all the textures correctly and such. I didn't find anything about a release of the improved program though, and the only download link I can find for the original gives me a corrupted rar. But my guess would be that the FF9 model format is probably closer to Chrono Cross'.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: halkun on November 11, 2007, 03:26:21 am
I found the UV data, Qhimm put the model togeather. There have been 2 runs at creating a model viewer. Each time the models initally render "wrong" due to some kind of error. (The polys are all there, but not in the right place)

I'm not sure that CC uses weighted vertexes, that technology didn't show up till tekken tag, I think. Let me show you what weighted vertexes are....

(http://krythic.typepad.com/photos/uncategorized/2007/08/27/dress.png)

This is a picture of a model I made. You see the colors in the dress? These are the "weights" that are assigned to the lower leg bone that is moved behind the model. The colors go from red to blue. The more red it is, the more influance the bone movement has on the surrounding vertexes. Because Kaori wears a dress here, I want to smoothly move the dress, but have parts "stick" with the bone.

When looking for the model data format, it is most likely going to be orginazed into a few sections with lookup tables in the headers. Psy-Q wrote out it's data in text format that was "compiled" into biniary data for the lib to understand in run-time. The big break for us was that FF7PC has the RSD files in an uncompiled text state so we could read them with standared text editors. we could then see how the models broke down.

Psy-q has the ability to save animation data per vertex, but not weights like my model above. If the model is in any way standard, there should be a kind of RSD discriptor at the beginning that defines how the model is put togeather.

Inside the RSD data it should point to other data types, depending on if the extended libiary was used.

Refrences inside RSD files [ReSource Data]
-PLY [PoLyGon data] (.p in FF7pc) defines the shape of an object in the model. (Head, Neck, Torso, l_arm)
-MAT [MATerial data] (TIMs) These reference the textures used on the particular PLY above
-GRP [GRouPing data] These discribe how various PLYs are grouped togeather. (Character Models vs. weapons mostly)

The other types are MSH [Mesh], PVT [Pivit], COD [coordinate], MOT [animation], and OGP [vertex groups]. I don't know much about these types as I've never ran across them. These are used on the per-vertex models and may need to be deciphered for CC.

Keep in mind an RSD file does not contain any data, but only points to other datasets, you may need to seperate out the refrenced data so you can get a clear idea of what section is where.

THE DATA WILL BE SECTIONED INTO DECRETE DATA BLOCKS AND NOT BE MIXED.

I have yet to see a model that didn't follow that rule above. Look for headers and lookup tabes that go upwards in value. That will lend a clue.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on November 11, 2007, 10:37:46 am
I am thinking the first 32 bytes of the Serge battle model file are a header. Specifically it looks like a pointer table:

Offset      Value              Comments
0x00000x00000006Number of sections of file?
0x00040x00000020Pointer to start of section 1
0x00080x00004EF8Pointer to start of section 2
0x000C0x000050C8Pointer to start of section 3
0x00100x00005228Pointer to start of section 4
0x00140x0000A2CCPointer to start of section 5
0x00180x00000000Pointer to start of section 6 (zeros because it's not present?)
0x001C0x0000ABDCThe length of the file

Note that at offset 0xABDC is the start of a long string of zeros that runs until nearly the end of the data. I am thinking that this is not part of Serge's battle model and that we can ignore it for now.

If this is accurate (and please correct me if it is not), the next step is to identify the contents of each section. I would expect the vertex/normal/uv/face data to be in one of the larger sections (like the first one).
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 11, 2007, 11:05:52 am
Wow! Luminaire, Halkun, thank you both for your input!

Looks like a header table indeed. I'll get Kid's model data mapped and uploaded tonight; cross-referencing will probably confirm that the headers have the same structure, though the sections will have different offsets since Kid's model data takes up more space.

Halkun, did you and Qhimm actually view Chrono Cross models? Even if they're screwed up, that is totally awesome! Thank you both VERY much for your work on this! Is it possible to "decompile" binary model data back into text format?

Ooh, and Lupus Erectus provided some input at Qhimm that will be applicable here:

Quote
I had a look at the "modelmine" file, I just noticed only now.
The file is nicely structured a header and relative offsets to subsections, and each subsection has a similar header. The only exception seems to be the (probable) model data starting at 9800, this may be hardcoded in the game code. Same for 14800 which is a header containig pointers to the other subsections until the end of the file.
Section 00009800 ~ 00014800:
the first $20 bytes are a header. The first value may be the number of sections, the others are relative the offsets (relative to the beginning of current section, that is). Some of the sections are similarly split in subsections. I have no clue what they may be
Section 14800 - end of file:
header as above; the "unknown" sections between weapon textures are certainly weapon models.
for example, the first is at 15dc8. From there:
    0-7 unknown
    8-11 offset to vertices section
    12-15 probably offset to unknown section (at 15df0)
        this seems to be made of groups of 4 bytes. I nocited some textures have weid coloring,
        maybe models are textured AND color shaded.  They could be RGB values. (but the 4th byte?)
    16-19 probably offset to unknown section (at 15ddc)
The vertices section is a Cyber said above: groups of 4 2-bytes values, the last is 00 00. Vagrant Story is like this both for characters and weapons, but your model data here seems different.
Note how the first value also is often 00 00 or little more, that's because of the flatness of weapon models. However the last value sometimes is 01 00 or 02 00 


EDIT: So Luminaire, when relative offsets are given in a pointer table, the rule is to switch the byte order then? For example, the relative offsets in the table header in ModelMine1 read F8 4E; C8 50; etc.

I'm attaching a file that is ONLY Serge's battle model data (sans textures) to facilitate. It is exactly ABDC bytes long, so that seems to confirm your header table.

Without further knowledge of the model cracking process, I guess I'll go ahead and start screwing up data one section at a time and see what happens. That might tell us what aspects of the model each section is responsible for.

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on November 11, 2007, 11:47:28 am
The file is in little-endian format, meaning that the value 0x1A2B3C4D (corresponding to the decimal value of 439041101) is stored as 4D 3C 2B 1A in the file. Therefore the first four bytes of the header represent the number 0x00000006 (decimal value of 6) and not 0x06000000 (decimal value of 100663296). More details at Wikipedia (http://en.wikipedia.org/wiki/Endianness).

Quote
Section 00009800 ~ 00014800:
the first $20 bytes are a header. The first value may be the number of sections, the others are relative the offsets (relative to the beginning of current section, that is). Some of the sections are similarly split in subsections. I have no clue what they may be

This is in good agreement with what I said, so that's a good sign.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 11, 2007, 12:16:23 pm
Thanks for the informative link Luminaire. I'm still at that point in my hacking career in which the words "Little Endian" bring up memories of childhood nursery rhymes. :D

The file I attached recently conflicts with what I had previously reported in the ModelMine1 map (where I said Serge's model data was 45127 bytes long -- or B047 bytes long). But in truth, the space between relative offsets ABDC and B047 is just a bunch of 00 buffer bytes, so I think we can treat the recent attachment as Serge's complete battle model.

Tonight I'll attach a ModelMine for Kid (battle and weapon models plus applied textures) and Kid's battle model without textures.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: halkun on November 11, 2007, 01:51:01 pm

Halkun, did you and Qhimm actually view Chrono Cross models? Even if they're screwed up, that is totally awesome! Thank you both VERY much for your work on this! Is it possible to "decompile" binary model data back into text format?

Oops, no, I was talking about FF8, not CC
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: halkun on November 11, 2007, 01:59:52 pm
Here's a neat trick:

When in battle, make a savestate. Then match the model data you have found to the data that will most likely be in the savestate. This way you only need to mess with the savestate and see immediately what you are "screwing up" (all you have to do is pause the emulator, change a value in an already open hex editor, save, reload the savestate in the emulator, and see what you have done.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 11, 2007, 02:12:16 pm
That's an excellent idea Halkun! I'll give it a try when I get around to messing with the model data. This wouldn't have any effect on the hardcoded model data though, would it? In which case the game would probably "normalize" the model to its original state the next time it loads the model. I guess I'll see what happens.

EDIT: On another note, I've gone back and checked out Serge's battle model data again. Strangely, well after the model ends (according to the header table), there's some extraneous data before Serge's first weapon texture begins in the iso. That's why I said that the model file size was B047/B048 bytes originally. Strictly for completion, I'm attaching another version of Serge's untextured battle model that retains all the 00 bytes and the section of unknown data that lasts until relative address B048.

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on November 11, 2007, 06:12:28 pm
It looks like sections 4 and 5 of Serge's battle model could also start with pointer tables of the same type as the overall file. They have 22 and 13 pointers, respectively, and in both cases the 4 bytes immediately after the pointer table is the total size of the section.

Interestingly, the section of data at the end of the file is also a pointer table of the same format, with 16 entries referencing a section of 62628 (0xF4A4) bytes, which I believe is pretty close to the total length of the weapon model and texture data. My guess is that this pointer table is a header for that data, which raises the question of what the eighth pair of pointers refers to.

It might be worthwhile to compare the pointer offsets to your ModelMine documentation to see how closely they agree. At any rate, this is more evidence that those bytes have little to do with Serge's battle model.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Cyberman on November 11, 2007, 06:46:50 pm
Sic et non, if there are pointers to the weapon models then the format is not too dissimilar to that of FF7's format.
Technically speaking the weapon models ARE part of the battle models, they are a special bone in essence. Notice the Serge/Kid merged version showed kids weapon held like Serges in the stance. The weapon was still a knife however instead of a two handed unit.  This does indicate that the weapons are treated like special bones and added into the total model.
This is also how FF7 dealt with models in the PS1.  Each character had there weapons in the battle model file along with all there animations as well.

Cyb
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 11, 2007, 08:24:44 pm
Oh WOW, Cyb and Luminaire, that is incredibly interesting yet it complicates things somewhat. But I'm actually relieved, since the presence of an extra weapons header would explain the extraneous data that falls between the battle model file and the first weapon texture.

Well, here's Kid's ModelMine2 and her untextured battle model data to look at. Note that her battle model file will include the extraneous bytes that probably represent a header for the weapon models. I'll truncate and re-up once we agree on the boundaries of her battle model file.

As before, Kid's ModelMine2 contains an overall file including textures and models for herself and her knife weapons, as well as the individual textures and the notes I took. Here's an overall map of ModelMine2:

0000000 ~ 0000000F: 16-byte header
000001A ~ 0000823B: Kid Battle Model Texture
0000823C ~ 00009467: Kid Eyeball Texture
00009468 ~ 000097FF: 00 buffer bytes
00009800 ~ 0001683F: Kid Battle Model
00016840 ~ 00017DBF: Kid Weapon Texture 1
00017DC0 ~ 00018977: Kid Weapon Model 1
00018978 ~ 00019EF7: Kid Weapon Texture 2
00019EF8 ~ 0001AC3B: Kid Weapon Model 2
0001AC3C ~ 0001C1BB: Kid Weapon Texture 3
0001C1BC ~ 0001CDA7: Kid Weapon Model 3
0001CDA8 ~ 00013E27: Kid Weapon Texture 4
00013E28 ~ 0001EEDF: Kid Weapon Model 4
0001EEE0 ~ 0002045F: Kid Weapon Texture 5
00020460 ~ 00020E2B: Kid Weapon Model 5
00020E2C ~ 000223AB: Kid Weapon Texture 6
000223AC ~ 00023000: Kid Weapon Model 6

Below is a reproduction of the 32-byte header of Kid's model file, with subdivisions according to my understanding of the data:
(http://img152.imageshack.us/img152/4633/kidbattleheadervm3.gif) (http://imageshack.us)

My translation of this follows:
6 sections
First section begins at relative address 20
Second section begins at relative address 4DB4
Third Section begins at relative address 50C4
Fourth Section begins at relative address 5224
Fifth Section begins at relative address C6F0
Sixth Section begins at relative address (N/A)
File ends at relative address D000

Once again, I have only just recently learned how to count "Little Endians," so please correct me if my interpretation is off.

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on November 11, 2007, 08:37:40 pm
Your interpretation is correct, and you're right that there's an extra header at the bottom of Kid's battle model file. I think her battle model stops at 0xD000. Oddly enough, Serge's file is padded with zeros to exactly 0xB000, and Kid's file ends at 0xD000, so no padded zeros are necessary.

I will compare the files more closely, but I immediately noticed that the last several bytes (at least 64) of the two battle model files (that is, prior to 0xABDC for Serge and prior to 0xD000 for Kid) are identical.

Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 11, 2007, 08:46:11 pm
VERY interesting Luminaire. Could that indicate a "footer" of some sort? I think I'll eventually do one last ModelMine3 (Guile) so we can tri-compare among the ModelMines.

Anyway, thanks to you and Cyb and Halkun, we have made extraordinary progress on decoding the battle model format, and in a single day no less. The next step is to just mess with the battle model data one section at a time to figure out which section handles which aspects of the models. I'll take care of that with my test iso over the coming days and post some more vids on Youtube to facilitate analysis.

This is exciting! :D

EDIT: Now that Luminaire's confirmed that the data tagged onto the end of Kid's battle model is extraneous (and most likely a header for the weapon models), I'm attaching her untextured battle model without the extraneous data. It ends at relative address D000. This is equivalent to SergeModel (the original, NOT version 2) attached on Page 5 of this thread.

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Cyberman on November 11, 2007, 09:05:09 pm
That information likely pads the information to the nearest sector. Data sectors are 2048 bytes OR in hex 0x800h  As for why 0xD000 my guess is it has to do with memory location (in the PS1 2M of user memory).  This offsets whatever follows in the data to a convenient location.  If you have the time look in memory to see if that is what's going on.
I suppose I should find the information regarding ePSXe's save file format. I'm so lazy sometimes. :D

Cyb
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 11, 2007, 10:01:39 pm
Without going through the whole process of providing another entire ModelMine, I can say that Guile's untextured, weaponless model is identical in its last 2112 bytes (!) to Kid's and Serge's. Looks like a common footer of some sort.

I'm attaching Guile's battle model data (no ModelMine this time; we'll worry about how the weapons work later). In addition, for simplicity's sake (hopefully), I'm attaching Serge's and Kid's equivalent battle model data alongside his for quick comparison.

Guile's model also has buffer bytes until it reaches a new sector, then the weapon model data header. So I think that confirms what Luminaire and Cyb suspected (D000 in Kid's model, of course, just happens to land on a fresh sector by chance).

@Cyb: What utility is best for examining PlayStation emulator memory? Would I just decompress a savestate?

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: halkun on November 11, 2007, 11:13:10 pm
Yea, I would just decompress the savestate. The emulator will restore uncompessed savestates so it saves you the hassle of compressing them again.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 11, 2007, 11:35:04 pm
Alrighty, thanks Halkun.

Now I've caught some more whacked-out video. This time I changed the values of bytes within the first section of Serge's battlefield model data:

http://www.youtube.com/watch?v=usSTi7mxwvM

It would appear that I've tweaked vertex values, but that's a guess. Anyone care to take a peak and confirm?

So, I guess the next question is: if the goal were to gather the knowledge necessary for writing a plugin for 3DS Max, Lightwave, Milkshape, or Blender, how in-depth do we need to go in each section of data? Should I start documenting which byte offset I changed to screw up Serge's bandana, for example?

And if the model format is in a binary form of RSD or some other format easily accessible to PlayStation hardware, would it be worth our while to run some of the data through a decompiler and see if it gives us anything recognizable?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Cyberman on November 12, 2007, 12:16:48 am
RSD is likely compiled to your header information that you have.

The files that are referenced by the RSD data are more interesting.  The RSD file is like a web page that references numerous other pages.  There is the possibility that the model is not a single mesh but a bunch of parts like FF7 had. Unlikely though. 

You may have been changing vector indexes (anything is possible). I noticed the polygons shooting off into the distance (IE they were extremely large values).

Cyb
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: halkun on November 12, 2007, 12:35:10 am
Looks to me like you got a vertex value for the very top of the head, and you zeroed it out. The dark artifacts appear to be the shadow unable to cope with the change. (division by zero?)
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 12, 2007, 12:50:33 am
I suppose the next step is for me to go through the original model data again, this time documenting which bytes I change. That might offer some clues as to which offsets affect which parts of the model. The major changes I noticed  in the vid were the large triangle/cone jutting out of Serge's head, a possible alteration of his glove cuff (hard to see in the video), and the giant spike sticking out from his leg(?). His texture includes some bluejean-like material for pants, so if the giant shadow-thingy is blue or dark blue, I believe I may have placed a vertex far away from the rest of the model and thus stretched the "bluejean" texture.

I'll repeat and get another vid upped tomorrow night. If anyone has advice on what to do next, I'm all ears. Maybe I'll get Serge to grow a few extra ears too.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on November 12, 2007, 01:06:54 am
So, I guess the next question is: if the goal were to gather the knowledge necessary for writing a plugin for 3DS Max, Lightwave, Milkshape, or Blender, how in-depth do we need to go in each section of data? Should I start documenting which byte offset I changed to screw up Serge's bandana, for example?
As I see it, the first goal is to narrow down the range of byte locations that could hold, for example, vertex data. If you can say that bytes x to y in the file represent a vertex, that could be helpful in both figuring out how the vertex data is stored and where the rest of the vertices are. It's probably more important to know that the data represents a vertex than it is which vertex it represents, so I wouldn't bother trying to search for specific body parts. Furthermore, I would not expect us to have to use your method to identify every vertex in Serge's battle model.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 13, 2007, 01:34:16 am
Sounds good to me, Luminaire! After a bit more investigation of section 1 of the model data, I'll move on to section 2 and we'll see what other surprises await.

This update comes past everyone's bedtime, but things are getting even more interesting.

First, I'll post links to two Youtube vids I upped to illustrate the effects on Serge's model (still altering bytes in the first section of his model data while holding the other sections constant). They're both very similar, so I'd recommend skipping to the second one, because that's more interesting.

http://www.youtube.com/watch?v=IZeUvSJgL-g
http://www.youtube.com/watch?v=B8C4xeZYreg

Both vids show that I've managed to gouge out Serge's left eyeball, leaving his face horribly mutilated. I suppose it's possible that I've somehow folded one or more of his facial vertices over his eye texture. Besides that, the other major features are the typical "shadow spikes" that stretch off into nowhere. Whereas there's major spikes jutting off Serge's back in the first video in this post, the vertex dislocations on his back are far less pronounced in the second vid.

The true significance of this post is that I divided the first section of model data into about 30 equal intervals so that I could spread changes evenly throughout the data. I tried at one point to change the value at relative offset 29 (on the first row of data just after the full model header), but that caused my emulator to scream bloody murder and crash when it tried to load Serge's battle model. Therefore, the earliest rows of data in the first section are critical in some way. Perhaps they constitute an internal header that applies to the vertices?

Also, perhaps very importantly, perhaps not, I've found a fascinating byte-value progression pattern that lasts from approximately relative offsets 28F0 ~ 4247 in Serge's battle model data. It's rather difficult to explain without a visual aid, so--

http://img230.imageshack.us/img230/9238/successionpatternth7.gif

The columns outlined in red progress in the following way.

xx xx xx xx xx xx 01 yy - xx xx xx xx xx xx 02 yy
xx xx xx xx xx xx 03 yy - xx xx xx xx xx xx 04 yy

And so on. The "yy" columns outlined in green evolve from 00 to 01 to 02 once the red-highlighted columns run their course from 01 to FF. At relative offset 4247 the data loses this pattern before the green-outlined columsn can progress fully to 03.

I'm not sure what it means though. Before I move on to examine the second section of Serge's model data, I'll see if I can find this pattern in Kid's or Guile's battle models.

I'm attaching my notation of which offsets I changed to yield the videos above. The first part of these notes corresponds to the first new video, the second part details a dud attempt due to game crashing, and the third part corresponds to the second new video.

Anyway, is it safe to assume that the first section of battle model data pertains to vertices, and vertices only?

EDIT: In my notation, "OByte" signifies the original byte value, while "NByte" signifies the new byte value to which I changed the offset.



[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on November 13, 2007, 12:34:16 pm
If by "vertices only" you mean just the spatial position of vertices in the model, then I doubt this is the only data in the first section. I don't think there are enough vertices on the Serge model to fill that space, and the hex data suggests there are multiple subsections within the first section anyway. More likely is that the first section contains all of the vertex, normal, and texture data, the face data (i.e. how to connect the vertices together), and maybe one or two other little things.

I had noticed that section you pointed out before, but now that you've posted that image the pattern in the red-boxed locations is obvious. This is very close to what was suggested would be the pattern for the vertex data, only instead of using 00 00 as padding bytes to make each vertex 8 bytes, some sort of counter bytes appear to be used instead. Also interesting in that section of hex code is how every second column has entries that are only either 00 or FF (excluding the boxed columns, of course).
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 13, 2007, 01:26:40 pm
Hopefully this vid will help illuminate things:

http://www.youtube.com/watch?v=mlQctDrSJek

I overwrote that "special" section Luminaire speaks of in part one of the model data with its equivalent in Kid's model, leading to Serge's complete and utter discombobulation. It should be noted that Kid's "special" section is similar to Serge's but not identical in structure. Hers follows this pattern:

xx xx 01 yy xx xx xx xx - xx xx 02 yy xx xx xx xx
xx xx 03 yy xx xx xx xx - xx xx 04 yy xx xx xx xx

The "special" section in part one of Guile's model data does follow the same general pattern as Serge's does though. I'll write Guile's data over Serge's next and see what happens.

So Luminaire, we'll probably need to identify which parts of section one of the battle model data pertain to various aspects of the model. Have you seen a subheader for the first section at all? I imagine it probably occurs starting at relative offset 20 but I'm unsure how long the subheader would be. In any case, I'll take a closer look at that later.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on November 13, 2007, 01:55:18 pm
The header starting at 0x0020 is not a strict pointer table like that at 0x0000. However, there appears to be part of a pointer table within it:

Offset        Value                Comments
0x00200x00000002?
0x00240x00000014?
0x00280x00000208?
0x002C0x042B0205?
0x00300x000000F9?
0x00340x00000338Pointer to start of ? section
0x00380x000028C8Pointer to start of ? section
0x003C0x00004228Pointer to start of ? section
0x00400x00000011?
0x00440x00000000?

My guess is the header ends at that point, although I could be wrong.

The subsection that starts at 0x0358 (0x0338 + 0x0020 for the offset to the start of this section) has a sharp decrease in the density of zeros as the subsection that precedes it. Near 0x28E8 is the reverse: a sudden increase in the density of zeros after that point. And I believe 0x4248 is the end of the "special" section we've been discussing today. I don't see any significance to 0x0034 and 0x0228 yet, other than the former's presence in the table above.

Lots of questions marks to hopefully fill in above.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 13, 2007, 02:24:07 pm
Ah, very good! If the offsets are relative to the subheader, then the pointers to 28C8 and 4228 correspond to offsets 28E8 and 4248 in Serge's overall battle model (untextured). Aaaand, budda-bing, offsets 28E8 ~ 4247 do represent all the "special data" we've been talking about!

We'll have to think of a name for this "special" data, then you can fill that in in your section one subheader table Luminaire.

Thankfully, the "special" data doesn't seem to have its own sub-subheader because it starts right into the byte progression pattern.

EDIT: Oh, and I just found the following utility. I'm going to start tossing some Chrono Cross data at it when I get a chance:

http://www.backerstreet.com/rec/rec.htm

Looks like it *might* be useful. It works with PlayStation compiled data, but is says "MIPS Target only." Anyone know what that means, exactly?

EDIT: Doesn't seem that the REC decompiler is giving me anything useful. It only works on the SLUS file and doesn't give me anything I couldn't have found with a hex viewer and disassembler, but perhaps others more experienced than I would have expected that. :mrgreen:

UPDATE: If the following 32 bytes constitute the section one subheader in Serge's model file...

(http://img80.imageshack.us/img80/5070/section1subheadersp0.gif) (http://imageshack.us)

The final three sections are definitely all pointers. The blocks marked "xxxx", "yyyy" and "zzzz" below...

| aaaa | bbbb | ????  | ????
| ????  | xxxx | yyyy | zzzz

Correspond to (xxxx) the beginning of a very dense hex string with no 00 bytes; (yyyy) the "special data"; and (zzzz) whatever comes between the "Special Data" and the end of the first section.

I will say that "aaaa" and "bbbb" are the same for Serge and Kid, but not Guile. So these do not provide any kind of common header lead-in.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on November 13, 2007, 06:56:45 pm
The final subsection of section 1 - from 0x4248 to 0x4EF7 - also has a common pattern of ii jj kk 00 for seemingly any byte values ii, jj, and kk. This section is 3248 bytes long, and if it contains 32-bit chunks, then there are 812 of them. Guess how many 64-bit chunks are in 0x28E8 to 0x4247: 812!

For reference, the second of the subsections - from 0x0358 to 0x28E7 - is 9616 bytes long and the first subsection - perhaps 0x0048 to 0x0357 - is 784 bytes long. (Note that what I called the second subsection is the first referenced in the header, and starts at 0x0358.)

Not sure what all of this means exactly. 812 seems like a lot of vertices for the Serge model, doesn't it?

Edit: Fixed typo.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 13, 2007, 07:18:03 pm
VERY good find, Luminaire! When you say that the final subsection lasts from 4248 to 43F7, do you mean 4EF7? Just checking.

I have no clue whether 812 vertices would be too much. However, we can compare to Kid's and Guile's models and see if theirs have similar numbers (which they probably do). On what basis can we assume that there's 32 bits (4 bytes?) per vertex in the final subsection? If there were 8 bytes per vertex in that section, it would bring the number of vertices down to 406, which might be more reasonable, perhaps. But I know no more than a stone when it comes to 3D modeling (I've gotta read those docs Halkun and Cyb provided yet).

Halkun, Cyb? How many vertices did Final Fantasy 7 character battle models typically have? I imagine Chrono Cross would have more because the models should be more detailed, but it could give us a rough ballpark figure on how many vertices the typical PlayStation character model has.

Anyway, the next step I'm going to take is to start fooling with each subsection of model data (meaning, each subsection within the first section) separately and see what happens. We'll document the probable data contained within each section based on the effects, then move on to the second full section of model data.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Cyberman on November 13, 2007, 08:16:12 pm
Also, perhaps very importantly, perhaps not, I've found a fascinating byte-value progression pattern that lasts from approximately relative offsets 28F0 ~ 4247 in Serge's battle model data. It's rather difficult to explain without a visual aid, so--

http://img230.imageshack.us/img230/9238/successionpatternth7.gif

The columns outlined in red progress in the following way.

xx xx xx xx xx xx 01 yy - xx xx xx xx xx xx 02 yy
xx xx xx xx xx xx 03 yy - xx xx xx xx xx xx 04 yy

And so on. The "yy" columns outlined in green evolve from 00 to 01 to 02 once the red-highlighted columns run their course from 01 to FF. At relative offset 4247 the data loses this pattern before the green-outlined columsn can progress fully to 03.
That appears to be vertex data IE the 3d locations Notice the numbers in the other columns are SIGNED SHORT INTS. IE D8 FF is FFD8 or -40. The incrementing numbers (since that 4th column can't have any real use but MUST exist due to the 32 bit alignment issues in the PSX to maintain performance), are likely them making better use of this memory.  Could be the vertex ID's (my guess at leasT). So you have found the VERTEX pool is my guess :)

Cyb
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 13, 2007, 08:46:31 pm
Thanks Cyb! We can most likely start calling the final subsection "vertex data" then! Yay! :D

Oh! But before we consider the term "vertex data" safe for the final subsection, does the fact that the final subsection of Kid's model data progresses based on the following scheme...

xx xx 01 yy xx xx xx xx - xx xx 02 yy xx xx xx xx
xx xx 03 yy xx xx xx xx - xx xx 04 yy xx xx xx xx

...change anything? It's just like Serge's model, but her vertex data seems shifted left by four columns.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on November 13, 2007, 09:13:16 pm
Four columns is probably okay. If it was not a multiple of four, I'd be worried.

I was thinking the same thing about the format of the vertex data. But can we just take the values directly from the hex? When I do I get the attached picture. I also attached a .zip file containing a .blend file (for Blender (http://www.blender.org/)) since it's hard to see the 3D position of the vertices in a single 2D image.

Of course, we still need to determine how the vertices are connected into faces.


[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 13, 2007, 09:32:23 pm
NICE work there, Luminaire!! OMG, I think I can actually see Serge in that cloud of vertex dots, sort of. Unfortunately my graphics card (ATI Express IIRC) detests Blender, so I won't be able to check this out personally until I have time to let my PC sit there and make crunching noises while it tries to load the model data.

Does this mean a plugin doesn't even need to be written to view the data? But I expect it will have to be done to view the full model with textures and all.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Cyberman on November 13, 2007, 10:15:51 pm
There should be a vertex list somewhere.  You found the GPU polygon commands correct? The list should be about the exact same number of entities as there are polygon opcodes in 4 word columns (Again a multiple of 32 bits). Triangle information likely terminates with a zeroed column. So I would look for data that has 0 spaces in the same ordered location as the triangle data does in the GPU opcode list.
Then you will have
Vertex Data
Polygon Vertex List
and GPU opcodes with UV locations in the textures.

Cyb
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 13, 2007, 11:35:03 pm
I've found the GPU opcode commands in Halkun's doc, so that's a start. :D I still have to find them yet within the model data, however. Looks like that's next on my list of things to do then, because that'll answer some questions.

Luminaire, I don't know if you've seen Halkun's PSX doc yet. If not, you can download it directly here:
http://www.zophar.net/tech/files/psx.pdf

GPU opcode info starts on page 38 as viewed in Adobe Reader. On p. 39, I think the table labeled "0x2c textured 3 point polygon" should read "0x2c textured 4 point polygon." Am I correct in that, Halkun?

Halkun or Cyb, it is my current understanding that there should be one GPU opcode per "face," right? Since each GPU command specifies three or four vertices... So if we were checking out, say, a pyramid with a triangular base, there would be four GPU commands to look out for?

And, will the color bytes directly following a GPU opcode be 00 bytes if the GPU opcode pertains to textured polygons? Or would the color bytes be used for shading in that case?

EDIT: I thought I should mention that I'm seeing an anomoly in the vertex pool. I hope this doesn't change things too much. Basically, there's a point at which the byte progression scheme changes. Right in the middle of the data, it will change from:

xx xx xx xx xx xx 01 yy - xx xx xx xx xx xx 02 yy
xx xx xx xx xx xx 03 yy - xx xx xx xx xx xx 04 yy

to:

xx xx xx xx xx xx 01 yy - xx xx xx xx xx xx 01 yy
xx xx xx xx xx xx 02 yy - xx xx xx xx xx xx 02 yy

Thus, the byte progression slows down to half-pace, I guess you could say. Here's a graphical illustration:
http://img144.imageshack.us/img144/4627/subsection1anomolyyv2.gif

I'm not sure what significance it has, if any.


Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 15, 2007, 01:28:29 am
Time for an update so large it needs a new post. To summarize our progress so far, I've more or less mapped everything we know about the header and first section subheader anatomy of the battle models, using Serge, Kid, and Guile as examples. Everything's listed as hexadecimal offsets.

In the hex viewer representations reproduced below, the byte strings are broken into four-byte chunks by red lines (for the overall model header) and blue lines (for the first section subheader). Relative offsets we've identified in the subheaders are followed by their true addresses in the model files (in parentheses). Anything we (or at least I) have not identified yet will receive the "???" treatment.

I always ignore the fifth line of hex code for Serge and Kid, but it becomes extremely important in the first section subheader of Guile's model.

First up is Serge's header and first section subheader:
(http://img248.imageshack.us/img248/8062/sergeheadersubheaderrv8.gif) (http://imageshack.us)
Header: 00 ~ 1F
6 Sections           | Section1 0x20       | Section2 0x4EF8 | Section3 0x50C8
Section4 0x5228  | Section5 0xA2CC  | Section6 N/A      | EOF 0xABDC

Section1: 20 ~ 4EF7
SubHeader: 20 ~ 3F
Pointer to Gobbledegook  | PointerTable 0x14(34)       | ??? 0x0280                       | Gobbledegook 0x042B0205
??? 0xF9                         | SubSection2 0x0338(0358)| SubSection3 0x28C8(28E8)| SubSection4 0x4228(4248)
SubSection1: 40 ~ 357
SubSection2: 358 ~ 28E7
Vertex Pool, SubSection3: 28E8 ~ 4247
SubSection 4: 4248 ~ 4EF7



Next up is Kid's model header and first section subheader:
(http://img248.imageshack.us/img248/2448/kidheadersubheaderls4.gif) (http://imageshack.us)
Header: 00 ~ 1F
6 sections           | Section1 0x20     | Section2 0x4DB4   | Section3 0x50C4
Section4 0x5224 | Section5 0xC6F0  | Section6 N/A         | EOF 0xD000

Section1: 20 ~ 4DB3
SubHeader: 20 ~ 3F
Pointer to Gobbledegook | PointerTable 0x14(34)       | ??? 0x0238                        | Gobbledegook 0x040701D9
??? 0x0226                    | SubSection2 0x0374(0394)| SubSection3 0x2C04(2C24)| SubSection4 0x4264(4284)
SubSection1: 40 ~ 393
SubSection2: 394 ~ 2C23
SubSection3: 2C24 ~ 4283
SubSection4: 4284 ~ 50C3



Guile's Battle Model Header and First Subsection Header:
(http://img248.imageshack.us/img248/9894/guileheadersubheaderjz9.gif) (http://imageshack.us)
Header: 00 ~ 1F
6 Sections           | Section1 0x20      | Section2 0x4C3C  | Section3 0x4F10
Section4 0x5070  | Section5 0xE41C  | Section6 N/A        | EOF 0xED2C

Section1: 20 ~ 4C3B
SubHeader: 20 ~ 4F
Pointer to Gobbledegook       | PointerTable 0x20(40)         | ??? 0xD8                           | ??? 0x016C
??? 0x01B8                          | ??? 0x025C                        | Gobbledegook 0x049A034B | ??? 0x02BE
SubSection2 0x033C(035C)   | SubSection3: 0x2A38(2A58)| SubSection4: 0x40D0(40F0)| ??? 0x0D
SubSection1: 50 ~ 35B
SubSection2: 35C ~ 2A57
Vertex Pool, Subsection3: 2A58 ~ 40EF
SubSection4: 40F0 ~ 4C3B


I'm still trying to find GPU opcodes within the model files, and so far I've come up dry searching through the first section of everyone's models. GPU opcodes wouldn't occur in the textures themselves, right? It should be in with the model data to my understanding.

EDIT: Luminaire85 has determined that the first 4-byte string in the first subsection header points to a section of data that I've termed "Gobbledegook" (solely for the reason that we don't know what it represents yet).
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: halkun on November 15, 2007, 05:18:38 am
Keep in mind, there isn't a steadfast rule that the opcodes will even be there. they happened to be in FF8. They might just be another vertex list. FF8 used both quads and triangles and the opcodes were  needed because 1) they flagged a difference between the following data. 2) it was one less byte they had to "prep" for the GPU.

If they went all quads or triangles, then the number of vetexes will be assumed.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on November 15, 2007, 09:15:45 am
Note that Guile's section 1 subheader starts with the value 0x00000005 instead of 0x00000002 like Serge and Kid. If you read five 32-bit sections after that point in Guile's subheader, you reach the same sort of data as when you read two 32-bit sections after that point in Serge's and Kid's subheaders. So I think the subheader format is still consistent, but as yet don't know what the extra three numbers in Guile's subheader refer to.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 15, 2007, 12:53:45 pm
Halkun and Luminaire, thanks again!

As long as we're able to decode the file format bit by bit (literally, as we seem to be doing with the headers now :D), I guess I won't worry about the GPU opcodes for the time being. If I'm unable to find them, perhaps the model format used in Cross really is significantly different than that used in FF8.

Luminaire, I see the subheader pattern now! The very beginning 4-byte set is sort of like a pointer itself, and tells where a certain section of data begins.

So in Serge's subheader, there are 2 4-byte sections between the first subheader section and what I like to call the "gobbledegook section", i.e., one that doesn't make any sense to me (yet). In Serge's subheader, that "gobbledegook section" reads 0x042B0205. Likewise, in Kid's subheader there's 2 4-byte sections between the beginning and the section that reads 0x040701D9. In Guile's, however, there are 5 4-byte sections filling the space between the subheader beginning and 0x049A034B.

The "gobbledegook sections" all seem to be similar in a way. Their values (in decimal notation) are:

Serge: 69,927,429
Kid: 67,568,089
Guile: 77,202,251

The fact that they're odd numbers is confounding; if they were divisible by 8, they might contain info on the number of vertices or something.

But the 0x02 and 0x05 don't point directly to the Gobbledegook Section; they point to the sections that read "0x0280" in Serge's subheader, "0x0238" in Kid's, and "0x025C" in Guile's. Is that what you had in mind, Luminaire?

Oh! And the second section of the subheader is a relative offset to the pointer table! In Serge's subheader, the pointer table begins at offset 34 (14+20), it's the same with Kid, and Guile's starts at offset 40 (20+20)!

If we can all agree on these observations, I'll add them to my map on the previous page. Our combined efforts are making this process go very smoothly! Thanks again everyone!!

Our analysis of the CC battle model format will be eventually be compiled into a page on the Compendium Encyclopedia no doubt. Halkun and Cyb, would Qhimm like this info too for the wiki over there?

As for next steps...

The section to which the 0x02 and 0x05 point could constitute a relative offset to some type of data further on in the first section. I wonder what? Could there be even more subsections hiding in the first section?

Once we determine the total number of subsections, I'll mess with them one by one so we can make observations on the type of data affected with visual Youtube evidence.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on November 15, 2007, 03:58:13 pm
I think the 0x02 and 0x05 represent the number of 32-bit sequences to read before you will get to the "gobbledygook" 32-bit section.

I am wondering if that "gobbledygook" is meant to be read as two 16-bit values or four 8-bit values or some combination of those. The values that result don't have immediate significance to me, but maybe they will later.

I have had no luck finding the opcodes either.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 15, 2007, 06:46:16 pm
Okay, thanks Luminaire. Yes, I think the "Gobbledegook Sections" may have to be split to make sense of them. I'm updating my subheader anatomy map to reflect the knowledge we've gained today, then I'll get back to trial-and-error experimentation with each subsection over the coming days. I still worry that the first subsection may in fact be several subsections, and if that turns out to be the case, I'll go back and mess with those individually.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on November 15, 2007, 09:00:59 pm
Is this where we stand on the structure of the first section? I'm using offsets from the very beginning of the model data, and specifically for the Serge battle model for now:

Range                 Length (bytes)    Contents
0x0020-0x004740Header - two pointer tables separated by "gobbledygook"
0x0048-0x029F600Unknown
0x02A0-0x0357184Unknown
0x0358-0x28E79616Unknown
0x28E8-0x42476496Possibly vertex data
0x4248-0x4EF73248Unknown - pattern is xx yy zz 00

I'm not sure yet that 0x0228 represents a break between sections - it's hard to see a difference in the hex code around that point. Also, I had the thought that the 0x4248-0x4EF7 section could be some sort of color data, only because 8 bits each for red, green, and blue and 8 bits of buffer fits with the pattern and since there are 812 such points and 812 vertices. Just a random thought though.

Would it be worthwhile to be keeping track of our current map of the battle model format on a Compendium encyclopedia page? I would certainly be willing to help update it as we figure things out.

EDIT: Arg, looks like I've been looking at hex code too long. Fixed an error.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 15, 2007, 10:56:08 pm
The header ending at 0x0047 looks good. I'll re-up Guile's header with an extra row in my previous map post based on that observation, because that'll push the end of his subheader into the 0x50 range.

Nothing wrong with starting an encyclopedia page at this point -- it would help to have something stationary we could access and alter easily. Our maps keep getting lost as we continue posting away. :lol: I'll see if I can get a page going this weekend. Do you have access to the wiki creation area, Luminaire? If not, PM Zeality and he can probably get you set up.

The color idea for 0x4248~0x4EF7 is a better theory than anything I've come up with. I wonder if it has to do with shading of the model? In any case, I can easily test the color theory by overwriting that section of Serge's data with another character's.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Cyberman on November 18, 2007, 10:14:03 am
Just in case you folks are utterly bored (not likely but .. hey). The weapon models in FF7 apparently are separate. They have a separate set of animation.  They are just lumped together with the battle model.  It's likely CC does the same thing (as it would be annoying to load each separately along with a single set of animations).
I'll point you to someplace things will be explained perhaps more clearly.  Go here to read. (http://forums.qhimm.com/index.php?topic=7185.0) Erstwhile if the weapons are separate, it's not likely they created new animations for each weapon (that would be insanely expensive to do).  So some of what you folks might be calling junk might be useful information.  Namely you might want to find the EXACT number of battle models and look for that number inside the header.
An aside animations are SMALL chunks of data if they are deltas (likely) the format used in FF7 is a bit complicated.  In any case the animations are likely compressed (as they consume a lot of space otherwise). So look for a list of pointers to data that has short increments (IE 8 to 500 bytes), and a lot of them as well.  These are likely your battle animations. The weapon likely has it's own set of animations as well. So it's very likely there is a large set of animations for those as well (they apply to all weapons more than likely).

Cyb
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: justin3009 on November 18, 2007, 10:28:02 am
I've been waiting for them to kinda mess with that.  It'd be kinda funny to see serge doing a Swallow stance for daggers >_>..
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 18, 2007, 05:15:35 pm
Updates will begin to flow forth once we've got the Encyclopedia entry for Chrono Cross battle models up; check the CC File Structure Page tomorrow for that. I'll link when it's ready for those who haven't seen the various file structure maps Luminaire and I have buried throughout this thread.

Thanks for the weapon model animation tips, Cyb! I'm going to be messing with character battle model data subsection-by-subsection over the next few weeks probably, so that should help us determine where the weapon animations are stored. I do know how many weapons each character has, so I'll keep on the lookout for header values that correspond to those numbers.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: ZeaLitY on November 18, 2007, 06:17:31 pm
I was poking around the outputted Nemesis data while checking to see if the debug menu text is in the scripts today and found the rooms folder. Not that it matters, but as expected, there are three files per room: two CPT files (images, script) and one DRP file ('other').

At any rate, we have Nemesis's real e-mail, so his schedule providing we can ask him some short questions if needed.

Anyway, looks like the debug menu text doesn't get dumped, which may have interesting ramifications for this entire debug thing.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 18, 2007, 08:07:30 pm
WOW Zeality, you figured out how to use Nemesis' tools successfully? DAMN my effort to formulate a months-early Xenogears April Fools joke, I should have been spending my ounce of free time at the Compendium! Can you fill us in on how you got Nemesis' utilities to work?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: ZeaLitY on November 18, 2007, 08:22:24 pm
Oh jeez, I'm having a hard time remembering, and I can't exactly try again right now. But it's important to remember that Nemesis's tools don't dump the rest of the assets. I guess they dump the rooms in case translators need to change graphical text. So we're still better with Yazoo's for the 3D.

\CD1\10_Image_Avant

I stuck the ISO in there and named it CC_CD1.iso. Then I opened Chrono_Cross.exe and executed "Dump_Main". I think that's it. Naming CC_CD1.iso was the only iffy part, and Sephiroth gave me the correct file name.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 18, 2007, 08:34:54 pm
Aha, thanks Zeality. I'll try again with Nemesis' utility later, since I'm intensely interested in the LZSS decompress function it contains IIRC. I wonder which files are compressed?

And getting away from model data for a second, do you happen to know which OUT files contain game script (as in dialogue) data? That'll be crucially important for text hacks, and I suspect the dialogue and accent files are compressed since I'm not seeing a hint of game text in the ASCII section of my hex viewer.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: ZeaLitY on November 18, 2007, 09:37:10 pm
If the room thing under Nemesis's structure is right (as in, if it uses Yazoo's basic setup), then the first of each set of three OUT files per room (compressed) should contain it.

Uncompressed, it looks like 8script is it under the \code folder.

I opened up a command line and ran the script-dec program in Yazoo's tools. Now, a bunch of new files have appeared in the \code folder, including "outscript.txt", which apparently contains the final result. Yep, and there's the dialogue. But would you look at that...the debug menu text is in EVERY location! I guess Nemesis's tool automatically nullifies it since it's so redundant. But hey, this is great, since it confirms that the debug menu is independent of the map I accidentally found it on.

Who knows what the script's compression type is, though? It's probably in Nemesis's user guide for his tools. Sephiroth can probably even tell us right off.

As a byproduct of this research into the mapping system, I can now deduce the location of the unplaced text in the Chrono Cross script. That'll be a great coup for the Compendium.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 20, 2007, 04:11:07 pm
Awright, we've got an entry for character battle models now. Check it on this encyclopedia page: http://www.chronocompendium.com/Term/Chrono_Cross_File_Structure.html

Feedback is welcome, especially error corrections and stylistic suggestions.


Now for some more Youtube vids showing screwed up character models. I'm going subsection-by-subsection within the first section (arg, that's confusing to type) of Serge's character battle model. I shall now use the nomenclature Section 1-1, Section 1-2, etc., to refer to the subsections within...the first section.

Section 1-1: Offset Range 0x48 ~ 357 (Subheader from 0x20 ~ 0x47 remains unchanged)
I don't actually have a vid for this yet, but I hope to in the future. A study of the first subsection is going to be tedious, because I can't simply overwrite Serge's data with another character's without the game freezing upon trying to load the model. My emulator tells me it's being forced to execute "illegal opcodes" as illustrated here: http://img159.imageshack.us/img159/9781/illegalopyv6.gif

I've previously changed a few bytes at a time within this data range without such consequences. I'll go through byte-by-byte sometime and make sure I'm keeping the "structure" intact, i.e., columns of 00 bytes may have gotten shifted this time around and maybe that's what's causing the trouble. Advice is welcome, 'cause I don't know what the heck's going on with this yet.

EDIT: The emulator is reporting an illegal opcode starting with value "2C" in one instance. Halkun, could this be a textured quad opcode!? Maybe I can find it in the model data after all, and somewhere within this section...


Section 1-2: Offset Range 0x358 ~ 28E7
http://www.youtube.com/watch?v=is5YdHgvJHg

Now, THIS is intensely interesting to me. Once again I've taken a section of Kid's model data and written it over Serge's, producing this mess of "shadow spikes," as I like to call them. Can anyone determine from this vid what type of data is being affected?

Also, I'd like to note that when Section 1-2 is messed with in such a way, I can no longer get Serge to perform a "fierce" (i.e., 3-stamina point) regular attack, nor can I get him to do his "Dash&Slash" special without the game crashing. He can do his other regular attacks and can cast other spells. So does this mean I've touched upon some animation data, or is the emulator just flipping out because it can't handle these animations with all the shadow spikes sticking out of Serge, I wonder?


Section 1-3: Offset Range 0x28E8 ~ 4247
http://www.youtube.com/watch?v=yrJQ5r0rSaE

Once again, data from the equivalent subsection of Kid's battle model has been pasted over Serge's. I think I see one "shadow spike" here, which is odd -- I would have thought all those were accounted for back in Section 1-2. But other than that, anyone know what kind of model data has been affected? We had taken to calling this subsection the "vertex pool." Do the results seem to jive with that label?


Section 1-4: Offset Range 0x4248 ~ 4EF7
http://www.youtube.com/watch?v=QIPrAZ2Vyas

This time I lifted the data from Guile's battle model and pasted it over the equivalent subsection in Serge's model. BUT - NO CHANGE!? I've re-checked time and again, and I've surely successfully overwritten Section 1, Subsection 4 of Serge's model with data from Guile's. Earlier Luminaire and I were hypothesizing that this data may correspond to color values or perhaps shader values. I can't see any difference between this and Serge's unaltered battle model, which I link to below:
http://www.youtube.com/watch?v=snlWXhjPYM8

The data change was significant, yet no visible alteration of the model. What gives?


That's enough for now, I think. I'd like to get feedback on the results for Sections 1-2 and 1-3 especially. For those who live in the US, or any other country that happens to worship turkeys this Thursday, have a happy Turkey Day!
 
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Cyberman on November 20, 2007, 07:43:58 pm
Quote from: FaustWolf
Once again, data from the equivalent subsection of Kid's battle model has been pasted over Serge's. I think I see one "shadow spike" here, which is odd -- I would have thought all those were accounted for back in Section 1-2. But other than that, anyone know what kind of model data has been affected? We had taken to calling this subsection the "vertex pool." Do the results seem to jive with that label?
It looks like it is so. The thing to keep in mind is the ordering of the vertex information is VERY specific with the Ps1 it is LEFT handed IE A B C are counter clock wise and the normal projects in the direction of the thumb from your left hand. (Make a fist partially relax your left hand and poke your thumb straight up and you get the idea right away.) That is only the triangle. HOWEVER the Quadric is a bit different since internally it is split into 2 triangles by the hardware. The ordering for a quad will be A B D C instead because of this.
See diagram I drew about 4 years ago here
Code: [Select]
Triangle Quad
B--C    B--D
|  /    |  |
| /     |  |
|/      |  |
A       A--C
What you have done is got the vertex references out of order and you notice a number of triangles missing (because they are invisible from the direction of there normal surface likely).

Your actual vertex data is NOT changing. Remember they aren't Vertex's they are references to vertexs (IE points in the model). Change the references your vertexs don't move just there ordering.  So this confirms they aren't vertex but references to vertexs.

Section 1-2 is likely the actual vertex information. Namely you killed the dimensional characteristics of the model when you messed with it.  The next thing to find is how this information is held together. I'm sure there is information on what blobs of polygon data are what.  (IE Section 1-3 is possibly your triangle data and 1-4 is likely your quadric attempt to add something into the fourth column in 1-3 in some of the data and see if anything at all happens if nothing then it's .. triangle data only and 4 is likely quadric).

Cyb
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 20, 2007, 08:25:55 pm
More wrinkles in my brain, Cyb! Now, in section 1-3 (vertex pool references), the data are arranged like so when viewed with a hex editor:

xx xx xx ** xx xx 01 yy - xx xx xx ** xx xx 02 yy
xx xx xx ** xx xx 03 yy - xx xx xx ** xx xx 04 yy

...with yy starting at 00 and progressing to 01 and 02 until the data reaches section 1-4. The ** are either 00 or FF. Here's a snip of the actual data (you've probably seen it already in this thread):
http://img230.imageshack.us/img230/9238/successionpatternth7.gif

So I'm wondering what the best way is to treat the ** and yy columns when I change the values. I could just change the values to something arbitrary, like make them all 0x50 I guess.

Section 1-4 is arranged like so:
xx xx xx 00 xx xx xx 00 - xx xx xx 00 xx xx xx 00
xx xx xx 00 xx xx xx 00 - xx xx xx 00 xx xx xx 00

And a true representation: http://img516.imageshack.us/img516/6649/section14samplenw8.gif
...so every fourth byte is 00 there at least, if that means anything.


EDIT: I've just done two experiments with Section 1-4 -- first writing some 0xCC bytes over every fourth column, and secondly wiping Section 1-4 entirely (replacing all data with 0x00 byes). NO CHANGE. Zip. Zilch. Zero. Serge is completely intact in appearance and animations. What could it mean? Is Section 1-4 "extraneous"?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Cyberman on November 21, 2007, 08:00:12 am
No clue. I did forget about the vertex numbering (the brain leaks you know). I think we can assume that Serge et al are likely made entirely of triangles (that would be simple to do).  Dumb question did you view the textures on Serge? IE did they move any when you messed with section 4?

Cyb
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: yaz0r on November 21, 2007, 11:20:51 am
Hey there,
a few years ago, when my nick was yazoo (it changed a bit since as you may have noticed), I wrote some of the tools you've been using to hack into CC files.
It's been a long time for me, but maybe I can give you a few pointers on where to look and how things work in the game.

Also, some of you may have come to realise that since my work on CC, I wrote a bunch of model viewer for FFX/FFX-2/KH/KH2/FFXII/SOTC/... so maybe I can also help you on that side.

yaz0r
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 21, 2007, 12:08:41 pm
OH.MY.GOD!!  :shock:

This is another joyous day for the Compendium. Yaz0r, I had no idea you and Yazoo were the same Entity! First, let me give you a big THANKS on behalf of videogame fans and asset enthusiasts everywhere for the work you've done, both on CC and outside of CC.

There are SO many questions I'd like to ask you. I'll start with these:

1.) First, I guess I'd like your input on whether we're going about this the right way, from what you've seen of our investigations -- is there any more "powerful" way to figure out how a model format is set up other than identifying headers/pointer tables and then messing with the data to see what happens? What basic process(es) do you typically use?

2.) If our goal is to extract models and view them outside of the game, would it be best/easier/more efficient to write a standalone model viewer for CC, or to write a plugin for 3DS Max/Blender/Lightwave, etc.?

3.) What programming language is most, er, "effective" for writing model viewers? I believe you wrote at least one later version of your FFX model viewer in DirectX (if DirectX is even a language -- please forgive me for my inexperience in that regard). I'm so incredibly interested in videogame models that I'd be willing to plunk down some time and learn a programming language over the next few years just for the ability to do what you do.

Thanks for walking in here yaz0r, and thanks for any advice you can give this newbie hacker!

@Cyberman: No change in Serge's texture when I filled Section 1-4 with 00 bytes -- it appears to be assembled properly on the model at least. It's extremely odd.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: yaz0r on November 21, 2007, 12:55:39 pm
First, let me give you a big THANKS on behalf of videogame fans and asset enthusiasts everywhere for the work you've done, both on CC and outside of CC.
I have a few stuff that I decided not to release, like the SOTC model viewer, but I hope it will make it to the public hands someday...

Here goes for the questions:
1.) I can't realy say before I look into the model files myself. I'll have to redump the data files tonight when I get home. I don't have much expertise on PS1 games so I can't really tell, but I suspect that looking how the PS1 handle vertice format and things like that would be interesting.
I don't really have any predefined process when looking into a game, but most of the time, I try to have simple objects work before I try to get animated objets working. This is mostly a question of getting the basic geometric data figured out before starting the skinning.

2.) Writting a model viewer from scratch can be a tricky task. One solution would be to write a tool that would export the data to a more universal format. I suggest you look into the collada format as it's open and widely accepted.

3.) My model viewer is written in C++, and use DirectX for 3d rendering. While C++ is nearly a must-have for that kind of tool, the question of DirectX versus OpenGL is mostly a question of taste. I ditched the OpenGL version mostly to stop supporting old hardware as I wanted my modelviewer to be a testbed for more advanced graphic features. But this is behond the scope of a model viewer.
In term of learning curve, I figure OpenGL is simpler the get started. I suggest you take a look at nehe's tutorial (just google nehe). But keep in mind that learnign programming isn't something you do overnight...

Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on November 21, 2007, 01:20:05 pm
In regards to 2, I think it will be better (and probably easier) to import the data into 3D modeling environments than writing a standalone viewer. Blender makes this very easy since it provides facilities for writing custom scripts in Python. This way all we have to worry about is finding the data and adjusting it to the right format, and once the data is imported we can export it in other formats.

In regards to 3, like yaz0r I do all of my 3D/game work in C++. However, I use OpenGL (via the Simple Directmedia Layer (SDL) (http://www.libsdl.org/)) because I try to write only cross-platform code.

---------

Section 1-2 has been bugging me for a while now because I think it contains important information but I have had no luck in deciphering the hex code. That section is 9616 bytes long, or 601 16-byte sequences, but the hex code doesn't seem to follow that sort of pattern. I am starting to wonder (perhaps incorrectly) if it is compressed data.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 21, 2007, 02:47:50 pm
Yaz0r, I've attached Serge's battle model and Kid's battle model to this post, so hopefully that might save you some work. There are also "ModelMines" consisting of the battle models and all the textures applied to the battle and weapon models, ripped straight from Disc 1, so you can take a glance at how the models and associated weapons are arranged on the CD. I think your dumping utility might extract these things as separate OUTs in the MISC folders.

For the battle models w/o accompanying textures, everything we know so far is recorded here:
http://www.chronocompendium.com/Term/Chrono_Cross_File_Structure.html#Character_Battle_Models

Thanks for all the advice on coding and model viewing, guys! Now I know which things I'll need to look into to make this sort of thing a long-term hobby.

Luminaire, I think it was Section 1-3 that you managed to view in Blender earlier - have you tried loading Section 1-2 as raw data? Cyb believes it may be related to vertices as well, and I was wondering if anything would show up.

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: ZeaLitY on November 21, 2007, 03:48:39 pm
Yeah, big welcome from all of us. Exploring Cross with your tools has been an adventure, and we can't wait until we've documented everything.

Other than file sharing, our other big "goal" for the short-term is figuring out how Chrono Cross instructs the room GFX in the .raw files to set up. Then, Ramsus or someone else can write a program to assemble the GFX files like that and combine them with the ACT files that your tools provide, giving us instant background images for the encyclopedia.

Anyhow, thanks for stopping by! It's a great time for Cross fans now.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: yaz0r on November 21, 2007, 04:21:52 pm
Other than file sharing, our other big "goal" for the short-term is figuring out how Chrono Cross instructs the room GFX in the .raw files to set up. Then, Ramsus or someone else can write a program to assemble the GFX files like that and combine them with the ACT files that your tools provide, giving us instant background images for the encyclopedia.

Regarding that part, I know someone who made a tool to do something similar with Parasite Eve. I think it's really close to the way CC store it's background so I'll be asking him for pointers..
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on November 21, 2007, 05:32:17 pm
I attached a picture of the Section 1-2 data, read as if each 6-byte set represented a vertex. I chose that because I thought I saw a vague pattern to that end in the hex, but as you can see, the picture does not look anything like Serge.

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 21, 2007, 06:16:30 pm
Thanks for checking that out Luminaire. I'm going to change Sections 1-2 and 1-3 simultaneously this time (from Serge's data to Kid's) and see what happens. It may be that there's some direct relationship between these subsections, which may become apparent when we view the results. I'll report back later and post a vid if it's anything worth seeing.

EDIT: Well, this is weird.

I overwrote Sections 1-2 and 1-3, additionally changing the subsection start values in Serge's first section subheader to match Kid's. Nothing important enough to make a new Youtube vid over (the changes aren't extraordinary), but I did notice something that may be useful. Specifically, I believe the "shadow spikes" are in fact stretched textures. BUT - there's a complicating factor. See for yourselves (these are JPEGs to preserve quality - 56k users beware):

http://img514.imageshack.us/img514/6243/sergetexhs8.jpg
A section of Serge's texture apparently stretched away from his model upon a "shadow spike."

http://img410.imageshack.us/img410/9002/sergefacetexqf5.jpg
Another.

http://img410.imageshack.us/img410/8236/glenntexxr8.jpg
This is where things get really odd. This is part of Glenn's texture jutting out of Serge's battle model! However, notice that the texture is discolored because it seems to be filtered through Serge's CLUT.

Note that Glenn's texture isn't jutting out of Serge's model when Glenn isn't in the party; another character's texture takes its place. Sooo -- is it possible that messing up Section 1-2 causes the emulator to barf up some of what's in VRAM?

Just an oddity for people's consideration. It probably doesn't help us whatsoever, but wanted to report it.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Cyberman on November 21, 2007, 11:43:34 pm
It's not odd.
The UV coordinates AND the texture page are all used to generate the data. So if things are over written correctly you will get strange texture information in the polygons being shown.
Further more I think this just reinforces that this is potentially UV data (so 6 bytes per UV (1 byte inside each page) if you dump the video memory It's possible to view what page is where. Just moving the page information shifts what data is being used, with a specific palette. 

Read up on it in PSX.PDF.  Part of the puzzle is really in there.

The GPU opcodes appear to be assembled and sent via DMA to the GPU from the model data you have thus far.  How they are assembled currently is a bit of a mystery. To me sections 1-2 and 1-3 are likely vertex indexs and UV information (If I was following all the nomenclature being used).

You may want to look through some of the data as signed short ints (2 byte integers -32768 to 32767) 1 byte unsigned (0-255) word etc. See what you might be looking at. The fact one could take some of the data and construct an outline of serge from it is a definite hint it is THE vertex data.  The data that showed a snow flake pattern is likely vertex information.  What is left is UV Information and texture page information. 

Cyb
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 22, 2007, 02:13:06 am
Thanks Cyb! So judging from Halkun's PSX doc, each GPU opcode for textured polygons has associated texture page values that tell where in the frame buffer (VRAM?) the model's texture is supposed to be pulled from, is that right? If so, then it would appear that I tripped over some texture page data, since part of another character's texture is apparently being applied to Serge's model in the final pic I posted just above.

Which means, the GPU opcodes for UV maps may be in Section 1-2 after all, maybe. Hmm. I'm going to have a closer look at that subsection then.

...Which actually leads me to another question. When I look at Section 1-2 of Serge's model data, I'll be comparing everything with tables that appear as follows in Halkun's doc:
(http://img263.imageshack.us/img263/6124/psxdocexampleli9.gif) (http://imageshack.us)

The numbers running along the top of the table, from 0 through 31 -- do these represent bits? Hence, the 0x34 opcode is 8 bits, or one byte, "wide." Therefore, the "CLUT ID" element for each vertex would be 2 bytes "wide." It's probably a silly question, but I wanted to make sure I'm understanding these tables correctly before I delve in for another look.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: halkun on November 22, 2007, 05:18:32 am
Yup, those are bits. The GPU uses a 32-bit data latch so when a "row" of data is put into the GPU, you have to wait for GPU_READY singal for it to allow another "row" of data.

When using DMA transfers, this is taken care of by the DMA controller. When you manually place GPU packets into the GPU register, you have to wait and ask the GPU if it is ready to accept more data.

Direct GPU access is rarely used, DMA is an order of magnitude faster.

Oops, here is some vocabulary for you.

DMA == "Direct Memory Access"

DMA allows chips other than then CPU to have direct access to memory. This allows the chip to "suck" information down from memory without the CPU being involved, so the CPU can do more important tasks.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: yaz0r on November 22, 2007, 06:58:50 am
Don't forget that on PS1 hardware, the data isn't sent directly over the GPU, it is sent to the GTE that will perform all the math processing and finaly project the points in screenspace before sending them to the GPU for rasterization.
Therefor, you should look at the GTE documentation when it comes to vertex format.

It seems the GTE handle fixed-point data following this pattern:
1bit for sign
3bits for intergral part
12 bits for fractional part

I suppose all vertex data are in this format.

That said, I figured that it should be far easier to look into the weapon data than character data. Due to skinning, even if you display Serge's vertex array in 3d, it will not looks like Serge as the vertices will be lacking proper transformation by bones matrix.

Regarding the background data, it seems there is a bunch of DMA commands somewhere that just blit the background data to there correct position.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 22, 2007, 11:15:23 am
Thanks again for all the help guys. Before I turn to weapon models personally, I'm going to try and map out the rest of Serge's, Kid's, and Guile's battle models and mess with the data as I've been doing, just to see what happens.

Weapon models are in the packs I attached earlier -- they're inside the "ModelMines" for those who want to look at them. I believe I've documented where they are inside the model mines, but of course all offsets are relative, so keep that in mind when you're looking for pointer tables and such:
http://www.chronocompendium.com/Forums/index.php/topic,4770.msg84377.html#msg84377

I'm also going to quote a post by Lupus from Qhimm. He had a look at Serge's ModelMine before I confirmed the 3D model data to myself, so that's why he refers to "unknown data." He comments about the weapon models as well:

Quote
I had a look at the "modelmine" file, I just noticed only now.
The file is nicely structured a header and relative offsets to subsections, and each subsection has a similar header. The only exception seems to be the (probable) model data starting at 9800, this may be hardcoded in the game code. Same for 14800 which is a header containig pointers to the other subsections until the end of the file.
Section 00009800 ~ 00014800:
the first $20 bytes are a header. The first value may be the number of sections, the others are relative the offsets (relative to the beginning of current section, that is). Some of the sections are similarly split in subsections. I have no clue what they may be
Section 14800 - end of file:
header as above; the "unknown" sections between weapon textures are certainly weapon models.
for example, the first is at 15dc8. From there:
    0-7 unknown
    8-11 offset to vertices section
    12-15 probably offset to unknown section (at 15df0)
        this seems to be made of groups of 4 bytes. I nocited some textures have weid coloring,
        maybe models are textured AND color shaded.  They could be RGB values. (but the 4th byte?)
    16-19 probably offset to unknown section (at 15ddc)
The vertices section is a Cyber said above: groups of 4 2-bytes values, the last is 00 00. Vagrant Story is like this both for characters and weapons, but your model data here seems different.
Note how the first value also is often 00 00 or little more, that's because of the flatness of weapon models. However the last value sometimes is 01 00 or 02 00   
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: yaz0r on November 22, 2007, 01:18:53 pm
Thanks again for all the help guys. Before I turn to weapon models personally, I'm going to try and map out the rest of Serge's, Kid's, and Guile's battle models and mess with the data as I've been doing, just to see what happens. 

Out of curiosity, how do you mess the data ? Do you rebuild and iso with modified data each time ?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 22, 2007, 08:01:44 pm
When I alter the model data, I perform whatever "surgery" I intend to do on a copy of Serge's battle model, then simply paste that altered copy over Serge's battle model on my 2048 byte/sector game image using Cygnus Hex Editor. I've got a pretty efficient system worked out, though I need to transfer Serge's model offsets from post-it notes stuck on my wall to the CC File Structure wiki sometime 8)

I've not yet tried out the iso rebuilding capabilities in your Chrono Cross tools yet, yaz0r, or Nemesis' tools, I'm sorry to say.

I'll be happy to run experiments on weapon models if anyone thinks that would be useful in determining which sections in those might correspond to which types of data. Kid has one less weapon than Serge I think, so it's possible there should be a reference in the overall weapon models header to that number. I think it's 5 for Kid and 6 weapons for Serge IIRC.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: ZeaLitY on November 23, 2007, 01:10:38 am
Fortune smiles tonight. Some random guy hacked the debug menu 6 months ago, and published it on Youtube. Only 2,433 views have registered, so it didn't get much exposure. But while searching クロノ for more concert footage (god I hate that page), I found this:

http://www.youtube.com/watch?v=MWLDwjfiNHY

Quote
Debug menu (press L2 and push 1x R1)
8006B456 0101

So NOW we can mess with the debug menu's model options in whatever emulator [PEC] is compatible with. Or the PEC plugin, I guess.

Edit: Damn, this is just the map menu. Exit/return should take you to the main debug menu, but here it just cancels you back out to the game. Oh well; at least it's a start.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 23, 2007, 02:22:55 am
ePSXe works well with PEC (PSX Emulation Cheater), I think. What kind of model options did you expect to find, Zeality? Is there more to the debug menu than just model size adjustments?

On another note, I'm detecting only 18 or so instances each of 0x24, 0x2C, 0x34, and 0x3C (possible beginnings for GPU command strings) in Section 1-2 of Serge's model data. I would expect one opcode per "face" on the model, so 18 instances is too few for this section to be representing UV map data -- I think. Furthermore, many of the instances are spaced far too close together for a GPU command to fit in between. But is it possible that a model format would contain commands for multiple types of faces, i.e., is it possible it would use both 3-point and 4-point textured polygons, shaded and unshaded?

And would it be prudent to look for GTE commands within a model file? yaz0r and Halkun have already explained some aspects of the nature of GTE vertex data and commands, though rest assured I'll have more questions about those when I begin investigating this particular matter in depth.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: ZeaLitY on November 23, 2007, 02:44:56 am
Just those commands.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: halkun on November 23, 2007, 03:20:49 am
Look for 7F...

Just for fun
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: yaz0r on November 23, 2007, 07:30:10 am
When I alter the model data, I perform whatever "surgery" I intend to do on a copy of Serge's battle model, then simply paste that altered copy over Serge's battle model on my 2048 byte/sector game image using Cygnus Hex Editor. I've got a pretty efficient system worked out, though I need to transfer Serge's model offsets from post-it notes stuck on my wall to the CC File Structure wiki sometime 8)

I know of an alternate way that may interest you. I abused it back in the days I was hacking PSX stuff. The main idea is that you can just patch the emulator memory. In Epsxe, make a savestate and rename the savestate file in .tar.gz and use winrar du decompress it. You can now just search the data you wanna hack in the save state file and modify it.
The nice thing is that epsxe is able to load a uncompressed save state. Most of the time, I just had the game running in Epsxe and at the same time the save state open in an hex editor. I would modify a byte, save, and it the reload savestate key in epsxe to see the immedate result.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Sora on November 23, 2007, 11:37:14 am
tl;dr.

did we win yet?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 23, 2007, 12:24:15 pm
Thanks yaz0r. Yeah, Halkun suggested the savestate-alteration method earlier, but I've had a heck of a time getting my ePSXe to run my 2048 byte/sector iso for some reason. It runs my 2352 byte/sector bin file just fine IIRC, but I have this (probably unfounded) fear that the applicable data will appear differently than the model files I extracted from my 2048 byte/sector iso. I'll give it a go with my .bin file sometime, though, and see what I come up with.

@Halkun: There's about 50 instances of 0x7F in Section 1-2 of Serge's model. They are spaced at widely varying intervals (anywhere from 8 ~ 100+ bytes apart). What else should I look for that could go along with 0x7F? Is it an opcode of some sort?

@Sora: "tl;dr" isn't a clue regarding opcodes or anything, is it? To my still-untrained eyes, that looks an assembly language command, so I have to ask. :mrgreen:
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: ZeaLitY on November 23, 2007, 02:33:33 pm
Oops, the original code was right. My Hydra marshes experiences just led me to make the wrong assumption about the debug menu's structure.

Okay, here's GIANT KID and mirror-world Kid (setting y and z rotation values to max). Nothing really important here after all, unless the GIANT thing can somehow be tracked to its target model data.

Still no idea what "set rect" does.

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 23, 2007, 02:45:09 pm
Attack of the 50 Foot Woman! That's actually pretty amazing, because it shows how detailed the textures are on the character overworld models even - unless that's a battle model you got onto the overworld? Are there any problems getting the oversize characters through narrow passages? That might tell us something about how collision detection is handled.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: ZeaLitY on November 23, 2007, 03:07:29 pm
The changes don't carry map to map, and so far I've been able to access any exit. Kid can't run any faster than her counterparts; it's like picking up the weights at Greco's.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 23, 2007, 07:36:16 pm
Now that I've already made one movie reference in this thread, it's time to make an analogy to Terminator 2. Specifically, when Section 2 (not to be confused with Section 1-2) of Serge's model data is overwritten, he looks quite a bit like the T1000 when it's been blown apart by the Governator's grenade launcher at the end of the movie:

http://www.youtube.com/watch?v=QgVi-lTspDY
http://www.youtube.com/watch?v=smXwjqrCjIM

In the first vid, only Section 2 has been overwritten with Kid's equivalent data. In the second, both Section 1 and Section 2 have been overwritten with Kid's equivalent data. It would appear that Section 1 is definitely responsible for UV mapping based on the observable difference.

Also, here's more evidence of vertex data in Section 1: http://img340.imageshack.us/img340/7960/section1proof1zl6.jpg

See that piece of hair that's identical in both Serge's messed-up model and Kid's? It would appear that Kid's vertices have taken the place of Serge's when his entire Section 1 is overwritten with hers, but the result doesn't resemble Kid completely because a.) her model shape is being molded onto Serge's skeletal structure; and b.) Serge's skeleton probably doesn't have enough "bones" upon which to map her hair braid, etc.

I think Section 2 does not have its own subsections (it's very small relative to the other Sections), but I still have to figure out the header. When I do, I'll post it here so others can double-check my interpretation before I throw it up on the File Structure wiki.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: halkun on November 23, 2007, 09:57:36 pm
@Halkun: There's about 50 instances of 0x7F in Section 1-2 of Serge's model. They are spaced at widely varying intervals (anywhere from 8 ~ 100+ bytes apart). What else should I look for that could go along with 0x7F? Is it an opcode of some sort?

When I was taking apart FF8, that was kind of a "header" for a quad. I have a really good idea how to find the UV map.

1) Take kid's Texture map and load it in Gimp, or you favorite graphic editor. The editor must be able to display the current X,Y coords where the cursor is over. Now the map should not be bigger than 256x256. That gives a texture range of 0x00 to 0xFF both on the U(X) and V(Y) direction.

2) In the probable Texture map section of your model, find "pools" of data close to each other and put dots on the texture (x,y) where the pools tell you.

3) When you start to trace out the edge of the texture, that means you have found the UV map.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 23, 2007, 11:22:22 pm
Damn good idea, Halkun. I considered that, but wasn't sure how to implement it in my search. I have a couple questions as usual, and these will require Kid's battle texture as an illustration (128 x 252 pixels):

(http://img214.imageshack.us/img214/1390/kidtextp2.gif) (http://imageshack.us)

1.) My Paint Shop Pro interprets the the top-left corner as (0,0) and the bottom-right corner as (127,251). Does the PlayStation interpret things the same way typically, or would it identify the bottom-left corner as (0,0) and the top-left corner as (127,251)?

2.) Let's say I'm looking for the UV coordinate (8,9) on a given texture. Should I look for 0x08 followed by 0x09 or should I look for 0x09 followed by 0x08? I'd guess the latter based on your PSX doc, which illustrates things in the order (V,U) reading from left-to-right.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: halkun on November 23, 2007, 11:41:18 pm
0,0 is the upper left hand corner.

Look for pools of the U,V pairs in sets of 3 (triangles) or 4 (quads)

I don't remember if the endian is switched or not. It was pretty easy to figure out when I was picking through it. Keep in mind, this was almost 8 years ago.

A little trial and error will get it, you will know when you hit an edge. When you do find it, it's pretty trivial to write a "mapper" program to draw the UV map to see what you have.

Even cooler; When you have the UV mapped, you can see how many polygons/vertexes the model uses. You can then use that information to find the other sections, such as vertex pools and polygon pools.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 23, 2007, 11:56:01 pm
Gotcha. Thanks Halkun! Hopefully we're on the verge of a breakthrough.

EDIT: Alrighty Halkun, I've got something that may be of interest. It might be a random coincidence, but the chances of it being random are very small IMO because it works out so beautifully.

First, the hex code I'm looking at:
(http://img248.imageshack.us/img248/5623/uvpossibilityvs4.gif) (http://imageshack.us)

I'm especially interested in the data values boxed in blue. Interpreted as (U,V), in decimal these would read:
(93, 206); (105, 206); (93, 220); (105, 217)
(81, 217); (81, 206); (93, 220); (93, 206)

Assuming (0, 0) coincides with the upper-left corner of the texture as you said Halkun, these values trace out the following points on Serge's texture; they're in yellow, with overlapping points in green:
(http://img406.imageshack.us/img406/1663/uvtracedqc2.gif) (http://imageshack.us)

The resulting quads are symmetrical, which I particularly like. There's loads of examples like this in Section 1-2 of the model (offsets 0x358 ~ 0x28E7) -- although the potential UV map data could be restricted to offsets 0xFB8 ~ 0x1E20. I could be wrong about that; it's only my first impression.

I believe this area is worthy of further investigation. Halkun, Cyb, Luminaire, et al, is it possible UV map data could be arranged in such a manner? The pattern seems to be:

xx xx xx xx xx xx xx xx - U1 V1 U2 V2 U3 V3 U4 V4

...where "xx" represents something I don't know at this point. Thoughts?

I'm attaching Serge's battle model texture so others can take a look if they wish.


[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Gemini on November 24, 2007, 02:58:57 am
If I were you, I'd use pSX for finding the UV coordinates instead of trial&error. Use its debugger, capture 5 frames in the GPU module and, from the GPU menu, select Show VRAM. This will allow you to see ALL the primitives on screen as they are sent on screen, with all their attributes, including uv coordinates and the structure addresses in OTag (a list of primitives).
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 24, 2007, 03:03:01 am
I'll try that next Gemini, since pSX is my favored emulator. For now, what's your opinion on the data I highlighted above?

EDIT: Ooh, I'm starting to like this debugger. I'll be hunting down tutorials on how to use its GPU functions, so if anyone knows of a really good one offhand, let me know.

I'm starting to get the hang of using the debugger. It reports varying polygon formats as illustrated by the snippets below:
(http://img517.imageshack.us/img517/885/debuggeroutputbm3.gif) (http://imageshack.us)

I'm liking the "polygt3" output way better than the other types, since its UV coordinates don't go all the way to 255 from what I've seen so far -- UV coordinates for the battle model textures should go from (U,V) = (0,0) to (U,V) = (127,251). I'm assuming that "polygt3" signifies a triangle that's shaded (as in gouraud shaded) and textured.

It would seem there's enough information to construct the GPU commands Halkun lists in his PSX doc. However, I'm up a creek without a paddle until I figure out which "texture page" value corresponds to which character texture. VRAM has texture pages for the backgrounds, character battle models, enemy battle models, and other objects I suspect. Any thoughts on this, Gemini or anyone else?

And folks, don't forget to look at my trial-and-error results above. I'd much appreciate some feedback on that post from veterans: http://www.chronocompendium.com/Forums/index.php/topic,4770.msg84497.html#msg84497
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Cyberman on November 24, 2007, 03:36:47 pm
You may wish to dump the VRAM to an image (unfortunately with 8bit paletted textures this may look like garbage to you). It should show where the palettes are though.
You will need to dig through the documentation of halkun's PSX.pdf to find out how to compute the CLUT locations and texture pages.  Also you will likely have font data in the VRAM during battle scenes.  A lot of the space in the 1024x512 word VRAM is reusable (fonts for example).

Cyb
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: yaz0r on November 24, 2007, 04:21:19 pm
I believe this area is worthy of further investigation. Halkun, Cyb, Luminaire, et al, is it possible UV map data could be arranged in such a manner? The pattern seems to be:

If you want to make sure, just fill those UVs with 00. The model should still be fine, but the texture will be one color only.

Regarding the question about the VRAM localisation thing, as far as I know about CC inner working, texture for party members 1, 2 and 3 are always loaded at the same position in VRAM. As a consequence, you probably won't find it in the model file.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 24, 2007, 06:35:34 pm
 :lee: AWWW YEAH! :lee:

We've got UV maps, folks! The purpose of Section 1-2 has been revealed!

This is what happens when the data highlighted in my previous post is 00'd out as per yaz0r's suggestion. Serge's model no longer maps his belt buckle:
http://img103.imageshack.us/img103/5880/image1as5.jpg

The logical next step is to 00 out the range 0xFB8 ~ 0x1E20 to see if that contains all of Serge's UV map or only a portion of it. If his whole model isn't blacked out, then Section 1-2 likely contains the UV map and only the UV map.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: ZeaLitY on November 24, 2007, 06:45:06 pm
(http://www.freewebs.com/cloudman2/SongsDusKim-ff7-sephiroth-20021207-medium.jpg)

Whew, we're carving a path through destiny here.

 :jiraiya:

Uhoh, you're at 255 posts. Don't break the limit, hah!
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Gemini on November 24, 2007, 06:50:55 pm
Nice work, dude.

PS: Long time no see you, yaz0r. :D
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 24, 2007, 06:58:10 pm
Now that kickass Sephiroth fanart has been sanctioned on this thread...
(http://img103.imageshack.us/img103/7683/image2nk2.gif) (http://imageshack.us)

We're getting there. Thanks once again to everyone!!
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: halkun on November 24, 2007, 07:02:33 pm
Ok, Next step:

Count how many vertexes are in the the UV map and use that to find the vertex pool. Do the same with the polygons.

I'll offer hints when you are done with that :P


Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 24, 2007, 08:40:51 pm
Provided that the UV map commands are all aligned in the same way, it should be just a matter of counting the 16-byte wide hex rows, multiplied by 4 vertices per row. We suspect Section 1-3 contains the vertex pool, so that will be the first target of comparison once I've got a number of vertices determined.

EDIT: Shoot, I just remembered many of the vertices defined within the model's UV map will overlap. Will that change things, I wonder?
Time for a thought experiment. Let's say we've got two quads sharing the same border as follows:
(http://img260.imageshack.us/img260/5471/25271439vn4.gif) (http://imageshack.us)

The UV map would tell me that there's 8 vertices (the two green vertices are shared) in this imaginary situation. Would the vertex pool also count 8 for these two quads, or would it only count 6 since two are shared? But if the UV map is redundant, maybe everything else will be too.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Cyberman on November 25, 2007, 11:09:42 am
No it would not.
To find the vertexes themselves all you need to do is dump what you think are vertexes into a 3d program such as POV or blender. If they form bits on a shape then they are vertexes.  Vertexes are likely stored as 8 byte records because the PS1 requires 32 bit alignment.  They may have used the 'extra' 4th column for something else.

I couldn't find a recent Serge Model dump so I poked a bit around
If 1-2 is the UV data here is a good way to approach things.
First you find how many UV pairs you have (shock) second you know how large the section is.
9616 bytes in size this means you have at least 4808 UV pairs let's say there are 3 UV pairs per polygon.
Ok it means 16 bytes might be used for something else (likely) and 4800 UV pairs that makes 1600 (exactly) polygons needed (assuming they are all triangles that is :) ). Assuming they are all quads makes 1202 or 1200 polygons.  Your polygon space needs to use between 9600 and 12800 bytes.  This is because you have 4 words per primitive irregardless of the number of vertexes in the primitive (due to 32 bit alignment issues).
That should give you a clue of what to look for in terms of the size of the index.

Have you determined what section 1-1 is yet?

I think 1-3 is the vertex pool (not positive but it's 6496bytes and this divides to a 812 vertex count, this is always smaller than the polygon count usually it's 1:1.5 to 1:2 in ratio ) unless I'm mistaken (wouldn't be the first time) as the data appears to be signed etc. It's likely in the ODD PS1 format (wee) IE 1:3:12 Likely you can calculate the vertex by dividing it type cast as a short int by 4096.0 so FFE7 could be -0.0061.

Cyb

Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: justin3009 on November 25, 2007, 12:53:32 pm
Not to completely change anything, but what program are you guys using to dump that stuff?  I've recently been interested into starting a project that deals with PSX hacking but I need something that can dump data and I haven't been finding anything anywhere ._.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 25, 2007, 01:48:45 pm
Lately I've just been snatching data with a hex editor, Justin, but I can only do that because I know exactly where the files are. That info, in turn, was made possible by Yazoo's (yaz0r's) dumper (made specifically for Chrono Cross), which rips individual files from the game image and thus gave me a good idea of Cross' file structure when it comes to models and such.

If you can't see the file archives on your PSX game disc when you pop it into your CD drive, you're in the same boat we are with Chrono Cross. When that happens, you have to rely on an index file that should be first thing on the game CD (although the PlayStation logo model and some other bootup stuff may come before -- I think that's the way it is with Cross). As far as how to read an index file, you'd have to ask yaz0r; I think his dumper might operate by stepping through the index file and dumping raw data based on the offsets reported by that file. yaz0r, is that basically how it works, or am I totally off?


Now back to the Cross models. I haven't figured out what Section 1-1 is yet, but I can say it's extremely sensitive to tweaking; usually causes the game to freeze when I overwrite Serge's Section 1-1 with another character's. I need to go back and carefully alter some of the bytes, and see if I can find out what's up there.

But first, I'll get a count of the (U,V) pairs in Section 1-2 and we can go from there. The UV map seems to trace out quads, and the UV map data are arranged as follows:

?? ?? ?? ?? ?? ?? ?? ??-U1 V1 U2 V2 U3 V3 U4 V4

I'll look into it more tonight to determine if every row of hex code contains (U,V) coordinates, which I think is the case. A complicating factor will be whether Section 1-2 contains other data besides the texture map. There's a nice pattern in Section 1-2's ASCII signature, but it doesn't last throughout the entire subsection.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: justin3009 on November 25, 2007, 02:01:22 pm
Ah....Mmk thanks.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 25, 2007, 07:46:18 pm
I can cheerfully say that Serge's UV map probably ends at offset 0x28DF. It *may* end at 0x28E7, in which case:

?? ?? ?? ?? ?? ?? ?? ??-U1 V1 U2 V2 U3 V3 U4 V4

would become:

U1 V1 U2 V2 U3 V3 U4 V4-U1 V1 U2 V2 U3 V3 U4 V4 (*NOTE: FORGET THIS. SEE BELOW)

But I'm going to check on that right now. Update in the works.

EDIT: Okay, THIS was unexpected, but I probably should have seen it coming. Within Section 1-2, the following scheme:
                                   -U1 V1 U2 V2 U3 V3 U4 V4  (QUAD 1)
xx xx xx xx xx xx xx xx-U1 V1 U2 V2 U3 V3 U4 V4  (QUAD 2)
yy yy yy yy yy yy yy yy

...operates as follows. The row labeled QUAD 1 maps out a quad on the texture as expected. The 8 bytes labeled xx xx... actually determine color or perhaps shading. When all 8 bytes in the xx xx... range are set to 00, QUAD 1 becomes transparent! Rinse and repeat for QUAD 2 and its associated yy yy...

Here's visual evidence:
(http://img218.imageshack.us/img218/1892/transparencyproofoj7.gif) (http://imageshack.us)

In the context of my exposition above, QUAD 1 is labeled "1" in red, both on the magnified texture and Serge's rump (I didn't choose this on purpose, you know. Just business...) while QUAD 2 is labeled "2" in both pics. I essentially changed the yy yy range to 00 bytes, leading to QUAD 2 becoming an open window through Serge's model! QUAD 1 is blacked out because I changed the UV map values to 00 bytes without altering the xx xx... range.

So what does this tell us? It appears that each quad on the texture map is followed by 8 bytes that define that quad's color/shading/transparency on the model. So if we count this "color" data as part of the UV map, then the UV map data terminates upon reaching offset 0x28E7, or the end of Section 1-2.

That came out more complicated than I had hoped; if anyone would like clarification on my findings tonight, just ask. I'm a bit confuzzled at the prospect of 8 bytes defining color, because I'm used to thinking of colors in terms of 3 bytes: 1 for Red, Green, and Blue each. Why would a color value possibly need 8?

Another thing that's discombobulating my brain at the moment: within the UV map data, some values in the "V" column are FF. Yet the battle textures are 128x252 pixels in WidthxHeight, meaning the max value in the V(Height) direction should be "FB" at the most (for 251 in decimal). Another piece of food for thought: when an FF does occur in a row of UV data, there seems to always be one other FF in another "V" column. Which leaves 6 bytes - enough to map one triangle on the texture. Is it possible that:

xx xx xx xx xx xx xx xx-U1 FF U2 V2 U3 V3 U4 FF

actually means:

xx xx xx xx xx xx xx xx-U1 N/A V1 U2 V2 U3 V3 N/A?

i.e., the "FF" is essentially a "skip me!" value allowing the data alignment to be preserved while directing the GPU to map triangles instead of quads? Is it possible that a single texture could be mapped alternately as quads and triangles?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 25, 2007, 09:58:19 pm
Okay, drop the FF = "skip me!" idea. I've seen up to three FF values in the UV map for a quad, all in the "V" columns. In fact, the range where I'm seeing "FF" in the V position may not even be UV map data at all! The phenomenon seems to occur within a range in Section 1-2 I was on the fence about in the first place. Only way to tell is to mess with some more data - but that won't happen till tommorow evening I'm afraid.

Yet another monkey wrench -- the model has to map a model texture, sure, but it also has to map an "eyeball blink" texture on top of that. I'm guessing there's got to be data defining a texture page at some point, and that tells the processor which texture in VRAM it's looking at - body or eyeball.

In the meantime, advice and feedback is most welcome. My top objective is to get Section 1-2 completely figured out. I know the UV map data ends at offset 0x28E7 now, but I do not know where it begins just yet for the above-cited reason ("FF" values toward the beginning of Section 1-2).
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on November 25, 2007, 10:53:37 pm
I think Section 1-2 contains both triangle and quad data.

Note that Section 1-2 starts with apparent 6-byte sequences. I think you can describe the triangles with the structure

aa bb cc dd ee ff ?? ?? ?? ?? ?? ??

where (aa, bb), (cc, dd), and (ee, ff) are the UV data. In the early part of Section 1-2, all FF values are found in the ?? ?? ?? ?? ?? ?? sections. I bet this continues in the quad part of Section 1-2. Also, if the question mark bytes are read as three 16-bit integers, all three are always divisible by 8. This is often a sign of pointer data, but pointers to what?

Based on your notes and the hex pattern, I bet the triangle-quad transition occurs at 0x0FB8. If this is true, then there are exactly 264 12-byte sequences and exactly 403 16-byte sequences in Section 1-2. 264 + 403 = 667.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 25, 2007, 11:13:07 pm
A transition from triangles to quads makes very good sense, Luminaire. I haven't done much investigating toward the beginning of Section 1-2 yet, but I did notice a stark change in the data structure's ASCII signature around that offset (0x0FB8).

667 polygons is our preliminary count then, right? With 264 triangles and 403 quads?

EDIT: Yes, offset 0x0FB8 is definitely the point at which the "FF" values disappear from the texture map data. The FFs still occur among the data that define color/shading/transparencies of the quads, but that's not problematic to me. In my investigation for tomorrow, I'll focus on finding out which bytes affect transparency, which affect shading, and which affect color of the quads in the range 0xFB8 ~ 0x28E7, if indeed those functions can be separated.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on November 25, 2007, 11:48:27 pm
A picture of the UV data mapped roughly onto Serge's battle model is attached. Seems to be decent at least.

There are about ten or so exceptions in the quad data, where FF bytes are present in the wrong locations. My immediate thought is that, for some reason, the UV and non-UV data might be reversed. Seems weird though.

At this point what we're still missing is which vertices correspond to each face. I'm hoping this is what the non-UV data in Section 1-2 refers to. I guess I'd be surprised if the non-UV data is color/shading/transparency information, but we'll see.

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 26, 2007, 12:40:15 am
 :shock:

Did you code a program to do that, Luminaire? That is freaking awesome! Does your program map out the potential triangles as well as quads, or just the quads?

I now disavow the possibility of the non-UV data referring to colors and shading, because it just theoretically doesn't make sense to me anyway, seeing as the non-UV data occurs in 8-byte chunks anyway. Your idea is much better.

Later on I'll pick a specific quad, then mess with its corresponding non-UV data a few bytes at a time to see what happens. If the non-UV data tells the GPU/GTE(?) which vertices correspond to each face, would it make sense that the polygon would become entirely transparent if the data were 00'd out, as occured in my example above?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on November 26, 2007, 12:53:19 am
I have a C++ program going that I use to experiment with various ways of reading the data (bits per number, signed/unsigned, etc.) One of the things I like to do is spit out sets of numbers to a text file, and I've been adapting my code to generate output in a form I can read into Blender (Wavefront OBJ). That's how the picture above was made.

The picture above spans all of the data in Section 1-2 (so both triangles and quads), using the parts of it we believe are the UV data.

If the non-UV data is what I think it is, it would make sense that zeroing the non-UV data out would cause the corresponding face to not be drawn. I will be interested to see what happens when the non-UV data is changed but left nonzero.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 26, 2007, 01:04:58 am
Gotcha. A non-00 change to the non-UV data will be the next project for me then. I'll most likely overwrite a quad's non-UV data with straight CC's or some consistent value.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: yaz0r on November 26, 2007, 03:18:25 am
Just a small note, the PSX handle color stored on 16bits. That's probably what you have here.
I don't have the specs with me, but I think it can be found in the GTE section of that PSX.pdf document.

Anyway, glad to see progress :)
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: yaz0r on November 26, 2007, 08:52:40 am
According to the spec:
Mask = 15th bit
Blue = 10-14th bits
Green = 5-9th bits
Red = 0-4th bits
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 26, 2007, 09:35:21 am
Yes, thanks for all the help again yaz0r! Now, there's actually 8 bytes we need to worry about in the non-UV data scheme I posted above (I posted xx xx... meaning there was an 8-byte series, not just the two bytes, so my bad if that's why you posted the color specs for 16 bits/2bytes  :mrgreen:).

The quad data (I still have to investigate what are potentially UV map triangles earlier in Section 1-2) are arranged as follows:

                                   -U1 V1 U2 V2 U3 V3 U4 V4  (QUAD 1)
xx xx xx xx xx xx xx xx-U1 V1 U2 V2 U3 V3 U4 V4  (QUAD 2)
yy yy yy yy yy yy yy yy

...with the xx xx... 8 byte series controlling "SOMETHING," or perhaps a set of "SOMETHING"s for QUAD 1 and the yy yy... 8-byte series controlling that same set of "SOMETHING"s for QUAD 2. All I can confirm at this point is that when the entire 8 byte series is 00'd out, the quad disappears entirely and becomes a "window" right through the model.

So if color can be handled with 16 bits (2 bytes), that can't account for the entire xx xx... and yy yy... series, correct? Unless I'm missing something in your explanation?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: yaz0r on November 26, 2007, 10:00:47 am
Ha, sorry, you are right, this don't makes sens, I looked into that a bit too fast :)

Anyway, those info you are looking into are per-vertices information. The next big step now is figuring out how they are connected together.
Usualy what happens is that there is a table somewhere giving the position of the vertices of each triangle (quads in that case) and an UV index that link to the UV table you're currently looking into. The reason to separate the position from the UV is that position (and usualy normals) have to be transformed, while the UV does not (I may be wrong on that point, but I lack info on the PSX hw).
To figure that out, I suggest you count the number of entries in you UV table. That will help you  find in the other sections a value that range from 0 to the number of entry you have.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Sora on November 26, 2007, 01:08:49 pm
I'm a bit confuzzled at the prospect of 8 bytes defining color, because I'm used to thinking of colors in terms of 3 bytes: 1 for Red, Green, and Blue each. Why would a color value possibly need 8? 
AARRGGBB
or Alpha 0 - 255
red - 0 255
green - 0- 255
blue 0 - 255
Alpha is how tranparent it is.

Edit: Example:  8800FFFF is half transparent cyan.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 26, 2007, 02:37:17 pm
I can tally up the quads that we know for sure exist tonight (Luminaire's already come up with a figure of 403 quads, which equals 1209 vertices for the quad data altogether, or 1209 UV coordinates). I'll end up with the same result I'm sure. So let's go with 403 quads, and I'll reconfirm later.

yaz0r, now that you've brought up the existence of a table full of quad locations, I wonder if that data at the beginning of Section 1-2 is actually such a table, and not triangle UV coordinates? Luminaire, didn't you say you saw potential pointers in that section of data?

@Sora: THANK YOU very much for the info on color/transparency. Now, if the first two bytes in the xx xx... sequence (or maybe the last two, depending on whether the Endian is reversed) represent transparency, then a 00 00 value would make the quad clear, whereas FF FF would make it completely solid, is that right? The only difficulty is, I don't *think* the xx xx... and yy yy... sequences ever had two FF bytes adjacent to one another. Is it possible that the value doesn't have to be FF FF to make the quad solid?? Or if the value wasn't FF FF but say, AA DD, would the difference be perceptible to human eyes?

Whatever the case, Sora's input tells me how to proceed in testing the non-UV data. I'll start by zeroing out ONLY the first two bytes or the last two bytes in a quad's non-UV data and see what happens. If that makes the quad disappear, it's possible that this is, after all, some sort of color/shading/transparency data. If not, I'll alter the data in a different way to test Luminaire's hypothesis.

Let me say thanks again to everybody! We are totally kicking some ass here!
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Sora on November 26, 2007, 03:30:38 pm
I can tally up the quads that we know for sure exist tonight (Luminaire's already come up with a figure of 403 quads, which equals 1209 vertices for the quad data altogether, or 1209 UV coordinates). I'll end up with the same result I'm sure. So let's go with 403 quads, and I'll reconfirm later.

yaz0r, now that you've brought up the existence of a table full of quad locations, I wonder if that data at the beginning of Section 1-2 is actually such a table, and not triangle UV coordinates? Luminaire, didn't you say you saw potential pointers in that section of data?

@Sora: THANK YOU very much for the info on color/transparency. Now, if the first two bytes in the xx xx... sequence (or maybe the last two, depending on whether the Endian is reversed) represent transparency, then a 00 00 value would make the quad clear, whereas FF FF would make it completely solid, is that right? The only difficulty is, I don't *think* the xx xx... and yy yy... sequences ever had two FF bytes adjacent to one another. Is it possible that the value doesn't have to be FF FF to make the quad solid?? Or if the value wasn't FF FF but say, AA DD, would the difference be perceptible to human eyes?

Whatever the case, Sora's input tells me how to proceed in testing the non-UV data. I'll start by zeroing out ONLY the first two bytes or the last two bytes in a quad's non-UV data and see what happens. If that makes the quad disappear, it's possible that this is, after all, some sort of color/shading/transparency data. If not, I'll alter the data in a different way to test Luminaire's hypothesis.

Let me say thanks again to everybody! We are totally kicking some ass here!

well, okay. for hex, FF is one byte, that is two characters represennt 1 byte FF FF is 2 bytes.

in my example i say 8800FFFF makes twitransparent (i think thats a word, as twi is a prefix meaning half) cyan.
88 - the Alpha aka transparency
00 = red
FF = green
FF = blue

in hex FF means 255, because you count like 1,2,3,4,5,6,7,8,9,a,b,c,d,e,f,10
so its really [88][00][255][255]

so to be transparent, it just needs one 00 value, and to show up, it just needs one FF.

also, it doesnt HAVE to be FF to show up, it just has to be > 00.
for example, if i wanted serge to look like a ghost, i'd set his transparency to 55. he'd show up, but you'd be able to see through him. if the value was say FE, i bet it'd be hard to tell the differance between FE and FF.

man, if i keep helping i'll lose my rep as an annoying and spamming member >.< lol
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on November 26, 2007, 04:07:33 pm
If the non-UV data is color data, then it's almost certainly three or four 16-bit colors (for triangle and quad data, respectively), as yaz0r said. One color per vertex is not unheard of in 3D model data. However, there is the multiples-of-8 pattern I found to consider. Color data would be highly unlikely to do that.

Interestingly, some of the non-UV values (read as 16-bit) are 0xFF??. Actually, it looks like the most-significant byte is always very near zero or very near 255, which is a sign of signed data. But pointer data is not signed, so I'm a little confused about that.

----------

If color is stored as four-byte data, it could be stored as A8R8G8B8 (like Sora's example), R8G8B8A8, A8B8G8R8, etc. So you can't just assume the first byte is the alpha data.

Also, 0x88 is 136 in decimal. Half-transparency would be achieved by setting the alpha to 0x7F, or 127.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 26, 2007, 04:23:18 pm
Wow, okay. The color discussion is getting more complex by the minute! I misread Sora's post, thinking the semitransparent cyan example read AA AA RR RR GG GG BB BB when it was only four bytes.  Silly brain. :roll:

Unless there's also gouraud(?) shading in there as well, with one byte per vertex of the quad. I don't know how likely that would be, but I guess it would account for all 8 bytes. I guess I'll still proceed as I had planned, changing the first and last byte pairs of the non-UV data to see if that invokes transparency.

Luminaire, what do you think of this observation made by yaz0r?
Quote
Usualy what happens is that there is a table somewhere giving the position of the vertices of each triangle (quads in that case) and an UV index that link to the UV table you're currently looking into. The reason to separate the position from the UV is that position (and usualy normals) have to be transformed, while the UV does not (I may be wrong on that point, but I lack info on the PSX hw).

The table he refers to -- could that be the vertex pool in Section 1-3?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on November 26, 2007, 04:33:28 pm
That's what I'm hoping. If we can figure out how the non-UV data points to the vertex data (if that's what it indeed does, of course), then I can have my program output the vertex data, how the vertices are connected into faces, and the UV data in such a way that I can import it into Blender. Hopefully the result will look at least somewhat like Serge.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 26, 2007, 04:50:22 pm
Ahh, so going back to the byte string:

                                   -U1 V1 U2 V2 U3 V3 U4 V4 (QUAD 1)
xx xx xx xx xx xx xx xx-

Is it possible the xx xx... series could point to QUAD 1's position in the vertex pool? Am I understanding that right? Or is it the mysterious (possibly triangle?) data early on in Section 1-2 that points to the vertex pool?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on November 26, 2007, 05:21:35 pm
My guess would be both. Each 16-bit sequence in the non-UV data would point somehow to the location of one vertex.

The point of having both a vertex pool and a "face pool" is that each vertex belongs to multiple faces, so it's cheaper storage-wise to store a pointer to the vertex (2 or 4 bytes) rather than another copy of the vertex itself (6 or 8 bytes).

Does that make sense?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 26, 2007, 05:44:58 pm
Crystal clear -- I think. If I'm understanding that correctly, then in the scheme:

                                   -U1 V1 U2 V2 U3 V3 U4 V4 (QUAD 1)
aa bb xx xx xx xx xx xx-

"aa bb" would point to the first vertex's location in Section 1-3?

If so, the pointer would be relative, but relative to what, I wonder? The beginning of Section 1-3?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: yaz0r on November 26, 2007, 05:45:03 pm
I'm going to slightly change the topic, but I have noted a few things that might interest you...

In Serge model mine file, I looked into the very last weapon model, and I noted the following:
data arround 22E10 is most probably the texture palette. The texture seems to be in 4bit mode, so that can be checked easily.

Next to that, there is 3 distinct blocks:
block 1: starts at 22E40, stride is 0x1C, num entries is 0x24
block 2: starts at 23230, stride is 0x24, num entries is 0x39
block 3: starts at 23A30, stride is 0x8, num entries is 0x4D

There is a few things we can make out if this.
block 1 and block 2 share similar design, but after a bit of inspection, block 1 is obviously the triangle table and block 2 the quad table.
Block 3 will be discussed later

A few block 1 entries:

7070 6034 8080 7D00 6060 6000 534D C03F 5147 1600 4E4A 4C00 3B00 3700
6060 6034 8080 7D00 7070 6000 4E4A C03F 5147 1600 534D 3800 4C00 3500
6060 6034 6060 6000 6060 6000 534D C03F 4A4D 1600 534D 3800 3B00 4C00
6060 6034 6060 6000 8080 8000 454F C03F 454F 1600 4C4F 4600 3B00 3800

A few block 2 entries:

6060 603C 6060 6000 A0A0 A000 8080 8000 583D C03F 513A 1600 5E3A 5635 3900 4A00 4700 4300
8080 803C 6060 6000 A0A0 A000 6060 6000 5635 C03F 513A 1600 5E3A 583D 4300 4A00 4700 3900
7C80 703C 7080 7000 9090 8800 8080 8000 341B C03F 461B 1600 3810 4913 2800 2B00 2600 2D00
8080 703C 8080 8000 6A70 5000 7080 7000 5614 C03F 4913 1600 501B 461B 2E00 2D00 2C00 2B00
7080 703C 8080 8000 6A70 5000 8080 7000 461B C03F 4913 1600 501B 5614 0C00 0B00 0900 0100

As said, the sequence are similar, with 3 vertices for block 1, and 4 for block 2 (hence the triangle vs quad).

The actual format is:
for each vertice {
    3bytes (usualy similar and most of the time alligned on 16)
    1byte
}
1 float (around 1.5f, is that scaling ?)
1 32bit value (is that an offset ?)
2 8bit values in case of block 1 and 4 8bit values for block 2
for each vertice {
    a 16 bit value
}

Additionaly, the last table of 16 bit data (one for each vertice) seems to range from 0 to the max number of entry in block 3.

Now what is block 3 ? But the vertex data off-course !
Block3 is just a table of 16bits X, Y, Z values padded with a blank 16bit of data.

I do not pretend all this to be completly accurate. Anyway, the point of all this is that when working on a file format, you should always start from the smallest dataset you have, and look at different models at the same times, as one model might give you clues that another would not...

Hopes this help.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 26, 2007, 05:50:27 pm
Wow, thanks yaz0r! So the weapon models seem to combine triangles and quads then? Perhaps the same is true for the character models as well after all.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: yaz0r on November 26, 2007, 06:00:07 pm
This should give you an idea of what you are looking for in serge model. In case of a skinned model like serge, there should be a section that describes bones, and an additional entry for each vertice giving the bone it is bound to.
The other issue with skinned models is that vertices may be in bone-space, and not in model-space like that would be the case for an unanimated object.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 26, 2007, 08:06:26 pm
...in which case there should also be pointers to the bone section? We haven't identified that yet; I'm not sure if it's Section 2 (not to be confused with Section 1-2) or not. But I'll say tihs -- wrecking Section 2 makes Serge go all squiggly, and if all of Section 1 is "in sync" with Section 2 (meaning, if I overwrite both Section 1 and Section 2 with Kid's data) then the texture seems to map "properly" to Serge's "squiggly-ness." I'll summon up some previously posted Youtube vids to illustrate that:

Section 2 of Serge's model overwritten by Kid's data:
http://www.youtube.com/watch?v=QgVi-lTspDY

Sections 1 and 2 of Serge's model both overwritten by Kid's data:
http://www.youtube.com/watch?v=smXwjqrCjIM

I'm not sure if that provides us any clues regarding bone data.

- - - - -

Alrighty, first result of the evening:
(http://img254.imageshack.us/img254/2856/beltbucklegoneby7.gif) (http://imageshack.us)


This is significant. I targeted the two quads that map Serge's belt buckle in the following fashion:

                                    -U1 V1 U2 V2 U3 V3 U4 V4  (QUAD 1)
00 00 xx xx xx xx xx xx-U1 V1 U2 V2 U3 V3 U4 V4  (QUAD 2)
yy yy yy yy yy yy 00 00

This means that we aren't looking at color data, but something that needs to be fully intact in order for the quad to be drawn. In short, a pointer as Luminaire hypothesized before. I'm going to 00 out a middle byte in one of the quads just to be sure.
- - - - -

UPDATE:

Lookie here:
(http://img254.imageshack.us/img254/4745/partialdrawij5.gif) (http://imageshack.us)

Those little sparklies circled in the left-hand pane mean part of Serge's belt buckle texture is mapped. I'll provide an illustration of how I changed the data this time. Here's how it originally looked, with bolded bytes the ones I 00'd out:

                                    -U1 V1 U2 V2 U3 V3 U4 V4  (QUAD 1)
90 13 E0 13 68 09 90 09 -U1 V1 U2 V2 U3 V3 U4 V4  (QUAD 2)
50 13 10 14 E0 FF C8 FF

Sooo...The portion of Serge's belt buckle that was still mapped this time is in QUAD 1 based on my notes. The intact triangle seems to be defined by three bytes bolded as follows:


                                    -U1 V1 U2 V2 U3 V3 U4 V4  (QUAD 1)
xx xx xx xx xx xx xx xx -U1 V1 U2 V2 U3 V3 U4 V4  (QUAD 2)
yy yy yy yy yy yy yy yy

Grr, I'm not sure what it means yet. Confuzzling. My next move will be as follows: transfer the xx xx... string values to the yy yy... string and zero out the xx... string. If we are correct in assuming we're looking at pointers of some sort, then the result should be QUAD 2 mapped to QUAD 1's position on the model. That is my belief! At least for now...
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Cyberman on November 26, 2007, 09:00:33 pm
Are there not more sections than 1 2 and 3? :)

Cyb
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 26, 2007, 09:22:43 pm
We've examined Section 1-2 and 1-3 so far, Cyb. Section 1-2 (what we're investigating in-depth at the moment) seems to be the UV map and something else (perhaps pointers); and Section 1-3 is most likely the vertex pool. In short, we've been stuck in Section 1 all this time! :lol:

Bone data and animation data, and perhaps some other data, should be found in Section 2, Section 3, Section 4, and Section 5. We've got a long ways to go yet! :P

- - - - -

UPDATE: This complicates things in my mind! This is what I did:

                                    -U1 V1 U2 V2 U3 V3 U4 V4  (QUAD 1)                                                  -U1 V1 U2 V2 U3 V3 U4 V4
xx xx xx xx xx xx xx xx -U1 V1 U2 V2 U3 V3 U4 V4  (QUAD 2)         => 00 00 00 00 00 00 00 00-U1 V1 U2 V2 U3 V3 U4 V4
yy yy yy yy yy yy yy yy                                                                      xx xx xx xx xx xx xx xx-

And here's the result:

(http://img504.imageshack.us/img504/9522/flipodditymu2.gif) (http://imageshack.us)

Putting this all into English: I expected Quad 2 to be mapped in Quad 1's place, and Quad 1 to be nonexistent. However, it is in fact Quad 2 that is nonexistant and Quad 1 is still drawn, although flipped 90 degrees leftward!! Thus, my current hypothesis:

I have a pet theory, but it's too darn complicated, so I'm going to rely on Occam's Razor and hope that my next experiment will help me make sense of things. Feel free to speculate in the meantime on these resutls.

Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Cyberman on November 26, 2007, 11:05:02 pm
Perhaps I should have said "subsections" 1, 2, 3
FF7's models had a section 1 which had an HRC header that was used for the bones and then each bone came from it.  I am sure the data for CC is not much different. If you have UV and vertex data (1-2 and 1-3) respectively.  The poly information is likely grouped with the UV data (as it would be parity with it as Yaz0r pointed out).  I thought there were 6 subsections to section 1? The disjoint nature of things at the moment is a tad messy at the moment for me.  However I should be able to create some of the information for POVray output.  I just forgot what section held the TIM data.
Now it's likely you have around 600+ polygons right? Section 3 may have more than just vertex data.
The polygon data may be packed, which would make things kind of interesting.
I'm positive that they have models with more than 256 vertexs therefore 1 byte per vertex is not a likely fit.  FF7 used 1 word per vertex index but the words were *8 byte offsets into the vertex array.  The same is possible here, as speed is of the essence in using the PS1 hardware.

Cyb
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 26, 2007, 11:32:59 pm
There are 6 Sections to the entire model itself; 4 subsections within the first Section. Hence, among all of us Sections 1-1, 1-2, 1-3, and 1-4 have been investigated, Sections 1-2 and 1-3 most thoroughly.

I still have to devise a way of dealing with Section 1-1 yet, and Section 1-4 doesn't seem to have any impact on Serge's model when it's changed. Wierdness!

The disjointed nature of things is my bad, Cyb. I'll direct you to the Chrono Cross File Structure wiki, which contains everything we know (or think we know) so far as a collective about the character battle models: http://www.chronocompendium.com/Term/Chrono_Cross_File_Structure.html#Character_Battle_Models

As a companion, here's a pack with Serge's and Kid's models. Don't worry about the ModelMine files for now; the characters sans textures and weapons should be in here:
http://www.chronocompendium.com/Forums/index.php?action=dlattach;topic=4770.0;attach=1987

On to one more experiment to devine the nature of the non-UV data that accompanies the UV maps for quads...

EDIT: UPDATE IN WORKS. WILL CLEAR UP SOME CONFUSION (mine at least). Be back in a few.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 27, 2007, 12:26:15 am
First, the evidence. Open this pic in a new window; file size is prohibitive for 56k users, maybe:
http://img104.imageshack.us/img104/2037/prooflr4.gif

What's happened? Serge's rear end has been mapped to his belt buckle quads, and his belt buckle has been mapped to his rear end quads! Here's what I did:

BELT BUCKLE UV and NON-UV DATA:                                       REAR END UV and NON-UV DATA:

                                   -U1 V1 U2 V2 U3 V3 U4 V4                                                      -U1 V1 U2 V2 U3 V3 U4 V4     
aa aa aa aa aa aa aa aa-U1 V1 U2 V2 U3 V3 U4 V4                   xx xx xx xx xx xx xx xx-U1 V1 U2 V2 U3 V3 U4 V4
bb bb bb bb bb bb bb bb                                                         yy yy yy yy yy yy yy yy


NOW, SWITCH NON-UV DATA LIKE SO...

                                    -U1 V1 U2 V2 U3 V3 U4 V4                                                      -U1 V1 U2 V2 U3 V3 U4 V4     
xx xx xx xx xx xx xx xx -U1 V1 U2 V2 U3 V3 U4 V4                  aa aa aa aa aa aa aa aa- U1 V1 U2 V2 U3 V3 U4 V4
yy yy yy yy yy yy yy yy                                                         bb bb bb bb bb bb bb bb 

See what I did? Leaving the UV maps for Serge's rear end and belt buckle alone, I swapped the non-UV data corresponding to those pairs of quads. If doing this switched which texture pieces are mapped to which polygons, we have the following for Section 1-2's quad data structure:

(http://img504.imageshack.us/img504/8823/explanationoq6.gif) (http://imageshack.us)

So basically, there's a UV map followed by a pointer to the polygon that UV map "maps" to!

If this makes sense to others besides myself, it shall be added to the wiki.

HOWEVER -- we are not finished with Section 1-2 yet! We must figure out the purpose of the non-quad (possibly triangle, possibly something else) data that occupies offsets 0x358 ~ 0x0FB8 in Serge's model data! Thus will begin my next series of experiments.

ADDENDUM: 403 rows of data for 403 quads on Serge, by the way. The quad data occur between offsets 0x0FB8 ~ 0x28E7 for 6448 bytes in decimal. Divided by 16 bytes per quad (8 bytes for each UV map, followed by 8 bytes for each polygon pointer), that makes 403 rows and 1612 vertices, just as Luminaire said earlier.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 27, 2007, 01:01:58 am
Folks who haven't read the post that immediately precedes this, please do so. Now for an addition so important it needs its own separate post:

(http://img104.imageshack.us/img104/2783/missingtrianglesqx4.gif) (http://imageshack.us)

Serge looks mean when he's missing half his mouth. Anyway, this is what happened when I 00'd out all the data at the beginning of Section 1-2, offsets 0x0358 ~ 0x0FB8. It appears that triangles are missing!

So those offsets apparently contain triangle data that is analogous to the quad UV maps and associated pointers!! I think I'm merely confirming what Luminaire has already stated about the contents of this offset range, but so much the better. I'll see if I can't figure out the exact structure of the triangle data as occurred with the quads.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Sora on November 27, 2007, 02:18:07 am
(http://img104.imageshack.us/img104/2783/missingtrianglesqx4.gif) (http://imageshack.us)
"Why are you in the way? Are you mister in the way!?"
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 27, 2007, 02:51:18 am
I'm glad the pic was put to good use, Sora. 8)

Time for an UPDATE:

The early part of Section 1-2 seems to be structured as follows:

                                     - U1 V1 U2 V2 U3 V3 xx xx
xx xx xx xx U1 V1 U2 V2 - U3 V3 yy yy yy yy yy yy
U1 V1 U2 V2 U3 V3 zz zz - zz zz zz zz

The structure is exactly the same as with the quads; the xx xx... string is a six-byte pointer to a triangular polygon stored somewhere else perhaps, and the UV coordinates preceding it map the appropriate part of the texture to the triangle indicated by the xx xx... string!

To boot, all FF values appear in the xx xx... ; yy yy...; and zz zz...-type areas. That means we're good to go! Only thing that bothers me is that the data doesn't retain a neat 32-byte alignment (or does it?) Cyb or Halkun, is this still okay?

Anyway, here's proof that the triangle data behave the same way as the quads:
(http://img187.imageshack.us/img187/1917/proofiipz2.gif) (http://imageshack.us)

Now we need to figure out where all these pointers are pointing at.

Also, I'm arriving at a figure of 264 triangles.  Offset range 0x358 ~ 0xFB8 contains 3168 bytes if counted in decimal, divided by 12 bytes for each triangle (6 for UV map, 6 for pointer) yields 264 polygons.

Therefore, we've got 403 quads and 264 triangles. Luminaire, IIRC that's what you said to begin with -- is this correct?


- - - - -

Anyway, we kicked some major ass and tore lots of model data up today, folks. Therefore, I shall leave you with a pic of Gally (from the manga Battle Angel)...kicking ass and tearing stuff up:

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: yaz0r on November 27, 2007, 04:02:00 am
Only thing that bothers me is that the data doesn't retain a neat 32-byte alignment (or does it?) Cyb or Halkun, is this still okay?

that means you have a stride of 0xC (aka, 12). And that's perfectly fine
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: halkun on November 27, 2007, 05:42:09 am
Therefore, I shall leave you with a pic of Gally (from the manga Battle Angel)...kicking ass and tearing stuff up:

I used to read Gunnm (Battle Angel) when I lived in Japan. At the time it was still being serialized in Shonen Jump. It's funny how absolutely twisted the translation got overseas. Especially when you realize was Gally's real name is. She was named after Edo's cat, which had recently died.... The Cat was Male.

It's name was Gary

That's why everyone tells her she has a "weird" name at the beginning. Her name is "Gary", not "Gally". When I see her, I *always* called her "Gary". It was the name I grew up with.

Don't even get me started on the whole "Alita" thing. She was *SUPPOSED* to have a weird name in the first place.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 27, 2007, 11:45:40 am
Heh heh. I was completely unaware of the Gary => Gally messup. I suppose it makes sense when you pronounce "Gally" in Engrish. Some fansites say that "Gally" is short for "Gallium" so maybe that's where the translator was coming from.

Back to the models, do these findings seem plausible to everyone? A quad or triangle UV map followed by some sort of pointer to the polygon it's supposed to be mapped to?

Luminaire, when you created the UV map for Serge's battle texture in Blender, did you use the stride pattern yaz0r mentioned for the data in offset range 0x0358 ~ 0x0FB7?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on November 27, 2007, 02:15:29 pm
Yeah, the UV map I posted has both the triangles and quads represented. The best part is that the UV coordinates appear to span the entire texture.

It would be nice to figure out if there's some sort of header somewhere that tells us there are 264 triangles and 403 quads in Serge's 3D model.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 27, 2007, 03:43:04 pm
I suppose we could try looking for the hex equivalents of 264 and 403 in Little Endian. Would you expect this data to be signed or unsigned, Luminaire?

And if working with signed hex becomes necessary, do you know if there's any decimal -> hex converter utility that has signed/unsigned options? I think Windows Calculator only works with unsigned hex, but I could be wrong.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: yaz0r on November 27, 2007, 04:08:28 pm
I suppose we could try looking for the hex equivalents of 264 and 403 in Little Endian. Would you expect this data to be signed or unsigned, Luminaire?

Signed or unsigned doesn't matter, it will still look the same in hex :)
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 27, 2007, 04:35:52 pm
Is that right, yaz0r? So I could just search for 0x0108 (08 01 in Little Endian) for 264 triangles, 0x0193 (93 01 in Little Endian) for 403 quads, and 0x029B (9B 02 in Little Endian) if the header gives a total number of polygons (667) instead of triangles and quads separately?

EDIT: Ooh! Hang on! Toward the end of Section 1-1, at offset 0x029C in Serge's untextured model file, there's the value 60 0C, which is Little Endian for 0x0C60, or 3168 -- that's the number of bytes for the triangle map and pointer data. Could it be a clue?

It may just be a coincidence, because I'm not seeing 0x1930 (30 19 in Little Endian) for 6448 anywhere that would appear to be a suitable location for a header.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: yaz0r on November 27, 2007, 04:44:25 pm
You have to search for 0x08 0x01 for 264 triangles, and 0x93 0x01 for 403 quads.
Unfortunatly I didn't find anything worth noting while searching those values in the model file. Maybe they are expressed in another way...
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Sora on November 27, 2007, 04:59:14 pm
we are losing T.T
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 27, 2007, 05:05:53 pm
Thanks for the uplifting observation, Sora. 8)

On that bleak note, I'd like to mention that there a few instances in which "FF" values creep into the quad UV data. Since the UV data shouldn't have that value at all, it's quite likely that my models for the quad and triangle data are flawed, at least in certain areas of Section 1-2. I think Luminaire had reported this oddity earlier - it's almost as if the pointer and the UV map are "switched" in some instances, or it's possible that two quads can point to the same UV map if they both follow that UV map one right after the other perhaps.

Only way to tell for sure is to mess with some data and fire up the emulator. I'll see if I can fit it in later today.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Sora on November 27, 2007, 06:01:58 pm
Luminaire seems to be always right.
instead of doing all these tests, why not just ask him and take his word on it and expand from there?
it seems like it'd be a lot faster.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 27, 2007, 06:17:30 pm
Luminaire IS always right. And so are yaz0r, Halkun, Cyb, Gemini, and all the other veteran hackers here. I just like to prove it, that's all. 8)

At the very least Sora, these various experiments have certainly increased my own understanding of how the 3D model format works. I'm sort of an apprentice hacker here - and an apprentice can't keep asking the master for handouts. The apprentice must go through the same work to figure out the tricks of the trade, so to speak.

With that said, time for more experiments! Mwahahah! :mrgreen:
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Sora on November 27, 2007, 06:23:59 pm
yes, but things need to go fasterrrrrrrrrrrrrrrrrr~~~~~~~~~~~~~~~~~~~~
its way to slow T.T
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: ZeaLitY on November 27, 2007, 06:45:15 pm
What the fuck? Halkun, Luminaire, and the others may be right, but they don't have the time to analyze the file in-depth and map it out completely. That's FW's job, and he uses their great advice to make headway. If you can't be patient, then hack it yourself.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Sora on November 27, 2007, 07:11:09 pm
What the fuck? Halkun, Luminaire, and the others may be right, but they don't have the time to analyze the file in-depth and map it out completely. That's FW's job, and he uses their great advice to make headway. If you can't be patient, then hack it yourself.
ohh, so times the issue, i get it now.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Cyberman on November 27, 2007, 07:40:58 pm
yes, but things need to go fasterrrrrrrrrrrrrrrrrr~~~~~~~~~~~~~~~~~~~~
its way to slow T.T
I suggest you look at this thread once a week instead, it will seem faster that way.  Otherwise you are just making noise, going off topic, and making it really hard to follow FaustWolf's experimental confirmation of everyone's thoughts and suggestions.  Learning is about making mistakes, proving them wrong, and deciding what is right.

Quote from: FaustWolf
EDIT: Ooh! Hang on! Toward the end of Section 1-1, at offset 0x029C in Serge's untextured model file, there's the value 60 0C, which is Little Endian for 0x0C60, or 3168 -- that's the number of bytes for the triangle map and pointer data. Could it be a clue?
FW that 'number that coincidentally is the size of the triangle data might be an offset to the Quad section if you know how large section 2 is you merely compute the size of the quad section by subtracting that value from the total. Erstwhile you know the triangle section size automatically that way as well as where the quads start.
The vertex indexes are likely what are adjacent to the UV data.  So you have a slightly different polygon format than FF7 that's pretty much it.  The GPU packets are constructed from the 3d data being transformed by the GTE and then married to the UV data to form the final chunks of data so 32 bit alignment is not necessary until you are sending data to the GPU. (IE DMA data used with the GPU, is 32 bit aligned hence why we were discussing that so much).

Cyb
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 27, 2007, 08:26:00 pm
Phew, Zeality lays the smackdown. :lee:

If it's any consolation Sora, there's only, oh, 5 whole Sections in the character model format we haven't even begun to analyze yet. And that isn't counting subsections.  :D But yaz0r's made major progress on the weapon models at the same time, so everything's going very smoothly all things considered. Admittedly progress probably would have been faster had I abandoned the character models in favor of the weapon models, but I'm really liking the fact that we're looking at more than one type of model at the same time. For example, yaz0r's observation about the presence of triangles AND quads in the weapon models taught me that models aren't necessarily exclusive in the type of polygons they use, which helped shape my experiments examining Section 1-2, etc.

Sora, if you've got the time, I invite you to take a look at the File Structure wiki, which should lead you to the character model sections we haven't started examining yet (the Section offsets are listed in the character battle model headers). You're welcome to dive in yourself and look for interesting hex patterns. Even if you have suggestions on how to improve the battle model format wiki entries, that would be welcome too.

Anyway, here's tonight's food for thought. First, some hex code, followed by pics:
(http://img266.imageshack.us/img266/9273/codeyk5.gif) (http://imageshack.us)
(http://img112.imageshack.us/img112/1207/part1if8.gif) (http://imageshack.us)

The 8-byte hex strings labeled "1", "2", etc., correspond to the same labels on the pics. Specifically, the pics are the result of zeroing out the corresponding hex string. Now, according to the theory I subscribe to on how Section 1-2 works, hex string #2 should NOT be UV data, because it contains the value "FF" - a value beyond the bounds of the character's battle texture.

HOWEVER -- string #1 is in the correct position to be a UV map for a quad. And it apparently acts as such -- zeroing out its data causes a quad to turn a blackish color without becoming a window through the model. This, despite the "FF" value it contains!

Now for some complicating factors. Zeroing out string #3 should have erased the quad mapped by #1 according to the model I settled on last night:
(http://img504.imageshack.us/img504/8823/explanationoq6.gif) (http://imageshack.us)

But zeroing out #3 erases a DIFFERENT quad, and possibly a triangle instead. Zeroing out #2 should have erased a different quad, but *may* have erased the SAME quad #1 refers to! I have to do some more experimentation on this to confirm that the pattern of UV Map -> Polygon Pointer has been reversed in this instance. Weird!

But the moral of tonight's lesson is, whichever polygon byte string #1 is associated with, it still functions as a UV Map, despite its containing an "FF." I'm not completely comfortable with that idea, and will delve even further to get this answered in my own mind.

@Cyb: The value being a pointer makes very good sense, and that would explain it. In which case, it may be preceded by a pointer to the triangle data. I'll compare Serge's model with Kid's. If they follow the same pattern, then we've got pointers to the quad and triangle data!  And that will explain part of the purpose of Section 1-1! Yay! :D
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Sora on November 27, 2007, 09:18:23 pm
sorry, but im busy with my own chrono project ^^;;

Zeal Edit: Removed the utterly unnecessary and superfluous quoting of FW's last post.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: justin3009 on November 27, 2007, 10:00:26 pm
As Zeality said.  Do you honestly expect all of this to happen right away?  3D hacking is a bitch to do hell, any hacking on PSX is harder then fuck.  I've learned that one the hard way not too long ago.  You can't expect everything just to magically be completely done in half a second..
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on November 27, 2007, 10:04:16 pm
I wish I was always right. It would make things so much easier. :)

I wonder if Serge's battle model texture is meant to be 128x256. I know that in OpenGL textures must have dimensions that are exactly powers of 2. (Not really sure why.) In that case FF would be an allowed value for the V coordinates. I'm actually more worried about the ones that have an invalid U coordinate (see the UV map I posted to see those).

Wait a minute...look at 0x2658. It looks like it switches back from quads to triangles there, for 12 polys! Then at 0x26E8 it switches back to quads until 0x28E8! That's weird, and I bet that's where some of the trouble is. I'll look into that.

Thanks for removing that unnecessary quote, ZeaLitY.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Kebrel on November 27, 2007, 10:09:45 pm
Before this topic gets completly back on track I want to take this time to congradulate every one involved in this it a huge undertaking and you guy are passing with flying colours. I my selfunderstand only enough to know what advanciments have been made.

At the very least Sora, these various experiments have certainly increased my own understanding of how the 3D model format works. I'm sort of an apprentice hacker here - and an apprentice can't keep asking the master for handouts. The apprentice must go through the same work to figure out the tricks of the trade, so to speak.
FaustWolf I must say I do admire your thirst to learn. But do give yourself more credit you have accompled more then many "hackers" can claim.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on November 27, 2007, 10:36:19 pm
I agree. FaustWolf, you are doing admirable work here, so kudos to you for that.

For more good news, look at the attached picture. Every extraneous U coordinate is dealt with because of the adjustment I mentioned in my last post. Not sure why there are suddenly 12 triangles in the middle (well, near the end, really) of the quad data. This may also affect the searching for headerlike information describing Section 1-2.

This also affects the non-UV "pointer" information. Thanks to that correction, the pointer data runs from -496 to +8928, with just over half of the values being negative. (Note that this is from reading the data in as signed 16-bit values, which I'm feeling more confident about with each passing post.) The correction got rid of some very negative values I was seeing, which is great.

I've also attached a text file containing all of the non-UV data converted to signed 16-bit integers, one line per triangle/quad. I don't know if anyone will see any significance in this, but here it is anyway.

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: justin3009 on November 27, 2007, 10:39:12 pm
One thing I'd like to ask here.  What exactly is everyone trying to accomplish?  Just trying to understand CC fully so we can mess around with it like a regular CT hack?  Or just messing around with graphics possibly trying to attach other people in other poses to see what they'd look like or something.  I never really understood but I do find this work amazing.  You guys do such a great job ._.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: ZeaLitY on November 27, 2007, 11:00:50 pm
Once we decode Cross's model format, a viewer and exporter can be coded so Cross's models can be used in 3D stuff or, for the Compendium encyclopedia, archived. But once we get 3D out of the way, we're also going to look at the instructions the game uses to string together room graphics. Then a program can be coded to replicate that and output PNGs of rooms. No matter what, it'd probably take less time to research and code that program to rip backgrounds rather than use the painstaking VRAM method. Finally, once we document everything, we can get involved in Cross ROM hacking, which is really exciting.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 27, 2007, 11:35:13 pm
Thanks for all the encouragement, everyone! This project will succeed precisely because we've got great teamwork going on here, and great knowledge on the subjects involved.

Luminaire, thanks for figuring out the unexpected switchover from quads to triangles! It would appear that my experiment earlier tonight cut into some triangle data tucked amongst the UV quads, so now I don't have to lose any sleep over the strange results.

So there's one two-byte value per non-UV vertex pointer, then. Read as signed integers, what significance does the negativity of some of the values have? Is everything relative to some offset designated "0" somewhere else, perhaps?

Luminaire, try using the attached image for your revised UV map. If Serge's texture CLUT is included, it bumps the dimensions up to 128 x 256, so it's quite possible the UV maps are correcting for the presence of the CLUT. This will map totally correctly, hopefully.

Also, I believe Luminaire stated that a total of 12 triangles "snuck in" what we thought was uniform quad UV data and pointers. That means we should bump up the number of triangles by 12 for a total of 276 triangles, and decrease our quad count by 9 for a total of 394 quads.

This discovery shouldn't affect Cyb's suggestion that there's a pointer to the quad data start (though I've been unsuccessful in confirming with Kid's and Guile's models - but I was checking haphazardly and need to spend more time with those). This could mean, however, that there's a pointer to every "switchover" from triangles -> quads -> triangles -> quads, for a total of three "transition pointers" in Serge's model. This is only based on intuition.

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on November 28, 2007, 12:36:35 am
Okay here's the new UV map. I actually think the previous one is a little better, but you can decide for yourself.

I'm still not sure what to make of the pointer data. One thing I don't understand is why the values span a range of 9424 when Section 1-3 is only 6496 bytes. Incidentally, Section 1-2 is 9616 bytes.

Another interesting thing to note: I adapted my C++ code to count how many of the UV coordinates are unique (that is, how many dots are in the UV maps I've been uploading). The result is 704. It would be nice if that was the number of vertices, but I wouldn't be surprised if it wasn't.

Also, the poly count for Serge should be adjusted to 276 triangles and 394 quads, for a total of 670 polygons.

To answer one of your questions from before: the +/- button in the Windows calculator also works in Hex mode. You should change the button from QWord (8 bytes) to Word (2 bytes) first, of course. For example, -40 is 0xFFD8 as a signed 16-bit value. More on the conversion method at Wikipedia (http://en.wikipedia.org/wiki/Two%27s_complement).

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 28, 2007, 02:15:49 pm
Yeah, the UV map with CLUT didn't turn out as well as I'd hoped. I guess we should go with the previous version then, since we know it maps Serge's belt buckle the same way it's done in-game as far as I can tell. Thanks for checking that.

Ahahaha! Now I know how to work with signed hex! Thanks Luminaire!

Wow, nice job getting the number of unique vertices. Soo, I imagine it's possible there's 704 vertex entries in Section 1-3, or whichever section is the vertex pool. That's something we can check out as well.

Followup Questions: Hey Luminaire, how exactly did you detect the presence of triangle UV maps among the quads in Serge's Section 1-2? I'd always gone by the "FF" byte pattern (since I had thought those occurred only in the non-UV vertex pointers), but is there a better (i.e., more accurate) technique seeing as FF bytes appear to be in the "V" position of some UV map coordinates?

Cyb and Halkun, were there vertex indexes similar to these in Final Fantasy VII? Now that we have a count of polygons (276 triangles, 394 quads, and therefore 670 polygons)  and vertices (828 + 1576 = 2400 vertices in the UV maps altogether, with 704 unique - possibly), how do we go about comparing our suspected vertex pool, Section 1-3, to this information?

I suppose one possible next step would be to look for headers containing values like:

FOR # OF POLYGONS...
276 = 0x0114 or 14 01 in Little Endian
 (And since the triangles are split up, the corresponding values for 264 and 12)
394 = 0x018A or 8A 01 in Little Endian
670 = 0x029E or 9E 02 in Little Endian

FOR # OF VERTICES...
828 = 0x033C or 3C 03 in Little Endian
 (Not sure if the triangle split up would force smaller separate listings of vertices here)
1576 = 0x0628 or 28 06 in Little Endian
2400 = 0x0960 or 60 09 in Little Endian
704 = 0x02C0 or C0 02 in Little Endian

I don't remember seeing any sort of header in Section 1-3; I think the data starts right into the byte-progression pattern we noted a while ago. I'll dig up a few posts relevant to that:

An early report on the subject of Section 1-3
http://www.chronocompendium.com/Forums/index.php/topic,4770.msg84065/topicseen.html#msg84065

Cyb's observation -- possibly a vertex pool
http://www.chronocompendium.com/Forums/index.php/topic,4770.msg84084/topicseen.html#msg84084

A followup citing an oddity within Section 1-3
http://www.chronocompendium.com/Forums/index.php/topic,4770.msg84094/topicseen.html#msg84094

Hahaha, one more question: I have an idea for another experiment, but I need a bit of theoretical guidance first. Provided we've got a vertex pool, if I were to zero out an entire vertex's info in the pool, what would probably happen to its associated polygon? Would the polygon not draw at all, or would the GTE/GPU attempt to draw a triangle where a quad would be, and a line where a triangle would be? I was thinking we could wipe out a vertex or perhaps an entire polygon, trace its location back to its UV map based on Luminaire's mapped texture, and that way figure out how the non-UV data addresses point to the vertex pool.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Cyberman on November 28, 2007, 05:54:31 pm
If you zero out one point for example the qauda would have a weird point attached to it (and every polygon attached to that point would mutate accordingly).

I guess finding how the information is organized (other than what it is) will be the hardest step. It took me several months staring at the bone data to have a DUH moment with FF7. :D

Cyb
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on November 28, 2007, 08:33:24 pm
There are three parts to identifying non-UV data from UV data. For a given 16-bit number, it is non-UV data if:

(1) The first byte ends is 0x?0 or 0x?8, signifying that the number is divisible by 8.

(2) The second byte is either very large (i.e. 0xF? or 0xE?) or very small (i.e. 0x0? or 0x1? or 0x2?).

(3) If three such 16-bit sequences exist adjacent to each other, then it's triangle data. If four exist, then it's quad data.

In addition, the UV data for a given poly tends to have very similar values for its three U and three V coordinates.

For example, the first triangle in Serge's UV data is 1a 63 1c 62 1b 63 70 0a 40 15 10 00. The UV coordinates are (0x1a, 0x63), (0x1c, 0x62), and (0x1b, 0x63), while the non-UV "pointers" are 0x0a70, 0x1540, and 0x0010.

Happy to clarify if any of that's unclear.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 28, 2007, 09:12:56 pm
Crystal clear, Luminaire, thanks!

Tonight's experimental results are in. See the attached image. At the top of the pic I've listed the hex code I zeroed out; offsets are immediately to the left. The offsets pointing to the various results are the ones I zeroed out per result. In the lower-left you can find a front and back view of Serge's poofy sock cuff when offsets 0x31A0 ~ 0x31A7 have been zeroed out. That's 8 bytes, and I figured based on the byte progression pattern that it might account for one vertex.

When the next four 8-byte strings are zeroed (for five 8-byte strings zeroed total), we get the result in toward the top-right. It would appear that the vertices affected have been dislocated by the same (or similar) amounts in 3D space.

Beyond that, I'm not sure what else to say. Does the vertex pool typically give coordinates in 3D space for the vertices? Would these results be theoretically consistent with messsing up the vertex pool?

Now we can relate the data in offsets 31A0 ~ 31C7 to the appropriate vertex pointers in Section 1-2. I've still gotta determine the vertices affected based on Luminaire's UV map for Serge's texture, but wanted to report this stuff first in case it's significant.

...Luminaire, you don't happen to have a copy of Serge's mapped texture that's 128x256 (or 128x252 if it's cropped to the visible texture) pixels in width and height, do you? If not, that's okay; I should be able to figure out the applicable UV coordinates still.

UPDATE: It would appear that offsets 0x31A0 ~ 0x31A7 define the spacial location of a vertex shared by polygons that create a border between Serge's sock cuff and the back of his leg. See the additional result attached below the first. This time I changed the non-zero bytes in that range from their original values to AA. Section 1-2's UV map seems to faithfully map the correct texture piece to this messed-up polygon, but because this one vertex's spacial coordinates are messed up, the texture stretches way out into space. I guess last night's results showed the same vertex crawling up Serge's leg, dragging the sock texture piece with it.

The really interesting thing is that, in Section 1-2, there's got to be a UV map for Serge's sock and a UV map for the back of his leg that share a vertex pointer. If we find something like that, we can figure out the mathematical relationship between that shared pointer in Section 1-2 and the data in this offset in Section 1-3 (vertex pool).

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Sora on November 30, 2007, 11:13:43 am
what the hell? this thread just insta-died o.O
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 30, 2007, 02:29:31 pm
Finals week arriveth soon, bringing with it insta-death of forum threads. But the next step, in my theory at least, is to identify the quad in Serge's model affected in my latest experiment above, then identify the UV map that textures that quad in Section 1-2. That will take a bit of doing though because I'm not sure if Luminaire's able to create a 128x252 mapped texture for Serge with the program he's written; no biggie though. Once we identify the UV coordinates in Section 1-2 that map said polygon, we can analyze how the associated non-UV data points to Section 1-3. IF the non-UV data points to Section 1-3, that is. But I think it should...

Anyway, we are close to having both Sections 1-2 and 1-3 completely analyzed provided Section 1-3 is indeed the vertex pool as we suspect. Then, after a wiki update, we can search for skeletal data - the arms and legs, and various clothing pieces that move in accordance with animation data. Long ways to go yet! But this project could be truly groundbreaking; besides Final Fantasy VII, I'm not sure if any other PSX game model format has been ripped and viewed successfully.

Once the format is completely analyzed, it's just a matter of writing a plugin or standalone viewer to view the models. I wish I could help in that regard, but I'll only just be getting into Python scripting over winter break (seems like a good language for a hobby-hacker to start off with). I wonder, is Blender capable of 3D model animation (completely noob question there, but I haven't explored any such functions yet), or is animation typically done in other programs once you've got a model? Yaz0r was certainly able to decode Final Fantasy X's animation format, so at least we know it's been done.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on November 30, 2007, 06:42:33 pm
Yeah, it's probably just a surge in busyness for all of us. I know it is for me.

Blender can certainly do animation of 3D models, although I am just beginning to learn how. The trick will be understanding how the PSX does it and converting it to how Blender does it, if necessary. If it's bone data like some of the PSX gurus have alleged, then it shouldn't be too bad to do this.

The way I made the UV map doesn't easily allow me to make an exactly 128x252 UV map, unfortunately. I could probably code something up, but I am wondering if that's too much work for what you need to do.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Cyberman on November 30, 2007, 07:52:44 pm
This is quite active Sora as far as I can tell. Heck if there wasn't anything on it for a few weeks then I would think faustwolf might of run into trouble or is on a trip. No biggie though.

I would guess they used variable bit depth delta compression seems to be popular with Squaresoft :)

Cyb
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on November 30, 2007, 08:11:44 pm
No prob Luminaire, and don't bother coding something up just for this small task -- I should be able to get the info I need by hand pretty easily. And wow, Cyb already knows about PSX animation compression! Do you have any general info on variable bit depth delta compression, Cyb? I assume we'll have to decompress for the animation to be "readable" by whatever viewing method we decide to go with.

Yaz0r, did they use the same compression technique in FFX, XII, and Kingdom Hearts? I know it's PS2, but I wonder if Square continued with the same (or similar) methods into it's next-gen projects.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Cyberman on November 30, 2007, 09:54:48 pm
URL for FF7 animation information it's a good reference
FF7's information (http://wiki.qhimm.com/FF7/Battle/Battle_Animation_%28PC%29) and although it says PC it is the identical format to the PS1 version data.

Cyb
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: yaz0r on December 01, 2007, 11:43:45 am
Yaz0r, did they use the same compression technique in FFX, XII, and Kingdom Hearts?

I don't know for FFXII, but FFX and KH are completely different when it comes to animation, mostly because FFX has motion captured animation while KH does not.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Sora on December 01, 2007, 08:35:28 pm
FFXII sucked. worst game ever! even 10-2 was better!
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on December 01, 2007, 09:26:20 pm
The judges were cool -- cool enough for me buy the game finally, now that I'm interested in model viewing and game resource collection. :P

But back on topic, thanks yaz0r and Cyb for the input on animations and compression formats. Unfortunately I won't have any new experimental results on my end for about a week -- I'm able to get everything I need to test out our hypotheses regarding the non-UV pointer data in Section 1-2, but college beckons for the time being. After that though, progress should pick up rapidly.

Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Cyberman on December 02, 2007, 10:56:45 am
The judges were cool -- cool enough for me buy the game finally, now that I'm interested in model viewing and game resource collection. :P

But back on topic, thanks yaz0r and Cyb for the input on animations and compression formats. Unfortunately I won't have any new experimental results on my end for about a week -- I'm able to get everything I need to test out our hypotheses regarding the non-UV pointer data in Section 1-2, but college beckons for the time being. After that though, progress should pick up rapidly.
A good idea keep your priorities straight ;)
Got that? ;)

Anyhow I'm going to play with that program I mentioned in Qhimm's forum I had been working on.  I think I have a good POA now for it.  Before I was just "Adding stuff", without planning anything.  I stopped when I said to myself "what the heck is this thing?"  So I think the first thing is to clear out useless features then add the first new feature which would be an XML (meta data) parser to read data that describes VFS on CD's.  The second would be a way to recognize CD's that the VFS belongs too.   The latter is EXTREMELY difficult I've found out.  PS1 CD's use the 'text' channel on the CD media to hide there SLUS/SLES/SLPS identification information I found out. How to discover this data with an ISO is a bit of a mystery too me (it's possible to do just not obvious how to go about it). I suspect one needs the sub channel data (crap).

This might make it a bit easier to copy data out, replace data or whatever with the ISO image at a later date. For now it's just to the VFS and where everything is (IE it's just a browser). Hence my name VFSBE (Virtual File System Browser Extension).   Actual file data will require more XML data for describing how to read the file AND what to do with it.  The nasty thing is, I will have to create my own tag system (that someone else already has created likely and I'll discovered AFTER I've done all that work), I would be pessimistic but it just won't work. :)

Anyhow a fair bit of work on my part and things might become more interesting as they say.

As to how this relates to your data fiddling, might make it easier to view the data from the file system in HEX. Are you modifying the ISO file directly and restarting the game and doing a save state load for a battle or doing as halkun et al have suggested editing the save state files?

Cyb
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on December 02, 2007, 12:32:02 pm
I've been modifying a test iso directly and re-starting the game each time (though I'm just loading up savestates, without having to go through the usual bootup process). In other words, I'm doing things the hard way. :mrgreen: The main reason being, I can only get my Chrono Cross iso to work with pSX and not ePSXe for some reason - and pSX savestates aren't quite as convenient to work with as far as I can tell. But things are still going very smoothly with this method, so it's no bother.

Your ISOViewer program sounds really awesome, Cyb! Does it display the file system based on the index file at the beginning of the CD?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Cyberman on December 06, 2007, 10:32:00 pm
Your ISOViewer program sounds really awesome, Cyb! Does it display the file system based on the index file at the beginning of the CD?
That is the idea, a separate page is supposed to display hidden file systems on game disks such as Xenogears FF8 FF9 as well as FF7 (it does have a considerable amount of hidden data hidden in the field directory). This is not an easy project, since I have to think of a sane way to describe a file system to piece the representative data from sector information.  Currently my biggest problem is either a virtual array class or how I'm accessing the data.  I suspect it's my virtual array class that is causing me headaches. All this from some sort of XML data or even a script language (that uses existing 'functions' to understand data).
A lot of the file system data I have available has been described using code It thus will be oddly entertaining to create something that can parse in an XML parser the data structures and magically read the data into a representative format (IE file browser style information). It's not that it isn't doable it's just nothing easy to do. :)

Cyb
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on December 06, 2007, 10:42:20 pm
Wow, THAT is going to be awesome when it's finished Cyb! The IsoViewer will be an absolute must-have for people who want to explore how PSX game files are stored. I'll definitely make use of it, that's for sure. Thanks for working on such an excellent utility!

It looks like I'll be able to resume the Chrono Cross model testing next Thursday, so a week from now.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Cyberman on December 07, 2007, 12:14:08 am
The idea is to make something I can use, if I can use it most people can use it.
That said comes the ugly messy stuff of dealing with data in variable length sectors.
Each new file structure and file data will need a new XML file describing how to deal with it.
Also I have to write the schema so that if someones makes an malformed file it dumps useful information why it won't work.

I'm sure it will be more useful than my original program to view data on PS1 disks I wrote a while back. Sure it allowed one to view FF7 models etc. it just was pretty clunky to debug and adding new features was a REAL pain.  Basically one had to write all new code to add new information to be viewable etc. 

Cyb

PS Hopefully it will be of use for CC data mangling.  Or at least easier to get at random files you might want.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: nightmare975 on December 11, 2007, 01:25:11 am
Seeing as I have no patience to read through 17 pages, what file type are you finding the models, if you've found them?

If you find .obj or .tim files, send them my way.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on December 11, 2007, 09:39:34 am
nightmare, the files are in a format that we're currently trying to decode, though it seems to have some close similarities to the format used in Final Fantasy IX (probably doesn't help you any, but just sayin'). I'm unsure what format the battle model textures are stored in (a variation of the TIM perhaps), but Zeality and I have all the main character textures in .bmp format. I haven't found separate textures for enemies yet -- it's possible they actually use the TIM textures we found back in October wth PSicture and TIMViewer.

This Thursday I'll finally be back in the swing of things, and all those interested can re-congregate back here for more model hacking. Once we've got everything figured out, someone can hopefully write a model viewer program/plugin for importing into Blender/3DS Max/Lightwave, etc.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: nightmare975 on December 11, 2007, 11:03:17 pm
Upon some exploration of my own, I have been able to import the models into Maya.

Problem: It imports them, but I find nothing in the plains. Not a damn thing. Funny thing is, It tells me that there is data in my "scene" (That's what Maya calls it's files).
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on December 12, 2007, 12:01:43 am
EERH?? Is there some way to specify in your import function which offsets the UV map and vertex pool begin? We currently know for sure that Section 1-2 is the UV map info, and Section 1-3 is *likely* to be the vertex pool, where I think the vertex coordinates in 3D space are specified (Cyb and others, correct my language if necessary). Relevant offsets for Serge's and Kid's models are in the Chrono Cross File Structure wiki page. I wonder if that sort of thing would make a difference?

nightmare, you've got the applicable textures for the models you're importing, right?

EDIT: For the heck of it, here's the offsets for the UV and vertex info in Serge's model. Sections 1-2 and 1-3:

SubSection2 (UV Texture Map) Offset Range: 358 ~ 28E7
SubSection3 (Vertex Pool) Offset Range: 28E8 ~ 4247

Oh! That's from the beginning of the model file WITHOUT texture included, BTW. If you feed the texture in with the model itself, that would bump the offsets up by the texture file sizes I suppose.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: nightmare975 on December 12, 2007, 12:19:40 am
An attempt to import the ModelMine file failed. Maya can not recognize the file. :(

As far as I can see, there is no way to specify the UV Map Info or Vertex Pools. :( :(

About to go on a search to find any help with this.

EDIT: My search has ended in failure. It seems that the problem is the file itself. A rare and risky solution is to import the raw rendering data into a MEL script and try from there. :( :( :(

Damn it.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on December 12, 2007, 12:47:47 am
That's what I figured; many thanks for checking it out with Maya though. An import plugin (or standalone viewer) will likely have to be developed. It's been done for Final Fantasy IX on top of Final Fantasy VII of course, so we WILL be viewing models outside the game one day.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on December 13, 2007, 06:16:06 pm
Time to get this thread back on track! Here's something for everyone to ponder. First, allow me to resurrect the working model for Section 1-2's UV map and pointer structure as a refresher:

(http://img504.imageshack.us/img504/8823/explanationoq6.gif) (http://imageshack.us)

So the UV map data for a polygon should be followed by the pointer data xx xx... and yy yy..., which in turn should point into the vertex pool (hopefully Section 1-3). I figured at first that each pair of pointer bytes would point to a single vertex like so:

                                    - U1 V1 U2 V2 U3 V3 U4 V4
P1 P1 P2 P2 P3 P3 P4 P4 -

But now I'm questioning that scheme for the pointer data. Here's a snippet of hex code from Section 1-2 pertaining to Serge's shoe:
(http://img249.imageshack.us/img249/6421/pointercheckrw0.gif) (http://imageshack.us)

Offset 0x1558 marks the start of a UV map (red box), and it should be followed by pointer info starting at offset 0x1560 (blue box). Compare with another UV map with analogous data starting at offsets 0x1578 and 0x1580. When I looked at that, I saw that these polygons share two points on Serge's texture map: points that correspond to coordinates (102, 103) and (104, 112) when converted into decimal format. A pic of where these coordinates lie on Serge's shoe texture:
(http://img248.imageshack.us/img248/7420/sergeshoedw5.gif) (http://imageshack.us)

And I thought, "Oh, snap! These UV maps should have the same pointer data for those vertices!" So I compare offsets 0x1564 ~ 0x1567 with the range 0x1584 ~ 0x1587, i.e., the applicable pointer data for those UV map coordinates (or what I thought to be such at the time). That panned out okay, but then I realized that, within the same polygon reference, the pointers for UV map coordinates (102, 103) and (104, 112) are identical! Given the distance between these coordinates on Serge's shoe, they can't possibly be pointing to the same vertex in the vertex pool.

Therefore, I no longer believe that the pointer scheme is such:

                                    - U1 V1 U2 V2 U3 V3 U4 V4
P1 P1 P2 P2 P3 P3 P4 P4 -

Because "P3 P3" and "P4 P4" should be different if "U3 V3" and "U4 V4" refer to different coordinates on the texture map, right? So the question is, does pointer data really follow the UV map data? It certainly makes sense for that to be the case, considering Final Fantasy IX followed such a scheme (thanks to Zidane from qhimm for that info). But if it is pointer data we're dealing with, it can't be pointing on a vertex-per-vertex basis. I think??

I'm still in the process of isolating a UV map that refers to a specific polygon in the vertex pool I noted earlier in this post:
http://www.chronocompendium.com/Forums/index.php/topic,4770.msg84803.html#msg84803

...so that will take some doing yet. I just noticed this phenomenon along the way and am interested in the opinions of others.

- - - - -

P.S. For comparison's sake, Final Fantasy IX's equivalent of Chrono Cross' Section 1-2 seems to be set up as follows:

P1 P1 P2 P2 P3 P3 P4 P4 - U1 V1 U2 V2 U3 V3 U4 V4
R- G- B-  TT UU UU UU UU -  (where R- G- and B- *might* stand for colors, TT for texture page pointer, and UU for unknowns). Anyone interested can download Zidane 2's FF9 documentation at this thread over at qhimm:
http://forums.qhimm.com/index.php?topic=7168.msg88403#msg88403
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on December 13, 2007, 06:56:56 pm
I would add that if you read the values you have in blue boxes as signed 16-bit values, all but the first of them are negative. Why would a pointer be negative? The only thing I can think of is that it's somehow a relative pointer (as opposed to an absolute one), but that doesn't really solve anything.

But I still think the multiple-of-8 pattern is significant. Is there anything else it could signify?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Sora on December 13, 2007, 07:09:21 pm
the nes uses 8x8 squares to draw. maybe this is the same? but i doubt it as psx is 52 bit.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on December 13, 2007, 07:18:09 pm
Hopefully when I get a polygon isolated such that we know where the UV map pointer *should* point in Section 1-3, that will help us answer some questions.

I'd like to provide another example of the pointer dilemma at work for further study, since I have one handy. First hex code, then a pic of Serge's shoe:

(http://img258.imageshack.us/img258/8746/pointercheck2ml9.gif) (http://imageshack.us)
(http://img142.imageshack.us/img142/4839/sergeshoe2eb7.gif) (http://imageshack.us)

The UV map labeled "1" is what's in the first blue box and the UV map labeled "2" is what's in the second blue box. Points in yellow are unique to UV map 1, points in, er, "ice" are unique to UV map 2, and points in green are shared between these two maps. So if the pointers operate vertex-by-vertex, we would expect two pointers to be shared. But looking at the red boxes in the code snippet, it would appear that a total of three pointers are shared. Shouldn't happen. So there's another nail in the coffin of the vertex-by-vertex pointer theory, unless someone can save it.

The multiple of 8 rule is interesting, now that you mention it again Luminaire. If this were pointer data, each byte pair should point to someplace in the vertex pool with offsets reading 0xbbb0 and 0xbbb8, is that right? Meaning, the offset number it points to would end in either "0" or "8"? The vertex pool certainly seems to be set up that way -- data aligned in 8-byte rows.

I guess we'll see what happens when I finally track down the UV map corresponding to the vertex pool polygon I saw earlier.

EDIT: Ya know what? I'm looking right at a separate UV map that maps the exact same area as "1" in the above pic. Let's take a look at its data:
                                   - 67 70 56 6E 64 67 59 66
D0 FF B0 FE E8 FF 58 FF -

Serge's shoe texture has to be used at the very least, four times in the model: two sides per foot. So it makes sense for this UV map to have a different pointer from "1" above. The differences are:

("1"'s pointer)                 ->          (This UV map's pointer)

D0 FF D0 FE E8 FF A0 08  -> D0 FF B0 FE E8 FF 58 FF
 
Does this tell us anything?
Title: A few Things
Post by: Cyberman on December 13, 2007, 08:14:44 pm
Code: [Select]
Pointers Poly 0
1910 -30, -130, -18, 898
Pointers Poly 1
1920 -30, -130, -18, 8A0
Pointers Poly 2
1930 -30, -130, -18, 8A8
I would suggest as an experiment is export the data and 'wind' the polygon's on the texture data (IE go through all the UV data and draw XOR lines on the edges of the polygons).  There is no doubt that is UV map data the question is do we have a list of vertex information OR something completely different.  I'm thinking it might be bone related data.

Silly question time, examining the directory structure a bit I noticed some files have ridiculously large LBA references, what does it mean? Also for the numeric value labeled "file type", what does that value mean? There doesn't seem to be any references as to what 'type' means.  Could it be the length in sectors? (256 * 2048 = 512k) Doesn't seem likely since video data is longer than 256 sectors (usually). Does anyone know?

Cyb
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on December 13, 2007, 08:30:15 pm
By XOR lines Cyb, what do you mean exactly?

And as for the "file type" question, are you referring to something on the Chrono Cross File Structure wiki page?

On a leap of faith, I'm going to see if the last two bytes in the "pointer data" happen to point into the vertex pool. I know that doesn't necessarily make sense since a lot of the time the values are "D0 FF" and the like, but the "98 08"; "A0 08"; etc., look quite attractive because, as relative offsets, they would point at an area that seems to contain vertices for Serge's shoe. It could be just a coincidence though. I'll report on that later.

UPDATE!: It would appear that UV map "1"'s pointer: D0 FF D0 FE E8 FF A0 08 points to offset 3188 in Section 1-3. When I zero out the data in offsets 0x3188 ~ 0x318F, one of the top vertices in "1" shifts up Serge's leg. "1" is mapped to the inner side of Serge's shoe, so getting a good pic is difficult. What I shall do is repeat the process with one of "1"'s clones, hopefully finding that it maps to the outer side of Serge's shoe for superior viewing.

The pointer in "1"'s pointer data is a relative offset from the beginning of Section 1-3, 0x28E8. I'm not sure what this means for the rest of the pointer data though, since many (perhaps all) of those end with values like D0 FF or something that doesn't nicely conform to the idea of a relative pointer from 0x28E8.

In any case I have yet to confirm 100% that I've found a pointer, but I'd say I'm at least 68% confident. I think that figure came from a stats class. We shall see...
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Cyberman on December 14, 2007, 12:08:08 am
By XOR lines Cyb, what do you mean exactly?

And as for the "file type" question, are you referring to something on the Chrono Cross File Structure wiki page?
From the Chrono Cross tools (Yaz0r?) there is a 4 byte struct defined as such:
Code: [Select]
typedef struct
{
   unsigned char LBA[3];
   unsigned char type[
} index_record;
Well not precisely as that but basically that's what it said the directory records were in the index table burried at sector 24-35 on CC disk 1.  What I was interested in was "type" what it was or wasn't and also for values of LBA address with the MSB of LBA[2] is set ment.  It must mean something or it wouldn't happen so frequently :D
It would be interesting to find out at least. Make things a bit easier for me.  These files appear to be sequential sectors of data to what's before and after them.  Not sure of there significance other than there type is always 0.

XOR is a logical operation often done with data that might have a color near that being plotted near it. Thus an XOR changes the pixel data to a state that is guaranteed (almost) not to be the same so it is distinguishable.
Notice the column labeled LS# Some of the columns begin with 8XXXXX the ones that do have type 0 and all point to the same sector (not real files?) 
(http://www.geocities.com/cyberman_phillips/Images/PS1_VW_CCD1.png)

Cyb
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on December 14, 2007, 12:57:11 am
OMG, is that ISOViewer? Looks like the project is coming along very nicely! That is awesome, Cyb! As a file reference that might be of interest to you, there's an STR-format CGI movie that begins at address 0x186BA000, so that would mean it starts at sector 200052 (decimal) or 0x30D74. Not sure if you can use that info as a cross reference in any way.

Also, thanks to Ramsus we've got offsets for the normal TIM files. One of those begins at offset 0x246000 (Sector 1164); another begins at offset 0x24d800 (Sector 1179). Those files should be of the same "type" I imagine, since they should have the same headers. There are some TIMs early on that are not aligned to a sector, which is particularly odd.

I'm updating later; need to gather pics as proof. I believe I've found a pointer in the "Pointer Data" that follows a UV map for Serge's belt buckle. But the position of that pointer is weird; I'll make a big post and people can theorize accordingly.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on December 14, 2007, 01:49:36 am
Alrighty, time for tonight's (er, this morning's) big update!

First pic is the texture piece mapped to Serge's belt buckle, with vertices defined by yellow dots.
(http://img232.imageshack.us/img232/2816/beltbucklemg0.gif) (http://imageshack.us)

Next up is the belt buckle UV map's applicable data in Section 1-2. In the blue box are the UV map coordinates on Serge's texture, and in red is the other data we've been wondering about. I believe that the third byte pair from the left (0x68 09) is a pointer -- but none of the others seem to be...
(http://img164.imageshack.us/img164/7137/buckleuvcodeyp1.gif) (http://imageshack.us)

Taken as an offset relative to offset 0x28E8 in Serge's untextured model file, that one pointer points to offset 0x3250 in the vertex pool. That data follows in the red box:
(http://img181.imageshack.us/img181/8070/bucklevertexyn4.gif) (http://imageshack.us)

Now, the very large pic below (click to view) summarizes the results of manipulating the data starting at 0x3250.
http://img181.imageshack.us/img181/5480/pointerproofzo7.gif

I should clarify first of all that when I altered the data in Section 1-3, I only altered the first, third, and fifth bytes. The second, fourth, and sixth bytes always seem to be either 00 or FF, so I steered clear to preserve the basic data structure. Likewise with the seventh and eighth bytes, which follow a very clear progression pattern. I would hypothesize that the first six bytes for each vertex entry in the pool represent X, Y, and Z coordinates in 3D space, but that's just a guess. It can be tested easily enough.

Getting back to the UV map data, and why (90 13); (E0 13); and (90 09) in the red boxed area aren't pointers...when I change the data in Section 1-3 these values should "point" to, areas other than Serge's belt buckle get messed up. If they were pointers from the belt buckle to Section 1-3, only Serge's belt buckle or some area adjacent to Serge's belt buckle should get messed up.

Another fun fact: if the third byte pair in the red box is a pointer (68 09 that is), then its position in the red box corresponds to the position of coordinates (5D,DC) on the texture map, i.e., the bottom vertex on the belt buckle quad I illustrate above. Judging from the big picture I link above (the one you have to click on), when I changed the bytes in Section 1-3 from their original values to "CC", it certainly appears as if this very same texture has been dragged over, warping the quad such that it stretches over the entire belt buckle area. The only weird thing is that it doesn't seem to take the adjacent quads below the belt buckle with it. I'm not sure if that's problematic theoretically.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on December 14, 2007, 07:54:27 pm
I'm knee-deep in Section 1-3's hex code still, because I think solving how that works can shed light on any relationship that exists between Sections 1-2 and 1-3. While I'm convincing myself of a few things, I've got a question for Cyb or anyone else who might be familiar with the topic:

How do negative pointers work? If they're relative to some offset, do they point to an address that comes before that offset? For example, if Section 1-2's non-UV data points into Section 1-3 but the pointers are negative when interpreted as signed integers, would I start at the end of Section 1-3 and count down to test where the pointers might be pointing at?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Cyberman on December 14, 2007, 08:28:44 pm
In words of one syllable yes.

That's how it should work however let me check the MIPS documentation to be certain.

Likely it's used by lw  with a sign extend (IE if it's negative it's turn into a 32bit word) then the referenced section is added and the resultant register is used to address the vertex structure.

So you negate and subtract the value.
IE
FED0 negated is 130 subtract 130 hex from your reference pointers and you should have something too look at.

Cyb
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on December 14, 2007, 08:58:53 pm
Okay, thanks Cyb! I'll see if that checks out.

I'm testing some things in the vertex pool right now (Section 1-3) and it may have the following structure:

8 bytes per vertex:
YY ** ZZ ** XX ** AA AA, where:

YY: Magnitude of coordinate on the up & down axis on the screen plane
ZZ: Magnitude of coordinate on depth axis; toward or away from you with respect to the screen.
XX: Magnitude of coordinate on right & left axis on the screen plane
**: A directional reverser byte. If 00, the vertex is placed in one direction on the preceding axis, and if FF, the vertex   gets placed on a coordinate the same "magnitude" but opposite direction on that axis.
AA AA: Two bytes that seem to form an index of some sort for the vertex. These two bytes show the progression pattern we noted a very long time ago: they go 00 00 for the first vertex, 01 00 for the second, all the way up to FF 00, then it progresses to 00 01, etc.

I may be describing these axes all wrong, and I'll post some pics later to illustrate. Also, the "origin" for each vertex in 3D space must be located with respect to a bone or something, so I'm wondering if the AA AA index somehow points to bone info.

Do vertex pools usually operate on this sort of system? Or does this setup look utterly wrong?

- - - - -

Freakin'Tastic UPDATE: I do believe the above scheme holds, based on the experiments I've conducted today. Here's some pics that result from manipulating the vertex info starting at offset 0x3250:

YY ** illustration:
This is extremely difficult to see, but look in the red circle. It appears that whatever vertex is controlled at this address has pushed the belt buckle up into Serge's chest. One can only make it out by virtue of polygon "clipping"...
(http://img257.imageshack.us/img257/3760/yfunctionupkx3.gif) (http://imageshack.us)

ZZ ** illustration:
By reversing the ** byte from FF to 00 as well as changing the magnitude on the depth axis, I've succeeded in impaling Serge with his own belt buckle...
(http://img265.imageshack.us/img265/8173/zfunctionbackfl1.gif) (http://imageshack.us)

XX ** illustration:
First pic involves changing the magnitude on the right-left axis without altering the ** switch...
(http://img265.imageshack.us/img265/6991/xfunctionleftej7.gif) (http://imageshack.us)

Next pic involves changing the magnitude on the right-left axis AND switching the ** byte, making the vertex go in the opposite direction on the right-left axis!
(http://img257.imageshack.us/img257/34/xfunctionrightco4.gif) (http://imageshack.us)

 - - - -

ADDITIONAL UPDATE:

I might as well just get all of Section 1-3 out of my system while I'm at it. Section 1-3 has 812 eight-byte "slots", and one vertex can fit in each "slot." Does that mean there are 812 unique vertices in Serge's model? NO!

Here's why I believe there aren't 812 unique vertices. Notice that each vertex "slot" has an index value AA AA following the coordinates in 3D space. In many cases the vertex pool exhibits a byte-progression pattern that affects each 8-byte "slot" as follows:

YY ** ZZ ** XX ** 00 00 - YY ** ZZ ** XX 01 00
YY ** ZZ ** XX ** 02 00 - YY ** ZZ ** XX 03 00

I shall term this pattern "8 byte mode" for future reference. But in many cases the data in Section 1-3 will enter "16 byte mode" using my terminology. That means two 8-byte "slots" are devoted to each vertex index like so:

YY ** ZZ ** XX ** 00 00 - YY ** ZZ ** XX 00 00
YY ** ZZ ** XX ** 01 00 - YY ** ZZ ** XX 01 00

Another reason why I believe one "slot" is devoted to each vertex in 8-byte mode versus two "slots" in 16-byte mode can be seen in the following picture. Only unaltered hex code is given along with the pictures; I've long since lost track of what new values I entered in.  In the top-most pic, I modified values in two adjacent "slots" devoted to separate vertices on Serge's shoe. In the bottom-most pic, I modified values in two adjacent "slots" that appear to be devoted jointly to a single vertex on Serge's belt buckle...
http://img526.imageshack.us/img526/5585/structureevidenceaq6.gif

Notice that when two adjacent slots that are in 8-byte mode are altered it affects two vertices, whereas two adjacent slots that are in 16-byte mode only affect one vertex when altered. Weird, huh?

I cannot explain why some vertices would need only one "slot" devoted to them, whereas others need two "slots." If this interpretation is accurate, however, it gives us the following structure for Section 1-3:

301 vertices in 0x28E8 ~ 0x324F (8-byte mode)
210 vertices in 0x3250 ~ 0x3F6F (16-byte mode)
   5 vertices in 0x3F70 ~ 3F97 (8-byte mode)
 43 vertices in 0x3F98 ~ 4247 (16-byte mode)

That adds up to 559 vertex indices. I'm not comfortable with that number to be honest, becaues Luminaire came up with a figure of 704 based on quad pointers in Section 1-2. I'm not finding pointers to the addresses that mark the boundaries between 8-byte mode and 16-byte mode vertices either (except the pointer from the belt buckle UV map to address 0x3250 in the vertex pool).

As far as the pointers from Section 1-2 to Section 1-3 go, I've found only a couple values that behave as pointers relative to the beginning of Section 1-3, address 0x28E8. We'll have to see what happens when we interpret the non-UV data in Section 1-2 as negative pointers relative to the end of Section 1-3, address 0x4247 (we can make it 0x4248 if that works instead). One quick way to check if this is possible is to take a look at the largest-magnitude negative and positive numbers in the non-UV data pointers. If the magnitudes are within the size range of Section 1-3, things will look up. Luminaire gave us that info awhile back, but I'll have to fish through this thread to find it again for testing.


Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on December 15, 2007, 01:50:15 am
Grr, the last post is simply too long to add even more stuff. Looks like Luminaire reported that the non-UV pointer values in Section 1-2 go from -496 to +8928.

Section 1-3 is 6496 bytes long (thanx to MDenham for the reminder), so it would appear that the non-UV pointer data doesn't necessarily point into Section 1-3. At least if the pointers are interpreted in this way. Something weird's going on. What's even more strange is that I was able to find a value that acted as a pointer to the address 0x3250, which is one of the vertices for Serge's belt buckle. Coincidence, maybe -- lots of other values that appeared like that pointer don't seem to behave as nicely.

I should mention that Section 1-4 is mathematically linked to 1-3 and consists of "4-byte mode" data in terms of my earlier terminology.

Section 1-4 follows this pattern:
?? ?? ?? 00 ?? ?? ?? 00 - ?? ?? ?? 00 ?? ?? ?? 00
?? ?? ?? 00 ?? ?? ?? 00 - ?? ?? ?? 00 ?? ?? ?? 00

Its purpose is unknown to me as of yet. Every fourth byte is "00", no ifs, ands, or buts. If interpreted as four bytes per "slot", there are 812 "slots" in this section, and 812 possible "slots" in the preceding section. Luminaire noted this earlier as well.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on December 15, 2007, 08:19:59 am
Grr, the last post is simply too long to add even more stuff. Looks like Luminaire reported that the non-UV pointer values in Section 1-2 go from -496 to +8928.

Section 1-3 is 9744 bytes long, so there's some possibilities here. I should mention that Section 1-3's structure was unfinished in my last post; lapse of brain power. Here's a map for all of Section 1-3, with some weird "4-byte mode" data that I haven't even begun to look at yet:

301 vertices in 0x28E8 ~ 0x324F (8-byte mode)
210 vertices in 0x3250 ~ 0x3F6F (16-byte mode)
   5 vertices in 0x3F70 ~ 0x3F97 (8-byte mode)
 43 vertices in 0x3F98 ~ 0x4247 (16-byte mode)
812 unknown "slots" in 0x4248 ~ 0x4EF7

For review, data termed "8-byte mode" follows this pattern:
YY ** ZZ ** XX ** 00 00 - YY ** ZZ ** XX 01 00
YY ** ZZ ** XX ** 02 00 - YY ** ZZ ** XX 03 00

"16-byte mode" follows this pattern:
YY ** ZZ ** XX ** 00 00 - YY ** ZZ ** XX 00 00
YY ** ZZ ** XX ** 01 00 - YY ** ZZ ** XX 01 00

And introducing "4-byte mode":
?? ?? ?? 00 ?? ?? ?? 00 - ?? ?? ?? 00 ?? ?? ?? 00
?? ?? ?? 00 ?? ?? ?? 00 - ?? ?? ?? 00 ?? ?? ?? 00

4-byte mode's purpose is unknown to me as of yet. Every fourth byte is "00", no ifs, ands, or buts. It should be noted that the "4-byte mode" section is mathematically linked to the data that precedes it: 812 "slots" in this section, and 812 "slots" in the preceding sections if you count 4 bytes per "slot" in the data from 0x4248 ~ 0x4EF7 and 8 bytes per "slot" in the data from 0x28E8 ~ 0x4247. Luminaire noted this earlier as well.

Well, 0x4248-0x4EF7 is Section 1-4, not the tail end of Section 1-3, according to posts earlier in the thread (page 7, and, in fact, your post (http://www.chronocompendium.com/Forums/index.php/topic,4770.msg84122.html#msg84122)).

I suspect 1-4 may be the bone data, but I'm not entirely sure about that (it seems awfully short for that, combined with the earlier observations that changing it had no apparent effect).

A couple of hunches here:

* The "pointers" in 1-2 may be using the top three or four bits for something else (since everything is guaranteed to be a multiple of 8 for whatever it's pointing at, it'd make a little sense to shift out the extra three zeros and pack in some additional information).  If all of the pointer values are multiples of 8 already (or all of them are identical modulo 8, which amounts to the same thing), disregard this.

* Is there a chance that the 16-byte vertex data pertains to the quads, while the 8-byte vertex data pertains to triangles (perhaps including normals for quads, while just implying them for triangles)?

--

Edit, after looking up earlier on the page, and not related to the rest of the post:  Cyb, it looks like all of the 0x8XXXXX entries are followed, at the end of any sequence of them, by an entry that's 0x0XXXXX where the last 40 (maybe the last 47) bits are identical.  I think the 0x8XXXXX entries just carry additional information (long file names, possibly - not having much luck looking up any sort of info that'd help here).
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on December 15, 2007, 12:06:46 pm
 :shock: Oh, shoot! You're right. Thanks for reminding me what I wrote earlier.  :mrgreen: I've rescinded the inaccuracy.

I'll do some more tests with Section 1-4 to make absolutely sure it has no effect when it's changed; I can't believe Square would just stuff extraneous data into their models and waste storage space. Changing it has to have some repercussions, and I'll explore further.

MDenham, your suggestion regarding "16-byte mode" being quad data and "8-byte mode" being triangle data is intriguing. First of all, the switches between "8-byte mode" and "16-byte mode" in Section 1-3 are analogous to the switches between triangle data and quad data in Section 1-2 (we'll need to see if the proportion of vertex indices in offsets 0x3F70 ~ 3F97 to triangle maps that sneak unexpectedly late into Section 1-2 is realistic). If that many triangles could reasonably be composed of 5 vertices, I'd say we have a winner here! Secondly, we already know that the info starting at offset 0x3250 controls a vertex on Serge's belt buckle, which is composed of quads!

EDIT: Darn, those 5 vertices in 0x3F70 ~ 0x3F97 would have to be applicable to 12 triangles (Luminaire reported the 12 triangle figure earlier, and it's correct). I've also checked the 5 vertex figure in the vertex pool, and that's correct. However, it would complicate things in a good way if those triangles were defined by those 5 vertices as well as vertices controlled by surrounding "16-byte mode" "slots." Hope that makes sense.

The thing to do next, then, is definitely to check whether the "8-byte mode" data only affects triangles.

- - - -

ADDITION: It'll take some doing to definitively prove whether or not "8-byte mode" data in Section 1-3 refers to triangle vertices whereas "16-byte mode" data refers to quad vertices. But for now, here's a side-by-side comparison of Sections 1-2 and 1-3, so that we can draw some preliminary conclusions:

SECTION 1-2 STRUCTURE                           SECTION 1-3 STRUCTURE
0x0358 ~ 0x0FB7: Triangles, 264                 0x28E8 ~ 0x324F: "8-byte mode", 301 vertices
0x0FB8 ~ 0x2657: Quads, 362                     0x3250 ~ 0x3F6F: "16-byte mode", 210 vertices
0x2658 ~ 0x26E7: Triangles, 12                   0x3F70 ~ 0x3F97: "8-byte mode", 5 vertices
0x26E8 ~ 0x28E7: Quads, 32                       0x3F98 ~ 0x4247: "16-byte mode", 43 vertices
= 670 polygons (176 tris, 394 quads)            = 559 vertices (306 in "8-byte mode" and 253 in "16-byte mode")

...Which is a bit wonky. Why would there need to be 306 vertices for only 176 triangles, yet only 253 vertices for so many quads? But depending on how they're all connected, perhaps it could still work out somehow. I think the map of Section 1-2 is correct -- Luminaire, can you back me up on that from memory? I think 670 polygons was the final figure we arrived at back in November.

As an upbeat note to all, Sections 2 and 3 (Big Sections, that is, not subsections) are both relatively small -- only 816 bytes between the two of them I think. And I believe the rest of the model is probably animation data. If Section 1-4 turns out to be inconsequential again, we can look into Sections 2 and 3 for bone data perhaps.

I'll try for an update to the File Structure wiki this weekend so we can get all this stuff in one place so we don't have to slog through 18 pages of posts to find basic info.

Oh! But let's not forget about Section 1-1 either. I still don't know what that is, and it's difficult to test because the game goes all spastic and dies when it tries to load a model with this subsection altered. This may be bone data too, considering Cyb said FF7's bone data is stored toward the beginning of those models IIRC.

- - - -

ADDITION: Checked Section 1-4 again, and sure enough, when I 00'd it out, nothing happened. Serge is still fully intact, and all his animations work just fine even without Section 1-4. I suppose we can safely ignore it.

Also, the file structure wiki is finally up-to-date. MDenham, if you haven't checked it out before, everything we know (or think we know) about the Chrono Cross battle model structure is here:
http://www.chronocompendium.com/Term/Chrono_Cross_File_Structure.html#Character_Battle_Models
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on December 15, 2007, 07:31:44 pm
ADDITION: It'll take some doing to definitively prove whether or not "8-byte mode" data in Section 1-3 refers to triangle vertices whereas "16-byte mode" data refers to quad vertices. But for now, here's a side-by-side comparison of Sections 1-2 and 1-3, so that we can draw some preliminary conclusions:

SECTION 1-2 STRUCTURE                           SECTION 1-3 STRUCTURE
0x0358 ~ 0x0FB7: Triangles, 264                 0x28E8 ~ 0x324F: "8-byte mode", 301 vertices
0x0FB8 ~ 0x2657: Quads, 362                     0x3250 ~ 0x3F6F: "16-byte mode", 210 vertices
0x2658 ~ 0x26E7: Triangles, 12                   0x3F70 ~ 0x3F97: "8-byte mode", 5 vertices
0x26E8 ~ 0x28E7: Quads, 32                       0x3F98 ~ 0x4247: "16-byte mode", 43 vertices
= 670 polygons (176 tris, 394 quads)            = 559 vertices (306 in "8-byte mode" and 253 in "16-byte mode")

...Which is a bit wonky. Why would there need to be 306 vertices for only 176 triangles, yet only 253 vertices for so many quads? But depending on how they're all connected, perhaps it could still work out somehow. I think the map of Section 1-2 is correct -- Luminaire, can you back me up on that from memory? I think 670 polygons was the final figure we arrived at back in November.
Well, that throws a little bit of a monkey wrench into my original idea that 8-byte vertices are solely for triangles, though I'm still pretty confident that the 16-byte vertices are a vertex plus a normal at that vertex.  (This means that there are "curved" triangles, potentially, if any of their entries hit a 16-byte vertex.)

So now comes the easy test for whether or not I'm right about these carrying a normal:

Change the second half of a 16-byte entry that's in a relatively obvious place (I'd suggest the head, if you can pin one down there).  If there's no obvious or major effect, the second half is, in fact, a normal.  (Don't zero out the normals completely, because that'd cause potential problems with division by zero.)

I'm willing to wager that 1-4 originally was color weighting for the vertices, and isn't paid attention to anymore because either the effects weren't what Square wanted or it slowed down the PSX too much to do the model that way (it is faster to just piece a texture around it than to interpolate colors as needed, though not drastically so).  If/when we can actually get a full model put together correctly, it'd be interesting to see what happens when the model's colored according to this idea.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: halkun on December 15, 2007, 07:38:39 pm
Dumb question:

Why are you using the battle screen to test when you can use the character view screen to see you changes? The character view screen has a much higher resolution so you can see things better....
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on December 15, 2007, 07:58:21 pm
My guess is FaustWolf has been wanting to see how the battle animations are affected by his hex modifications. But you bring up a good point about looking at vertex/face effects.

670 was indeed the most recent poly count.

Don't forget that the triangle data in Section 1-2 has 6-byte pointer sections rather than 8-byte. This means that whatever decisions you make about what the pointer data means must be adaptable to both the triangle and quad data.

I'm willing to wager that 1-4 originally was color weighting for the vertices, and isn't paid attention to anymore because either the effects weren't what Square wanted or it slowed down the PSX too much to do the model that way (it is faster to just piece a texture around it than to interpolate colors as needed, though not drastically so).  If/when we can actually get a full model put together correctly, it'd be interesting to see what happens when the model's colored according to this idea.
That's what I was thinking too.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on December 15, 2007, 10:12:10 pm
Thanks everyone! Halkun, as for why the battle screen v. the character menu screen for observation, the game actually uses separate models for the character menu, believe it or not! The models are roughly identical to the character battle models, understandably lacking animation data. In addition to the lack of animation, Serge's simplified model has data that isn't aligned in the same way as Serge's "real" model -- Serge's "real" model is actually easier to look at in a hex editor.

Now that you've given me more ideas for experiments, it's time to get cracking!

- - - - -

BOY, have I got interesting news!

It appears that both "slots" in "16-byte mode" data do the EXACT SAME THING!! Here's an illustration. It's big, so click. The pic on the left is offset 0x3258's right-left coordinate function in action, compared to 0x3250's on the right. Neat, huh? So both control the same vertex's coordinates:
http://img107.imageshack.us/img107/633/3258xfunctionleftad4.gif

But that ain't all, folks. It just so happens that when a vertex is in "16-byte mode", both "slots" interact to produce the vertex's location in 3D space!! Look at the next pic; the altered code shows what happens when both this vertex's X functions are assigned the same magnitude and direction -- the magnitudes build on each other, producing a coordinate that is way farther to the left than possible with one "slot" alone. The pic on the right is just a back view showing just how far out the vertex extends under these conditions.
http://img338.imageshack.us/img338/7362/doublexfunctionleftoi4.gif

Now I'm really excited. I guess this shows that the second "slot" isn't devoted to a normal, but at least we now know the purpose of "16-byte mode" in Section 1-3! So the data enters "16-byte mode" for vertices that, for some reason, need two interacting coordinate data "slots".

Any more ideas for experiments? We are totally kicking ass once again. I've tried and failed again to get Section 1-1 into testable state; even being very careful with a data transplant from Kid's Section 1-1 to Serge's, the game still cries bloody murder when it tries to load the character models in battle.

I still can't get the working pointer from address 0x10D4 to address 0x3250 out of my mind; I wonder if every vertex that's in 16-byte mode has such a working pointer, while the vertices that are in 8-byte mode are pointed to in a bizarre way, perhaps exactly what MDenham suggested earlier about a collection of bits and not the entire byte pair being used as the pointer for those. That's just a crazy hunch on my part though, but it's fairly easy to test -- I'll just go to the next set of "16-byte mode" slots, calculate the pointer that would be needed to point there relative from the beginning of Section 1-3, and see if such a pointer value actually exists in Section 1-2.

- - - - -

Breaking News from the FW laboratory: Another working pointer found. Update definitely tomorrow morning once a personal theory of mine is developed -- it isn't quite as simple as I supposed above, but we might be able to get a better understanding of what's going on, perhaps.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on December 16, 2007, 03:50:18 am
Well, this isn't the breakthrough I was hoping for, because I can't make head or tail of what's going on with Section 1-2's non-UV pointer data just yet. But here's what may be three working pointers for everyone's perusal. Keep in mind that the data in Section 1-2 is stored as follows for quads:

                                    - U1 V1 U2 V2 U3 V3 U4 V4 
P1 P1 P2 P2 P3 P3 P4 P4

So here's a section of code from Section 1-2. Suspected pointers are highlighted in red boxes, and their corresponding UV map coordinates are boxed in blue.
(http://img249.imageshack.us/img249/3493/pointerlistsampleyz8.gif) (http://imageshack.us)

The first red box almost certainly points to a certain vertex on Serge's belt buckle -- that's the very vertex I've been manipulating for all of today's experiments. The pointer's value (0x0968) behaves as a relative pointer (relative to 0x28E8) to address 0x3250, the start of the two 8-byte slots that control the vertex. The corresponding UV map coordinate is at the bottom of Serge's belt buckle, which corresponds perfectly with where we would expect the vertex to be.

Click on the pic below for proof of the second red box's possible pointer status:
http://img257.imageshack.us/img257/7045/pointerexample3260wo5.gif
Here's the interesting thing: we would expect the pointer value (0x0970) to point to address 0x3258. However, I believe it actually points to 0x3260 based on the visual evidence. I.e., the alteration of the 0x3260 / 0x3268 pair in Section 1-3 warped the circled vertex on the UV map; alteration of 0x3258 is the same as alteration of 0x3250 as proven in my earlier post. Therefore, I will call this a "questionable" pointer, since it doesn't point precisely where we would expect it.

Next is proof of the third red box's possible pointer status, this actually might not be a pointer, on second thought; the vertex affected doesn't seem to be in the right place on the quad map after all]:
http://img257.imageshack.us/img257/2441/pointerexample3270ay6.gif
The value in the third red box (0x0988) [might] behave as a relative pointer to address 0x3270, and alteration of the "slot" beginning at said address appears to warp the circled vertex on Serge's model [or not].

For awhile I thought the following pattern might hold:

Pointer value 0x968 points to 0x3250.
Pointer value 0x970 should point to 0x3258, but gets "bumped up" to 0x3260 because 0x3258 is already linked to 0x3250.
Pointer value 0x988 points to 0x3270.
Pointer value 0x990 should point to 0x3278, but gets "bumped up" to 0x3280 because 0x3278 is already linked to 0x3270.

...Except for the fact that the value 0x0990 just to the right of the first red box does not point to 0x3280. Nor does it even point to 0x3278; altering either of those "slots" in Section 1-3 affects vertices completely unrelated to the quad being mapped out in this case. So I think we can scrap this proposal.

So, I'm still confuzzled. I would recommend treating the first red box as a real pointer, and the second and third red boxes I'm a little iffy on for the above-stated reasons. Also, the pointer at address 0x10D4 (the first red box) only occurs once. The value at address 0x10E4 (an adjacent quad) corresponds to the very same coordinate on the UV map, so this should refer to the same vertex as the pointer at address 0x10D4. Is there any way the values 0x968 and 0xFFE0 could possibly point to address 0x3250 in Section 1-3?

I'll try out some more potential pointers in this data range tomorrow. If that yields nothing conclusive, I'll move on to Sections 2 and 3 (big sections, not subsections) to search for bone data. The data in Sections 1-2 and 1-3 must be related to the bone data somehow, so finding the bone data may help solve our difficulties.

Also, if anyone needs clarification on anything I've reported in this post, just ask. Things are getting really complex now. Though animation data will be worse, I'm sure. :P
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Sora on December 16, 2007, 01:47:55 pm
Is there any way the values 0x968 and 0xFFE0 could possibly point to address 0x3250 in Section 1-3?

if they're both pointing to it, or pointing to another pointer that is pointing to it.
im not 110% but i think you can have pointers of pointers.

IE
0x986 -> 0x1337 -> 0x3250.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on December 16, 2007, 01:51:18 pm
Interesting. I'll keep that in mind then. Real quick Sora, what's the relationship between 0x986 and 0x1337 in your example? 0x986 seems to point directly to 0x3250 but there's always the possibility that it's going through an intermediary in some way, I suppose.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Sora on December 16, 2007, 03:28:35 pm
it reads: 0x986 points to 0x1337 (i made up this pointer, btw) which is a pointer on its own that is pointing to 0x3250.
i am not basing this on anything i've seen in the chrono files (i havent looked at em) just on my programming knowledge (and pointers were always a pain in the ass for me, <3 Java)
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on December 16, 2007, 04:24:19 pm
Ah, okay. Thanks for clarifying.

So as I see it now, there's two possibiliities for the pointers. First is the intermediary pointer possibility as Sora described above (which could apply to pointers besides the first and third red-boxed pointers I listed above; I'm fairly confident those are straight pointers).

Secondly, as MDenham described, the non-UV data may be composed of pointers as well as other unknown info. Perhaps bone info, perhaps some other kind of orientation info for the polygons. This info would not be needed for the first red-boxed pointer a few posts above, and probably not for the third one either if I'm correct in assuming it is also a "working" pointer. But this info might be in the second red-boxed pointer, meaning we would have to "discount" the pointer by some value to get the true pointer. Here's a theoretical illustration of what that would mean:

First red-boxed pointer: 0x968 = [(Pointer, value 0x968) + (other, value 0x00)]
Second red-boxed pointer: 0x970 = [(Pointer, value ???) + (other, value ???)]
Third red-boxed pointer: 0x988 = [(Pointer, value 0x988) + (other, value 0x00)]

One way to test would be to try and find the vertex to which UV coordinate #4 on Serge's belt buckle maps (I don't have a pic up for that, so don't worry if it doesn't make sense -- coordinate #4 would be the UV coordinate corresponding to the non-UV value 0x990, just to the right of the first red-boxed pointer above).

- - - -

UPDATE: I think I may have just found three more working pointers from the non-UV data in Section 1-2 to the vertex pool. I'm getting some pics together to illustrate where the pointers are in terms of hex addresses and their impact on vertices specified by the UV coordinates.

Also, I should point out that I've noticed the 3D coordinates for the vertices specified in Section 1-3 are given in reference to the bone the vertex is on. For example, I changed the up-down magnitude and direction for a vertex on Serge's sock, and the vertex crawled up his leg diagonally, i.e., the vertex moved in accordance with the bone's angle. So the vertex indices given in Section 1-3 may refer to bone data in some way.

- - - -

Promised Update: Okay, here's an illustration of four working pointers (i.e., what appear to be pointers relative to address 0x28E8, the beginning of the vertex pool), which will hopefully give everyone a full idea of what I've been looking at today. Sorry, pics are big, so click to view.

First pic: three working pointers on Serge's shoe. Hex code insets show the code in Section 1-2 (top inset) and the code in Section 1-3 the pointers point to (bottom inset). Pointers are in red boxes as always. There are three polygons numbered in red here, and I've given the order in which each each coordinate in each polygon's UV map is listed. So the label "1-#2" is the first polygon's second UV map coordinate on Serge's texture. The circled coordinates apparently correspond to vertices in Section 1-3, i.e., altering the coordinate in Section 1-3 suggested by the vertex's non-UV byte pair makes this vertex on Serge's model shoot out somewhere.
http://img257.imageshack.us/img257/5940/shoepointersyb6.gif

Let's run through an example. The coordinate "1-#4" (0x59, 66 in hex) has a suggested pointer of hex value 0x0898 (fourth byte pair of polygon 1's non-UV data). This points to address 0x3180 in Section 1-3, and when this vertex is altered, sure enough the circled point on Serge's model does funky things. It should be noted that this vertex is in "8-byte mode".


Second pic: one working pointer on Serge's belt buckle; this is the one I used to determine the various purposes of the byte positions in the vertex pool.
http://img339.imageshack.us/img339/3926/bucklepointersor4.gif

The coordinate "1-#3" (0x5D, DC in hex) has a suggested pointer of hex value 0x0968 (third byte pair of polygon 1's non-UV data). This points to address 0x3250 in Section 1-3, and when this vertex is altered, sure enough the circled point on Serge's model does the funky things I've reported in previous posts. It should be noted that this vertex is in "16-byte mode." Thus, the data starting at address 0x3258 pertains to the same vertex as the data starting at 0x3250.


To tell everyone the truth, I've never seen more than one "working" pointer in each row of Section 1-2's non-UV data. This "working" pointer doesn't seem to have a definite position in the row though -- the shoe pic shows that the working pointers are all the fourth byte pair of non-UV data, but the belt buckle pic shows a working pointer as the third byte pair of non-UV data. The next step I'm going to take is to pick a random triangle and a random quad and see if each has at least one "working" pointer. It may tell us that only one pointer is necessary for each polygon, and the rest of the data can somehow be devoted to bones or other orientational aspects.

Whew! I'm going to take a day off and go collect 2D data (the EASY stuff) from another game. This will hopefully give everyone some time to digest the findings from page 18 onward in this thread. I'll check back though to clarify on things as necessary.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on December 17, 2007, 02:16:34 am
Behold, the first working negative pointer!  :lee:

http://img140.imageshack.us/img140/2973/negpointerpm3.gif

The non-UV data value at 0x2870, 0xFF50, yields the value 0x4198 when it's added to 4248 (b/c FF50 is negative when interpreted as a signed integer -- right?). And voila, when the data spanning addresses 0x4198 ~ 41A8 (it's in "16-byte mode") is altered, it appears that the proper vertex on Serge's model is affected!

Now, this certainly doesn't end our problems, and may generate more questions than answers. Firstly, I still haven't determined whether there's more than one "working" pointer per quad/triangle mapped in Section 1-2. In this case, the value 0x1168 (last non-UV byte pair for the quad) does not appear to point to its corresponding vertex, and I have yet to check the other non-UV byte pairs. For one thing, the value 0x22E0 in the byte pair next to the working negative pointer is too large to point into Section 1-3. I wonder what's up there? Anyone have any ideas? I've tried out Sora's idea, but interpreted as a pointer to another value in Section 1-2, it points to a value that's FFD0. Many other polys in Section 1-2 have non-UV byte pairs that are FFD0, so I'm in doubt as to the possibility that all these polys could be pointing to the very same vertex. I'll investigate the FFD0 conundrum later.

Secondly, how does the GPU/GTE know when to add the pointers to offset 0x28E8 or to 0x4248? BTW, 0x28E8 is the beginning of Section 1-3, whereas 0x4248 marks the end.

Thirdly, I have to reproduce similar results with another negative pointer before we can be absolutely sure. But I figure if we can successfully trace a vertex in Section 1-3 back to Section 1-2 based on a supposed pointer value, that happenstance is unlikely to be a fluke.

Fourthly, even if I'm able to reproduce this sort of thing, I expect that not all negative byte pairs will point correctly, just as not all positive byte pairs point correctly. I still think there might be other info stuffed in some of these pointers as MDenham proposed earlier. Maybe I was incredibly lucky and chose to investigate a vertex pointed to by a value for which this "extra" info is essentially zero, making the byte pair value point correctly without having to be decomposed.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on December 17, 2007, 07:59:41 pm
Come one, come ye all! THIS is what you've been waiting to see! THIS is what you've come here for! Watch as some of Section 1-2's and 1-3's mysteries unfold before your eyes!

First, I give you the almighty "shoe." This texture will have to account for both sides of both of Serge's shoes. That means we might be able to account for any bone data within the pointers eventually (but not yet; I shall show you other important things for the time being). Below is Serge's shoe texture, with some quads mapped over the cuff:
(http://img122.imageshack.us/img122/2843/shoemapmx6.gif) (http://imageshack.us)

What follows is some code in Section 1-2 that acts on this texture piece. The red numbers to the left of each pointer data row correspond to the numbers of the quads mapped out above. "A" and "B" I've singled out as particularly interesting, because they both have the exact same pointer data, yet different quad UV maps are applied to them.
(http://img155.imageshack.us/img155/5863/shoecodecd2.gif) (http://imageshack.us)

Now for my first trick. I shall ask and answer the following question: "If I set quad A's pointers to 00 00, will that quad map to the vertex at address 0x28E8 in Section 1-3? The answer: A resounding YES!!
http://img402.imageshack.us/img402/2503/experiment1resultsjj8.gif

How can we tell? The left and center pics show the effect on Serge's sock cuff of zeroing out quad A's non-UV data. It may appear as if the quad and the quads it connects to have disappeared, but the center pic shows that the UV map has merely converged on a point just below the back of Serge's jacket, probably warping some connecting quads along the way. The right pic shows what happens when the data starting at address 0x28E8 is altered; the coordinate to which the zero'd texture piece maps changes!!


Now for the second trick. I shall ask and answer the question: "Seeing as several of these quads map the same texture piece in Section 1-2, do these act on the same foot (bone)? The answer: a resounding YES! BUT ON BOTH SIDES OF THE SAME FOOT!!
http://img440.imageshack.us/img440/6842/experiment2resultsor6.gif

When the UV map data for quads "A" through "B" are blacked out, Serge's entire sock cuff gets blacked out on one foot! The pics are just the same alteration at different angles to prove that this section of data applies to both sides of the same foot. In other words, notice from the shoe texture that quads "1"; "2"; "3"; "4"; "5"; and "B" map the same three quads twice; that's because each quad gets used on one side of this foot. It's very difficult to tell, but I believe Quad "A" maps to the outer side of the foot; it's counterpart, which remains unlisted in this post, would black out the inner side of the foot if I could locate it.

What have we learned from this post? Well, that the non-UV data, when set to 00 00 in all byte pairs, are made to point to the same address -- 0x28E8. If I can find the counterparts of these quads on the other foot, we can see if the pointers are "situational" in any way -- if the symmetrical pointer values all point to 0x28E8 when they're zero'd out, then we know that regardless of which bone the texture applies to, it will always point to 0x28E8 if its non-UV data is 00 00 for each byte pair.

In addition, we might be able to tell if some kind of orientational info is in the non-UV data along with pointers. Quads "2"; "3"; "4"; and "5" have identical pointer values except for the last byte pair. They're on the same bone (I think? Since they're on the same foot), but on different sides. It's possible that the first three byte pairs of any UV map's quad data refer to bone information I suppose (Cyb suggested this earlier). We'll have to account for triangles as well, and I'd like to point out that the working pointsrs in the data being examined (the fourth byte pairs of non-UV data for quads "1"; "2"; "3"; "4"; and "5") point into "8-byte mode" sections of Section 1-3. The fourth byte pairs of "A" and "B" are not working pointers -- negative or otherwise.

And, of course, whatever anyone else sees fit to add. I'm going to see which quads map to which side of this foot next, and maybe we can glean some pointer information from that.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on December 17, 2007, 11:29:27 pm
S'more findings: http://images.jupiterimages.com/common/detail/02/00/23030002.jpg

Okay, that was a horrible play on words.  Looking at hex code for three days straight does weird things to one's sense of humor. Anyway, here's some more results.

FACT: Quads "A" and "B" map to the same side of Serge's shoe, the outer side. Here's what happens when one blacks out "A" and "B" 's UV data: http://img525.imageshack.us/img525/1803/abblackedss0.gif

Quad A's non-UV data values: D0 FF B0 FE E8 FF 58 FF
Quad B's non-UV data values: D0 FF B0 FE E8 FF 58 FF


FACT: Quads "1" and "2" map to opposite sides of Serge's shoe. They're both on the back of the shoe, but symmetrically opposite: http://img525.imageshack.us/img525/3342/12experimentza1.gif

Quad 1's non-UV data values: F0 FF D0 FE 88 08 90 08
Quad 2's non-UV data values: D0 FF D0 FE E8 FF 98 08


FACT: Quads "3" and "B" map to opposite sides of Serge's shoe:
http://img525.imageshack.us/img525/6194/3bexperimentpq8.gif

Quad 3's non-UV data values: D0 FF D0 FE E8 FF A0 08
Quad B's non-UV data values: D0 FF B0 FE E8 FF 58 FF


FACT: Quads "4" and "5" map to opposite sides of Serge's shoe. Like "1" and "2", they seem connected yet symmetrically opposite:
http://img525.imageshack.us/img525/4971/45experimentzq4.gif

Quad 4's non-UV data values: D0 FF D0 FE E8 FF A8 08
Quad 5's non-UV data values: D0 FF D0 FE E8 FF B0 08


Anyone notice any useful patterns in the hex code? It would appear that all quads for which the last byte pair ends in the digit "8" map to one side of Serge's shoe, whereas all quads for which the last byte pair ends in the digit "0" map to the opposite side.

Also keep in mind that the last byte pairs of non-UV data for quads "1" through "5" are working positive pointers, whereas the last byte pairs of quads "A" and "B" do not appear to behave as nicely. Also, it's really weird that when the non-UV byte pairs of "A" are altered to 00, they behave as pointers to 0x28E8, the beginning of the vertex pool. However, when they are in their present state, they do not behave as working pointers. Therefore, whether or not the value is a pointer seems to be intrinsic within the value itself.

But on the other hand, not all values that look like they should be positive pointers really are. Confuzzlement. Any ideas on how these non-UV data might work?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on December 18, 2007, 12:24:14 am
Also keep in mind that the last byte pairs of non-UV data for quads "1" through "5" are working positive pointers, whereas the last byte pairs of quads "A" and "B" do not appear to behave as nicely. Also, it's really weird that when the non-UV byte pairs of "A" are altered to 00, they behave as pointers to 0x28E8, the beginning of the vertex pool. However, when they are in their present state, they do not behave as working pointers. Therefore, whether or not the value is a pointer seems to be intrinsic within the value itself.
I assume specifically that you mean that you're changing all of A's non-UV to 0, and not just the pointer part.

The only thing I'm seeing as any sort of flag is that the second word is 0xFEB0 instead of 0xFED0 for A and B, which makes it look like the first four bytes of non-UV data are flags pertaining to, for example, whether or not the last four bytes are two pointers, one pointer and one non-pointer, two non-pointers, or whatever.

However, since the same bit is set in quad 1's Flags1 (only without the other bit, 0x0040, reset to 0), it looks like the 0x0020 flag isn't strictly a "corresponding value is a pointer" flag.

---

Side comment, and thoroughly unrelated to the current line of research: I have a pretty good guess as to what the "gobbledygook" value may be, and why modifying Section 1-1 seems to wreak such havoc.

The "gobbledygook" value is probably a checksum for Section 1-1.  This would explain why a pointer is kept to it, why making changes to Section 1-1 crashes the game (it doesn't match the checksum, game halts; when the game was being tested, presumably it'd pass information to an external debugger saying "hey, check me out"), and so on.

The problem is that I'm not entirely sure if it's just a straightforward "sum of this and every four-byte entry in 1-1 is 0" checksum, or if it's a CRC32, or what - but there's my idea as to what's going on earlier in Section 1.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on December 18, 2007, 02:30:11 am
Thanks MDenham! Yes, I've been changing all the non-UV data to 00, on the assumption that the pointers would work on a byte pair-by-byte-pair basis. So in my first example where I changed quad "A" 's pointers, the non-UV data went from its normal state:

D0 FF B0 FE E8 FF 58 FF

to: 00 00 00 00 00 00 00 00. It seemed to make the UV map for A extend out to the vertex defined at address 0x28E8. Actually, I haven't found a working pointer anywhere in A's non-UV data; the values all look like they could be negative pointers, but no go -- all the vertices mapped at the addresses they would point to are on Serge's jacket and not his shoes.

Plus, both "A" and "B" have the exact same non-UV data, which worries me incredibly -- if these data values were pointers, these UV maps should be drawn to the same polygon on Serge's model, which isn't the case. That really complicates things.

THANK YOU for the checksum suggestion regarding Section 1-1 -- that's certainly a most plausible explanation for what's going on there. Looking at my records, it appears I was actually able to change one byte per experiment in Section 1-1 without a hitch back in October. I really didn't have any clue as to what I was looking for back then, so I think I'll try again and see what happens. I'll report what the original and new values are for the data I change, and maybe you can tell from that whether there's a checksum involved.

In addition to re-examining Section 1-1 very carefully, I'll try searching for bone data in Section 2 and Section 3. It's possible that the bone arrangement can provide some insight into how the non-UV data in Section 1-2 works, hopefully.

And BTW, does my model for the vertex coordinates in Section 1-3 appear plausible based on the visual evidence provided? I welcome critiques. And I have yet to determine the purpose of the vertex indices that follow the 3D coordinate data. Could be that that's linked to the bone data in some way too.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on December 18, 2007, 04:38:49 am
Thanks MDenham! Yes, I've been changing all the non-UV data to 00, on the assumption that the pointers would work on a byte pair-by-byte-pair basis. So in my first example where I changed quad "A" 's pointers, the non-UV data went from its normal state:

D0 FF B0 FE E8 FF 58 FF

to: 00 00 00 00 00 00 00 00. It seemed to make the UV map for A extend out to the vertex defined at address 0x28E8. Actually, I haven't found a working pointer anywhere in A's non-UV data; the values all look like they could be negative pointers, but no go -- all the vertices mapped at the addresses they would point to are on Serge's jacket and not his shoes.

Plus, both "A" and "B" have the exact same non-UV data, which worries me incredibly -- if these data values were pointers, these UV maps should be drawn to the same polygon on Serge's model, which isn't the case. That really complicates things.
Well...  from what I've seen so far, the vast majority of non-UV data consists of (negative multiple of 16, negative multiple of 16, possible pointer, possible pointer) - with the exception, so far, of 0x19B8-0x19C7's quad, which is somewhat different.  Therefore, my conclusion right now is that the code that "parses" this data has two major features:

* If a two-byte value isn't a multiple of 8, it'll error; and
* Certain numbers, mostly negative ones, are special cases (most notably 0xFFE8, which seems to be a "refer to last polygon's fourth pointer" code).  For the time being, I'd go on the assumption that 0xFF80-0xFFF8 are special codes, not pointers, although this would seem to hose the last 8 16-byte vertices (they're still reachable by way of positive pointers, though).

Note that a lot of the "negative pointers" seem to be multiples of 16, though, by comparison to the normal pointers.

Current tentative list of "special codes", based on what I've seen so far:

0xFEB0 - unknown
0xFED0 - unknown
0xFFD0 - unknown
0xFFE0 - refer to prev. poly's 1st pointer
0xFFE8 - refer to prev. poly's 2nd pointer
0xFFF0 - refer to prev. poly's 3rd pointer
0xFFF8 - refer to prev. poly's 4th pointer

Quote
And BTW, does my model for the vertex coordinates in Section 1-3 appear plausible based on the visual evidence provided? I welcome critiques. And I have yet to determine the purpose of the vertex indices that follow the 3D coordinate data. Could be that that's linked to the bone data in some way too.
It's possible, though I suspect it's like Section 1-4 - Square didn't bother stripping out unnecessary data, and since it provided padding to keep things at an 8-byte multiple, it stayed in.

Out of curiosity, what's with the "polygons" at 0x1958 and 0x1968?  Their UV maps appear to be a single line of pixels.  Are they really flat-colored or a simple stripe pattern, or is something screwy going on here?

Finally, the "reversed" polygon for A seems to be at 0x18B8, based on how its UV data is set up.  (It seems like if one polygon is X1 Y1 X2 Y2 X3 Y3 X4 Y4, the reversed polygon will always be X2 Y2 X1 Y1 X4 Y4 X3 Y3, which makes sense [aside from the whole "I'm wondering how the graphics loader works now" thing].)
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on December 18, 2007, 11:55:06 am
Whoah, MDenham, you've done some very impressive work! I *think* I can very easily test the special values based on what you've provided -- then we'll have a bit more of the puzzle worked out. Thanks again!

As far as the "quads" starting at 0x1958 and 0x1968, that happens quite frequently, actually. I'm not sure what's up with it; these might act as filler space between other polygons. You know what, I'll see what happens when I black these out (zero out their UV map data, that is).

Oh, and MDenham -- by this:

0xFFF8 - refer to prev. poly's 4th pointer

you didn't mean this, did you?

0xFF58 - refer to prev. poly's 4th pointer

I'm actually not seeing any byte pairs that are F8 FF in Section 1-2 at all. Lots of 58 FF though. But maybe 0xFF58 is yet another code, and there are no codes that refer to the previous polygon's fourth pointer?

And it's certainly possible that the negative pointers I've seen so far are merely coincidence. Maybe all the xx FF byte pairs are special codes.

- - - - -

First experimental result of the day: MDenham is correct that the UV map starting at address 0x18B8 is "A" 's counterpart on the opposite side of Serge's shoe. I'll call this counterpart "Quad X"

So...
Quad A's non-UV data values: D0 FF B0 FE E8 FF 58 FF
Quad X's non-UV data values: D0 FF E0 FE E8 FF 70 08

- - - - -

Just to let everyone know, the .. FF byte pairs run the gamut from 00 FF through F0 FF in the non-UV data. No F8 FF in Kid's model either, so I guess if these are codes for the GPU/GTE to work with, they could potentially go from 0xFF00 through 0xFFF0.

Also, it appears that the values 0xFFA0 ~ 0xFFF0 occur way more often than 0xFF00 ~ 0xFF98. Could mean the ones above 0xFF98 are all codes, and the ones below are negative pointers. But keep in mind, not all values that should be negative pointers really are, at least from my experience.

- - - - -

Also MDenham, when the quads beginning at 0x1958 and 0x1968 have their UV data zero'd out, tiny areas at the edge of Serge's sock go black. Interestingly, the areas that go black don't necessarily correspond to the exact area we would expect to find them; it's possible that their purpose is to lift small snippets from one part of the texture and apply those to another part of the sock. In any case, here's the non-UV data for those two for quick comparison. They're on opposite sides of Serge's shoe.

"Line" 0x1958's non-UV data: F0 FF D0 FE B8 08 C0 08
"Line" 0x1968's non-UV data: D0 FF D0 FE E8 FF C8 08
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on December 18, 2007, 04:41:35 pm
Hey, I finally succeeded in changing a few bytes in Section 1-1 without the game crashing! :P

The results are fairly interesting considering I changed only two bytes. Two views to get a full idea of what happened:
http://img75.imageshack.us/img75/3328/jacketdisappeareo4.gif
http://img66.imageshack.us/img66/834/jacketreappearsx5.gif

I thought at first that the lower parts of Serge's jacket disappeared, but in reality it's been blown out of proportion and possibly misplaced, perhaps. Here's the code I changed in Section 1-1. Perhaps we can use this example to determine whether or not there's a checksum going on:
(http://img75.imageshack.us/img75/4424/jacketdisappearcodeeb7.gif) (http://imageshack.us)

I changed the first boxed value (at address 0x2A5) from 3F to DF.
I changed the second boxed value (at address 0x2C0) from 05 to 88.

- - - - -

Okay, I am this close to being certain that Section 1-1 contains bone data as Cyb suspected all along. I very carefully picked at the data, producing results like this:
(http://img75.imageshack.us/img75/2225/footinairyx1.gif) (http://imageshack.us)

Too many changes were involved to take detailed notes; I just randomy made values way larger, being careful to pass anything that was already 00 in value. But you can clearly see Serge's calf muscle and sock cuff sticking out of his hand. I'll get a Youtube vid up so everyone can see a full 360-degree view. (Meh, it's too fuzzy to really see what's going on, but it'll have to do for now: http://www.youtube.com/watch?v=8-Ao4M1amWU)

Can anyone familiar with bone data comment?

- - - - -

Having spent some quality time with Section 1-1, I still can't characterize the nature of the data with any certainty. I was hoping I'd be able to stick Serge's shoes on his head or something, but I'm mostly getting weird texture stretches. The data in Section 1-1 seems to run on an 8-byte scheme from what I can tell, so I figured on taking two bytes at a time and seeing what happens. Here's some resutls...

First two bytes of random "slots" altered in various ways. Serge's textures go all haywire, and may even be trying to map to the other characters in the party:
http://img337.imageshack.us/img337/3650/bytes1and2fg1.gif

When I change the seventh and eight bytes of randomly-selected "slots", I get results that aren't all that much different -- texture stretches:
http://img444.imageshack.us/img444/7007/bytes7and8gb7.gif

But then again, Serge's foot and leg were floating in the pic in this post's previous update, so I dunno. Hopefully someone with more experience in these matters can tell whether or not bone data is being affected.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on December 18, 2007, 10:38:58 pm
Oh, and MDenham -- by this:

0xFFF8 - refer to prev. poly's 4th pointer

you didn't mean this, did you?

0xFF58 - refer to prev. poly's 4th pointer
Actually, what I had was off by a bit.  Serves me right for posting that late at night.  :D

Corrected table, under the "special codes" theory:

0xFFE8 - previous poly's Ptr4
0xFFE0 - previous poly's Ptr3
0xFFD8 - previous poly's Ptr2
0xFFD0 - previous poly's Ptr1

- OR -

0xFF?? is a negative pointer...  but not into the vertex data itself.  Instead, it points backwards relative to the "expanded" form of the vertex data (each poly's vertices, listed in order), like so:

(poly 1 V1) (poly 1 V2) (poly 1 V3) (poly 1 V4) (poly 2 V1) ... (poly X V3 or 4)

Keep in mind each of these entries is, presumably, 8 bytes, and there are duplicates.  Sometimes frequent duplicates, depending on how many polys actually share a vertex.

Now, 0xFFE8 happens to be -24, or -3 entries.  Since 0xFFE8 seems to be very common as a third entry, we count backwards three spots (not counting itself)...  and we run into the previous polygon's fourth vertex!  This also explains the prevalence of 0xFFD0 (-48, or -6 entries), possibly - though tracing back through a sequence of 0xFFD0 looks like it takes a while.

How do we check if it's actually working this way?  Well...  a run of triangles that have non-UV data of the form XX XX F0 FF (two bytes of real pointer) would be a damn good sign of this (you'd end up with a series of triangles where each one shares an edge with the preceding one).  Likewise, the first poly overall shouldn't have ANY of these back references, the second one can have ones up to 0xFFC8 (but probably will only have 0xFFE8), etc.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on December 18, 2007, 11:06:47 pm
Ah, thanks again M. I'll say this, if the value 0xFFE0 points to the previous poly's third non-UV byte pair/pointer, I'd be very happy. It just so happens that two quads for Serge's belt buckle could fall into such a situation; they share a specific vertex I've been focusing on, but only one of the quads has a working pointer for that vertex. The other quad, which follows in the data, has the value 0xFFE0 for the corresponding pointer. You can see an illustration of this occurrence in the following pic:
http://img339.imageshack.us/img339/3926/bucklepointersor4.gif

So poly #1's third byte pair, 68 09 or 0x0968, behaves very nicely as a pointer and the corresponding pointer on the next quad listed is 0xFFE0. Everything checks out as if 0xFFE0 does exactly what you say, and I'm going to do some tests to prove it 100%. I'll also look for the run of triangles; should be pretty easy to find. But I like your explanation, since it accounts for both a.) the need for a system with one byte pair per UV map coordinate; and b.) why there's so many ..FF byte pairs.

Every value that begins FF.. is negative when a byte pair is interpreted as a signed integer, correct? So the 0xFF58's I've been seeing could possibly point backward 168/8 = 21 positions within the non-UV data?

This is turning out to be the exact thing Sora had suggested earlier. Pointers to intermediate pointers that point into Section 1-3. We'll have to worry later about values that should behave as positive pointers yet don't seem to, but we'll get these special codes/backward pointers nailed down first. Thanks again MDenham! Boy, am I glad you walked in here!
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on December 18, 2007, 11:57:32 pm
Ah, thanks again M. I'll say this, if the value 0xFFE0 points to the previous poly's third non-UV byte pair/pointer, I'd be very happy. It just so happens that two quads for Serge's belt buckle could fall into such a situation; they share a specific vertex I've been focusing on, but only one of the quads has a working pointer for that vertex. The other quad, which follows in the data, has the value 0xFFE0 for the corresponding pointer. You can see an illustration of this occurrence in the following pic:
http://img339.imageshack.us/img339/3926/bucklepointersor4.gif

So poly #1's third byte pair, 68 09 or 0x0968, behaves very nicely as a pointer and the corresponding pointer on the next quad listed is 0xFFE0. Everything checks out as if 0xFFE0 does exactly what you say, and I'm going to do some tests to prove it 100%. I'll also look for the run of triangles; should be pretty easy to find. But I like your explanation, since it accounts for both a.) the need for a system with one byte pair per UV map coordinate; and b.) why there's so many ..FF byte pairs.

Not only that, but note the 0xFFC8 (-56) for poly 2, vertex 4, which happens to be (surprise, surprise) identical to poly 1, vertex 1...  seven entries earlier.  Aside from the bad habit Square seems to have had of making ridiculously long chains of 0xFFD0 on occasion (why not just make it a single pointer back?) it's looking like this may finally be what's going on with the negative values.

Quote
Every value that begins FF.. is negative when a byte pair is interpreted as a signed integer, correct? So the 0xFF58's I've been seeing could possibly point backward 168/8 = 21 positions within the non-UV data?
It's not just values that start with FF (I've seen an 0xFED0 in one of your hex dumps recently, for example) - it's any number 0x8000 or "larger".  What with the observation, if memory serves, that the largest-in-magnitude negative number for Serge is -496 (62 entries) I'd be amazed if we see anything of the form 0xFC??, though if any of the characters have a sufficiently complicated model, there might be some rare 0xFCF8s and such.

Incidentally, this is why 0xFFF8 doesn't seem to occur at all - this points to the preceding entry, and so it'd only appear as the first pointer of a polygon.  However, due to whatever orientation rule Square decided on for the polygons, they seem to have avoided sharing the first vertex of a polygon with the last vertex of the preceding one.

And yes, 0xFF58 is probably pointing backwards 21 positions - which happens to close the loop from, for example, your polygons 1, 2, 3, 4, 5, and B (B's 4th vertex is saying "use the vertex 21 earlier", which happens to be 1's 3rd vertex).

So here's an idea for what to do as a test on this:

For poly B (I would have said to change poly A; however, tracing its chain leads off the top of that hex dump :(), change its non-UV data to A0 08 60 08 B0 08 88 08.  Assuming things are working the way they seem to be, there should be no change in the appearance of the model.  However, if there's something else at work here, then something will change with poly B (possibly fairly dramatic).

Now to figure out what's going on with the "too large, but positive" pointers...

---

Edit: Thank god for Wikipedia as far as helping (somewhat) with my hunch as far as the "gobbledygook".  Can you check for all of the characters' models to see if any of them have this value larger than 0x04C11DB7 (which happens to be a pretty standard divisor for CRCs)?  I see that changing things doesn't end up crashing things without fail, which means that it may not be getting checked against, but it'd be nice to be able to pin down whether or not this is, in fact, a checksum.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on December 19, 2007, 12:37:25 am
M, you are correct with regards to the value 0xFFE0, which means you are correct about everything else as well, no doubt! Congrats on figuring this out!  :lee:

Here's irrefutable proof as to the nature of the negative pointers. It's a big pic though, so 56kers click at own risk.
http://img178.imageshack.us/img178/7420/ffe0provendq0.gif

Here's the rundown: I changed the 3D coordinates of the vertices beginning at addresses 0x28E8 and 0x3188 to make their locations obvious, then pointed the non-UV data for the shared coordinate of two belt buckle polygons to both vertices (i.e., the third byte pair for quad "1" in previous belt buckle pics was directed at 0x3188 and the third byte pair for quad "2" was directed at 0x28E8). Thus, two "prongs" stuck out from Serge's belt buckle in different directions. When I changed the third byte pair for quad "2" back to E0 FF (or 0xFFE0), only one prong stuck out from Serge's belt buckle toward the vertex controlled at address 0x28E8. Arrgh, the experimental design is difficult to communicate, but suffice it to say that M's right. :P

Yeah, Luminaire posted that -496 is the "largest" negative number for Serge's non-UV data. So I'd look for 0xFE10, correct? If we find that value works the same way, then we can assume that all negative pointers beteween 0xFE10 and 0xFFF0 work the same. We're getting there!

As for the "gobbledegook" data, I can tell you right off the bat that Kid's "gobbledegook" value is 0x040701D9, and Guile's is 0x049A034B -- but I'm cheating by looking at the wiki entry. I'll take a look at some of the other models later and see what they've got.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on December 19, 2007, 02:31:24 am
Okay M, here's something we need to figure out. First, a range of hex code from Serge's Section 1-2:

(http://img167.imageshack.us/img167/2415/fe10codebp3.gif) (http://imageshack.us)

I'm looking at the value 0xFE10 @ address 0x1832. Its value as a signed integer is -496, which means it should point back 62 spaces according to the scheme formulated earlier. That points it to address 0x1736 (if I counted right), which in turn points to address 0x1724. Problem is, the pointer at address 0x1724 does not refer to the same coordinate on the UV map as the non-UV data at 0x1832.

The UV texture coordinate referenced for address 0x1832 is (59, 8A). The UV texture coordinate referenced for both 0x1736 and 0x1724 is (7D, 9A) so those check out okay. But how to handle 0xFE10, I dunno. I can say that it is NOT a negative pointer into the vertex pool because that would point it to address 0x4058, which controls a vertex that has nothing to do with the texture being mapped to the polygon described by 0x1832.

Interestingly, address 0x1832 (pointer 0xFE10) shares the UV coordinate (59, 8A) with address 0x1820 (pointer 0xFE40). And in addition, the only other addresses that share (59, 8A) are waaay back in the 0x600 ~ 0x690 address range in Section 1-2, in with the triangle UV data! I'm starting to wonder if 0xFE10 points backward from the boundary between quads and triangles, which would be incredibly messy to tangle with.

It's becoming clear that we must tread lightly and carefully from this point forward with the pointers in Section 1-2. I'll try out your other suggestions tomorrow as a brief test to make sure other negative pointer values check out okay. Weird!
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: halkun on December 19, 2007, 05:28:59 am
I'm going to throw a lesson about polygon packing here. You may find this helpful.

I'm going to introduce you guys to a concept called "triangle strips" and "triangle fans". Now this might have nothing to do with the model, but clues indicate this might help you out. The reason why I think this might confuse matters is because triangle strips and fans were not supported under the PS1 GPU. (They were, however, supported under the PS2). That being said, triangle fans and strips can be managed in software to, and you still get some benefits out of it.

Triangle strips
When the PSX GPU draws a quad, it is actually drawing two triangles with shared corner vertexes. When the GPU goes into "quad drawing mode" it will allow both triangles be drawn in one pass, as opposed to "kicking" two separate GPU triangle commands down the pipeline. Now, the idea of a triangle strip is that you don't have to stop with two sets of triangles. All you have to do is add one more point and you have another triangle. If you add another point, you can make another triangle. It makes "packing" easier because you only have to define a single point past a quad to create another three-sided polygon.

Here's an example of a triangle strip.
(http://www.codesampler.com/d3dbook/chapter_05/chapter_05_files/image007.jpg)
Here, you define v0, v1, and v2 to make a triangle. Adding one more vertex, v3, makes a quad. What makes strips very efficient is all you have to do is add one more vertex, v4, and you have another triangle without having to define another three points! Do you need another triangle? All you have to do is add v4 and you have another object from a single point definition. Now, like I said, the PSX GPU doesn't do triangle strips, but this looks like some of your data descriptions. (Then again, I might be wrong.) Keep in mind, many 3D modeling applications with create triangle strips for you as a matter of convenience. Square might be taking advantage of this.

Triangle fans
Triangle fans follow the same idea, but one vertex works as a "center" and the other vertexes orbit about this center, creating a fan shape.
(http://www.codesampler.com/d3dbook/chapter_05/chapter_05_files/image008.jpg)
In this example, v0 is the center, with v1 and v2 creating the first triangle. In this mode, v4 uses v0 to create a new triangle. Now if you want to make a new polygon, just add a single vertex.

These lookup tables look "stripish" in their construction. I might be wrong, but at least you guys learned something....
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on December 19, 2007, 09:53:02 am
These lookup tables look "stripish" in their construction. I might be wrong, but at least you guys learned something....
They don't just look it - they are, though the idea of a "quad strip" is still a little awkward to handle (more in the whole sense of "yeesh, that's a lot of looking things up" than anything :D).

---

Okay M, here's something we need to figure out. First, a range of hex code from Serge's Section 1-2:

(http://img167.imageshack.us/img167/2415/fe10codebp3.gif) (http://imageshack.us)

I'm looking at the value 0xFE10 @ address 0x1832. Its value as a signed integer is -496, which means it should point back 62 spaces according to the scheme formulated earlier. That points it to address 0x1736 (if I counted right), which in turn points to address 0x1724. Problem is, the pointer at address 0x1724 does not refer to the same coordinate on the UV map as the non-UV data at 0x1832.

The UV texture coordinate referenced for address 0x1832 is (59, 8A). The UV texture coordinate referenced for both 0x1736 and 0x1724 is (7D, 9A) so those check out okay. But how to handle 0xFE10, I dunno. I can say that it is NOT a negative pointer into the vertex pool because that would point it to address 0x4058, which controls a vertex that has nothing to do with the texture being mapped to the polygon described by 0x1832.

Interestingly, address 0x1832 (pointer 0xFE10) shares the UV coordinate (59, 8A) with address 0x1820 (pointer 0xFE40). And in addition, the only other addresses that share (59, 8A) are waaay back in the 0x600 ~ 0x690 address range in Section 1-2, in with the triangle UV data! I'm starting to wonder if 0xFE10 points backward from the boundary between quads and triangles, which would be incredibly messy to tangle with.
Also, 0x1820 ends up pointing back to 0x1740...  which is wanting the vertex at 0x1200 into the pool (0x3AE8, I believe?).  I don't think this is right either, so it wouldn't surprise me if one of the "unknown" values in the header controls where the transition between "check backwards in the quads table" and "check in some direction in the triangles table" is.

However, just because it doesn't refer to the same point in the UV map doesn't mean that the current model isn't still correct.  While most of the texture is contiguous for specific portions of the model, there are still spots where you go from, say, the top of the foot into his pants, and those are in two different parts of the texture.  Keep that in mind here and check that just in case, because I suspect that it probably is a transition between "sections" of Serge (as far as his texture goes).

Anyway, I've gotta run for work here.  I'll be back to check in on any new developments in about ten hours. :D
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Sora on December 19, 2007, 01:18:43 pm
glad to see we're winning again ^.^
DR.Faust always knows whats going down.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on December 19, 2007, 02:00:36 pm
Yeah, we're really kicking ass, but it's all thanks to the knowledge everyone's bringing to the table here. If we can get these pointers nailed down and find the bone information, I think that may be all we need to do some rudimentary viewing of the models. I would assume the models exist in a frozen battle pose in their "natural" state, without animation data being applied to them -- I think that's how FF7 worked anyway, judging from the FF7 models I've seen with Mirex's viewing tools.

Halkun, major thanks for taking the time out to illustrate the triangle strips and fans. It certainly seems we've found quad strips, and I imagine if I mapped out some triangles on Serge's texture according to the data they'd be arranged the same way, or similarly. If the PSX GPU doesn't do such things, the model editing program the Squeenies used certainly did -- I wonder how much it would help if we knew which model editing program these were created in?

The next step is figuring out what these pointers are pointing to, exactly. And MDenham, I don't have a pic on hand at the moment, but there certainly is a texture boundary being crossed in the data I posted above. The pointer at address 0x1832 is referring to a vertex on the side of Serge's shoe from what I can tell, and the ones at addresess 0x1724 and 0x1736 refer to Serge's leg. The value 0x07E8 at address 0x1724 definitely works as a positive pointer into the vertex pool, because changing the coordinates of the vertex it's pointing to causes a texture spike from the area being mapped on the texture.

- - - - -

Okay, this evening's first experimental results are in. I did a test MDenham suggested earlier -- going back to the almighty "shoe" and changing Quad B's pointers (which are the negative kind we've been examining recently) to the values we believe they would point to based on the scheme M developed. The results are 50% successful, with some oddities hindering our full understanding of the pointers.

First, the code that's applicable here:
(http://img155.imageshack.us/img155/5863/shoecodecd2.gif) (http://imageshack.us)

We're focusing on the data for Quad B. Its original pointer byte pairs are thus: D0FF  B0FE  E8FF  58FF

Let's trace where they go (or where they should go) one by one...

0xFFD0 = -48, /8 = 6 positions back in the non-UV data. That brings us to address 0x1934, which in turn leads us an additional three positions back to address  0x1926.

0xFEB0 = -336, /8 = 42 positions back. That leads us to...address 0x18A6 if I'm counting right.

0xFFE8 = -24, /8 = an easy 3 positions backward to address 0x1946.

0xFF58 = -168, /8 = 21 positions backward to address 0x1904.

Thus, reading by our current scheme, Quad B's pointer byte pairs should be equivalent to: A008 6008 B008 8808

If we're reading the pointers correctly, then changing Quad B's pointers to these byte pairs should have no effect on the model -- those values should be the actual pointers into the vertex pool.

Now let's try altering the last two byte pairs so Quad B's non-UV data becomes D0FF B0FE B008 8808. So far, so good -- no change:
http://img263.imageshack.us/img263/4103/lasttwopterschangedwu2.gif

That means we're reading the byte pairs E8 FF and 58 FF correctly.

Now let's try the first two byte pairs as well, so that Quad B's non-UV data is A008 6008 B008 8808:
http://img263.imageshack.us/img263/1993/allpterschangedvi1.gif

If you look closely, there's a bit of a graphical hiccup, a very thin texture stretch from Serge's sock. That means we're just slightly off. At first I thought something weird might be up with the value 0xFEB0, so I switched the second byte pair back to B0FE. But now things are even worse:
http://img263.imageshack.us/img263/8769/firstpterchangedox2.gif

This means that the first pointer value, 0xD0FF, isn't being read correctly, since it's the only one that could be causing a problem if the second byte pair is switched to its original state. So I figure, "okay, the problem is with the first pointer value." Yet switching only the second pointer is still problematic:
http://img263.imageshack.us/img263/7586/secondpterchangedyy6.gif

So I believe we're interpreting the values 0xFFE8 and 0xFF58 correctly, but something weird's up with our interpretation of 0xFEB0 and 0xFFD0. I wish it were my counting that was off -- let me know if that's the case, anybody, and I'll be a happier camper than I am right now. But as things stand, the interpretation of these as negative integers with division by 8 giving us the number of positions backward doesn't capture the full picture.

Discuss.


Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on December 19, 2007, 10:42:18 pm
So I believe we're interpreting the values 0xFFE8 and 0xFF58 correctly, but something weird's up with our interpretation of 0xFEB0 and 0xFFD0. I wish it were my counting that was off -- let me know if that's the case, anybody, and I'll be a happier camper than I am right now. But as things stand, the interpretation of these as negative integers with division by 8 giving us the number of positions backward doesn't capture the full picture.

Discuss.
That is bizarre.  Near as I can tell, the only real assumption that can be made is that negative pointers that end in 8 ("odd" pointers) are correct, while negative "pointers" ending in 0 ("even" pointers) have something else entirely going on with them, although I'm not sure what.  (I do notice that the first and second vertices of every poly, when they have a reference, are 0x???0 invariably, while the third and fourth vertices, as references, are 0x???8.)

B's first two vertices should be pointing at the last two vertices of the poly at 0x18E8, by the way.  I was going to chalk that up to these being divided by 16 instead of 8, but this puts both of B's first two vertices as the fourth vertex of 0x18E8, in addition to other weirdness with other vertices, so it's not that simple.  It is, at least, obvious that for references, that last digit controls the behavior of how it looks up the reference.

On a related note with strange values, I'm thinking there's a limit of 1024 vertices per model, which means anything between 0x2000 and 0x7FFF needs to have the top two bits separated out.  (Not sure what purpose, if any, those two serve, but it's something to check at this point.)  Confirmation for this requires either finding a vertex pointer of, say, 0x2??? and changing it to 0x0???, and seeing what effect, if any, results.

Finally, is there any chance that someone has a complete disassembly (the original source is a bit much to hope for, :D - I'll make do with semi-cryptic opcodes and no real names for procedures and variables) of the program itself for Chrono Cross?  I'd like to try and pin down where the battle model loader is and see what all we're missing as far as odd behavior (such as why "even"/"odd" references are treated differently; what, if any, purpose bits 13 and 14 serve for vertex addresses; and how it determines where to change between triangles and quads).
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on December 19, 2007, 11:07:44 pm
Well, I can say that 0xFFE0 has been interpreted correctly under your scheme as well, M. The experiment conducted in this post lends credence to the division-by-eight rule, I believe:
http://www.chronocompendium.com/Forums/index.php/topic,4770.msg85654.html#msg85654

But I'm going to take another look at my latest experiment based on what you've just said. It might lead to something.

Do you have a hex editor and disassembler handy at all, M? There's some ASCII signatures in Cross' executable that may be of some interest to you. PS2Dis seems to work fairly well as a disassembler even for PS1 executables (I assume the program itself is for PS2 though). I think PS2Dis might even preserve the ASCII signatures that correspond to loaders, so maybe a hex editor wouldn't even be necessary. If you're interested, I can post some screenies of the executable in PS2Dis and my hex editor so you can see if the info shown in these might help. PS2Dis should be available freely for download somewhere -- I'll check up on where they're hosted and post those addresses here if you'd like.

- - - - -

Here's an example of what PS2Dis shows. Looks like it recognizes some basic commands:
http://img255.imageshack.us/img255/7156/ps2disxm0.gif

Anyone know what PutDrawEnv and the like are, exactly? Could these help in any way?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on December 19, 2007, 11:27:20 pm
Do you have a hex editor and disassembler handy at all, M? There's some ASCII signatures in Cross' executable that may be of some interest to you. PS2Dis seems to work fairly well as a disassembler even for PS1 executables (I assume the program itself is for PS2 though). I think PS2Dis might even preserve the ASCII signatures that correspond to loaders, so maybe a hex editor wouldn't even be necessary. If you're interested, I can post some screenies of the executable in PS2Dis and my hex editor so you can see if the info shown in these might help. PS2Dis should be available freely for download somewhere -- I'll check up on where they're hosted and post those addresses here if you'd like.
As far as a hex editor, just grabbed a copy of XVI32 to use, so that's one major shortcoming in my toolkit addressed. :D  Also found PS2Dis's homepage, so I'm taking a crack at things.  The executable is SLUS_010.41, right?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on December 19, 2007, 11:31:40 pm
Yup, that's what I'm looking at. I know absolutely zip when it comes to assembly language (I think it has something to do with shifting bits  :lol:), so I'm very interested in what you'd find. I'm not sure if it comes in the default install, but make sure you get the PS1 Linker Address Map, because I think it's required to do an "Invoke Analyzer." Not sure about that, though.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: ZeaLitY on December 19, 2007, 11:47:45 pm
Just in case, the Chrono Cross demo's executable is out in plain sight. I imagine the basic rendering engine was done by then, so in case analyzing it can help:

http://chronofan.com/Black/Cross/KID.EXE

That might be the total opposite of what you're looking for, though.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on December 19, 2007, 11:53:33 pm
Hmm, it's way bigger than the SLUS executable of the final version. I'll toss it into PS2Dis just for the heck of it and see what's in KID.exe...

Zeality, was Cross the only playable demo on the disc you ripped this from? Judging by the name, it should only apply to the Cross demo if there was more than one. Thanks for providing it again!

BTW M, everything looks like it works out fine if I interpret 0xFFD0 and 0xFEB0 as being divisible by 16 and not 8. What's the best rule of thumb to use, do you think? Because 0xFFE0 works best when interpreted as being divisible by 8...

- - - -

PS2Dis is telling me things like "Bad sjis code" and "Bad hankaku code" as I scroll through KID.exe. SJIS refers to Japanese script, is that right? Anyone know what Hankaku means by any chance? If there's any clues in KID.exe, looks like they might all be in Japanese.

- - - - -

Nah, I see OTag references in KID.exe too, just like in the SLUS executable. Interesting. M, what Zeality posted is probably worth a look too, from what I can tell. I wonder why KID.exe is so much larger than the final SLUS?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: ZeaLitY on December 20, 2007, 12:05:49 am
The other demos / trailers were kept in different folders. Cross had one all to its own, with KID.EXE, CRONO.HED, END.DAT, CROCRO.IMG (the actual game data; 101 MB), and TITLE.XAM, BLOOD.XAM, and TIDAL.XAM. For whatever reason, the last three refuse to copy off the disc onto my hard drive. "Invalid MS-DOS function."
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on December 20, 2007, 12:30:15 am
Nah, I see OTag references in KID.exe too, just like in the SLUS executable. Interesting. M, what Zeality posted is probably worth a look too, from what I can tell. I wonder why KID.exe is so much larger than the final SLUS?
I'll take a look at it sometime tomorrow, probably, though I imagine that KID.exe is larger because either Square hadn't stripped the symbols out yet or because of extra debugging code that was still in there.

I'm pretty sure the function we'd be looking for, if we had the original C source, would be Kz_modelGetNormalPolygon(), but tracking it down is a whole other kettle of fish.  :(
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on December 20, 2007, 12:32:59 am
Ah, I do remember seeing things like that in another completely unrelated game's executable. It looks familiar. I'll go back to that game (it was Ogre Battle PSX, btw) and see if I find it again, then I'll check it against Cross' SLUS executable. Maybe that way I can cut down some of the busywork for ya.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on December 20, 2007, 01:22:41 am
Well, right about now I'm ready to beat things with pointy sticks. :D I am NOT a fan of the whole MIPS "yeah, we'll execute the command immediately AFTER a jump in your program, just to mess with people reading a disassembly" thing.

It also doesn't help that immediate operands are limited to 16-bit quantities...  that get sign-extended out.  :?

I'm going to have to actually try and do some kind of live trace on it and see when it finally loads in a vertex to get any sort of information this way, unfortunately.  Ah, well.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on December 20, 2007, 04:50:47 pm
I had high hopes we'd be able to develop a general Pointer Theory without having to dive into the assembly language, but here's another monkey wrench for us to deal with:

You know the positive pointers? The ones in the form of byte pairs 5808 (for value 0x0858) and the like? Their meaning may be situationally dependent in some way.

Allow me to illustrate such an instance. First off, I believe Quad "B" in the above examples should have pointer info of the following: 8008 5808 B008 8808. I'll get around to presenting graphical evidence later -- in any case, M's mathematical scheme may lead us to the same conclusion.

For now, let's focus on the first byte pair pointer in quad B's non-UV data. This is what happens when I change the first pointer to the 8008 (for value 0x0880):
(http://img88.imageshack.us/img88/1770/0880pterkc0.gif) (http://imageshack.us)

It would appear that changing the pointer as such makes the texture try to map to a vertex on Serge's elbow. We can test the location of the vertex it's pointing to by radically altering the vertex's 3D coordinates. A value of 0x0880 would point to address 0x3168 in the vertex pool (0x28E8 + 880).

But here's what happens when we change the vertex at address 0x3168:
(http://img176.imageshack.us/img176/9848/0880vertexchangedau2.gif) (http://imageshack.us)

What the!? That was the vertex we were trying to map to in the first place! The proper vertex moved! But when Quad B's pointer is changed so that it points to that vertex mathematically, it doesn't point to that vertex!!

The proper vertex moved, but that UV coordinate in Quad B still tries to map to Serge's elbow. This means one thing: when address 0x18E6 (the "end" address in the back-pointer loop) reads 8008, the machine reads it as 0x0880 pointing to 0x3168. But when address 0x1950 reads 8008, the machine interprets it as something entirely different.

I'm going to double-check my experimental results just to be sure, and to see if this sort of thing occurs elsewhere. I should point out that I've seen other positive pointers that don't "work," yet in this case the 8008 at address 0x18E6 does work -- just not at address 0x1950. Double confuzzlement!
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on December 20, 2007, 07:41:15 pm
Here's what I've got for the byte pairs Quad B's pointers should point to: 8008 5808 B008 8808

The last two byte pairs work perfectly, the first two suffer from the problem I noted above, so I may still not have things right -- MDenham, see if you agree with these values for the byte pairs. I'll reproduce some code from this section of the model:
(http://img259.imageshack.us/img259/9031/ptercolorcodevu4.gif) (http://imageshack.us)
The highlighted section at the bottom is Quad B's non-UV data. Pointers and the byte pairs I believe they point to are in color-coded boxes, so the red pointer points to the other red box, etc.

Here's why I believe 8008 and 5808 are the pointers to the correct vertices in Section 1-3. The value 0x0880 points to the vertex at address 0x3168, and the value 0x0858 points to the vertex at address 0x3140. Below you can see the results of changing the 3D coordinates of both vertices; quad B, which I've blacked out, appears to map to both!
(http://img259.imageshack.us/img259/5343/31403168proofjd1.gif) (http://imageshack.us)

Now, is there some way we can get from Quad B's non-UV data (0x1950 ~ 0x1958) to the color-boxed addresses mathemagically? One consideration is that the value 0xFFE0 works best if divided by 8 for the section of data pertaining to Serge's belt buckle.

- - - - -

Another ominous sign: when I direct Quad B's first pointer to Serge's belt buckle via changing the byte pair to 6809, Serge's sock texture tries to stab Glenn in the leg:
http://img266.imageshack.us/img266/3197/pointedtobeltwl4.gif

So obviously something's weird with the address 0x1950. But on the upside, if we can figure out the mathematics behind the pointers indicated above, we'll know what's going on with the negative pointers at least!
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on December 21, 2007, 01:44:34 am
Okay, I think I've divined the rules by which these negative pointers should be interpreted. Judging from everything I've seen so far, the rule set is:

*If the pointer value ends in an 8, divide by 8 to get the number of positions backward in the non-UV data
*If the pointer value ends in B0, divide by 16.

*If the pointer value ends in D0, divide by 16.
*If the pointer value ends in E0, divide by 8.
*If the pointer value ends in F0, divide by 16.

I suppose we could insert "If the pointer value ends in C0, divide by 8" into the blank line to fill in a pattern. But does anyone have a guess as to why this is so? Are these rules based on a mathematical principle of some sort, or does it have something to do with the way the GPU/GTE processes information?

Anyway, let's run through Quad B's first two pointers based on these rules.

First Pointer: address 0x1950, value 0xFFD0.
0xFFD0 = -48, /16 = 3 positions back...
->address 0x1942, value 0xFED0 = -304, /16 = 19 positions back...
-->address 0x18F4, value 0xFFE8 = -24, /8 = 3 positions back...
--->address 0x18E6, value 0x0880. Just what we want! Yay!

Second Pointer: address 0x1952, value 0xFEB0.
0xFEB0 = -336, /16 = 21 positions back...
->address 0x1900, value 0xFFF0 = -16, /16 = 1 position back...
-->address 0x18F6, value 0xFF58 = -168, /8 = 21 positions back...
--->address 0x18A4, value 0x0858. Just what we want! Yay!

It doesn't show up in this example, but we need to interpret 0xFFE0 as being divisible by 8 in order to preserve the functionality of the belt buckle pointer we saw at address 0x10E4 here: http://img339.imageshack.us/img339/3926/bucklepointersor4.gif

If others can help me theoretically determine why the negative pointers may function this way (some divisble by 16, others by 8 ), we'll be ready to move onto the search for bone data soon. I'm not sure what the heck we're going to do with the positive pointers, because those seem to be going even more haywire.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on December 21, 2007, 02:40:01 am
Next up, for M or anyone else interested in diving into the executable's assembly code, here's my cursory findings via hex editor:

First, the function kzModelGetNormalPolygon() occurs as an ASCII tag around 0x7EEE0.

0x46D40: some commands, e.g., SetDrawEnv, appear in ASCII around here.
0x48310: a long section of gibberish starts here; maybe others will get more out of it than I.
0x52AF0: Some more "interesting stuff" according to my notes. I forget what's in here specifically.
0x52CF0: I see the ASCII tag vertex tras around here. Not sure if that'll be useful at all.
0x53AF0: Some more functions here it seems. I see something about setting camera projection.

That's just in the hex editor. I'll have to see what shows up in PS2Dis tomorrow and record those offsets. But M, there's your kzModelGetNormalPolygon() anyway.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on December 21, 2007, 03:04:07 am
Okay, I think I've divined the rules by which these negative pointers should be interpreted. Judging from everything I've seen so far, the rule set is:

*If the pointer value ends in an 8, divide by 8 to get the number of positions backward in the non-UV data
*If the pointer value ends in B0, divide by 16.

*If the pointer value ends in D0, divide by 16.
*If the pointer value ends in E0, divide by 8.
*If the pointer value ends in F0, divide by 16.

I suppose we could insert "If the pointer value ends in C0, divide by 8" into the blank line to fill in a pattern. But does anyone have a guess as to why this is so? Are these rules based on a mathematical principle of some sort, or does it have something to do with the way the GPU/GTE processes information?
Well, the simplified way to handle it would be like this (note that this probably isn't quite correct, for reasons that I'll state later):

Put P[ix] into VP.
HEAD:
If (VP < 0) jump to A.
(do some processing on VP)
Jump to END.
A: If (VP & 0x08), change VP to P[ix + VP/8] and jump to HEAD.
If (VP & 0x10), change VP to P[ix + VP/16] and jump to HEAD.
Change VP to P[ix + VP/8] and jump to HEAD.
END:
(return)

This is, of course, assuming that the pattern holds true for 0xFFA0, 0xFF80, etc. as well.

As far as what's going on with the positive pointers: well, it seems we've figured out why there's so many backwards references for the first two vertices. :D  Something is being done with these vertices in the process of tracing the pointers backwards - most likely the references are to a post-processed vertex array, NOT[/i] the vertex pool!  Also note that every vertex that isn't a backwards reference in the first or second slot that I've seen so far is at least 0x1000.  This brings me back to my note about the pseudo-code for the vertex reader.

Quite possibly, every entry in the first two columns is divided by 2 initially.  Then, anything that still ends in 0 afterwards (which were multiples of 32 to begin with) is divided by 4, while everything else now ends in an 8 and can be handled in one step.  (References in columns 3 and 4 are simply divided by 8.)  Easy check on this would be to take, say, poly 0x17A8 (as all four of its pointers are "normal") - the first two vertices read as 0x1240 and 0x1260.  Change vertices 0x0920 and 0x0930 and see what the effect is on this poly.  We should actually get a useful result from this - either confirmation that there's something weird-but-stupid going on, or confirmation that things are a LOT weirder than I expect.

And now for my minor nitpick of the day: 0xFFD0 is -48. :D

(As far as the whole ASCII tags and such, I noticed them when running through the hex editor myself, which is why I commented on them, especially because they seem to be discarded by PS2Dis, while the error messages for these functions are retained.)
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: yaz0r on December 21, 2007, 09:55:06 am
KID.Exe doesn't seems to have any debugging symbols. It's bigger mostly because it's a flat binary and all the additional space is filled with 00.
Anyway, I remember FFX using a similar system for the indices. Some vertex indices were actualy negative values, and in that case it was used as on offset to point to previous indices. That seems close to what you are seeing.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on December 21, 2007, 11:52:08 am
M, I've corrected my error. Thanks! Whew, at least I got the result right.

Thanks for the experimental suggestion and the pseudocode. I'll get on the experiments today, and we'll see what's up. I'd like to mention as well that, in the belt buckle experiment (seen here: http://img339.imageshack.us/img339/3926/bucklepointersor4.gif), when I input the pointer byte pair 6809 into address 0x10E4, everything behaves normally. No change in the model because the next quad is still pointing at the right place.

yaz0r, it's good to know a similar scheme is used in FFX -- development of that began in 1999 if I'm not mistaken, so it makes sense for Square to re-use some of their modeling techniques. Do you remember how positive pointers were handled in FFX? Maybe we can glean some knowledge from that. The documentation on the FFIX models doesn't go so deep; but we DO need to know this stuff to view the models, right?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Sora on December 21, 2007, 03:20:47 pm
are they still on Namick?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on December 21, 2007, 03:25:58 pm
The latest experiment M suggested turned out to be really interesting. Here's a snippet of hex code starting at address 0x17A8 in Serge's battle model:
(http://img147.imageshack.us/img147/7761/codesnipuu1.gif) (http://imageshack.us)
We notice something right of the bat: the UV map section of the code refers to a single point on Serge's texture, (65,89) or (101,137) in decimal, which is a point on the bottom of Serge's shoe.

So, given that this coordinate on the texture maps to a single point, it's awfully weird that the non-UV data look like positive pointers to widely different vertices. The vertices being pointed to, from left to right, are at addresses 0x3B28; 0x3B48; 0x31F8; and 0x3210. Let's test them out to see which of these vertices is correctly given in the non-UV pointers...

First up is the vertex at address 0x3B28. Nope, it's nowhere close to Serge's shoe, so the value given in the first pointer position isn't interpreted "normally."
(http://img147.imageshack.us/img147/6118/3b28km9.gif) (http://imageshack.us)

Next up is the vertex at address 0x3B48. Same deal:
(http://img136.imageshack.us/img136/4008/3b48xp1.gif) (http://imageshack.us)

Now for 0x31F8. Looks like we might have a winner.
(http://img519.imageshack.us/img519/1932/31f8sh1.gif) (http://imageshack.us)

But 0x3210 is also plausible:
(http://img136.imageshack.us/img136/351/3210ob1.gif) (http://imageshack.us)

Now for the final test -- If I black out all the UV map data, which vertex is affected? Clearly the vertex at 0x31F8:
http://img147.imageshack.us/img147/9315/31f8proofzu7.gif

This is an extraordinary case, because it's the first time we've been able to pin down the differences between the values a pointer actually has and the value it's supposed to have if it's a working positive pointer. Let''s take a look at these differences byte pair by byte pair. Here's the values the "quad" at address 0x17A8 ~ 0x17B8 actually has:

0x1240 0x1260 0x0910 0x0928

The bolded pointer can be read literally as a positive pointer into the vertex pool. It leads to the vertex starting at 0x31F8. Now, if the machine is able to get to that vertex from each of these pointers somehow, then we have to discount the values by certain amounts. So here goes:

-0x930  -0x950  -0x00  -0x18

But I don't think that means the machine discounts positive pointer values by these amounts in each column.. M, does this exercise provide us any more insight into the way the pointers are working?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on December 21, 2007, 09:51:45 pm
(http://img147.imageshack.us/img147/7761/codesnipuu1.gif) (http://imageshack.us)

(...snip...)

The bolded pointer (0x0910) can be read literally as a positive pointer into the vertex pool. It leads to the vertex starting at 0x31F8. Now, if the machine is able to get to that vertex from each of these pointers somehow, then we have to discount the values by certain amounts. So here goes:

-0x930  -0x950  -0x00  -0x18

But I don't think that means the machine discounts positive pointer values by these amounts in each column.. M, does this exercise provide us any more insight into the way the pointers are working?
Mostly this just confirms what we already know - the first two columns aren't working in the same manner as the last two, and I think I know why - it's to provide a simple means to distinguish between triangles and quads (which was something we were having a slight issue with ourselves.

New model of the vertex reader, in pseudo-code and designed to handle triangles (sort of):

Code: [Select]
Read first four bytes of non-UV data (VS[ix..ix+3]) and put them as appropriate into VP[0] and VP[1].
If ( !!! SOME CONDITION HERE !!! ) jump to READ_TRIANGLE.

READ_QUAD:
Read the next four bytes of non-UV data and put them as appropriate into VP[2] and VP[3].
***Divide VP[0] and VP[1] by 2.***
Over (x=0, 1) {
* If (VP[x] > 0), store the actual vertex in the quads' vertex buffer and advance x.
* If (VP[x] & 0x08), set VP[x] = VS[ix - VP[x]/8) and retry with x the same.
* Otherwise, set VP[x] = VS[ix - VP[x]/4) and retry with x the same.
}
Over (x=2, 3) {
* If (VP[x] > 0), store the actual vertex in the quads' vertex buffer and advance x.
* Set VP[x] = VS[ix - VP[x]/8) and retry with x the same.
}
Return to calling procedure.

READ_TRIANGLE:
?????

The reason I can't say how it's handling triangles yet, or exactly how it's distinguishing between triangles and quads, is because I haven't had a chance to look at any of the sections with triangle data yet (it's all been quads to date in the thread).  I suspect triangles only have the first vertex's pointer multiplied by 2, and as with a quad, the last two are used directly.

Anyway, to summarize: I'm almost certain at this point that, for the polygon you were referring to, the first two vertices are, instead of using 0x1240 and 0x1260 for pointers, using 0x0920 and 0x0930 - putting them at 0x3208 and 0x3218 respectively.  Call this the "Rule of One-Half".

I'm a little surprised that nobody else seemed to have noticed that the first two columns for every quad's vertices to date have been multiples of 16, when they seem to be evenly dispersed between xxx0h and xxx8h for the third and fourth vertices.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on December 22, 2007, 12:14:27 am
We now have the General Theory of Chrono Cross Model Pointers!!

M's absolutely correct; there's a "rule of one-half" for the negative pointers analogous to the rule for positive pointers illustrated earlier. Here's some pseudo-English to match MDenham's pseudocode:

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

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

 :lee: We've got all quad pointers figured out, folks!  :lee:

Supercalafradulistic-expialodocious THANK YOU to MDenham!!

I now leave you with the coolest pic I could find to celebrate.

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: ZeaLitY on December 22, 2007, 12:26:54 am
The revolution continues!

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on December 22, 2007, 01:11:30 am
 :lee: YEE-HAW!  :lee:

So let's go through the "almighty shoe" exercise with this basic rule set. First, the code:
(http://img259.imageshack.us/img259/9031/ptercolorcodevu4.gif) (http://imageshack.us)
The highlighted section at the bottom is Quad B's non-UV data. Pointers and the byte pairs I believe they point to are in color-coded boxes, so the red pointer points to the other red box, etc.

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

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

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

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

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

So far, so good. I'll go through some other examples as tests, then we'll quickly get the triangle pointers nailed down before moving onto the bone data.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on December 22, 2007, 06:24:57 pm
After a tentative look at what should be triangle data, triangles seem to be a little odd in their metapointers:

(http://i274.photobucket.com/albums/jj267/mdenham82/triangles.jpg)

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

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

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

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

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

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

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

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

I wouldn't be too surprised if the reason this block of triangles appears in the middle of things is because the region they're at used to be made up of quads that were broken apart (by moving one or two vertices out of the plane they were all in) prior to finishing the model.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on December 22, 2007, 07:23:18 pm
Excellent, excellent, M! I won't have a chance to test the N,D,D scheme out for a few days due to pre-Christmas festivities (ahem, shopping :wink:). Thanks a million for your help; I never would have figured this pointer stuff out, that's for sure.

When I get some time, I'll pick a few quads and triangles at random and see if we can map them manually based on the schemes you've developed. Then, it's onto searching for bone data -- it's either in Section 1-1, Section 2, or Section 3 I believe. Depending on how long it takes to code a plugin or standalone viewer (whichever is easiest for the coders who would like to take a crack at it), we could be viewing models quite soon!
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on December 23, 2007, 12:36:15 am
Oh, and if anyone wants to track me down at any sort of random time that they've seen me post to ask a question that MUST BE ANSWERED NOW :lol:, the best way is to check if I'm playing poker (badly) or blackjack (less badly) through UltimateBet.  I'll try to answer any sort of quick questions there, and if it takes longer I'll just tell you to expect a PM with your answer. :D

Slight edit before I get some sleep, which is thoroughly unrelated to this thread as well: I'm probably going to be spending the next couple of weeks (well, after Christmas :D) mostly working on my "sort of like RPG Maker, only not nearly as limited or annoying to use" project.  If anyone's up for either tossing suggestions at me, writing code (it'll probably be about half Managed C++, half C# - VS2k5 Express for the, uh, not quite a win but not a loss), or otherwise possibly being useful, e-mail/PM/track me down.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on December 23, 2007, 01:02:47 pm
Whoah, it's an actual game-maker, M? Sounds awesome. Is it a 2D engine, or can it do 3D as well -- maybe we can put all these battle models to use :P? My, my, between you and Cyb, we game creation / hacking enthusiasts are going to have all sorts of new programs to fuel our projects. Thanks a million guys!

I might just be able to squeeze in the necessary tests for the pointer schemes tonight or tomorrow. Then it's on time to sift through the hex for bone data!
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on December 23, 2007, 03:41:53 pm
Whoah, it's an actual game-maker, M? Sounds awesome. Is it a 2D engine, or can it do 3D as well -- maybe we can put all these battle models to use :P?
It definitely will have a 2D mode, and 3D's in the cards for, at the very least, "later" - pulling off PC ports of as many of the Square/SE games [with the exception of FF11 - there's already a perfectly good PC version of it, :P] as possible is one of the main reasons for the project. :D
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on December 23, 2007, 03:45:32 pm
Oh-hoh-hoh! I'm looking forward to it. Then the Compendium can get together and do some hair-brained scheme like collecting every SNES RPG sprite out there and making some huge CT-themed fangame.

I'll be doing some tests this evening with the Cross models finally, and I'll get the results up tonight to confirm your General Theory on Chrono Cross Model Pointers!
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on December 23, 2007, 05:03:36 pm
Oh-hoh-hoh! I'm looking forward to it. Then the Compendium can get together and do some hair-brained scheme like collecting every SNES RPG sprite out there and making some huge CT-themed fangame.
If that happens, please leave the Disney characters out of it, okay? :D
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Sora on December 23, 2007, 08:24:36 pm
*Triangle 10's metapointers*: (-5)->(-2)->1090, (-8)->1090, (-12)->(-3)->10D0
* Triangle 12's metapointers*: 10B8, (-12)->(-2)->1090, (-13)->(-2)->1090

ummm...these don't look like triangles to me.
unless 12 and 10 are used to create 1 triangle, but why would they do that?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on December 23, 2007, 08:39:56 pm
You're referring to the "overlapping" values, Sora? It's a fairly prevalent phenomenon -- my guess is these "points" and "lines" in the triangle and quad data are used for some aesthetic purpose on the models. Maybe to fill in gaps that occur due to texture folding? They do seem to behave correctly though -- I tested one quad somewhere in the posts above that consists of a single point on the UV map, and sure enough when I blacked it out this affected neighboring quads.

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

When MDenham gets finished with his uber RPGMaker, we'll have...CHRONO HEARTS!!
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Sora on December 23, 2007, 08:53:42 pm
well, these are the points listed between both triangles.
(http://i148.photobucket.com/albums/s7/SoraCross/tri1.png)

now, the first one seems to be making a line by referring to 1 point twice.
(http://i148.photobucket.com/albums/s7/SoraCross/tr2.png)

and even with both of them, they aren't making a triangle together like i thought, but just a ^, as seen here:
(http://i148.photobucket.com/albums/s7/SoraCross/tr3i.png)

for a correct triangle, you would need.
1090, 10D0, and 10B8 to be listed in 1 triangel.
(http://i148.photobucket.com/albums/s7/SoraCross/t4.png)
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on December 23, 2007, 08:57:41 pm
Hmm, I'll take a look at it during the experiments, whenever I get around to them. Thanks for bringing it up.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on December 23, 2007, 09:04:41 pm
*Triangle 10's metapointers*: (-5)->(-2)->1090, (-8)->1090, (-12)->(-3)->10D0
* Triangle 12's metapointers*: 10B8, (-12)->(-2)->1090, (-13)->(-2)->1090

ummm...these don't look like triangles to me.
unless 12 and 10 are used to create 1 triangle, but why would they do that?
They're only referred to as triangles because they're in with the triangle data.

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

Besides, I did mention that I might be off in my math as to where they land, so the repeated 1090s may not be correct.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on December 24, 2007, 06:43:31 pm
You guys rock. I don't think I would have ever thought of a scheme like that for the pointer data.

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

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

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

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

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

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

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

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on December 24, 2007, 07:37:17 pm
 :shock:  :shock:  :lee:

HOLY COW!!

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

I still have some things to take care of outside the world of Chrono Cross, so in-depth testing on the General Theory of Chrono Cross pointers has to wait for a few more days. I'm hoping to have the pointer scheme finalized and bone data located before the first of 2008 though. Great job team! WOOT-WOOT!!
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: halkun on December 25, 2007, 04:02:54 am
Ok... This looks good, let me help you guys by giving out some advice bout the model structure.

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

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

The head will most likely be first.

It appears that each "part" in the pictures above are mushed together, with the center of each part at 0,0,0. That center point is where the bone node is going to attach.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on December 25, 2007, 11:59:39 am
Sweet. Thanks again Halkun. I think Section 1-1 is probably the HRC structure, given how sensitive it is to modification and how much the model gets screwed up when it's tweaked in the slightest. So if Section 1-1 is the HRC structure, would it essentially contain a collection of pointers to everything else, or just to the bone data?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: halkun on December 25, 2007, 03:56:26 pm
The bone data is defined in an HRC.  Each "Body part" is an RSD object (ReSource Data). You make a list of RSD objects that make up the hierarchy. The RSD is made up of ploygons (PLY) and textue images (TIM). It looks like you found the RSD pool, but you missing the header for it.

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

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


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

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

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

HRC file format

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

Quote
:HEADER_BLOCK 2
:SKELETON sd_yufi_sk
:BONES 24

hip
root
2.9662
1 ABJC

chest
hip
4.0621967
1 ABJE

head
chest
5.017107
1 ACAA

joint
head
3.5236073
0

ribon_a
joint
8.52051
1 ACAF
....

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

Header

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

Quote
:HEADER_BLOCK 2

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

Quote
:SKELETON sd_yufi_sk

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

Quote
:BONES 24

Tells you how much bones are stored in this skeleton.

Bones

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

First Line: ("hip")

This is the name of the current bone.

Second Line: ("root")

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

Third Line: ("2.9662")

That's the Length of the bone.

Fourth Line #1: ("0")

Fourth Line #2: ("1 ABJC")

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

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

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

Notes

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

Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on December 25, 2007, 04:16:41 pm
Wow, thanks Halkun. Since only bone lengths are defined in the HRC, we'll need some animation data after all to put the models together then? I.e., to give the bones their proper angles? So we've still got lots of work to do then -- the animation data, once found, will have to be processed and applied to the bones.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: halkun on December 25, 2007, 06:29:22 pm
The compiled version of the HRC is going to probably be in this format


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

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

RSD files are also recorded. I won't duplicate that there. I do have a link..Here you go (http://wiki.qhimm.com/PSX/RSD)
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on December 28, 2007, 02:35:53 am
So, how was everyone's Christmas?  (Best present for me this year was a three-foot tube of unpopped popcorn - black, yellow, and red - from World Market. :D)

Haven't really had a chance here to try looking for anything in the way of bones data recently (computer's been flaky since I replaced the mobo and processor around the beginning of December, and my RPG Maker-alike, Thunderclap, is hollering at me "hey, why aren't you working on me" - which reminds me: Emacs-style key commands, or more like normal Windows programs, folks?  I'm leaning somewhat towards Emacs-style myself just because there aren't enough number keys to wedge all of the layers onto them :lol:), though assuming I can get more than just an interface mockup done for Thunderclap over my 5-day weekend, I'll check if Section 1-1 is in fact the HRC.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on December 28, 2007, 02:05:20 pm
That would be great, M. I've been sidetracked with certain other things recently, so I guess this means more downtime for the thread. First thing I'll do when I get another project out of the way is test out the pointer scheme for triangles, and maybe by that time someone will have found the bone data.

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

Halkun, thanks as always for putting more wrinkles in my brain!
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: halkun on January 08, 2008, 03:39:18 am
Did everyone die :)
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on January 08, 2008, 03:55:17 am
Still alive, halkun, and I'm hoping to finally jump back into vertex code (it'll probably be Thursday Friday). I've been sidetracked with another hacking project, grad school applications, and a funeral all this time, but it's all winding down now.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Cyberman on January 08, 2008, 07:42:10 pm
Did everyone die :)
Just my sleep.  I have GTE related questions for you, however that will have to be else forum as it's currently unrelated to Chrono Cross.
Still alive, halkun, and I'm hoping to finally jump back into vertex code (it'll probably be Thursday). I've been sidetracked with another hacking project, grad school applications, and a funeral all this time, but it's all winding down now.
Sorry about the funeral. You might wish to visit Qhimm and look at some of the posts in tech if you haven't recently.


Cyb
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on January 08, 2008, 07:55:10 pm
I thank you kindly for your condolences, Cyb. Ooh, and thanks for the Qhimm reminder!
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on January 11, 2008, 11:24:14 am


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

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


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


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

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

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

The rule for negative pointers works like a charm. I'm still investigating the rule for positive pointers -- I got weird results last night, but that may be due to sleepiness. I did a positive pointer test with the quads earlier before this thread's temporary death, and it worked out fine then. I plan on having a final verdict tomorrow morning.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: suri on January 11, 2008, 07:00:25 pm
nice work gents!

I am very happy that poking around in console files is not dead.
I devoted most of my fleeting youth to it.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on January 11, 2008, 07:04:58 pm
Hey, welcome aboard suri! I hope we can determine enough about how these models work for Luminaire85 to convert them into a usable format, and then one day we can see Serge, Kid, and Guile walking on those maps you're creating!

I've gotta do some final randomized tests to confirm the nature of the quad and triangle pointers yet. Gah, thanks to my nitpicking it seems this thread has gone backwards upon my return, since we had already started discussing bone data in depth right before I left. Suri, if you've got any input on Chrono Cross model exploration, by all means join in! I'm glad to have additional insight.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: suri on January 11, 2008, 07:20:14 pm
I hope you guys succeed! Id like to help if I could.
I dont know if i can help much because the only formats ive done where the file actualy had pointers in it was nights into dreams.  and being you can emulate it I worked from a memory dump and all the pointers were real ^^.
Lattely ive been doing alot of nextgen extracts like sonic 2006,eternal sonata,enchanted arms, doa4, and doax2.  those formats are gravy compared to the ultra compacted no info you dont need to live formats of psx era. also saturn didnt have mapping cordinates 1 texture per 1 quad, corners are  1 to 1 maped.  I did document the nights bone animation format though, I could post some details on it if you think it might be simular.  (i got it from finding the function that interpolates between keyframes and following the code over and over until i made sense of how it stored each keyframe and how it mapped to the model)

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

Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on January 11, 2008, 07:30:14 pm
Wow, you're quire experienced! I typically make changes to a file taken from the game image, paste that altered file back into a test game image, and see what the results are when I fire up my emulator. That's no doubt the most inefficient hacking method ever, but it's what I'm personally comfortable with, and I've honed it into as fine a science as I possibly can.

I'm not sure how similar Nights would be to Chrono Cross in model format, though there are no doubt similarities between all model formats I imagine. Can you tell if the model formats you've investigated are similar at all to what halkun described for Final Fantasy VII here?: http://wiki.qhimm.com/FF7/Kernel/Low_level_libraries#Model_formats_for_PSX

All the info we've confirmed so far regarding the Chrono Cross models (with the exception of the quad and triangle pointer schemes) can be found at the Chrono Cross File wiki: http://www.chronocompendium.com/Term/Chrono_Cross_File_Structure.html#Character_Battle_Models
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on January 14, 2008, 01:00:27 pm
Cross, I have not forgotten thee!

I've finally finished my evaluation of the quad pointers, and the results are unfortunately confuzzling. Here's the data from Section 1-2 (the UV map) that I tested:


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


Now here are the rules by which I tested:

QUADS...

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

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

The rules for negative pointers for quads work out just fine; in the data above, the negative pointer of a certain color leads to the positive pointer of the same color but underlined. The point on the UV map corresponding to each pointer of the same color are identical or maybe a pixel or two off, meaning that these points are mapped to the same vertex.

Now for the positive pointers. By the rules above, the first vertex (red) has a positive pointer of 0x22C0, which is divided by two to yield 0x1160 (which leads to address 0x3A48).

The second vertex (green) has a positive pointer of 0x2100, which is divided by two to yield 0x1080, and leads to address 0x3968.

The third vertex (purple) has a positive pointer of 0x1158, which is undivided and leads to address 0x3A40.

The fourth vertex (yellow) has a positive pointer of 0x10C8, which is undivided and leads to address 0x39B0.

Here's where the vertices should be on Serge, judging from the UV map:
(http://img167.imageshack.us/img167/6784/properplacestf3.gif) (http://imageshack.us)



And here's where the vertices actually are:
(http://img530.imageshack.us/img530/962/3a48yh7.gif) (http://imageshack.us)
(http://img126.imageshack.us/img126/6766/3968mt0.gif) (http://imageshack.us)
(http://img167.imageshack.us/img167/2070/3a40fs9.gif) (http://imageshack.us)
(http://img126.imageshack.us/img126/2047/39b0rs6.gif) (http://imageshack.us)

So something screwy is afoot. I should note that when I tested the quad rules previously, everything pointed into parts of 1-3 that were in "8-byte mode", whereas here each pointer points into "16-byte mode" parts.

EDIT: I should also note that there IS one pointer that points into "16-byte mode" while working as MDenham had theorized. It was one of the pointers in the non-UV data for Serge's belt, and it's highlighted in this post:
http://www.chronocompendium.com/Forums/index.php/topic,4770.msg85432.html#msg85432

It's at address 0x10D6 (pointer value 0x0968). Being in the third column, it is a straight pointer to address 0x3250 -- which happens to be the very beginning of "16-byte mode" in Section 1-3. The next pointer over, value 0x0990, didn't work for me back then as a straight pointer, but it points a bit further into Section 1-3. If we can get that last pointer to work in Serge's belt buckle through some adjustment, then we'll be well on our way to a really full understanding of the pointer scheme. I'll have to brood on this tonight over alcohol to figure it out...
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on January 16, 2008, 12:57:54 am
I find truth in the bliss of sleep. No, really -- an idea came to me as I hung in the altered state of consciousness between sleep and waking hours. I shall name it "vertex index theory."

Let's revisit Serge's belt buckle and the pointers associated with it on the UV map:
(http://img182.imageshack.us/img182/1939/bucklepointersnc3.gif) (http://imageshack.us)

It is now my belief that the pointers all behave as M said, but that in addition, they do not report raw offsets -- they report vertex indices in the vertex pool. The red-boxed pointer, value 0x0968, when divided by 8 yields an index of 12D, or 2D 01. We have already confirmed that this vertex is where the bottom of Serge's belt buckle is applied. If you take the last pointer value for quad #1 and divide it by 8, you get an index of 132. For the first and second pointers you must divide by 2, but then you must divide by 8 on top of that to get indices 139 and 13E. Look what happens when the vertices labeled 32 01; 39 01; and 3E 01 are altered:
(http://img508.imageshack.us/img508/4214/vertex132jr3.gif) (http://imageshack.us)
(http://img182.imageshack.us/img182/3282/vertices13913esh6.gif) (http://imageshack.us)

It would appear that the correct vertices are altered (there's a bit of clipping with Serge's shirt and arm in the lowest cap, but that's normal). This facet of the non-UV data's nature was imperceptible at first because my later examples stuck mainly to areas that pointed into Section 1-3's "8-byte mode" data. Raw offsets and vertex indices coincided, so everything seemed to check out fine. Since "16-byte mode" data progresses at half pace, things got out of whack, but with this interpretation the quads seem to check out.

So when we see "16-byte mode" data like this in Section 1-3:

YY ** ZZ ** XX ** 00 00 - YY ** ZZ ** XX ** 00 00
YY ** ZZ ** XX ** 01 00 - YY ** ZZ ** XX ** 01 00

...the underlined bytes we were wondering about earlier are in fact the indices of each vertex. If a first-column pointer were to point to the first vertex, its positive pointer would be 00 00; if it were pointing to the second, its positive pointer would be 10 00.

Does this sort of thing sound realistic? If so, we have the following for the quad pointer rules:


QUADS...

Rule for Positive Pointers (as interpreted in hexadecimal)
*If you're in one of the first two columns, divide the byte pair value by 0x2, then by 0x8. This value is the index for the vertex to which the UV point is mapped.
*If you're in one of the last two columns, divide the byte pair value by 0x8. This value is the index for the vertex to which the UV point is mapped.

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

I'm not sure how the heck that would be written in pseudocode though. Luminaire, do you think your viewer could be adjusted to accomodate this altered interpretation of Section 1-2's non-UV data? In any case, I have to confirm the triangle pointers yet. We'll know for sure this is right if those also work best interpreted as vertex indices.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on January 16, 2008, 09:54:43 pm
It is now my belief that the pointers all behave as M said, but that in addition, they do not report raw offsets -- they report vertex indices in the vertex pool.
I can't remember if I'd mentioned this idea once off-handedly or not (doesn't help that my computer died for the second time in two months, hence no work on anything useful, or even RPG-related, aside from beating Star Ocean 3 on Universe :lol:) but it sounds correct - and so what it boils down to is this (in a mishmash of C code and plain English):

(Notes: pd_uv[][] is the UV data array; pd_vptr[][] is the array of vertex "pointers"; pd_vertex[][] is the array of vertices to use for rendering; and vertex_pool[] is, well, the vertex pool after the step that converts all two-part vertices into a single value.)

* Load polygon data (2N bytes of UV positions, 2N bytes of vertex values) into pd_uv[cur_poly][0..N-1] and pd_vptr[cur_poly][0..N-1].
* If N = 3, divide pd_vptr[cur_poly][1] and pd_vptr[cur_poly][2] by 2.  Otherwise, divide pd_vptr[cur_poly][0] and pd_vptr[cur_poly][1] by 2.
* for(i=0; i<N; i++) {
* If pd_vptr[cur_poly] < 0: { pd_vptr[cur_poly] = **(pd_vptr + pd_vptr[cur_poly]); i--; continue; }
* pd_vertex[cur_poly] = vertex_pool[pd_vptr[cur_poly]];
* }

And yeah, it's amazing what ideas come to people when they're either just about to get to sleep or just about to wake up.  I lose more sleep from the former than from anything else. :D
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on January 16, 2008, 10:42:28 pm
Welcome back, M! Sorry to hear about the computer problem. It seems to happen to everyone who dabbles in game hacking, so I'm wondering when the bell will toll for my Compaq Presario *knocks on wood.*

Thank goodness, we're making progress then. I'll have a finalized report on the triangle pointers tomorrow night hopefully. The scheme for the positive pointers for triangles seems to work like this:

TRIANGLES...

Rule for Positive Pointers (hex)
*If you're in the first column, divide the byte pair value by 0x8. This value is the vertex index.
*If you're in one of the last two columns, divide the byte pair value by 0x2, then by 0x8. This value is the positive pointer into the vertex pool.

Which corresponds to what you had earlier -- it's the last two positions that are half value. I believe the negative pointers also behave as expected, though something really weird's going on -- it seems that the first UV coordinate might get the second-position pointer, the second UV coordinate might get the third position pointer, and the third UV coordinate might get the first-position pointer. That's what I jotted down in my notes, anyway. I'm not sure why that sort of thing would occur, but I'll post my findings when I can get my mind dis-discombobulated. Until then, take a look at the twelve triangles that are contained within offsets 0x2658 through 0x26E7 and see what you think:


00002658  69 EC 67 FB 5D EB-08 10 50 20 D0 21
00002664  5A EF 5D EB 56 F9-50 11 70 22 D0 FF
00002670  51 D9 3B DB 4B D6-D8 10 90 21 00 21
0000267C  3B DB 33 DC 37 D7-E0 10 D0 FF F0 20
00002688  33 DC 33 D7 37 D7-E0 FF D0 FF A0 21
00002694  3B DB 37 D7 3C D7-A0 FF 80 FF D0 FF
000026A0  6A D9 6E D6 7F DA-70 10 60 21 20 21
000026AC  47 DC 36 D5 32 DA-68 10 E0 FF 30 21
000026B8  32 DA 36 D5 33 D7-A0 10 E0 FF C0 FF
000026C4  47 DC 3A D5 36 D5-D8 FF 80 FF 40 FF
000026D0  30 DB 24 D7 2A D7-38 FF 80 FE 80 21
000026DC  31 DA 2B D6 25 D6-B8 10 40 FF 50 FF


The first six bytes in each row are the UV map coordinates; the last six bytes are the positive and negative pointers.

Looking at the first two triangles (0x2658 ~ 0x266F), for example, I ran an experiment showing that these triangles share one vertex. It would make the most sense if that shared vertex had the same UV coordinate -- 5D EB -- in both triangles. The other possibilities (69 EC and 67 FB) are too far away from triangle #2's UV coordinates for the mapped vertices to be plausible shared points IMO. I'll post visuals tomorrow night.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on January 16, 2008, 11:04:33 pm
Welcome back, M! Sorry to hear about the computer problem. It seems to happen to everyone who dabbles in game hacking, so I'm wondering when the bell will toll for my Compaq Presario *knocks on wood.*
Yeah...  according to what I'm seeing as far as the mobo manual online, supposedly the memory isn't working right.

I don't believe it. :D  I'm going to try rearranging the memory when I get home (currently up the hill at the local community college) and see if I can get the stupid thing to boot up.  If not, I'm computer-less for at least another 2-4 weeks so I can save up the money for new memory (as things stand, it looks like I'm probably looking at ~$60 if I'm only getting the system back up to 1GB of memory [it's currently got 1.25 - 2x512MB and 1x256MB]...  but who knows, I may try and push the system up further as an early [or late - 2/2] birthday present. :D).
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on January 16, 2008, 11:56:38 pm
Jeez, good luck with that. If I have to carry on without your genius for another week or two, just be sure to send me some brainwaves -- must've been what happened the other day.  :P  Hopefully we'll get through this triangle weirdness and find the bone data by the time your computer's back in shape.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on January 17, 2008, 01:28:41 am
Jeez, good luck with that. If I have to carry on without your genius for another week or two, just be sure to send me some brainwaves -- must've been what happened the other day.  :P  Hopefully we'll get through this triangle weirdness and find the bone data by the time your computer's back in shape.
Did we find the bone data yet? :D

Computer's back up and running - the oldest one of the three memory sticks (the 256MB one, thank God) is thoroughly flaked out so I'm down to just (:D) 1GB of memory.  I'm thinking that I will be spending $60 on the damn computer anyway just to double it up.

Anyway...  LET THE GAMES CONTINUE!
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Cyberman on January 17, 2008, 07:48:33 am
I suspect the model is still boneless there.
:D

Oh yes I'm still watching the thread, not much to add currently.

Cyb
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: halkun on January 17, 2008, 08:51:39 am
I'm still watching too. I'll pipe up when I see anything I can offer.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on January 17, 2008, 01:11:45 pm
YEAH! All we need is Luminaire, and the team will be fully assembled!! :lee: Yeah, I haven't even tried investigating bone data in depth yet; I've gotta review and digest halkun's notes on that once we get the UV triangles nailed down. I'll write up a report on the triangles tonight.

UPDATE: The triangles are still bothersome, but I'll report my findings so far. First, the really good news -- it seems the UV triangles are consistent wth M's description of them as far as which columns have positive pointers that must be divided by two and which are "straight" positive pointers, though they all need to be divided by 8 on top of that to yield vertex indices. I conducted some experiments with the UV triangle beginning at address 0x2658, and it would seem the rules for positive pointers lead to the correct vertices in the vertex pool.

The UV and non-UV data for this triangle are as follows:

00002658  69 EC 67 FB 5D EB-08 10 50 20 D0 21
And here's where that exists on the UV map:
(http://img443.imageshack.us/img443/2395/triangle2658va3.gif) (http://imageshack.us)
Coordinate #1 is 0x(69, EC); #2 is 0x(67, FB); #3 is 0x(5D, EB).

The non-UV value 1008, divided by 0x8 due to its first-column position, yields vertex 0x201. The next slot over, value 0x2050, is divided by 0x2 because it's in the second column, then by 0x8 to yield vertex 0x205. Rinse and repeat for the third non-UV slot, value 0x21D0, to get vertex 0x21D. Here's what happens when each of those vertices is altered:
(http://img242.imageshack.us/img242/7327/vertex201ck5.gif) (http://imageshack.us)
(http://img242.imageshack.us/img242/8016/vertex205zb3.gif) (http://imageshack.us)
(http://img242.imageshack.us/img242/4632/vertex21ddh8.gif) (http://imageshack.us)

Now notice something really interesting. It's quite clear that coordinate #1 is mapped to vertex 205! So the first UV coordinate for a triangle apparently gets the second pointer!

This odd swap principle can be further illustrated. Take a look at the following code for the first triangle followed by another triangle in this section of UV & pointer data:


00002658  69 EC 67 FB 5D EB-08 10 50 20 D0 21
00002664  5A EF 5D EB 56 F9-50 11 70 22 D0 FF


There is one negative pointer in the second triangle beginning @ address 0x2664. To make sure it points somewhere back into the first triangle's non-UV pointers, let's see if the triangles are connected by blacking them out:
(http://img256.imageshack.us/img256/5881/tangenttg2.gif) (http://imageshack.us)

It's not 100% conclusive (clipping issues may make it appear as if the triangles are separated by a pixel or so), but highly suggestive that the triangles are connected at the third coordinate, or 0x(5D, EB). But how can we use the negative pointer such that the 0x(5D, EB) in the second triangle is mapped to the same vertex as the 0x(5D, EB) in the first triangle?

According to my notes, it would appear that the second UV coordinate gets the third pointer. The value of the negative pointer is 0xFFD0, which leads 3 spaces back in the non-UV data when converted to decimal and divided by 16. That would lead three spaces back in the non-UV data, and we would land at the last pointer of the first triangle. Problem with that is, my notes tell me that the third UV coordinate might get the first pointer; the last goes to the second UV coordinate.

I'll have to spend more time theorizing on this weirdness later. At least we can conclude with some certainty based on actual visual evidence that the first UV coordinate gets the second pointer for triangle data. Anyone know why the heck that would be the case? For the quads, I always believed that the first UV coordinate got the first pointer, the second the second, etc, in logical order. This is very illogical at first glance.

EDIT: Looking at the positive pointer experiments for that first triangle, it does seem that the second UV coordinate is mapped to the third vertex pointer and the third is mapped to the first. I'll have to see if the scheme works out consistently via another thought experiment.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on January 18, 2008, 07:07:05 pm
I'll have to spend more time theorizing on this weirdness later. At least we can conclude with some certainty based on actual visual evidence that the first UV coordinate gets the second pointer for triangle data. Anyone know why the heck that would be the case? For the quads, I always believed that the first UV coordinate got the first pointer, the second the second, etc, in logical order. This is very illogical at first glance.
Obviously we now have to test this for quads to see if they are ordered "correctly" or not.

BTW, negative pointers may not be resolved until after the vertices have all been processed otherwise - in which case the routine that's reading the vertex pointers for triangles is reordering them prior to associating them with UV values.  As things stand (and assuming that quads have their vertices ordered correctly), however, it means that the pointers associated with the first two UV coordinates are always divided by 2 initially, regardless of where they actually land in the data as stored.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on January 18, 2008, 07:32:22 pm
Thanks M! Yes, I agree that regardless of where the last two negative pointers in any triangle fall after reordering, they are still divided by whatever amount their original location would suggest. There are several negative first-column pointers that are only divisible by 8 (and not 16) for example, so even if they're reordered during processing they have to be divided by 8 still. I guess the next thing I'll do is a thought experiment in which I reorder all the positive pointers according to the scheme I've arrived at, then figure out how the negative pointers can point to those.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on January 18, 2008, 10:42:17 pm
I too continue to lay in wait to a time where I can be useful.

Question, if I may: have you ever encountered a pointer data trajectory that crosses between triangle data and quad data? For example, say you started at a pointer in the 0x2658-0x26E7 triangle data. In the process of figuring out what that pointer actually should be, are you ever sent outside of the 0x2658-0x26E7 range? (I hope I'm still following well enough for that to make sense.)

The way I have the C++ program I used to make those images set up assumes that this never happens.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on January 18, 2008, 10:59:15 pm
Thanks for the question Luminaire. I haven't seen anything like that yet, though I haven't checked all quad-triangle boundaries yet. From what I've seen on my part, it appears that the first quad/triangle after a boundary will start with all positive pointers, then succeeding polygons may have negative pointers that go back no further than that first polygon.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on January 18, 2008, 11:10:34 pm
I wouldn't bother checking them all manually, at least not until after I try adding in the triangle-mapping procedure to my C++ program. Unfortunately that won't be for a few days since I have family in town this weekend.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on January 19, 2008, 12:35:08 am
No rush; I'm largely booked for the weekend as well. I'll be lucky to squeeze in some more ruminations on the triangle procedure. I blindly hope the scheme will function sensibly once I do the following switcharoos:

Give UV coordinate 1 the 2nd pointer.
Give UV coordinate 2 the 3rd pointer.
Give UV coordinate 3 the 1st pointer.

But, in doing this shifting, one must be careful to retain the divisions suggested by the pointer's original position, so figuring it out will be a bit tricky. Even though the first pointer would be shifted to the third column to correspond to the third UV coordinate, it will still be divided only by 8 (in decimal terms) as if it were in the first column. Ugh.

But the more I think about the quads, the more I believe they are mapped to their vertices in order.  I started thinking about the pointer swap for triangles precisely because I couldn't get the negative pointers to work properly, but I never had that problem with the quad pointers once I used M's scheme for those. So I think we're good there, and your program replicated the model quads accurately from the looks of it Luminaire.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on January 19, 2008, 12:47:50 am
No rush; I'm largely booked for the weekend as well. I'll be lucky to squeeze in some more ruminations on the triangle procedure. I blindly hope the scheme will function sensibly once I do the following switcharoos:

Give UV coordinate 1 the 2nd pointer.
Give UV coordinate 2 the 3rd pointer.
Give UV coordinate 3 the 1st pointer.

But, in doing this shifting, one must be careful to retain the divisions suggested by the pointer's original position, so figuring it out will be a bit tricky. Even though the first pointer would be shifted to the third column to correspond to the third UV coordinate, it will still be divided only by 8 (in decimal terms) as if it were in the first column. Ugh.
Alternatively, you can use a simpler scheme after swapping, and just divide the first two by 16 and the subsequent one(s) by 8. :D
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on January 25, 2008, 12:30:34 pm
For great justice!  :lee:

I've been tinkering with these triangles like an apologist for Ptolemy's model of the universe, adding circles within circles and wondering why the hell things weren't working out 100% of the time. Then the spirit of Copernicus must have come upon me and showed me that simplicity rules after all.

The triangle pointers can be understood as follows:

Rule for Positive Pointers (hex)
*If you're in the first column, divide the byte pair value by 0x8. This value is the vertex index.
*If you're in one of the last two columns, divide the byte pair value by 0x2, then by 0x8. This value is the vertex index.

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

*Switch pointers such that the first UV coordinate gets the second pointer; the second UV coordinate gets the third pointer; the third UV coordinate gets the first pointer. The pointers retain the division properties they had in their original positions.

We've known this much for the past week or so. The new news is, even though there's only three pointer "slots" in the triangle non-UV data, the fourth "slot" is still there for purposes of negative pointing!

So let's see how this works. Here's the data from those 12 triangles in Section 1-2 I've previously rattled on about; the non-UV pointer columns have been re-ordered so that they correspond directly to the UV coordinates:


2658   69 EC   67 FB   5D EB   50 20   D0 21   08 10
2664   5A EF   5D EB   56 F9   70 22   D0 FF   50 11
2670   51 D9   3B DB   4B D6   90 21   00 21   D8 10
267C   3B DB   33 DC   37 D7   D0 FF   F0 20   E0 10
2688   33 DC   33 D7   37 D7   D0 FF   A0 21   E0 FF
2694   3B DB   37 D7   3C D7   80 FF   D0 FF   A0 FF
26A0   6A D9   6E D6   7F DA   60 21   20 21   70 10
26AC   47 DC   36 D5   32 DA   E0 FF   30 21   68 10
26B8   32 DA   36 D5   33 D7   E0 FF   C0 FF   A0 10
26C4   47 DC   3A D5   36 D5   80 FF   40 FF   D8 FF
26D0   30 DB   24 D7   2A D7   80 FE   80 21   38 FF
26DC   31 DA   2B D6   25 D6   40 FF   50 FF   B8 10


We'll run through the triangle @ address 0x2694:

0xFF80 = -128, /16 (because it was once in the second column) = 8 slots back. Add an imaginary fourth column and this leads to address 0x2682, value 0xFFD0. 0xFFD0 = -48, /16 = 3 positions back. With the imaginary fourth column, this leads to address 0x2679, value 0x2100.

0xFFD0 = -48, /16 (because it was once in the third column) = 3 slots back. Add the imaginary column and this leads to address 0x2692, value 0xFFE0. 0xFFE0 = -32, /8 (because it was once in the first column) = 4 slots back. With the imaginary fourth column, this leads to address 0x2686, value 0x10E0.

0xFFA0 = -96, /8 (because it was once in the first column) = 12 slots back. Add the imaginary columns and this leads to address 0x267A, value 0x10D8.

Suffice it to say I've tested these values to ensure that this scheme accurately describes the behavior of the negative pointers. But rather than flood this post with pics of Serge's battle model in various states of intact-ness, I'll end with some awesome artwork I found on my hard drive.  :P

PS: Luminaire, to answer a question you asked earlier, it does seem that the quad and triangle sections are self-contained as far as negative pointers are concerned; once you cross the boundary from triangles to quads and vice-versa, the negative pointers will not go back beyond that boundary.

Once I get the quad and triangle pointers in the wiki, it's time to hunt for bone data.  :twisted:

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: ZeaLitY on January 25, 2008, 04:52:33 pm
I've been eager to post this since I found it:

(http://chronofan.com/Zeality/grimmjaw_by_tobiee.jpg)
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on January 25, 2008, 06:16:50 pm
Once again, a kickass Grimmjow pic heralds the dawn of a new era in which fans will gain complete control over their favorite franchises. In addition to the awesome work being done at qhimm and in Kajar Labs, various similar efforts are achieving success throughout the globe.

Hear the rumblings of the fan communities!

http://forum.xentax.com/viewtopic.php?p=24193&sid=8c9db27619f4bd9280225c394f811a3f#24193
http://auritech.eu/
http://www.youtube.com/watch?v=PyyZegEFDOo

Ahem. Enough FANaticism for one day. What's most pertinent at the moment is this:

(http://img261.imageshack.us/img261/9194/section2fl1.gif) (http://imageshack.us)

This is what happens when a fair amount of Section 2 (not to be confused with Section 1-2!  :mrgreen:) is zero'd out. It's possible this experiment may have hit on some bone lengths, reducing them to zero and thus planting Serge's head directly on top of the origin point for the model's bones. But I've gotta review all of halkun's notes before I try more experiments.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: halkun on January 25, 2008, 10:10:44 pm
Look like the HRC, or probably a "bone pool" pointed to by the HRC.  The HRC has bone length and what attaches to what. I'm guessing 0 is the root bone so you are attaching all the RSD's to the root (bone 0) with a length of 0.

Oops! Vocabulary!

the "root bone" is the bone that comes up from the floor and goes to the center of the body. It is the bone you move to move the whole model.  It was always the bone we missed with hacking FF7s models. It's usually first (bone 0) and sometimes it's assumed and not declared explicitly.

The HRC also is supposed to tell what RSD to use, so it might be "converting" the "arm" RSD to a "Head" RSD and putting it at 0. But I can't tell.

Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on January 25, 2008, 10:17:15 pm
Here's what the data in Section 2 looks like in hex, halkun:


00004EF0                          17 00 00 00 FF FF FF FF          ........
00004F00  00 00 01 FC 00 00 00 00-F0 FD 06 00 FF FF FF FF  ................
00004F10  00 00 00 00 00 00 00 00-FB FB 00 00 00 00 00 00  ................
00004F20  00 00 00 00 01 00 00 00-00 00 00 00 46 00 70 00  ............F.p.
00004F30  00 00 00 00 00 00 01 00-02 00 00 00 00 00 00 00  ................
00004F40  00 00 E7 00 00 00 00 00-00 00 02 00 03 00 00 00  ................
00004F50  55 FC FF 03 00 00 42 00-35 00 00 00 00 00 03 00  U.....B.5.......
00004F60  03 00 00 00 55 FC FF 03-00 00 42 00 35 00 00 00  ....U.....B.5...
00004F70  00 00 04 00 02 00 00 00-00 00 00 00 00 04 B4 00  ................
00004F80  02 00 8D FF FF FF FF FF-06 00 00 00 00 00 00 01  ................
00004F90  BF 03 00 00 00 00 00 00-00 00 05 00 07 00 00 00  ................
00004FA0  00 00 00 00 00 00 76 00-00 00 00 00 00 00 06 00  ......v.........
00004FB0  08 00 00 00 00 00 00 00-00 00 87 00 00 00 00 00  ................
00004FC0  00 00 07 00 02 00 00 00-00 00 00 00 00 04 B4 00  ................
00004FD0  02 00 73 00 FF FF FF FF-0A 00 00 00 00 00 00 FF  ..s.............
00004FE0  BF 03 00 00 00 00 00 00-00 00 08 00 0B 00 00 00  ................
00004FF0  00 00 00 00 09 00 75 00-00 00 00 00 00 00 09 00  ......u.........
00005000  0C 00 00 00 00 00 00 00-00 00 88 00 00 00 00 00  ................
00005010  00 00 0A 00 0D 00 00 00-00 04 00 05 F7 FF CB 01  ................
00005020  10 00 5C FE FF FF FF FF-01 00 00 00 00 00 00 00  ..\.............
00005030  00 04 00 00 00 00 C8 FF-FF FF FF FF 0F 00 00 00  ................
00005040  00 00 0C 00 00 04 00 00-00 00 00 00 00 00 0B 00  ................


Very sparse; lots of 00s. Not sure if that provides any immediate insight. IIRC, for the experiment above I zero'd out addresses 0x4F90 ~ 0x4FCF. My guess is, that stuff (0x4F90 ~ 0x4FCF or thereabouts) all applies to Serge's chest and arms; the stuff above to his head, and the stuff below to his legs. So it might flow in a top-down logical order.

EDIT: halkun, what would be the theoretical effect on the model if I zero'd out the root bone, provided it exists explicitly?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on January 25, 2008, 11:01:28 pm
Here's what the data in Section 2 looks like in hex, halkun:


00004EF0                          17 00 00 00 FF FF FF FF          ........
00004F00  00 00 01 FC 00 00 00 00-F0 FD 06 00 FF FF FF FF  ................
00004F10  00 00 00 00 00 00 00 00-FB FB 00 00 00 00 00 00  ................
00004F20  00 00 00 00 01 00 00 00-00 00 00 00 46 00 70 00  ............F.p.
00004F30  00 00 00 00 00 00 01 00-02 00 00 00 00 00 00 00  ................
00004F40  00 00 E7 00 00 00 00 00-00 00 02 00 03 00 00 00  ................
00004F50  55 FC FF 03 00 00 42 00-35 00 00 00 00 00 03 00  U.....B.5.......
00004F60  03 00 00 00 55 FC FF 03-00 00 42 00 35 00 00 00  ....U.....B.5...
00004F70  00 00 04 00 02 00 00 00-00 00 00 00 00 04 B4 00  ................
00004F80  02 00 8D FF FF FF FF FF-06 00 00 00 00 00 00 01  ................
00004F90  BF 03 00 00 00 00 00 00-00 00 05 00 07 00 00 00  ................
00004FA0  00 00 00 00 00 00 76 00-00 00 00 00 00 00 06 00  ......v.........
00004FB0  08 00 00 00 00 00 00 00-00 00 87 00 00 00 00 00  ................
00004FC0  00 00 07 00 02 00 00 00-00 00 00 00 00 04 B4 00  ................
00004FD0  02 00 73 00 FF FF FF FF-0A 00 00 00 00 00 00 FF  ..s.............
00004FE0  BF 03 00 00 00 00 00 00-00 00 08 00 0B 00 00 00  ................
00004FF0  00 00 00 00 09 00 75 00-00 00 00 00 00 00 09 00  ......u.........
00005000  0C 00 00 00 00 00 00 00-00 00 88 00 00 00 00 00  ................
00005010  00 00 0A 00 0D 00 00 00-00 04 00 05 F7 FF CB 01  ................
00005020  10 00 5C FE FF FF FF FF-01 00 00 00 00 00 00 00  ..\.............
00005030  00 04 00 00 00 00 C8 FF-FF FF FF FF 0F 00 00 00  ................
00005040  00 00 0C 00 00 04 00 00-00 00 00 00 00 00 0B 00  ................
00005050  10 00 00 00 00 00 00 00-D2 FF A7 00 00 00 00 00  ................
00005060  00 00 0C 00 11 00 00 00-00 00 00 00 00 00 23 01  ..............#.
00005070  00 00 00 00 00 00 0D 00-01 00 00 00 00 00 00 00  ................
00005080  00 04 00 00 00 00 38 00-FF FF FF FF 13 00 00 00  ......8.........
00005090  00 00 F4 FF FF 03 00 00-00 00 00 00 00 00 0E 00  ................
000050A0  14 00 00 00 00 00 00 00-D2 FF A7 00 00 00 00 00  ................
000050B0  00 00 0F 00 15 00 00 00-00 00 00 00 00 00 23 01  ..............#.
000050C0  00 00 00 00 00 00 10 00                          ........       


Very sparse; lots of 00s. Not sure if that provides any immediate insight. IIRC, for the experiment above I zero'd out addresses 0x4F90 ~ 0x4FCF. My guess is, that stuff (0x4F90 ~ 0x4FCF or thereabouts) all applies to Serge's chest and arms; the stuff above to his head, and the stuff below to his legs. So it might flow in a top-down logical order.

EDIT: halkun, what would be the theoretical effect on the model if I zero'd out the root bone, provided it exists explicitly?

I want to say there's six distinct bones, each terminated with 0xFFFFFFFF (or, alternatively, 2x 0xFFFF, which reads like the same thing - I mention this because it looks more likely to be pairs of 16-bit quantities, rather than single 32-bit quantities, for the most part), which break down into sections of length 1, 3, 29, 19, 19, and 4.  I have no idea what the last 20 bytes are, other than that they seem to be 3-byte numbers (in which case $504E-$5050 is missing its most significant byte - it's probably 0).  However, considering that Section 2 continues for another 136 bytes after what you've posted (last byte is $50C7, according to a couple of months ago (http://www.chronocompendium.com/Forums/index.php/topic,4770.msg83991.html#msg83991)), it may just be another bone or two you left out.  The 3- or 6-byte stride that seems to be showing up here is somewhat troubling, though.  I'm suspecting it may be bone rotations - either that, or I'm completely misreading it. :D

This gives us 74, 75, 148, or 150 (depending on whether or not the first 4 bytes are actually a bone or not, and on whether or not it's pairs or singlets of 16-bit numbers for each entry within a bone) total entries...  and 156 bytes of additional information as well (either 26 or 52 entries for the second half).

Something isn't quite matching up right here.


EDIT to handle the additional information, and because part of the info I gave is now wrong:

Looks to be a total of 8 bones now - lengths 1, 3, 29, 19, 19, 4, 19, and 15.  Bones 4 and 5 match up almost exactly (slightly different numbers, which is to be expected), as do bones 7 and 8...  with the exception of the last 4 entries of bone 7, which have no counterpart in bone 8.  They do, however, match up with bone 6, so they're divided a little strangely.

If I had to guess what bones are what:

#1 - Unknown; if it is a bone, it's probably the root.
#2 - 2nd-tier "control" bones - essentially, the spine.  Might be the head instead.
#3 - Torso.  Might include the head if #2 isn't the head.
#4 and 5 - Considering the relatively close correspondence between these two (some corresponding pairs are equal, others add up to 0x10000), and how 6+first part of 7 matches end of 7+8, I'm pegging these as the legs, despite what happened in the picture.
#6 - Dominant arm.
#7 - Non-dominant arm and hand.
#8 - Dominant hand.

The camera angle for that image is a little bad, also.  Was he still standing on the ground, floating above it somewhat, or partway in the ground?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on January 26, 2008, 12:15:39 am
Thanks for noting those various patterns, M. I was wondering what the significance of those FFFF strings might be. Since Section 2 is short enough, let me post the whole thing so everyone can see:


00004EF0                          17 00 00 00 FF FF FF FF          ........
00004F00  00 00 01 FC 00 00 00 00-F0 FD 06 00 FF FF FF FF  ................
00004F10  00 00 00 00 00 00 00 00-FB FB 00 00 00 00 00 00  ................
00004F20  00 00 00 00 01 00 00 00-00 00 00 00 46 00 70 00  ............F.p.
00004F30  00 00 00 00 00 00 01 00-02 00 00 00 00 00 00 00  ................
00004F40  00 00 E7 00 00 00 00 00-00 00 02 00 03 00 00 00  ................
00004F50  55 FC FF 03 00 00 42 00-35 00 00 00 00 00 03 00  U.....B.5.......
00004F60  03 00 00 00 55 FC FF 03-00 00 42 00 35 00 00 00  ....U.....B.5...
00004F70  00 00 04 00 02 00 00 00-00 00 00 00 00 04 B4 00  ................
00004F80  02 00 8D FF FF FF FF FF-06 00 00 00 00 00 00 01  ................
00004F90  BF 03 00 00 00 00 00 00-00 00 05 00 07 00 00 00  ................
00004FA0  00 00 00 00 00 00 76 00-00 00 00 00 00 00 06 00  ......v.........
00004FB0  08 00 00 00 00 00 00 00-00 00 87 00 00 00 00 00  ................
00004FC0  00 00 07 00 02 00 00 00-00 00 00 00 00 04 B4 00  ................
00004FD0  02 00 73 00 FF FF FF FF-0A 00 00 00 00 00 00 FF  ..s.............
00004FE0  BF 03 00 00 00 00 00 00-00 00 08 00 0B 00 00 00  ................
00004FF0  00 00 00 00 09 00 75 00-00 00 00 00 00 00 09 00  ......u.........
00005000  0C 00 00 00 00 00 00 00-00 00 88 00 00 00 00 00  ................
00005010  00 00 0A 00 0D 00 00 00-00 04 00 05 F7 FF CB 01  ................
00005020  10 00 5C FE FF FF FF FF-01 00 00 00 00 00 00 00  ..\.............
00005030  00 04 00 00 00 00 C8 FF-FF FF FF FF 0F 00 00 00  ................
00005040  00 00 0C 00 00 04 00 00-00 00 00 00 00 00 0B 00  ................
00005050  10 00 00 00 00 00 00 00-D2 FF A7 00 00 00 00 00  ................
00005060  00 00 0C 00 11 00 00 00-00 00 00 00 00 00 23 01  ..............#.
00005070  00 00 00 00 00 00 0D 00-01 00 00 00 00 00 00 00  ................
00005080  00 04 00 00 00 00 38 00-FF FF FF FF 13 00 00 00  ......8.........
00005090  00 00 F4 FF FF 03 00 00-00 00 00 00 00 00 0E 00  ................
000050A0  14 00 00 00 00 00 00 00-D2 FF A7 00 00 00 00 00  ................
000050B0  00 00 0F 00 15 00 00 00-00 00 00 00 00 00 23 01  ..............#.
000050C0  00 00 00 00 00 00 10 00                          ........       


When I get a chance to do another experiment, I'll record which offsets I zero out and post a pic of the results. If anyone has a specific suggestion for how to mess with this data, I'm all ears; otherwise I'm shooting in the dark, since this is a completely new type of data I'm working with.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on January 26, 2008, 01:25:22 am
When I get a chance to do another experiment, I'll record which offsets I zero out and post a pic of the results. If anyone has a specific suggestion for how to mess with this data, I'm all ears; otherwise I'm shooting in the dark, since this is a completely new type of data I'm working with.
Hm...  the first thing I'd recommend is seeing what gets moved/changed by zeroing out 5028-5037 (bone 6 in my new, updated version of my last post :D) as I suspect it's his right arm (seeing as how he's right-handed, it'd make sense to separate the hand for it into its own bone, which would be bone 8; his left arm, in its entirety, would then be bone 7).
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on January 26, 2008, 01:33:31 am
Alrighty, I've got time for another experiment, so I'll get on that right away. Thanks M!

Is it possible that the bones have 20 bytes of data each? Section 2 starts with the value 0x17, and if the entire section is split into 0x17 equal parts, it appears each subdivision (we'll call 'em "bones") would have 20 bytes each (that's in decimal). Also, when I zero out addresses 0x4EF8 ~ 0x4F18, the game can't load Serge's model and crashes. I'd say it's because I obliterated the 0x17 at the beginning; perhaps its a root bone or a header for this section.

I'm not sure what was going on with Serge's feet in that pic I posted awhile back; I was under the impression that everything below the waist was normal at the time, but I could be wrong because I was paying attention to the fact that Serge was discombobulated from the waist up.

UPDATE: Ooh, look! I zero'd out addresses 0x5028 ~ 503B, which is a little more than what you suggested M because I wanted to see what would happen if I counted 20 bytes per section.

(http://img352.imageshack.us/img352/1587/5028to503blm6.gif) (http://imageshack.us)

It would appear that the angle of one of Serge's legs has been significantly altered. But not the bone length itself as far as I can tell, which is odd. I'll go back and do only up to 0x5037 next -- that way we can isolate the purpose of those FF strings that seem to come at the tail end of each section.

EDIT: Here's the same views of a normal Serge for quick comparison:
(http://img20.imageshack.us/img20/2916/normalsergefe7.gif) (http://imageshack.us)
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on January 26, 2008, 02:13:26 am
Hmm, not really a noticeable difference if I leave alone the FF string that comes after address 0x5037:

(http://img147.imageshack.us/img147/5870/5028to5037tb3.gif) (http://imageshack.us)

The purpose of the FF string is still hidden from me. The next step is to start zeroing out adjacent areas, to see if each bone has an angle component and a length component that occur separately or something.

Intriguing!
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on January 26, 2008, 10:46:11 am
Ooh, look at the pretty colors in the attached pic. It's Section 2 color-coded into the header (which is in the black box, value 0x00000017) and "objects" of 20 (dec) bytes each. Given that this works out, I believe this might be the basic structure of Section 2.

The header says that there's 0x17 (0r 23 in dec) objects, and sure enough there's that number of 20(dec)-byte sections in Section 2! I'm unsure whether this is related to HRC in any way though.

I'm interested in any observations people might have on this. Just to be clear, there's absolutely no significance to the colors I've assigned the various "objects." I just wanted to make them stand out from one another. Also, I'm not sure that each "object" is an entire bone, since my experiment last night altered only bone angle it seems; so M's observation of 8 or so bones could still pan out. At least this gives me some structure to work with; I'll need to find out what each byte does in a given "object," and how many objects make up a bone.

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on January 26, 2008, 03:53:53 pm
 :D
(http://img118.imageshack.us/img118/3307/4f10to4f23ag2.gif) (http://imageshack.us)

Zeroing the range 0x4EFC ~ 0x4F0F makes the model disappear entirely and makes the game crash when I try to get Serge to attack, so this range must have some high-level organizational function for the model. This pic is what happens when the next range, 0x4F10 ~ 0x4F23, is zero'd out. It would appear that this might have affected the root bone that halkun referred to earlier, the one that goes from the ground to the model's central point. But to make sure, here's a Youtube vid so people can see the behavior of the model in various situations:
http://www.youtube.com/watch?v=ni3Kse0YmKI

It's obvious that bone angles are defined in this section of model data, but I'm still not sure that bone lengths are defined here. In any case, I'm going to go section-by-section to see what parts of the model are affected. I'll get a list and pics up for that once I've gone through all of them.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on January 26, 2008, 07:24:58 pm
I'm interested in any observations people might have on this. Just to be clear, there's absolutely no significance to the colors I've assigned the various "objects." I just wanted to make them stand out from one another. Also, I'm not sure that each "object" is an entire bone, since my experiment last night altered only bone angle it seems; so M's observation of 8 or so bones could still pan out. At least this gives me some structure to work with; I'll need to find out what each byte does in a given "object," and how many objects make up a bone.
Interesting to note is that, with the exception of the first 0xFFFFFFFF (at the beginning of Entry 0), all of the others terminate an entry.

Within each "group" of entries, then, the first four bytes seem to indicate an index (note: I'm converting out of hex):

Group 0: -1
Group 1: 0, 1, 2, 3, 3, 2
Group 2: 6, 7, 8, 2
Group 3: 10, 11, 12, 13
Group 4: 1
Group 5: 15, 16, 17, 1
Group 6: 19, 20, 21

4, 5, 9, 14, 18, and 22 don't appear in this list for whatever reason; 22 may be implied by the -1 in Group 0, however (though I doubt it).

Presumably, this gives the child bone list for each bone, in which case Groups 1-6 are Bones 4, 5, 9, 14, 18, and 22 respectively.

Alternatively, follow the last two bytes of each entry (again, by group):

Group 0: -1
Group 1: 0, 1, 2, 3, 4, -1
Group 2: 5, 6, 7, -1
Group 3: 8, 9, 10, -1
Group 4: -1
Group 5: 11, 12, 13, -1
Group 6: 14, 15, 16

...and also note that the two preceding bytes are 0 unless the last two bytes are 0xFFFF.

This narrows it down to a total of 12 bytes per entry of "real" data - probably X, Y, Z, rotX, rotY, rotZ in some order.

Therefore, I can pretty safely say that there are no bone lengths here - just rotations and translations.  Section 3 probably has the remaining interesting bone data, namely "what polys are attached to which bone, and (maybe*) how long the bones are".

* Assuming that the bone lengths aren't calculated upon loading the model, which is entirely possible but slower.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on January 26, 2008, 07:48:07 pm
THANK YOU M, that's very enlightening and gives me more ideas on what to target in further experiments. Yes, I'm definitely getting the impression from my investigations so far that only orientational data is in Section 2. When I did that first unguided experiment yestereve I fooled myself into believing I had found bone lengths when in reality I was simply telling Serge's head and some other appendages to connect to the central point in his model or something.

When I get done identifying which 20-byte runs affect which appendages and joints, I'll get a gallery up somewhere so everyone can see the effects on the models. It's quite interesting.

I'd like to report at the moment that range 0x4F4C ~ 0x4F5F is the orientation of Serge's left bandana tail, and 0x4F60 ~ 0x4F73 is Serge's right bandana tail (but I'm directionally dyslexic, so I could be off on which is which  :D)! Since these pieces are identical, we might be able to tell from the data where the rotational, etc., data is!
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on January 26, 2008, 11:00:05 pm
I'd like to report at the moment that range 0x4F4C ~ 0x4F5F is the orientation of Serge's left bandana tail, and 0x4F60 ~ 0x4F73 is Serge's right bandana tail (but I'm directionally dyslexic, so I could be off on which is which  :D)! Since these pieces are identical, we might be able to tell from the data where the rotational, etc., data is!
I'd guess that the breakdown is as follows:

Bytes 0-3: Parent bone, not child bone.  In standard order.
Bytes 4-5: rotX
Bytes 6-7: rotZ
Bytes 8-9: rotY
Bytes 10-11: X
Bytes 12-13: Y
Bytes 14-15: Z
Bytes 16-19: ID # of next entry for this bone.  NOT in standard order - the upper and lower 16-bit numbers are swapped from standard order.

-1 in the parent field indicates the root bone.  -1 in the "next entry" field indicates the end of a bone.

Now for the question some of you may have - "Why are you so sure the rotations are in the first six bytes of 'real data'?"

This has to do with the "debug menu" - rotations are given as being in a 0-4095 range there.  Since it's a reasonable assumption to make that they would also be stored here in that same range (or possibly -2048 to 2047), we have to look at the range given for values in the first three numbers vs. the range given for the last three:

First three: 0xFBFB (-1029) through 0x0500 (1280).
Last three: 0xFDF0 (-528) through 0x01CB (459).

Notable is the relatively frequent presence of values near 0x0400 and 0xFC00 in the first three numbers - which correspond to 90-degree rotations - and of small numbers in general in the last three.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on January 27, 2008, 12:01:55 pm
Huge thanks again M. I've got a gallery up of what bones/joints are affected by which offset ranges, in order, so maybe we can gain some more insight by having this evidence in front of us all:

http://s2.supload.com/gal/0801273355/0/

If each 20-byte offset range after the Section 2 header is labeled with a letter, we have the following map of joints, or articulation points, in the model:

(http://img112.imageshack.us/img112/9852/jointmapto5.gif) (http://imageshack.us)

I start with "B" because the offset range corresponding to "A" appears to have an extremely special purpose of some sort, judging from the game hanging when I zero it out. In any case, here's a list of articulation points:

Starting from 0x4F10 and going through 0x50C7, with each letter being a run of 20 bytes...

B: Root bone articulation; runs through center of model.
C: Waist articulation.
D: Neck articulation.
E: Bandana tie - left.
F: Bandana tie - right.
G: Shoulder - left.
H: Shoulder - left.
I: Elbow - left
J: Wrist - left.
K: Shoulder - right.
L: Shoulder - right.
M: Elbow - right.
N: Wrist - right.
O: Weapon.
P: Knee - left.
Q: Hip - left.
R: Knee - left.
S: Ankle - left.
T: Knee - right.
U: Hip - right.
V: Knee - right.
W: Ankle - right.

It's interesting to note that some joints seem to need two "slots" of articulation data. Also, weapon articulation is completely handled within the character model itself, so no animation data would theoretically be needed in the weapon model section that directly follows Serge's battle model.

Next step is to test out M's General Theory of Chrono Cross Model Articulation. We can already tell that a root bone specification is involved from Serge's Yoga Workout in the gallery linked above.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: halkun on January 27, 2008, 01:31:30 pm
The root bone connects to where the shoulders meet the spine. There are two sets of shoulder bones because two bone hierarchies come from it.

1) Root bone -> shoulder center -> neck - > head -> ....

2) Root bone -> shoulder center -> torso -> waist -> ....
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on January 27, 2008, 02:36:42 pm
That makes good sense. Would this reasoning apply to the knees? But I could simply be confusing the knees for the hips; sometimes it's hard to judge from the views I was able to get in-game.

UPDATE: Here's the result of an experiment testing the assumption that the first four bytes represent the parent bone. By changing the value 0x03 @ address 0x4F60 to 0x11, I told one of Serge's bandana ties to attach to his knee. I think. The ankle begins with 0x11, so I figured 0x11 represents the bone to which that articulation point is attached.

(http://img184.imageshack.us/img184/2867/tie03to11cs9.gif) (http://imageshack.us)

It would appear that the experiment was successful, but Serge's bandana tie, now misplaced, still stretches toward its original root at the back of Serge's head. Perhaps it's necessary to change other data (maybe in the vertex pool?) to get this experiment to work such that it places a correctly-shaped bandana tie on Serge's knee. I also noticed earlier that when Serge's wrist is detached from his arm and placed on the "root" bone, the arm texture similarly stretches so that it still connects the wrist to the arm. Any thoughts on this phenomenon and how it relates to the parent bone assumption?

But at least we know that the value at the beginning of the 20-byte run (first three bytes or so) have something to do with the articulation point to which each bone attaches.

Rotations are next. I'll see if I can get Serge to do the Exorcist maneuver...
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: halkun on January 27, 2008, 04:43:14 pm
I think that's how it's supposed to work. Bones influence the movement of vertexes. With Psy-Q you can define a bone to an RSD object, but it's not much of a jump to assign a bone to a vertex pool. I'm guessing that that information is in section 1-1
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on January 27, 2008, 05:13:35 pm
(http://img184.imageshack.us/img184/4575/zrotationny4.gif) (http://imageshack.us)
 :D The next two bytes after the parent bone definition are apparently for Z-axis rotation, or however we should define this type of rotation. I'm not sure what will happen if I try this with Sege's arm.

Note that to get Serge to do an Exorcist manuever, I had to change the rotation bytes from 00 00 to FF 03. I wonder how degrees are defined in hex? 0x3FF is obviously doesn't equal 360, and I haven't even gotten his head all the way around yet.

Yeah, as much as I dread it, we'll have to re-visit Section 1-1 after we get this done in search of missing info. Section 3 could still hold some interesting things too. Sections 4 and 5 are probably devoted specifically to battle animations.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on January 27, 2008, 05:36:47 pm
Note that to get Serge to do an Exorcist manuever, I had to change the rotation bytes from 00 00 to FF 03. I wonder how degrees are defined in hex? 0x3FF is obviously doesn't equal 360, and I haven't even gotten his head all the way around yet.
0x07FF, or 0xF800, will be a 180-degree rotation.

It's using the "4096 = 360 degrees" system the debug menu uses, so, for interesting angles:

0 degrees = 0x0000
30 degrees = 0x0155 or 0xFEAA
45 degrees = 0x01FF or 0xFE00
60 degrees = 0x02AA or 0xFD55
90 degrees = 0x03FF or 0xFC00

and so on.  I wouldn't suggest trying anything between 0x1000 and 0xEFFF, though; it may work properly (and just act like it's continuing through more rotations) but it might crash things instead. :D
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on January 27, 2008, 05:40:24 pm
Thanks! Now I can try this with some precision. BTW, the next two bytes after the Z rotation are for Y Rotation, if you count the Y axis as the axis that points away from you on an X-Y-Z axes model. I'll do another gallery for this stuff when I've gathered all the experimental evidence.

I'll be pushing to get all 20 bytes figured out by the time I clock in tonight.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Cyberman on January 27, 2008, 10:04:44 pm
It appears to be following PS1's 0-4095 (0x000 - 0xFFF) range of rotation. This is directly fed into the GTE as is. This makes sense too me.

Cyb
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on January 27, 2008, 10:50:50 pm
Egg-cellent. I've been doing rotations of 0x3FF all this time, and I think 90 degrees would have a value of 0x400 on the 0~4095 system if my Windows calculator was correct.

M, everything is just as you had theorized earlier -- only Z rotations and coordinates come first, followed by X and Y (or Y and then X, depending on one's perpective). For the coordinates, there's a byte that can either be 0x00 or 0xFF, a directional switch byte like we say earlier in the vertex pool. There's a few instances with 0xFE though, and I'm not sure what that does. I'll have to test that as well as the purpose of the last four bytes, and then we'll have Section 2 pretty much covered.

Figuring out the last four bytes of the twenty-byte run may give us some insight into the first range following the header that freezes the game and makes the model disappear when zero'd out, since that has two FF FF... runs. These may be related in meaning to the FF FF... runs we see at the end of succeeding 20-byte ranges.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on January 27, 2008, 11:45:30 pm
Egg-cellent. I've been doing rotations of 0x3FF all this time, and I think 90 degrees would have a value of 0x400 on the 0~4095 system if my Windows calculator was correct.
Since any change of 1 unit is roughly 0.08 degrees (5.7 minutes), 0x03FF and 0x0400 aren't really distinguishable.

Quote
M, everything is just as you had theorized earlier -- only Z rotations and coordinates come first, followed by X and Y (or Y and then X, depending on one's perpective). For the coordinates, there's a byte that can either be 0x00 or 0xFF, a directional switch byte like we say earlier in the vertex pool. There's a few instances with 0xFE though, and I'm not sure what that does. I'll have to test that as well as the purpose of the last four bytes, and then we'll have Section 2 pretty much covered.
There's also at least one 0x01 if memory serves, which just indicates that these are signed numbers.  Treat them as such and you'll be fine there.  (I'm suspecting fixed-point math here, BTW, unless they aren't in "standard" half-precision format as shown on Wikipedia.)
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on January 28, 2008, 12:00:33 am
*slaps forehead* Signed numbers! Of course! I need to specify that in the wiki entry for the vertex pool. Sweet simplicity. I needn't bother with the FE coordinate values then.

So for the 20-byte runs I've got this so far:


PB PB PB PB ZR ZR YR YR - XR XR ZC ZC YC YC XC XC
?? ?? ?? ??


Where...

PB = Parent Bone index.
ZR = Z-axis rotation.
YR = Y-axis rotation.
XR = X-axis rotation.
ZC = Z-axis coordinate.
YC = Y-axis coordinate.
XC = X-axis coordinate.
?? = the four bytes of unknown functionality at the tail end of these things.

The X, Y, and Z axis coordinates in 3D space seem to be relative to the attachment point with the parent bone, which I hope makes sense theoretically.

UPDATE: Pics confirming this stuff will be up tomorrow. In case anyone wanders in here before then, I'd like to report that the first run of 20 bytes is ALSO related to the model's root bone. So the root bone, like the shoulders and possibly the knees, has two "slots" devoted to it apparently. The model disappears entirely and the game easily crashes if I delete the first four bytes of this first "slot." But the others seem to affect rotations and coordinates.

Something really interesting -- when I checked out the rotations and coordinates for the first root bone "slot," the bytes were out-of-order with respect to what I posted above. Instead of Z -> Y -> X axis specifications, it has Y -> Z -> X specifications apparently. It will be interesting to see if this is the way all double-"slot" articulations work.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on January 28, 2008, 12:27:42 pm
Just so you guys can see what I've been looking at:
http://s2.supload.com/gal/0801289979/0/

The pics are in order of experiments and thus in order of the various specifications given for the bones. The rotations and coordinate axes have only been confirmed for the neck bone though.

Pic 1: A demonstration of parent bone attachment. I've shown this before I think.
Pic 2: Z rotation of the neck bone.
Pic 3: Y rotation of the neck bone (added to the Z rotation)
Pic 4: X rotation of the neck bone (added to the Z and Y rotations)
Pic 5: Z coordinate change, new value 0xFFAA
Pic 6: Z coordinate change, new value 0x00AA
Pics 7, 8, and 9: I had labeled the first two Y coordinate changes and the third an X coordinate change, but now that I look at them I'm not sure that different axes are being affected here. They might both be X axis specifications.

The bone having two X axis specifications is weird to think about, but truth be told, the first root bone specification after the header ("A" in the letter scheme, the one that causes freezing when its first four bytes are zero'd) seems to have two X rotation specifications and one Z rotation specification (no Y). Grr. It'll take a bit to figure out the scheme being used here. It appears from my findings so far that the specifications are not consistent among the various bones.

But in any case, the 20-byte runs can be broken down like so, in general terms:


PB PB PB PB R1 R1 R2 R2 - R3 R3 C1 C1 C2 C2 C3 C3
?? ?? ?? ??


Where the first four bytes are a bone or articulation point ID; the next six bytes are devoted to rotations, which can be in just about any order; the next six bytes are devoted to coordinates in 3D space; and the last four bytes are related to the bone ID in some way, but are functionally neutral -- changing these bytes to wacky values has no visible effect on the model or battle animations.

Since we know the ins-and-outs of Sections 1-2 and 1-3 in intimate detail, it would perhaps be best if I spent the next week or so figuring out the scheme by which the rotations and coordinates are ordered into X, Y, and Z axis-related info.

After that, I'm going to move on to Section 3 and see what wonders may be hidden there. It could be stationary battle animations, but that's a wild guess. Section 1-1 may be the HRC structure to which Halkun refers, and there we may find bone lengths if they exist. I think?

In any case, we are this close to having enough info for model viewing in static poses.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on January 30, 2008, 01:08:10 am
The bone having two X axis specifications is weird to think about, but truth be told, the first root bone specification after the header ("A" in the letter scheme, the one that causes freezing when its first four bytes are zero'd) seems to have two X rotation specifications and one Z rotation specification (no Y). Grr. It'll take a bit to figure out the scheme being used here. It appears from my findings so far that the specifications are not consistent among the various bones.
Actually, this could probably be chalked up to gimbal lock (http://en.wikipedia.org/wiki/Gimbal_lock) (article not readily helpful, but it's a semi-common problem with angle systems in computer graphics).  How many of these where it looks like it's got two fields representing the same axis have a 90-degree rotation on any of the axes?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on January 30, 2008, 02:10:32 am
I don't believe any of the bones I suspected of having doubled axis specification have a 90 degree rotation in their natural state. However, I'll read about this gimbal lock so I know what to watch out for. I still have to do some more experiments to make sure, but I've revised my understanding of the rotational specification order for the first few bones to the following:

Bone A (first root bone): Y -> Z -> X specifications
Bone B (second root bone): still indeterminate; more experiments needed
Bone C (waist articulation): Z -> Y -> X
Bone D (neck articulation): Z -> Y -> X
Bone E (bandana tie - left): Y -> X -> Z (but more experiments needed to confirm for sure)

This is too sketchy to draw certain conclusions from yet, but I'm hoping I can eschew the double-axis specification observation I made earlier as a mistake. At this point I'd like to float a theory by you guys and see if it sounds like a possibility:

Serge's waist and neck articulations are both specified in the order Z-axis; Y-axis; X-axis. These articulation joints are also on parallel planes. Thus, any articulation joint on a plane parallel to Serge's waist will have rotational specifications in the order Z -> Y -> X. The articulation joint through which bone "A" runs has differently-ordered axis specifications because that articulation point lies on a plane that's perpendicular (or otherwise at an angle with respect to) to those planes.

Such a model, if it were to pan out, would essentially mean that the X/Y/Z axis specifications are given relative to the plane upon which an articulation joint rests. But if this is the case, we'd probably have to assume that the angles of the articulation joint planes are somehow specified elsewhere in the model data.

I'm not sure that made sense; I'll be back later in the week with sketches and in-vivo evidence hopefully.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on January 30, 2008, 03:15:15 am
I don't believe any of the bones I suspected of having doubled axis specification have a 90 degree rotation in their natural state.
I just started going through and checking simply because I'd noticed the 0xFC01 rotation in bone A (which is close enough to 90 degrees that any difference wouldn't be readily noticeable), and here's the bones that MAY have gimbal lock issues and the axis they have a 90-degree rotation on (and the sign of that 90-degree rotation as well):

A (Y, -)
E (Y, +)
F (Y, +)
G (Z, +)
H (Z, +; 0x03BF or ~84 degrees, so there may be some noticeable movement off-axis)
K (Z, +)
L (Z, +; see H's note)
O (X, +)
P (Z, +)
Q (Z, +)
T (Z, +)
U (Z, +)

As far as symmetric pairs, we have E-F, G-K, H-L, P-T and Q-U, with A and O not having a symmetric partner (main and weapon bones, respectively); no left-right pairs have one bone with a 90-degree rotation and the other without.

So: B should still be Z->Y->X; F should be Y->X->Z; O will probably be X->Z->Y, but may be X->Y->Z; and all of the others mentioned above will be Z->X->Y.

Hopefully this matches with what you end up finding.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on February 01, 2008, 06:10:11 pm
Alrighty, I'm gonna do multiple posts here to keep the update somewhat orderly. First off, some corrections to my earlier list of the joints. M, this doesn't affect your earlier analyses in any way; I just had some joints mislabeled in a minor way.

If each 20-byte offset range after the Section 2 header is labeled with a letter, we have the following map of joints, or articulation points, in the model:

(http://img112.imageshack.us/img112/9852/jointmapto5.gif) (http://imageshack.us)

Starting from 0x4EFC and going through 0x50C7, with each letter being a run of 20 bytes...

A (unseen in diagram): Root bone articulation; runs through center of model.
B: Root bone articulation; runs through center of model.
C: Waist articulation.
D: Neck articulation.
E: Bandana tie - left.
F: Bandana tie - right.
G: Upper Shoulder - left.
H: Lower Shoulder - left.
I: Elbow - left
J: Wrist - left.
K: Upper Shoulder - right.
L: Lower Shoulder - right.
M: Elbow - right.
N: Wrist - right.
O: Weapon.
P: Upper Hip - left.
Q: Lower Hip - left.
R: Knee - left.
S: Ankle - left.
T: Upper Hip - right.
U: Lower Hip - right.
V: Knee - right.
W: Ankle - right.

Now that we've got this down, let's take a look at the possible scheme for rotations...
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on February 01, 2008, 06:53:46 pm
First, let's get our bearings. I'm going to use the following axes to describe 3D space from the player's point of view when Serge's belt buckle is facing the player:
(http://img520.imageshack.us/img520/7002/generalrotationdirectioyn5.gif) (http://imageshack.us)

That is, up-down is the Z axis; right-left is the X axis; and the Y axis is the line that would jut out toward you, the viewer.

Each joint lies on a certain plane. If you could tilt that plane such that its broad surface faces you, this appears to be the order in which the rotations are specified in general:

(http://img265.imageshack.us/img265/249/generalrotationmodelpn5.gif) (http://imageshack.us)

Which means, the first rotation occurs parallel to the plane itself; the attached appendage would sweep out an angle along the plane. The second rotation is perpendicular to the plane, but in a right-left direction with respect to the plane (that means the axis of rotation lies in an up-down direction). The third rotation is also perpendicular, but in an up-down direction (as if the axis lies along the plane going left to right).

That was confusing, so let's run through an example in 3D space with the X, Y, and Z axes specified first thing in this post. Let's say we're looking at Serge, and we want to predict how his head will rotate at the neck joint:
(http://img265.imageshack.us/img265/1711/normalneckkt2.gif) (http://imageshack.us)

According to the model I'm basing things on, we should predict that the first rotation will be along the Z axis (Exorcist maneuver); the second should be along the Y axis (meaning the axis is straight away from you, producing a right-left rotation arc that digs the head into the shoulder); and the third rotation should be along the X axis.

Let's take a look at what really happens. I've definitely posted the first image before, but I'm not sure about the first and second. I apologize for the opposite camera angle, but you can still tell that the model describes what happens. Note that the changes are built upon one another in this example. Serge does his Exorcist thing first, then the Y axis rotation buries his head into his shoulder, then the X axis rotation turns his head so that the back of it faces us while it's buried in his shoulder:
http://s2.supload.com/gal/0802018214/0/

More examples coming up...

Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on February 01, 2008, 07:09:03 pm
Now let's take a look at Serge's right knee (bone "T" on the list) to see how that behaves. It acts as if it's on a plane that's parallel, or nearly so, to the neck plane:
http://s2.supload.com/gal/0802017429/0/

How about Serge's shoulders? There are two joints for the shoulders apparently, one that connects the arms to the body and one just above the elbow, right on the edge of Serge's shirt sleeve. We'll examine the upper shoulder joints, bones "G" and "K" on the list. They behave as if they are on a plane with the broad surface already facing us -- that is, the order of rotation is Y -> Z -> X, just following the normal 3D coordinate axes.
http://s2.supload.com/gal/0802012790/0/

The upper hip joints, bones "P" and "T", appear to behave the same way:
http://s2.supload.com/gal/0802016104/0/

I think I posted earlier regarding the rotations of Serge's bandana ties, and that description didn't fit with the possible variants produced by this model. I'll check the bandana ties again, and the model will hinge on those results.

If anyone needs clarification, let me know. I'm not sure how clear I've explained the rotation scheme model.

UPDATE: Hmm, interesting. The bandanna ties appear to behave as Z -> X -> Y. This indicates they operate on a flat plane, but usually that's supposed to be Z -> Y -> X. However, Z -> Y -> X would look like Z -> X -> Y if viewed from a 90 degree angle instead of head-on, so I'm pretty weirded out over this. My inclination is to still use the model, since it at least provides an adequate predictor of where the Z-axis rotation would be so far.
http://s2.supload.com/gal/0802016482/0/

In any case, a final analysis of the 3D coordinates given to the joint is next on the agenda. 
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on February 01, 2008, 10:45:32 pm
I have finally gotten around to adding the triangles algorithm to my growing C++ model-parsing program. I believe the results speak for themselves (see attached picture).



[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on February 02, 2008, 12:29:02 am
Woot, woot!! Superior work, Luminaire! The one thing I'm really worried about there are the hair pieces sticking out of the top of Serge's bandana wrap (*slaps head -- Oh, those aren't hair pieces! They're just Serge's trunks. Very good!). Since those aren't bones in-and-of themselves, adding Section 2 info may not solve the problem.   What concerns do you have about the models Luminaire, since you've got first-hand experience actually reproducing them? I can always go back and check stuff out, doing more experiments if need be.

It would seem that the bones have been shaped into their final forms via the vertex pool, but they still need to be snapped into place based on info from Section 1-1(?) and Section 2. Do you guys think we actually need to hunt for bone lengths still, or is it possible those are already taken care of with the vertex pool info?

I'm prepared to declare that the 3D joint coordinates given in Section 2 are consistent with regard to X, Y, and Z specifications. Looking at Serge with the model's belt buckle facing us, it appears the joint coordinate specifications are in Z -> Y -> X order. Take a look at Serge's neck joint again:
http://s2.supload.com/gal/0802013763/0/

The first specification changes the height of Serge's head on the Z axis; the second specification moves the head toward or away from us (that's what it would look like if the pic were taken from the belt buckle view, anyway); and the third specification moves Serge's head along the X axis with respect to the frontal belt buckle view.

Now here's where things get interesting. I believe I reported earlier on Serge's upper shoulder joints having a Y -> Z -> X order for the rotation specifications. But it appears that the joint coordinates still have Z -> Y -> X specification!
http://s2.supload.com/gal/0802013224/0/

In the first pic, Serge's shoulder joint is raised slightly (along the Z axis), causing his hand to miss his weapon handle; in the second, his shoulder joint is stretched away from us if you're viewing the model with the belt buckle facing you (Y axis specification); and in the third pic, Serge's arm is drawn along the X axis until he appears to look something like Goro of Mortal Kombat fame.

UPDATE: Just wanted to mention that, after changing the file structure wiki a bit, the 3D coordinate specification order in Section 2 conforms to the same order we saw in the vertex pool! Yay for consistency!

In honor of Luminaire's work, I'm posting a slick pic as per our custom. They're cheaper than cigars.

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on February 02, 2008, 03:42:09 am
I'm getting really, REALLY dubious about there being any further bone data besides translation-and-rotation, folks - which means that bone lengths are calculated upon loading the model.  The only problem is, how do we assign polygons to a bone?

Section 1-1 does not correspond in length, at all, to the bone count (for Serge, you get 10 bytes + 36 per bone excluding the root, while for Kid, you get 16 bytes + 22 per bone excluding the root...  not a good sign here).  Section 3 seems to be, guaranteed, 0x160 bytes, regardless of whose model it is.

Considering how Section 1's entire purpose is polygon-related, 1-1 is probably polygon assignments to bones, and that's all, which explains why it doesn't match up in any sort of manner that makes sense to the number of bones for the character in question.

Now comes the interesting problem: The first four bytes of 1-1 don't seem to match up with the number of bones for a character (17 vs. 23 for Serge, 23 vs. 39 for Kid, and ???? (possibly 13) vs. 36 for Guile).  This may or may not be irrelevant (considering doubled joints like the shoulders and hips, and the two root bones, Serge ends up matching up; but I don't see why Kid would have fourteen doubled joints + the two root bones).

Also, can anyone confirm that there is not any 16-bit number in Section 1-1 for Serge that is more than 0x029E (the polygon count)?  If we can confirm this, then 1-1 is almost certainly solely polygon->bone assignments, and as far as bone lengths go, well, we'll have to hand-calculate them just like the engine does. :P
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on February 02, 2008, 11:02:02 am
Before heading back to Section 1-1, I'm going to post Section 3, since it's a shortie:


000050C0                          B8 00 00 00 00 00 03 00
000050D0  28 00 B0 FF 00 00 03 00-10 00 00 00 00 00 03 00
000050E0  00 00 00 00 00 00 0A 00-00 00 00 00 00 00 06 00
000050F0  00 00 00 00 00 00 0C 00-00 00 00 00 00 00 08 00
00005100  28 00 00 00 F8 FF 0D 00-28 00 00 00 08 00 09 00
00005110  00 00 00 00 00 00 02 00-00 00 00 00 00 00 15 00
00005120  00 00 00 00 00 00 11 00-00 00 00 00 00 00 16 00
00005130  00 00 00 00 00 00 12 00-00 00 88 FD 00 00 00 00
00005140  30 FB 00 00 00 00 00 00-78 00 C0 FF 00 00 02 00
00005150  70 00 D8 FF 20 00 09 00-00 00 00 00 00 00 0E 00
00005160  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
00005170  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
00005180  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
00005190  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
000051A0  00 00 00 00 00 00 00 00-00 00 00 00 00 00 0E 00
000051B0  00 00 00 00 58 FF 0E 00-00 00 00 00 80 02 0E 00
000051C0  00 00 00 00 B0 FC 0E 00-80 80 80 00 80 80 80 10
000051D0  80 80 80 00 80 80 80 00-80 80 80 00 80 80 80 00
000051E0  80 80 80 00 80 80 80 00-00 00 00 00 00 00 00 00
000051F0  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
00005200  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
00005210  00 00 A0 FF 12 00 00 00-00 0C 00 0C E0 0F 00 00
00005220  00 00 00 00 07 00 00 00                       


It's very sparse. I assume it has something to do with animation, but I could be wrong. I'll try tweaking it and see what happens...

Ah, zeroing out Section 3 entirely appears to have various effects:
(http://s2.supload.com/thumbs/default/All_Zerod.gif) (http://s2.supload.com/free/All_Zerod.gif/view/)
(http://s2.supload.com/thumbs/default/All_Zerod_2.gif) (http://s2.supload.com/free/All_Zerod_2.gif/view/)
(http://s2.supload.com/thumbs/default/All_Zerod_3.gif) (http://s2.supload.com/free/All_Zerod_3.gif/view/)

Interestingly, the animations themselves are still intact. That means Sections 4 and 5 have to house all the animation data.

Looks like a re-examination of Section 1-1 is in order.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on February 03, 2008, 01:27:10 am
Well I realized as I was catching up on the bone search that my C++ program wasn't going to be much help in getting that info into Blender. For this reason I rewrote the program as a Blender plugin (i.e. a Python script). The idea is that, once the model is successfully imported into Blender, it can be exported to other formats for archiving, viewing with other 3D modeling software, etc. if desired. Currently the Python version produces the same image as I provided in my last post, which means it's more or less working. Next will be to read the bone info from the battle model file.

I have to say that the Blender Python scripting documentation is pretty bad.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on February 03, 2008, 05:10:32 am
I have to say that the Blender Python scripting documentation is pretty bad.
I've never been terribly impressed with Blender at all, personally.

I'm also not much of a fan of the Maya UI, though - it seems like it should make sense, and then it throws something that ruins the whole "okay, I think I get it" experience.

Oh well. :D
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on February 03, 2008, 10:56:07 am
Wow, thanks for all the work you're putting into this, Luminaire!

M, I'm seeing a 0x4D6C @ address 0x2A8 in Serge's model, and a 0x3F50 @ address 0x2A4.  :(

Next weekend I'll do some more experiments in Section 1-1 and see if we can glean any info from that. I don't believe Section 3 is all that important for our purposes (though Cyb may be interested in knowing how that functions for Gears). I should mention that Section 4 is heterogeneous like Big Section 1 is, so it's slightly possible something else might be stuffed into Section 4 along with all sorts of animation data.

Here's a question for halkun or Cyb: In the FF7 HRC table structure, what "counts" toward the number of bones? Do root bones (the invisible ones that determine stance angle, etc.) count? As M has stated, if we subtract the double joints and root bones from the number of total "joints" listed in Section 2, we get the number at what might be the beginning of the HRC. We currently have that offset range (0x40 ~ 48 IIRC) listed as part of the subheader in the wiki, but that could be changed. The number there is 0x11, and Serge has 0x17 joints. If the root bone joints (0x2) and the second joints for the shoulders and hips (0x4) are subtracted, we get 0x11. BUT - Kid has a value of 0x17 in this potential HRC beginning v. 0x27 joints, and that would be an awful lot of double joints, as M has stated already.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: halkun on February 03, 2008, 06:02:58 pm
One of the problems with FF7 was that we kept "missing" the root bone. It's really contextual. I don't think it was counted in FF7 until the render stage.

Also, we count bones, not joints. Bones have a few attributes that are universal

1) Parent
2) Child (if present)
3) Length
4) rotational data relative to the parent.
5) Vertex pool to move

The bone structure you are looking at now is probably a "default" postion before animation is added. This means the model is most likely standing in a "T" like formation with his arms out to the sides.

Now I've seen some games where there are two root bones, because they want to play the model against a sloped terrain. I don't think that's used here.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on February 06, 2008, 10:37:26 pm
Right, right -- I misspoke about the number of root bones; I should say that the root bone has two joints.

So far, in Section 2, we might have:

1.) Parent
2.) Child (I think it's the last four bytes in the bone data specifications).

4.) Rotational data relative to the parent. This is definitely there, of course.

We're definitely missing "length" and "vertex pool to move" on your list halkun. Section 2 also appears to have some specification for the 3D coordinates of the joint. BTW, if I zero out the "child bone" specification, would that theoretically have any impact on the model from your experience? I've done a few experiments where I zero out what I believe is the child specification, yet no noticeable impact on the model. If there should be an impact on the model when I zero out the child bone specification, then the last four bytes in each joint data section are for something other than what I suspect.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on February 08, 2008, 04:44:17 pm
The discovery continues!  :lee:

I present as an attachment to this post all of Section 1-1, with an outline of Section 1-1-1!. Luckily, I haven't seen any sub-sub-sub sections yet, so I think three numbers is as deep as we'll have to go.

Section 1-1-1 is periodic, with a stride of 4 bytes (hope I'm using technical language correctly here  :mrgreen:). The last two bytes in any "slot" would seem to be a bone or joint index. Here's an example of how they work...

The value 0x0003 is the index number for Serge's head bone or neck joint. The bytes 03 00 @ address 0x52 tell the powers that be to assign the rotational and other data of joint D from Section 2 to Serge's head/neck. In addition, animation from an as-yet unknown source (Section 4, most likely) is also assigned.

So what happens when we change the bytes @ address 0x52 from 03 00 to 04 00? Serge's head is ripped right off his neck, given the rotational data for joint E (bandana-right), and starts jerking just like Serge's bandana tail does! Here's a pic to give everyone a proper impression:
(http://img181.imageshack.us/img181/9227/exp9jn1.gif) (http://imageshack.us)

Now let's take a look at the pattern in the last two bytes of each "slot" in this sub-subsection. The indices run in this order:

00; 01; 02; 03; 04; 05; (06 excluded); 07; 08; 09; (0A excluded); 0B; 0C; 0D; (0E excluded); (0F excluded); 10; 11; 12; (13 excluded) 14; 15; 16.

Five joint specifications from Section 2 are excluded, bringing this down to 17, or 0x11, slots -- our theoretical number of bones (18 bones, actually, if you count starting at 1 and not 0). But we were mistaken about which joints should be excluded. Let's take a look at which joint specifications from Section 2 are excluded here...

A (unseen in diagram): Root bone articulation; runs through center of model.
B: Root bone articulation; runs through center of model.
C: Waist articulation.
D: Neck articulation.
E: Bandana tie - left.
F: Bandana tie - right.
G: Upper Shoulder - left.
H: Lower Shoulder - left.
I: Elbow - left
J: Wrist - left.
K: Upper Shoulder - right.
L: Lower Shoulder - right.
M: Elbow - right.
N: Wrist - right.
O: Weapon.
P: Upper Hip - left.
Q: Lower Hip - left.
R: Knee - left.
S: Ankle - left.
T: Upper Hip - right.
U: Lower Hip - right.
V: Knee - right.
W: Ankle - right.

The weapon and extra shoulder and hip joints are removed, leaving us with the number of bones on the character model itself perhaps. That would leave us with two root bones, which I'm not particularly happy with, but it could be what's going on.

So what do the first two bytes in each slot do? Hell if I know. Here's the typical results of changing them...
http://s2.supload.com/gal/0802086837/0/

In order, the experiments conducted in this gallery were...


1st: @ address 0x48, changed 02 -> 03
2nd: @ address 0x48, changed 02 -> 04
3rd: @ address 0x4C, changed 08 -> 0A
4th: @ address 0x50, changed 53 to 5A


I don't think it's bone length that's being affected; what are your opinions? Something having to do with vertex assignments, perhaps? Note that symmetrical appendages (Serge's bandana ties, for example, the fifth and sixth slots) have identical values for the first two bytes.

EDIT: BTW, this is what happens when I give Serge's head slot the first two bytes shared by his bandana tie slots. It doesn't simply turn Serge's head into a bandana tie, which is what I was hoping for.
(http://img181.imageshack.us/img181/3417/exp12uq0.gif) (http://imageshack.us)

I really have no clue what's up with the first two bytes in each slot of Section 1-1-1.


[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on February 08, 2008, 08:46:38 pm
Five joint specifications from Section 2 are excluded, bringing this down to 17, or 0x11, slots -- our theoretical number of bones (18 bones, actually, if you count starting at 1 and not 0). But we were mistaken about which joints should be excluded. Let's take a look at which joint specifications from Section 2 are excluded here...

A (unseen in diagram): Root bone articulation; runs through center of model.
B: Root bone articulation; runs through center of model.
C: Waist articulation.
D: Neck articulation.
E: Bandana tie - left.
F: Bandana tie - right.
G: Upper Shoulder - left.
H: Lower Shoulder - left.
I: Elbow - left
J: Wrist - left.
K: Upper Shoulder - right.
L: Lower Shoulder - right.
M: Elbow - right.
N: Wrist - right.
O: Weapon.
P: Upper Hip - left.
Q: Lower Hip - left.
R: Knee - left.
S: Ankle - left.
T: Upper Hip - right.
U: Lower Hip - right.
V: Knee - right.
W: Ankle - right.

The weapon and extra shoulder and hip joints are removed, leaving us with the number of bones on the character model itself perhaps. That would leave us with two root bones, which I'm not particularly happy with, but it could be what's going on.
This is pretty close to what I said, aside from it being the weapon that's skipped instead of one of the two root bones. :D

Anyway:
Quote
So what do the first two bytes in each slot do? Hell if I know.
From the looks of things, it controls how the assignment of polygons to a bone is, along with (part of) the rest of Section 1-1 - whether it's 1-1-2 (starting at 2A 00 00 00 @0x8C and running for I don't know how long - probably either 84 or 168 bytes, putting its end at either 0xE4 or 0x138; note that if there's only one section, then the rest of this is either compressed in some odd manner, or it really does have a stride of 17 bytes) or 1-1-3 (unsure of the starting point, but runs until the end) that it's referencing, I'm not entirely sure.  I think it's working from 1-1-3, however.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on February 10, 2008, 03:18:49 pm
The attached picture is to show the bone connectivity my Blender importer is finding in the Serge battle model. I don't have the bone positions/orientations/scales yet, as I played with those to produce the image. It's supposed to look kind of like a person in that, based on your earlier notes:

- Bone.0 and Bone.1 are the root bones
- Bone.2 and Bone.3 are the spine
- Bone.4 and Bone.5 are the bandana ends in the head
- Bone.6 through Bone.9 are one arm, Bone.10 through Bone.13 are one arm, and Bone.14 the swallow
- Bone.15 through Bone.18 are one hip and leg and Bone.19 through Bone.22 are the other hip and leg

That makes 23 bones in total. Now if we could only figure out which vertices go with each bone...



[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on February 10, 2008, 03:49:11 pm
I'm not sure if it makes a difference Luminaire, but it's 23 joints and 17 bones in Serge's model. Your specifications are what I've got in my notes though; just need the word "joints" instead of "bones." There's definitely some bone info in Section 1-1-1, but I won't be able to do an in-depth exploration of the rest of Section 1-1 for a while yet. Hopefully the vertex assignments are somewhere in there...
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on February 10, 2008, 05:07:15 pm
I am wondering if the vertex pool is in some sort of order with respect to their associated bones/joints, and that the mysterious bytes in Section 1-1-1 are simply vertex counts. So when I look through Section 1-1-1, I assign 0 vertices to bone 0, 2 to bone 1, 8 to bone 2, 83 to bone 3, etc. If I select only vertices 10-93 as specified by this procedure, I get the decapitation in the attached picture.

Two problems (at least) with this idea:

(1) What happens with the bones/joints with no entry in Section 1-1-1?

(2) If you add up every other two-byte sequence in Section 1-1-1 (what I'm proposing could be vertex counts), you get 301, not 559 or 812.

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on February 10, 2008, 06:48:04 pm
Nice work!

The weapon will be defined in its own section seperate from the model (except for rotational data, which must somehow be lifted from Section 1-2), but I'm not sure what's up with the extra hip and shoulder joints. Is it physically possible for the bandana ties to have only a single vertex each? Am I understanding that right?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on February 10, 2008, 07:37:21 pm
I am wondering if the vertex pool is in some sort of order with respect to their associated bones/joints, and that the mysterious bytes in Section 1-1-1 are simply vertex counts. So when I look through Section 1-1-1, I assign 0 vertices to bone 0, 2 to bone 1, 8 to bone 2, 83 to bone 3, etc. If I select only vertices 10-93 as specified by this procedure, I get the decapitation in the attached picture.

Two problems (at least) with this idea:

(1) What happens with the bones/joints with no entry in Section 1-1-1?

(2) If you add up every other two-byte sequence in Section 1-1-1 (what I'm proposing could be vertex counts), you get 301, not 559 or 812.
This also ruins it for them being polygon counts (which, honestly, would make a little more sense).

As far as the rest of 1-1 (which seems to only be one section, now that I look at its organization), interesting things that are fairly common:

0xNN33, where NN is 07;
0xNN66, where NN is 02, 0A, or 0E;
0xNN99, where NN is 01, 05, or 0D;
0xNNCC, where NN is 08;
0xNN00, where NN is 00, 04, 08 or 0C; and
Numbers that are 0x00??

Interestingly, everything in the first five groups is immediately preceded by something in the last group.  For example, 0x0733 is preceded by (in order) 0x0010, 0x0014, 0x0015, 0x0011, 0x0001, and 0x0001.

Also interesting is that any "entry" that starts with a number 0x0020 or larger is (apparently) 8 bytes, while everything else is 4 bytes.  This gives a total of 172 entries - 7 long ones and 165 normal.  The long entries are at the beginning (0x008C), and otherwise mostly in the middle (0x0290, 0x0298, 0x02A0, 0x02A8, 0x0348, 0x0350).  It's possible that the first four bytes are a count of something...  but I can't make 42 entries of ANY length work out properly, so I'm disregarding it at this time.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on February 10, 2008, 10:43:00 pm
Well I guess I'm not sure if assigning vertices or faces to bones makes more sense. Blender does it with vertex groups and weighting, for what it's worth.

At any rate, I am still thinking that Section 1-1-1 should be read as follows:

   Assign 0 vertices to Bone.0
   Assign 2 vertices (vertex index range 0-1) to Bone.1
   Assign 8 vertices (2-9) to Bone.2
   Assign 83 vertices (10-92) to Bone.3
   Assign 1 vertex (93) to Bone.4
   Assign 1 vertex (94) to Bone.5
   Assign 10 vertices (95-104) to Bone.7
   Assign 20 vertices (105-124) to Bone.8
   Assign 6 vertices (125-130) to Bone.9
   Assign 10 vertices (131-140) to Bone.11
   Assign 20 vertices (141-160) to Bone.12
   Assign 6 vertices (161-166) to Bone.13
   Assign 15 vertices (167-181) to Bone.16
   Assign 36 vertices (181-217) to Bone.17
   Assign 16 vertices (218-233) to Bone.18
   Assign 15 vertices (234-248) to Bone.20
   Assign 36 vertices (249-284) to Bone.21
   Assign 16 vertices (285-300) to Bone.22

Just looking at what vertices are in those positions in the vertex pool, it makes a ton of sense for them to be assigned to bones as stated above. The catch is that I doubt those are the only vertices belonging to those bones.

Take, for example, the ends of Serge's bandana. FaustWolf is correct that the two bones should have more than one vertex each assigned to them. But in the vertex pool the other bandana edge vertices are not adjacent to vertices 93 and 94.

This trend becomes easier to see when looking at what Section 1-1-1 assigns to Serge's arms and legs, as they end up about half-attached to the appropriate bones. This post's attached image is the UV map corresponding to the vertices assigned to Bone.20, Bone.21, and Bone.22 by the above interpretation. You can see that all vertices are in the "leg" portions of Serge's texture, but that many of the vertices are missing.

Also, the vertices assigned to Bone.16, Bone.17, and Bone.18 overlap those in the picture exactly, and the vertex overlap also occurs analogously in the arm bones.

So, does Section 1-1-2 deal with the remaining vertices (either 559 - 301 = 258 or 812 - 301 = 511)? And why not just do it the same way as Section 1-1-1?

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on February 10, 2008, 11:00:17 pm
Awesome. I haven't had a good block of time to check out Section 1-1-2 at all, so anything's possible as far as I know. The only thing is that the numbers after Section 1-1-1 don't seem to fit a reasonable pattern (the third and fourth bytes in each "slot" are typically 00 00 there, and sometimes CC 00) -- though I really have no clue what's going on there until I test. I wonder if the entries are variable length somehow after Section 1-1-1 as M suggested above?

It'll be a while before I can test, certainly not till next weekend. In the meantime, I'll certainly take requests for experiments if it will help test out any theories you guys have.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on February 10, 2008, 11:14:50 pm
I just decided to look back a way through the thread, because 301 was rattling around back there.

HEY GUESS WHAT!

READ THIS POST. (http://www.chronocompendium.com/Forums/index.php/topic,4770.msg85487.html#msg85487)

The first run of 301 vertices is exactly how many there are before it runs into double-mode vertices.  The first two bytes after the 0x0000002A starting the next run is 0x0968, which offsets us exactly to the beginning of the first set of double-mode vertices.

Unfortunately, trying to get a count in the same fashion here gives us a total of 450, instead of 210 or 420, slots, so this second run doesn't behave quite how we'd expect.  I think it runs out to 0x02AC, at which point we have a sequence that gives all of five vertices - which happens to be the remaining block of single-mode vertices.

HOWEVER!

The double-mode vertices use longer entries here than the single-mode vertices do!  In fact, the entries here are 12 bytes instead of just 4 - the first four bytes are the number of vertices to count, and the remaining 8 don't just refer to a bone number, but also (I think) include weighting amount for the first and second parts of each vertex, thereby explaining the predominance of the numbers noted in my previous post.

This leaves two ranges of indeterminate purpose, which are fairly close in appearance (but not identical):

0x0294-0x02AB, and 0x0344-0x0357.

So, organization of Section 1-1 is just alternating segments of Type S and Type D:

Type S - Single-mode vertices.
Header: 4 bytes, number of entries minus 1.
Entries: 4 bytes -
* 2 bytes: Number of vertices.
* 2 bytes: Bone # to attach to.

Type D - Double-mode vertices.
Header: 8 bytes -
* 4 bytes, number of entries minus 1.
* 4 bytes, offset to move counter ahead by from last Type D section in this model. *
Entries: 12 bytes -
* 2 bytes: Number of vertices.
* 2 bytes: Zero.
* 2 bytes: ??
* 2 bytes: Weighting value #1?
* 2 bytes: ??
* 2 bytes: Weighting value #2?

Type X - Who knows?
* May simply be a "footer" for Type D sections to resync the counter for the following Type S section.

*I'm not entirely sure if this is actually used, or if it's a throwback to an earlier version of the model loader that required it.  If it is used, it's related to the two "Type X" sections more likely than not.

Now we just have to figure out what else is being kept track of in the Type D entries, and why they aren't kept track of with the bones (I have my suspicions here - I think they're for interpolation between bones...).

EDIT: After looking at things in there, I'm an idiot for hedging my bets.  Modified version of the Type D entries follows:

* 2 bytes: Number of vertices.
* 2 bytes: Zero.
* 2 bytes: Bone 1 and slot 1.
* 2 bytes: Weighting value for Bone 1 and slot 1.
* 2 bytes: Bone 2 and slot 2.
* 2 bytes: Weighting value for Bone 2 and slot 2.

Note that EVERY pair of weighting values adds up to 0x10000 or 0xFFFF.  NO exceptions.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on February 10, 2008, 11:25:47 pm
*Cries tears of utter joy.* I'll be damned, that looks great. Luminaire, is this enough info for you to go off of with your model viewing plugin?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on February 10, 2008, 11:46:01 pm
Absolutely. That makes perfect sense.

I can add a point of clarification, too. By MDenham's logic, Section 1-1 now has four subsections. Section 1-1-3 is from 0x028C to 0x02B7, and is identical in structure to the section from 0x0020 to 0x008B. So whatever the "header" from 0x0020-0x0039 does is what the "header" from 0x028C-0x02AB does.

So the first entry in the Type S and Type D headers is the number of entries, not the number of entries minus 1. In both cases you just skip the next four bytes before you begin counting entries.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on February 10, 2008, 11:55:38 pm
YEE-HAW~!  :lee:

What other info do we need at this point? Do we still need bone lengths, or do the vertex assignments magically handle that issue?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on February 11, 2008, 12:36:04 am
My Blender import script now assigns each vertex to at least one bone. Huzzah!

Unfortunately the model still looks like a mess because the bones aren't in the proper positions yet. The trouble is that I don't know what bone positions are the ones that result in the jumbled mess. Once I know what those are, I should be able to move the bones to a more humanlike arrangement and thereby reveal our silent protagonist. I was hoping Section 2 would contain that information, but I need to study your previous findings in more detail, as the quick implementation I did last week isn't working at all.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on February 11, 2008, 12:52:48 am
The descriptions for bone rotations we came up with in the previous few pages could be off since I never did conclusively prove how the rotations are ordered. The 3D coordinates for the bone roots/joints should work like the 3D coordinates for the vertices (the X, Y, and Z specifications shoule be in the same order for both). If you need clarification on any point in Section 1-2, just ask. I can do some further experiments with that data if needed.

We're getting close! Woot-woot! Huge thanks guys! :lee:

For quick reference, our discourses on Big Section 2 start with this post and continue at great length:
http://www.chronocompendium.com/Forums/index.php/topic,4770.msg87683.html#msg87683
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on February 15, 2008, 08:28:38 pm
I have figured out the purpose of the "16-byte" sections in Section 1-3. Recall that these are the vertices assigned to two bones. It's actually pretty simple:

* The first eight bytes represent the vertex's location relative to the first bone it is associated with.
* The second eight bytes represent the vertex's location relative to the second bone it is associated with.

Boy, am I glad to have that figured out.

Since I'm not having much luck with arranging the bones yet, I think I'm going to try using just the above information to arrange the vertices and see what happens. Hopefully I will have some good-looking pictures soon.

EDIT: There appear to be two caveats to this:

* The distance between the two vertices appears to differ slightly among vertices attached to the same pair of bones (for example, those in Serge's neck, which belong to Bone.2 and Bone.3).
* Sometimes the difference is a simple translation, but other times it's a combination of translation and rotation.

The good news is that the distances correspond well with the bone positions as suggested in Section 2.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on February 15, 2008, 11:25:36 pm
Consider it in the wiki. Take all the time you need, and let us know if you need any more experiments run. I'm still quite unsure about the veracity of the scheme I posted earlier about rotations (as far as how to tell which byte position specifies X, Y, and Z rotation), so if it's producing incorrect models, I can delve back in sometime and do more investigation.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on February 15, 2008, 11:57:25 pm
At this point there are two things that puzzle me about the bone data in Section 2:

(1) Bones 1, 7, 11, 16, and 20 have the vector (0, 0, 0) for their position data, suggesting a bone of length 0. Besides the fact that Blender doesn't like bones of length 0 (and correctly so), looking at what vertices are attached to each bone suggests that they are in fact not zero. I don't understand yet what to do with these bones.

(2) At this point I haven't used the rotation data in Section 2 at all, so I haven't had to worry about whether I understand it right. I suspect at some point I will need it, perhaps in regards to above, or perhaps to move Serge into his rest position before applying the animation transformations.

Also, I believe that, from the point of view of the vertices, the x-axis is "up", the y-axis is "forward", and the z-axis is "left/right". This swaps the x-axis and z-axis from your earlier definition, which is not really a big deal. It does make the bone position data come in the order xx yy zz rather than zz yy xx, which makes more sense.

Finally, I have attached two progress pictures: with and without bones.


[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on February 16, 2008, 12:15:08 am
An X-Z swap is no biggie, and would probably improve the logical-ness of things. I'm not sure it makes any difference, but I figured the vector coordinates (0, 0, 0) mean the specified joint is located at the center of the model (joints, not bones, are specified in Big Section 2). Let's see if there's any logical sense to the weirdness of these joints...

Joint 1 is a root bone joint.
Joint 7 is the upper shoulder joint, right.
Joint 11 is the upper shoulder joint, left.
Joint 16 is the upper hip, left.
Joint 20 is the upper hip, right.

I'm using the list of joints from this post, with A = 1: http://www.chronocompendium.com/Forums/index.php/topic,4770.msg88099.html#msg88099

Hmm, so the vector 0,0,0 doesn't mean they're at the origin in 3D space. The root bone joint might be at that location though. As for the rest, it is interesting that these are also skipped over in Section 1-1-1. The joints labeled "upper shoulder," etc., seem to be different in some way.

In any case, perhaps an experiment in changing these (0,0,0) specifications would yield some insight?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on February 16, 2008, 01:03:39 am
Before an experiment to test, I want to be sure I'm reading you right Luminaire. When you say "Bone 1", "Bone 7", etc., are you referring to the first, seventh, etc., 20-byte sections in Section 2?

For the seventh 20-byte run in Section 2, I've got:
02 00 00 00 00 00 00   00 00 04 B4 00 02 00 8D FF FF FF    FF FF

That is, the first four bytes tell us something I can't recall at the moment, like a joint ID or parent joint ID; the following three sets of bytes are for axis rotation (and read 00 00 00 00 00 04); and the three sets of bytes following that are for joint 3D coordinates (and read B4 00 02 00 8D FF).

I'm not looking at the same thing you are, am I?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on February 16, 2008, 01:14:04 am
No, "Bone 7" is the eighth bone. I'm starting my counting from zero.

That particular sequence is 06 00 00 00 00 00 00 01 - bf 03 00 00 00 00 00 00 - 00 00 05 00, and the bolded bytes represent the position data. My current interpretation is that the data represents a displacement rather than a position, meaning the bone is of length zero rather than having one of its ends at the origin.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on February 16, 2008, 03:39:16 am
Ah, the joy of weird things going on.

Section 2 isn't bones, it's joints, Luminaire.  It's got references to bone numbers, as children of each joint (these are the last two bytes of each entry; no idea what the two prior to that are, unless they're stored in mixed-endian order [2 3 0 1]), but the first four bytes are the parent joint number.

So there's 17 bones (-1 means "no bone") and 23 joints (-1, which only appears on the first joint, means "no parent joint").  The joint paths are as follows, from most-dependent to least:

W > V > U > T > B > A
S > R > Q > P > B > A
O > N > M > L > K > C > B > A
J > I > H > G > C > B > A
F > D > C > B > A
E > D > C > B > A

So, a few of the early bones are mislabeled (I think):

Quote from: Old version
A: Root bone articulation; runs through center of model.
B: Root bone articulation; runs through center of model.
C: Waist articulation.

Quote from: New version
A: Root joint.
B: Waist joint.
C: Spine joints (well, it's a single joint, but in a real person it's multiple joints).

All of the joints with zero translations happen to have, as their parent joint, a joint without a bone.  (However, the "weapon" joint has no child bone for other reasons, including the fact that the weapon is a separate model.  I assume the engine first consolidates things, then positions the weapon based on the sole remaining childless joint, in which case you could confuse the engine.  This is, at present, beyond the current scope of what we're doing. :D)  This explains why there's no translation or displacement - there's no bone on the parent joint!

Hopefully that helps.  A little.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on February 16, 2008, 08:30:56 pm
I'll re-submit this evidence as to what joints B and C could be:
(http://img165.imageshack.us/img165/6649/bcid3.gif) (http://imageshack.us)

Joint (B) seems to affect the whole model, which is why I labeled it a second root. Is it possible to determine from these experimental results one way or the other that joint C is for the spinal column v. the waist?

Let me get a list of which joints have (0,0,0) 3D coordinate specifications now that I'm on the same page with Luminaire:

Joint 1 is a root bone joint (according to the old list; it's joint B in any case).
Joint 7 is H: Lower Shoulder - left.
Joint 11 is L: Lower Shoulder - right.
Joint 16 is Q: Lower Hip - left.
Joint 20 is U: Lower Hip - right.

Which is interesting; what I call the "upper" joints have 3D coordinates, but the "lower" and root joint B (possibly, depending on how we decide to label it) have 00 00 for all coordinate specifications. I wonder what would happen if Luminaire gives these "secondary" joints the same coordinates as the "upper" joints. Although I distinguished between an "upper" and a "lower" for these, they're still very close together I think. Maybe I was just wrong on that. I'm going to do some experiments to clarify the nature of these 3D coordinates.

In the meantime, I'm going to regurgitate some previous experimental results that occur when all Section 2 data for joints 10 and 11 are zero'd out (meaning the right arm from the shoulder down is going to be assigned to the root bone as parent, regardless of the 3D specifications, which will be zero'd in both cases as well):
(http://img99.imageshack.us/img99/5498/1011mm2.gif) (http://imageshack.us)
Clearly from this, it is impossible to even distinguish between an "upper" and a "lower" joint visually...I might have screwed up in using a physical description like that.

Which gives me an idea. Is it possible that bone lengths are calculated as the difference between one joint's 3D coordinates and the next joint's 3D coordinates? Joint 10 would have 3D coordinates of some magnitude and Joint 11 has zero magnitude, meaning the joints coincide perhaps. But I'm sure there will be difficulties with this upon further examination and it will have to be eschewed. I'm just throwing this out there to see what you all think of it.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on February 16, 2008, 08:41:52 pm
Yeah, the bone lengths are embedded in the position/displacement data in Section 2. It turns out the vertices were already properly scaled in the vertex pool, so they just need to be properly translated and rotated. That's part of what Section 2 is for.

I'm this close to having it. Once I get Serge's arms to be the correct length rather than drooping past his feet, I will be attaching a most kick-ass picture.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on February 16, 2008, 08:43:38 pm
 :P
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on February 17, 2008, 12:41:59 am
:mrgreen:

I'm not quite sure I've got everything 100% correct quite yet, as there is at least one wayward vertex in one of his bandana ends, the root bone(s) aren't visible yet, the texture is a little off in some places, etc. Pictures with and without the armature visible are provided.

Also, in regards to the "bones of length zero" I was worried about, a good solution appears to be to use the same displacement as its first child bone. These bones are the ones in his upper arms and his thighs. We'll see if this holds up as we go on, but for now it's fine.


[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: ZeaLitY on February 17, 2008, 01:04:35 am
All right, since we're almost there...

(http://chronofan.com/Zeality/the_creation_of_gai_sensei.jpg)

(http://chronofan.com/Zeality/Gai_the_Sunflower_by_Zenbu_no_Naruto.png)

(http://chronofan.com/Zeality/zabuza_nmsgwewse.jpg)

(http://chronofan.com/Zeality/SEPHIROTH.png)

Aaroniero is also floored!

(http://chronofan.com/Zeality/Aaroniero_l__espada_9_by_kakarouto.jpg)

Now, ever major achievement is marked with a ton of encouraging, disturbing character explosions!

BUT LETS NOT FORGET GRIMMJOW JEAGERJAQUES

(http://chronofan.com/Zeality/Bleach/Chalkkjow_by_NeroAngelus.png)

(http://chronofan.com/Zeality/Bleach/Grimmch_the_movie_by_puppetdemon.jpg)

(http://chronofan.com/Zeality/Bleach/Grimmjow_Jeagerjaques_by_saishuu_hinoiri.png)

Congratulations to all parties.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on February 17, 2008, 02:21:23 am
AAAWWWW YEAAAH!!

It would appear Luminaire's got a good semi-T pose. This is even better for anyone who wants to do some character animation in Blender or whatnot; the user doesn't have to un-bend the character from the normal battle pose.

Luminaire, the only thing that looks awkward is the lower half of Serge's overcoat, below the belt. See how the part of his belt that hangs from the buckle is interrupted? Is it possible to fix that, you think? It was correct in an earlier iteration IIRC, before any bone data was applied.

*goes bonkers and throws Luminaire into a mosh pit*

This is a major achievement for the Chrono community and PlayStation fans in general. I'd like to say thanks to MDenham, halkun, Cyb, Gemini, and yaz0r for their advice, without which this wouldn't be possible.

Once Serge's model is perfected, the next step is to get all our knowledge into the wiki, see if Kid's model can be run through Luminaire's plugin without a hitch, then figure out Guile's model -- there's an extra section in his, but I still have yet to identify it; it might just be extra animation data or something.

Oh, and Luminaire -- did you actually apply the joint rotations indicated in Section 2, or does the model start out like this without those rotations?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on February 17, 2008, 10:19:38 am
Yeah, I used the Section 2 rotation data. It was giving me fits all evening until I figured out the trick.

The texture map below Serge's belt has always looked like that. I think it has to be something in the UV data because the vertices are correct. You can see a problem in Serge's wrists as well.

As for Kid's model...it's a start. You can see her skirt's all wrong, and the textures are off in several places, but it's not bad.


[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on February 17, 2008, 11:03:30 am
Kid's looking pretty good; that could become a new hairstyle. The fact that she's in that good shape without any extra investigation into her model is extremely promising.

I can't tell for sure, but the last pic you posted while you were still using C++ suggested to me that the belt was okay:
(http://www.chronocompendium.com/Forums/index.php?action=dlattach;topic=4770.0;attach=2421;image)

I can see more of Serge's belt in that pic than in the current version, where only the very tip of the hanging belt texture can be seen. I think?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: torin on February 17, 2008, 12:53:47 pm
wow, well done, i didn't know that there was job on chrono cross. Well, sorry for my bad english xD, this is a surprise to me, becouse i was working on chrono cross spanish translation (never finished by the way) a long long time ago. Maybe i can bring a little help for u guys; I'm programming a windows interface tool to dump the cd's, and a tool for translation.

congratulations again xD
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on February 17, 2008, 01:56:56 pm
Welcome torin! A Windows interface dumper would be extremely handy. Have you seen Terminus Traductions' source for their CD dumper? It works with the first game CD, but not the second as far as I know, so having a dumper for both CDs would be really awesome.

Did the Spanish translation stall because you needed more people to help with the translation from English to Spanish itself? The Compendium probably has a fair amount of fans with Spanish skills, and I'm looking for exercises to keep up my own Spanish speaking / reading / translating skills. Let us know if you need help.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: torin on February 17, 2008, 02:49:09 pm
yeah, i've stopped the translation becouse i was alone :( and my time to work with the project was too short ( university). Anyway, i'll be very happy for anyone help. The cctools from terminus translations work with both cd, they released two cctools into one rar file, one for cd and the other for cd 2. The other tool that i'm traing to program, is a translation tool, to view by blocks the script :)
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on February 17, 2008, 04:05:48 pm
Torin, how much of the script have you translated already? I wouldn't mind translating, say, one dialogue box's worth every evening, and we've got the script dump courtesy of ZeaLitY and Terminus Traductions (not sure if it's in game CD order). Eventually we could get it busted out. If you're up for continuing the translation project, you could start a new thread in Kajar Labs sometime.

Creo que yo tenga bastante habilidad con la lengua para ayudarte. Y mas importante, un buen diccionario.  :mrgreen:
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on February 17, 2008, 04:11:15 pm
I have solved the issue with the textures around Serge's waist. Turns out that Blender decided the order the model file has the faces in wasn't good enough, and changed a few around without warning. I have adjusted my plugin to correct for this.

Now to fix the texture at Serge's wrists. A question in that regard: are all of the battle model texture files 128 x 252?

Pictures later tonight may be good enough for front-page update.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: ZeaLitY on February 17, 2008, 04:26:32 pm
Yep, all 128x252.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on February 17, 2008, 04:28:56 pm
SIIII! Er - YEAAAH!

Yeah, ZeaLitY's correct. All the playable characters seem to have 128 x 252 textures for the battle models -- overworld models are 128x128 though. At least some of the enemies have 128x252 textures, though Garai might have a really huge texture if I'm not mistaken (that's for his regular TIM texture viewable in PSicture/TIMViewer; not sure what his battle texture is like).

Here's an example of what happens when a character's battle texture doesn't need the full 128 x 256 texture space. Hopefully this sort of situation won't generate the need for any extra work on your part Luminaire:

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on February 17, 2008, 09:08:03 pm
A certain silent protagonist would like to say "...".

I am 98% sure that that's what he's supposed to look like. I had to play around with the UV coordinates in order to get rid of a few minor texture artifacts, and the solution for the wayward vertex is temporary at best, but nonetheless, we have successfully extracted Serge's battle model.

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: ZeaLitY on February 17, 2008, 09:46:28 pm
Yikes, I accidentally overwrote the scan of Serge's battle model from Ultimania while uploading this new image in the encyclopedia. But that's okay, because I've pretty much overwritten a crude facsimile with the REAL THING IN LOSSLESS IMAGE FORMAT!

Hah!
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on February 17, 2008, 10:04:42 pm
*does the happy dance*

Serge looks perfect. This goes on the front page first thing tomorrow morning!
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: halkun on February 18, 2008, 04:45:41 am
I would like to amke some observations.

First I think you have the leg rotations mis-calculated. They should not be pitched forward. The feet should be planted firmly on the ground. I think this is the same error that is causing Kid's model to be messed up. (Are you missing a bone?)

Second of all, looking at your alterations, what you have is the "rest" pose that all animations are based off of. Now a little thing about the animation format...

Most likely the animation is stored in a "delta" format. This means that bone rotations are not explicitly stored for every frame of animation for every joint. What are actually stored are only the changes from the reference pose (delta), and then only the changes from the last frame to the current frame for each frame of animation.

Inf FF7, the first frame of animation was the reference frame, and then then each animation frame deltas off of that. In CC here, it would seem that the reference pose is all by itself, and then all animations will delta from that.

Information on FF7's delta animation format is duplicated here for reference

Quote
   Notes for rotational delta compression scheme
   =============================================

   The delta values are stored in compressed form in a bit stream. Consecutive
   values share no bit correlation or encoding dependencies, rather they are
   encoded separately using a scheme designed to optimize small-scale rotations.

   Rotations are traditionally given in normalized PSX 4.12 fixed-point compatible
   values, where a full rotation is the integer value 4096. Values above 4095 simply
   map down into the [0,4095] range, as expected from rotational arithmetics. When
   encoded, only the required 12 bits of precision are ever considered.

   In some animations, the author can choose to forcibly lower the precision of
   rotational delta values below 12 bits. Though these animations are naturally not
   as precise, they encode far more efficiently, both because of the smaller size of
   'raw' values, and also because of the increased relative span of the 'close-range'
   encodings available for small deltas. The smallest 128 [-64,63] sizes of deltas
   can be stored in compressed form instead of as raw values. This method is
   efficient
   since a majority of the rotational deltas involved in skeletal character animation
   will be small, and thus doubly effective if used with reduced precision. Precision
   can be reduced by either 2 or 4 bits (down to 10 or 8 bits).

   The encoding scheme is capable of encoding any 12-bit value as follows:

   First, a single bit tells us if the delta is non-zero. If this bit is zero, there
   is no delta value (0) and the decoding is done. Otherwise, a 3 bit integer
   follows, detailing how the delta value is encoded. This has 8 different meanings,
   as follows:

   Type   Meaning
   ------ -------------------------------------------------------
   0      The delta is the smallest possible decrement (under the
      current precision)
   1-6    The delta is encoded using this many bytes
   7      The delta is stored in raw form (in the current precision)

   The encoding of small deltas works as follows: The encoded delta can be stored
   using 1-6 bits, giving us a total of 2+4+8+16+32+64 = 126 possible different
   values, which during this explanation will be explained as simple integers (the
   lowest bits of the delta, in current precision). The values 0 (no change) and -1
   (minimal decrement) are already covered, leaving the other 126 values to neatly
   fill out the entire 7 bit range. We do this by encoding each value like follows:

   - The magnitude of the delta is defined as the value of its most significant
     value bit (in two's complement, so the highest bit not equal to the sign bit).
     For example, the values '1' and '-2' have magnitude 1, while the value '30' will
     have a magnitude of 32. For simplicity, we also define the 'signed magnitude' as
     the magnitude multiplied by the sign of the value (so '-2' has a signed
      magnitude of -1).
   - When encoding a value, we subtract its signed magnitude; essentially pushing
     everything down one notch towards zero, setting the most significant value bit
     to equal the sign bit and thus ensuring that none of the transformed values
     require more than six bits to accurately represent in two's complement.
   - The transformed value is then stored starting from its magnitude bit (normally,
     you would have to start one bit higher to include the sign bit and prevent
      signed integer overflow). Small values will be stored using fewer bits, while
      larger values use more bits. The two smallest values, 0 and -1, are not
      encodeable but are instead handled using the previously mentioned scheme.

   When decoding, you only need to know the number of bits of the encoded value, use
   the value of its most significant bit (not the most significant value bit!) as
   the magnitude, multiply it by the sign of the encoded value to get the signed
   magnitude, and then add that to the encoded value to get the actual delta value.

   Some examples of encodings:

   Delta value *      Encoded            *) in current precision, as integer
   ------------------ ------------------
    0                 0
   -1                 1 000
   -5                 1 011 111
   15                 1 100 0111
   128                1 111 xxxx10000000  (length depends on precision)


   (Note: The reduced precision is treated as rounding towards negative infinity)

More information can be found here...

http://wiki.qhimm.com/FF7/Battle/Battle_Animation_%28PC%29
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on February 18, 2008, 11:15:53 am
Whoah, animation. Might as well tackle it if we can. I've some questions for you halkun:

1.) If I hit a delta frame and changed its hex values, would that affect all delta frames thereafter, making for easy observation during experiments? I could at least use this to detect the presence of animation data.

2.) Also, would it theoretically be possible to get a rough estimate of the number of frames in an animation by recording how long an animation lasts and multiplying that by the frames-per-second the game is running on? Like, if an attack took 2 seconds to complete and the game runs at 30FPS, there would be 60 frames for that attack animation?

3.) I imagine that there will not be a set length in bytes for each frame while the data is compressed, but after it's uncompressed should there be, say, two bytes each devoted to X, Y, and Z rotations?

Ha, I've been remiss in wiki scribing. Luminaire, how did the rotational data in Section 2 work out for you? Is there some way to determine consistently which order the X, Y, and Z rotations are stored?

If Luminaire gets Kid's model working, I need to take a look at the structure of Guile's model, which is different from either of the first two, and get the nature of that structural discrepancy settled before moving on to animation experiments.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: halkun on February 18, 2008, 01:03:58 pm
The problem is that the delta data is a variable-length bitwise data stream. If you change data in the stream, you corrupt all the data after the point. It's kind of a pain :)
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on February 18, 2008, 09:39:49 pm
Well, after a little bit of staring cross-eyed at Section 3, I can determine...  absolutely nothing. :lol:  Aside from that it doesn't have a header at all.

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: [Select]
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. :D
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on February 18, 2008, 10:28:28 pm
Oh my goodness, if the animation data wasn't compressed that would be, like, so awesome. Great work M! I'm not even sure how I'd go about testing this, but at least I'll have a pretty good idea as to what I'm looking at once I get to it.

Grr, I'm short on time and I'm going to be attending a conference for the week with little or no Internet access. Just to make sure that interested parties have Guile's battle model in the meantime, it's attached to this post. If you look at the file structure wiki you'll see that Guile has an extra section specified in his model header; I'm not sure if this will be a problem. Guile's texture is inside the zip in .bmp format -- I think that's the type Luminaire's been using. If not, let me know and maybe I can excise the native format version before I head out tomorrow.

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on February 19, 2008, 12:16:42 am
Bitmap format is fine, although I usually use PNGs for images like that.

Well, I got Guile's battle model loaded with a few minor tweaks to my script. As you can see, it's also not bad, although there's plenty of issues to deal with, including but not limited to:

(1) Guile's ankles

(2) All of the faces with small versions of Guile's entire texture

(3) The armature doesn't match the vertices in a few places

But hey, at least you can tell it's Guile.

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on February 19, 2008, 01:45:43 am
Wow.  :lee: 

If you can Luminaire, let us in on how your python script interprets the rotational specifications in Section 2 when you have some spare time; I listed my theory a couple pages back, but it was pretty shoddy and you've probably come up with something different and more consistent. When I return I'm going to try and bust out a wiki update with all the knowledge we've gained over the past few weeks.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: ZeaLitY on February 19, 2008, 02:57:27 am
GUILE RULES
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on February 20, 2008, 11:48:20 pm
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, :lol:).

And in other news, I'm trying to piece together a tool that, at this point, would be able to "summarize" a model into a more human-readable format, and is meant to (eventually) be able to do edits of pretty much everything in the game data (either "exploded" into separate files, or from disc images).  More updates on that as the situation warrants, though I will recommend that anyone interested in the tool be prepared to learn C# if they don't already know it.  It'd make it easier to keep it up to date if all interested parties are capable of adding features as necessary. :D
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on February 21, 2008, 12:35:58 am
Good to see progress into the animation data. As you might imagine I will probably focus first on fixing up the base models for Kid, Guile, etc. before attempting animations.

In the meantime I have attached version 0.2.1 of my Blender plugin. (It's compressed only because .py isn't an allowed file type.) I wrote some instructions for how to use the plugin, which are embedded in the source, for anyone who wants to try it. I tried to write them for someone who's never used Blender, but I expect there are parts that are not clear, and I would be happy to clarify.

The second attachment contains Serge's battle model data and texture (which the plugin will prompt for), plus a .blend file that is what should result from following the plugin instructions. This file is more for anyone who hasn't been following along and therefore doesn't have the files.

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on February 21, 2008, 12:52:14 am
After looking through your script, I think I can safely say what the "minor problems" with the resulting models have been.

You're going to need to apply the weights from Section 1-1 to the two-slot vertices (they're in 4.12 format and add up to 1 [0x1000 or 0x0FFF] as it is) to determine what the actual values for the final vertex are.  Since you've got it just dumping one half of it instead, it ends up being "off" by some odd amount every time...  and pretty much always right near a joint, too.

Hopefully that helps correct some of the oddities you've noticed with the models.  (I'm sort of wondering if it'll fix the whole "ponytail sticking straight out" thing as well.)
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on February 21, 2008, 12:09:28 pm
Okay, I changed things to work that way. Turns out I pretty much just had to change it so that the two-slot vertices are combined after they are transformed rather than vice versa, which in hindsight makes a lot more sense anyway. For some reason the bones and weights for the two-slot vertices still need to be switched in order for things to work.

The good news is that the parts of Serge, Kid, and Guile that were right before are still right. The bad news is that the parts that are wrong are still wrong, although probably not as wrong as before.

I am thinking that the issue may be in the way the bone rotations are handled. As I recall I wasn't completely happy with the way I was doing it, so I will probably take another look at that next.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: halkun on February 24, 2008, 01:57:01 am
I'm not one to bump, but we've fallen off the front page.

Progress?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on February 24, 2008, 04:02:11 am
I'm not one to bump, but we've fallen off the front page.

Progress?
It's the weekend, of course not! :D

I'm wasting time listening to Vocaloid-based music on YouTube, personally.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on February 25, 2008, 11:17:33 am
I'm finally back, so I'll get to work on wiki-fying the progress soon. That will take a few days, then it will be time to do testing (if needed) or begin excising character models and textures to make sure everything works across the board.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Cyberman on February 25, 2008, 07:07:13 pm
Ah Wiki documentation. That is music to my ears. :D

Cyb
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on February 27, 2008, 11:58:30 pm
I'm overdue for a progress report, but unfortunately there's not much progress to report.

My current procedure for placing bones and adjusting vertex locations is probably best illustrated with an example. Firstoff, Serge's joint data:

Code: [Select]
Joint Parent Rotation (deg) Displacement Last
0 -1 0.0, -89.9, 0.0 0, -528, 6 -1
1 0 0.0, 0.0, -90.4 0, 0, 0 0
2 1 0.0, 0.0, 6.2 112, 0, 0 1
3 2 0.0, 0.0, 0.0 231, 0, 0 2
4 3 -82.5, 89.9, 0 66, 53, 0 3
5 3 -82.5, 89.9, 0 66, 53, 0 4
6 2 0.0, 0.0, 90.0 180, 2, -115 -1
7 6 0.0, 22.5, 84.3 0, 0, 0 5
8 7 0.0, 0.0, 0.0 118, 0, 0 6
9 8 0.0, 0.0, 0.0 135, 0, 0 7
10 2 0.0, 0.0, 90.0 180, 2, 115 -1
11 10 0.0, -22.5, 84.3 0, 0, 0 8
12 11 0.0, 0.0, 0.0 117, 0, 0 9
13 12 0.0, 0.0, 0.0 136, 0, 0 10
14 13 90.0, 112.5, -0.8 459, 16, -420 -1
15 1 0.0, 0.0, 90.0 0, 0, -56 -1
16 15 0.0, 1.1, 90.0 0, 0, 0 11
17 16 0.0, 0.0, -4.0 167, 0, 0 12
18 17 0.0, 0.0, 0.0 291, 0, 0 13
19 1 0.0, 0.0, 90.0 0, 0, 56 -1
20 19 0.0, -1.1, 89.9 0, 0, 0 14
21 20 0.0, 0.0, -4.0 167, 0, 0 15
22 21 0.0, 0.0, 0.0 291, 0, 0 16

To my understanding the joints with a -1 in the last 2 bytes (corresponding to the last column of the table above) are "origin joints" (my terminology) in the sense that all bones that are children of that joint are translated and rotated using that point as the origin. This column probably represents bone number, with -1 entries meaning that no bone exists between that joint and its parent.

For each joint, a position vector is formed by summing the displacements of all joints between the origin joint and the current joint, inclusive. This vector is then rotated around its origin joint by the sum of the rotations of all joints between the origin joint and the current joint, inclusive. The rotated vector denotes the actual position of that joint.

As an example, take joint 8. Its parent joint is joint 7, whose parent joint is joint 6, which is an origin joint. The unrotated position vector would be (180, 2, -115) + (0, 0, 0) + (118, 0, 0) = (298, 2, -115), and the rotation would be around the origin joint of (180, 2, -115) by the angles (0.0°, 0.0°, 90.0°) + (0.0°, 22.5°, 84.3°) + (0°, 0°, 0°) = (0.0°, 22.5°, 174.3°).

This interpretation seems to work great for all of Serge's joints/bones except joints 4 and 5, corresponding to the tips of his bandana. In the attached image you can see neither the vertices nor the bones are anywhere close to their proper locations. (They are, however, close to one another, which is good considering I apply the transformation described above to both joints and vertices.) I haven't had much luck figuring out what the problem is.

I hope at least some of that makes sense, and I hope someone has advice.

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: halkun on February 28, 2008, 07:15:02 pm
The knees bending forward is a little distressing. Maybe if you checked the rotation in the knees first (The goal being either straight or slightly bent th other way.) There is a small enough error induced there to see what the number should be if you "corrected" it.

Word of note. The GTE did have rounding errors that Sony didn't fix because many applications relied on them . This was corrected in software  by the Psy-Q lib itself. It might be that you aren't account for the GTE bug. FF7 had that problem when were were trying to align the walkmesh to the background graphics.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on February 28, 2008, 11:01:40 pm
Attached is an image of what happens if you simply take the negative of the z rotations before applying them. (I also took the negative of the x rotations to produce the images, but that does not affect the legs at all.) Both Serge's and Kid's impossible knee action appear to be fixed. Also, Kid's ponytail is now pointed behind her head rather than through her skull. There's still a problem with Guile's shoes, however they were wrong even before this change.

The attached also provides a nice visual summary of what's wrong with Serge, Kid, and Guile's models. Right now I'm only worrying about vertex and bone positions and saving the UV issues for later.


[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on March 08, 2008, 02:57:35 pm
Shoot, Luminaire, earlier you asked if everyone's textures were 128x252 pixels. I've located Glenn's battle model, and his texture appears to be 128x256. Is this a large problem?

Glenn's texture and model data are attached as I did with Dark Serge.

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on March 14, 2008, 09:06:05 pm
It seems like every time I figure something out, another issue arises.

Case in point: I think I've got all of the UV problems fixed, but I noticed that the number of faces in the imported models are lower than they should be, sometimes significantly. The problem is that the algorithm that determines the vertex indices appears to be assigning the same exact set of indices to multiple faces, and Blender is responding by deleting the extra faces.

The best example of this is at the tips on the bottom of Serge's shirt. The incorrect version is to the left in the attached image, while the correct version is to the right. Note that there are exactly two vertices with this mistake; Blender reports that there are only 668 faces where there should be 670.

Fortunately the offending faces are easy to find in Serge's face data, as they are at the start of the last section of quads. The four faces causing the issue are at 0x26E8, 0x26F8, 0x2708, and 0x2718. I am hoping the bug is in my interpretation of the method for converting pointers to vertex indices. It would probably be useful if someone would manually step through the pointer data for these faces. Meanwhile I will review my code.

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on March 15, 2008, 01:13:01 am
Fortunately the offending faces are easy to find in Serge's face data, as they are at the start of the last section of quads. The four faces causing the issue are at 0x26E8, 0x26F8, 0x2708, and 0x2718. I am hoping the bug is in my interpretation of the method for converting pointers to vertex indices. It would probably be useful if someone would manually step through the pointer data for these faces. Meanwhile I will review my code.
Raw data (after appropriate division by 2), where back-references are not shown in hex:

0x1008, 0x10F8, 0x10E8, 0x1100
0x1108, -4, 0x1150, -7
-5, -4, -8, -4
-1, -4, -8, -11

which gives real pointers of:
0x1008, 0x10F8, 0x10E8, 0x1100
0x1108, 0x10F8, 0x1150, 0x1008
0x1100, 0x10F8, 0x10E8, 0x1008 (same as first face, but opposite order, so back side)
0x1008, 0x10F8, 0x1150, 0x1108 (second face, back side)

So it's just an issue with how Blender deals with coincident faces - you're reading them correctly, it's just not behaving correctly.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Ema on March 16, 2008, 05:30:53 pm
Do you guys have any idea if it's possible to rip the pre-rendered backgrounds of CC?? o_o
Or if there's a website that has all of them.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on March 16, 2008, 06:02:22 pm
Ema, we've got our hands on all the prerendered backgrounds, believe it or not! The problem is assembling them. If you have a good working knowledge of 2D data, or would like to study CC's backgrounds, I'd be happy to post some of what we've got. The problems we've experienced so far are thus:

1.) The backgrounds are split into little rectangular chunks.
2.) One needs Photoshop to easily apply the palettes to the images. I have mixed success with TileMolester, but now that I know WAY more about 2D image data, I might just try exploring the hex in-depth to locate the palette addresses.

The major thrust of this thread is model data currently, but we can start another thread on 2D data to run concurrently with this one so we don't get all mixed up.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on March 16, 2008, 11:15:08 pm
I think I have a fix for the coincident faces issue coded up. I've also smoothed out most of the UV issues, although a face here or there seems to have its texture rotated incorrectly yet. For comparison with previous I've attached a picture of the latest output of Guile.

I've also attached version 0.2.2 of my script. I've done some refactoring along with the other bugfixes.


[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on March 17, 2008, 12:15:52 am
That's looking pretty darn good. Since Glenn and Guile both have that weird issue going on with their feet, I'd guess both models share the same basic structure (i.e., an extra section). I've gotta get on that sometime to figure out what's up with that.

For what it's worth, at this point I'd like to post the Section 1 subheaders of Serge's model and Dark Serge's model for comparison purposes, since those both work perfectly or nearly so.

Serge's Section 1 Subheader:

SECTION 1 SUBHEADER...
OFFSETS  OFFSET VALUES
00000020 02 00 00 00 14 00 00 00-80 02 00 00 05 02 2B 04
00000030 F9 00 00 00 38 03 00 00-C8 28 00 00 28 42 00 00


Dark Serge's Section 1 Subheader:

00000020  02 00 00 00 14 00 00 00-34 01 00 00 17 02 4A 04 
00000030  F9 00 00 00 98 02 00 00-C0 28 00 00 D0 3C 00 00 



Now compare to Guile's Section 1 Subheader:

00000020 05 00 00 00 20 00 00 00-D8 00 00 00 C6 01 00 00
00000030 B8 01 00 00 5C 02 00 00-4B 03 9A 04 BE 02 00 00
00000040 3C 03 00 00 38 2A 00 00-D0 40 00 00 0D 00 00 00
00000050 00 00 00 00


Actually, I'm not sure just where the header stops and Section 1-1 begins on Guile just yet -- that's just what I've got in the wiki, which doesn't reflect anything we've learned since the very beginning because I've been documenting only Serge all this time. But certainly the structure is different to some degree. Also, while I'm at it, here's Glenn's Section 1 Subheader since he's got the same foot issue as Guile:


00000020  03 00 00 00 18 00 00 00-CC 00 00 00 5C 01 00 00
00000030  16 02 45 04 93 01 00 00-90 01 00 00 A8 28 00 00


Not sure what we can glean from these headers yet, or even if it's Section 1 that's causing the difficulties, but that's what I suspect. I've gotta unload a bunch of notes I've taken on character model locations and so forth, then I can get back into this to run tests on Guile's model.


Also, and probably more usefully Luminaire, I've attached the models for the Mystic Knights (i.e., Ozzie, Slash, and Flea). I'm wondering if Slash's will turn out normal whereas Flea's will have whacked-out feet like Glenn's and Guile's do; just a hunch based on the Section 1 Subheaders.

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on March 17, 2008, 12:49:29 am
Guile's Section 1 Subheader:

00000020 05 00 00 00 20 00 00 00-D8 00 00 00 C6 01 00 00
00000030 B8 01 00 00 5C 02 00 00-4B 03 9A 04 BE 02 00 00
00000040 3C 03 00 00 38 2A 00 00-D0 40 00 00 0D 00 00 00
00000050 00 00 00 00


Actually, I'm not sure just where the header stops and Section 1-1 begins on Guile just yet
The 0D 00 00 00 at 0x4C is the beginning of Guile 1-1.

I'm thinking that the 32-bit numbers preceding and immediately following the "gobbledygook" are counts for something, but I'm not quite sure what yet.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on March 17, 2008, 12:53:48 am
Excellent, thanks for catching that flub M.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on March 17, 2008, 07:15:31 pm
Ozzie, Slash, and Flea for your viewing pleasure. The hunch about the feet of Slash and Flea appears to be accurate.

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on March 17, 2008, 08:18:38 pm
Huge thanks for checking that out Luminaire! That settles it (maybe), something in the Subsection 1 header is screwing up the feet at least. Interesting that Kid's skirt and Flea's skirt are screwed up in similar ways, as well as their hair bangs. Flea's model could exhibit characteristics of both Kid's and Guile's.

In any case, I've gotta get a party of Guile, Flea, and Kid together (with some hacking, heh!) to help figure out what's going on.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Cyberman on March 23, 2008, 04:53:11 pm
Luminaire85 and FaustWolf
Examining Flea as you call her and Guile notice the torso and the legs to the feet both are esckew in terms of the rotation (assume the X axis goes from left to right viewing flea from the front and Y axis goes from bottom to top Z axis plugins into the image).  This means using the left handed rule flea's rotation is negative if the right hand rule applies then it's still the same problem (IE the direction the fingers curl).  So that portion is being rotated the wrong direction. Examine the neck (they look like they've been hung) and the feet stretching portion. The sections of the model above them (bones?), are going rotated positively (below the waist) my guess is the rotations of these two bones are FLIPPED (IE the one being used on the torso is being used on the tigh bones and visa versa).  If that's the case tracing where the wrong bone rotation is being assumed and that might lead to solving the problem (and understanding the data better too).

Cyb
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on March 23, 2008, 05:13:23 pm
Thanks Cyb! I see what you mean, and that gives me some more direction. I'll get back to this project as soon as I put the finishing touches on another thing I've been working on, and once I've finally got everything we know so far wikified.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on March 28, 2008, 09:29:45 pm
I've finally made a little bit of headway into what I think is going on.

You may or may not recall a while back I was worried about bones with "translation" data of (0, 0, 0), of which there are five in Serge's armature data, including in all four of his appendages. I figured out that a pretty good solution seemed to be to give these bones the translation data of its child bone. It turns out that I should not have stopped there.

For example, take Serge's arm which is not holding the swallow. The translation data as read from the model file is (180, 2, -115), (0, 0, 0), (118, 0, 0), and (135, 0, 0), representing the shoulder, upper arm, lower arm, and hand, respectively. My correction explained above would adjust this to (180, 2, -115), (118, 0, 0), (118, 0, 0), and (135, 0, 0). Now I am thinking that it should be (180, 2, -115), (118, 0, 0), (135, 0, 0), and (?, ?, ?). The question remains of what to do with the last bone's length.

When you do it this new way Serge's forearm bone actually ends in his hand instead of at the tip of his glove, which makes more sense considering the way the vertices are assigned. Ditto for the other appendages; see picture.

EDIT: I am also starting to think that there are two issues to deal with. Remember that the joint data is, as I'm currently trying to use it, for both transforming the vertex data and generating bone information. I've found that I've had to make modifications to the joint data after transforming the vertices but before generating the bones. It seems that the rotations aren't being applied to the vertices or the bones correctly, but the translation data as provided is correctly translating the vertices to their correct positions, but giving wrong bone lengths.


[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on March 28, 2008, 10:20:00 pm
Makes me feel bad for not doing any work on this for awhile. I shall get back to it soon.

Luminaire, what's up with Serge's bandana in that pic? The bandana ties looked okay in the pic we released as part of the site update on model viewing, but here they're stretched way out and down.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on March 28, 2008, 11:10:50 pm
I wish I had not since forgotten, because I think it would solve a lot of the model problems.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on March 28, 2008, 11:55:19 pm
My first step is to get everything wikified, so maybe I'll come across something in the many notes we left in this thread along the way. I seem to recall one experiment where I got one of Serge's bandana ties to stretch all the way to his knee or something, so I'll have to keep an eye out for that when I do a run-through and see if that will be useful in any way.

There are probably several possibilities for the messed-up bandana ties, but at first glance it looks to me like the 3D coordinates assigned to each of the bandana tie vertices is way off, although the bandana ties are "rooted" to the correct place (i.e., the head bone/head joint I guess). Either that, or the 3D coordinates given to the bandana tie vertices are being specified relative to the wrong joint. We'll figure it out eventually.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on March 29, 2008, 01:04:14 am
Okay, so this is where I think the first four bones of Serge's model actually go, since (1) the bones exactly span the vertices mapped to each bone and (2) Bone.3 ends right at the point in Serge's head where the bandana tips connect.

As my earlier post today suggests, I have adjusted my code so that Bone.1 takes the length of what is given for Bone.2, Bone.2 takes the given length for Bone.3, and Bone.3 takes the given length for Bone.4. All of these bones keep their given rotations. Right now I am only manipulating the bone data, and leaving the vertices intact as they are.

The next step will be to try to figure out one of Serge's arms or legs. I think if I can figure one of them out then the others will fall into place.

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: ZeaLitY on March 29, 2008, 02:22:37 am
I'm sorry...

Call me juvenile, stupid, shallow, immature, or outright peurile,  but that picture is HILARIOUS HAHAHAAH!!!

(http://chronofan.com/Zeality/picardno.jpg) at myself
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on March 30, 2008, 10:10:29 am
Heh, wasn't thinking about that at all.

Some good news: Version 0.2.1 of my script, which I archived on the forums for good reason, calculates Serge's bandana correctly. Hopefully all I need to do is compare that version with the current version and figure out which of the changes I made is causing the trouble.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on March 30, 2008, 10:54:57 am
Awesome! Do you think it would be worthwhile running the Mystic Knights models through that version as well and seeing what (if any) difference it makes for those models?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on April 21, 2008, 03:20:58 pm
I don't know if I've mentioned this before, but I've noticed that most, if not all, of the troublesome areas of each model occur where the joint data contains significant values for all three rotation angles. I've been thinking of them as Euler angles (http://en.wikipedia.org/wiki/Euler_angles) and just using Blender's Euler construct to work with them, but I've been thinking that may be premature.

I'm fairly sure that the angles as presented in the model files represent rotation around the x-axis, y-axis, and z-axis, respectively, but I'm not sure how to interpret coupled rotations. Any insight into this would be most welcome.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on April 21, 2008, 03:30:06 pm
By "coupled rotations" Luminaire, are you referring to the dual shoulder and hip joints specified in Section 2? I'll have to take a look at Serge's Section 2 rotation values compared to Kid's and Flea's and Guile's when I get a chance to dive back into this.

EDIT: There was some other joint type being discussed in this thread a while back, might have been posited by MDenham. I can't remember what that was offhand and I can't find it in the thread at the moment, but I'll shout it out if I come across it next time I try to wikify everything.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on April 21, 2008, 03:44:30 pm
As an example of what I meant to say, take one of Serge's bandana ties. According to the way my script is interpreting the Section 2 data (which appears to be kinda close, but not quite, to the right way to do it), the rotation data for those vertices comes out to be (-82.5, 89.9, 6.2). A set of rotation angles with only one nonzero value, e.g. (-82.5, 0, 0), would correspond to a rotation around the axis corresponding to the nonzero value by the amount of the value, e.g. rotate -82.5 degrees around the x-axis. The problem is that rotating around one axis causes the other two axes to move, and so the order of rotations matters.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on April 23, 2008, 01:15:44 am
Hey Luminaire, while I was going through the Chrono Cross File Structure Page lately, I checked out ZeaLitY's debug room notes and found a debug option for this:


Adjust Chara.'s rot
   Start Changes
      "Current Values...
      X:0
      Z:0
      Y:0"
      Set rotx = 0000
         (If >4096) "Max is 4096!"
      ~
      Next
      Set rotx again
      ~
      Set rotz again
      ~
      Set roty again


Would it help things any to see this option in motion? I could do a Youtube vid after I get finals out of the way. I'm not sure if it rotates the whole model (ZeaLitY would know better), but it might demonstrate how the rotation planes are handled, perhaps.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: ZeaLitY on April 23, 2008, 02:23:49 am
Yep, just rotates everything.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on April 23, 2008, 04:03:50 am
Faust: It's because of how that menu's ordered that I was pretty sure most rotations were in either X-Z-Y or Y-Z-X order (not sure which of the two, though, but probably X-Z-Y).
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on April 23, 2008, 11:02:09 am
If that's the way the root bone operates (hence the whole model turning) for field models, then I imagine all bone joints would operate thus. I didn't pick up on this earlier because I was trying to figure it out solely by observing, and no doubt got mixed up along the way. Luminaire, does the assumption of an X-Z-Y order Euler rotation for all joints change things at all?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on April 23, 2008, 01:57:16 pm
I can't say for sure until I mess around with it, but as near as I can tell the way I was doing it was X-Y-Z order, so it's something different anyway.

I may also try to play around with those rotations in debug mode too.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on May 10, 2008, 02:24:28 am
Time to get the ball rolling again with a review question.

Luminaire and MDenham, did we ever settle on the exact offset ranges for Serge's Section 1-1-1, 1-1-2, 1-1-3, and 1-1-4?

I know Section 1-1-1 is offsets 0x40 ~ 0x8B, but how about the others? The vertex numbers for Section 1-1-1 add up to 301, but I'm having difficulty getting the other sections to add up to 210, 5, and 43 vertices respectively. I've attached a screencap of Section 1-1 of Serge's model, and also a zipped Excel spreadsheet in case anyone wants to fiddle with it.

Our previous posts on the matter begin here:
http://www.chronocompendium.com/Forums/index.php/topic,4770.msg88512.html#msg88512




[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on May 10, 2008, 10:19:04 am
That's because Section 1-1 actually has the repeating structure

{unidentified data}
8-byte vertex groups
16-byte vertex groups

The length of each segment of unidentified data can be determined by reading the first four bytes. If the value is 1, the length is 24 (including the first four bytes); if the value is greater than 1, the length is 24 + 4*value.

In Serge's model file there are two repeats of that structure, with offsets

0x0020-0x003f Unknown
0x0040-0x008b 8-byte vertex groups - 301 vertices
0x008c-0x028b 16-byte vertex groups - 210 vertices
0x028c-0x02ab Unknown
0x02ac-0x02b7 8-byte vertex groups - 5 vertices
0x02b8-0x0357 16-byte vertex groups - 43 vertices

No idea what the unknown sections represent.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on May 10, 2008, 05:45:58 pm
Ah, the unknown data was throwing me off after all.

I've attached a proposal for a revised Section 1-1 model. It has 8-byte headers consistently, and the number of sections should add up to the number indicated in the first four bytes of the header. Headers are in bolded boxes.

Besides the unknown data highlighted in red, I'm a little miffed that only the 16-byte mode vertex assignment headers have offsets into Section 1-3 (regardless of whether you use this proposed model or M's model with 4-byte headers for the 8-byte mode vertex assignments). Section 1-1-2's header is an offset from the beginning of Section 1-3, and Section 1-1-4's header is an offset from the end of the previous run of 8-byte mode vertices in Section 1-3. In other words, each 16-byte mode vertex assignment header seems to report the length of the previous 8-byte mode run in Section 1-3. Why the 8-byte mode data requires no such offset, I haven't a clue.

I'm really hoping that the model data from offset 0x20 ~ 0x40 is simply a Section 1 header, since it seems to report the starts of Section 1-2, Section 1-3, and Section 1-4, as we found waaay long ago. Could the unknown data be some kind of "footer" to the 16-byte mode vertex assignments?

In any case, time to figure out what this unknown data does...

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on May 10, 2008, 06:42:22 pm
First results in. Zeroing out the entire range 0x28C ~ 0x2AC freezes the game, so we know that it's way important.

Here's what happens when I change the four-byte value starting at address 0x290 from 24 00 80 01 to 24 00 80 00:
(http://img525.imageshack.us/img525/9633/addy290changedl9.png) (http://imageshack.us)

The result is eerily similar to wiping out "...all the data at the beginning of Section 1-2, offsets 0x0358 ~ 0x0FB8."
http://www.chronocompendium.com/Forums/index.php/topic,4770.msg84651.html#msg84651

Thus, this piece of unknown data may be somehow responsible for completing the process by which texture pieces are mapped to the polygons. Maybe.

Quick link to our wiki for viewer's convenience.
http://www.chronocompendium.com/Term/Character_Battle_Models.html#Example_1:_Serge
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on May 10, 2008, 08:49:34 pm
Alrighty, it appears that all the unknown data affects Section 1-2's relationship to the model. Here's some test results for perusal.

Changed four bytes @ 0x29C from 60 0C 00 00 to 60 0D 00 00:
(http://img206.imageshack.us/img206/8531/addy29cchangenq8.th.png) (http://img206.imageshack.us/my.php?image=addy29cchangenq8.png)

Changed four bytes @ 0x2A0 from 38 26 00 00 to 38 27 00 00:
(http://img301.imageshack.us/img301/5508/addy2a0changegs8.th.png) (http://img301.imageshack.us/my.php?image=addy2a0changegs8.png)

Changed four bytes @ 0x2A8 from 6C 4D 00 00 to 6C 5E 00 00:
...and there was no discernable effect on the model. Perhaps the polygons affected are too small to be seen easily.

Changed four bytes @ 0x348 from 24 00 0C 00 to 24 00 0E 00:
(http://img301.imageshack.us/img301/8250/addy348changezr5.th.png) (http://img301.imageshack.us/my.php?image=addy348changezr5.png)

Changed four bytes @ 0x350 and four bytes at 0x354 from 2C 00 20 00 90 00 00 00 to 2C 00 22 00 A0 00 00 00:
(http://img206.imageshack.us/img206/46/addies350354changeww7.th.png) (http://img206.imageshack.us/my.php?image=addies350354changeww7.png)

My guess is that they're pointers, but perhaps it's best to wait until we take an in-depth look at Guile's model so that we have something to compare these unknown data to. Once I've got all known sections of Serge wiki-fied, I'll analyze Guile, locate differences in structure from Serge's, and bring those up here for collective analysis.


EDIT: Luminaire, I said earlier I'd let you know about another theory of joint rotation that M posted about earlier. He gave us a link to "Gimbal lock" joint information here: http://www.chronocompendium.com/Forums/index.php/topic,4770.msg87978.html#msg87978
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on May 11, 2008, 11:43:01 am
Fourth post in a row. I'm such a poor role model. :P

I know we've been over Section 2 ad infinitum, but wanted to make sure I've got the joint articulation format right, and to bring up the XYZ rotation order issue again.

A map of Serge's Section 2 is attached to the post. The format I have might be described as:


PB PB PB PB XR XR ZR ZR - YR YR XC XC ZC ZC YC YC
CB CB CB CB

Where...
 PB = "Parent Bone" index.
 XR = X rotation
 ZR = Z rotation
 YR = Y rotation
 XC = X coordinate in 3D space relative to last joint
 ZC = Z coordinate in 3D space relative to last joint
 YC = Y coordinate in 3D space relative to last joint
 CB = "Child Bone" index.


Is this an accurate way of describing the format? I changed my earlier notation so that both rotation and 3D coordinate order are commensurate with the debug mode X-Z-Y rotation order. I'm hoping 3D coordinate specifications follow the same order for simplicity.

Also, just so I understand how the joints, bone lengths, and rotations are interrelated, is this an accurate portrayal?
(http://img156.imageshack.us/img156/900/bonescv6.png)

According to this model, Section 2 gives each joint a relation to a parent bone and a child bone. A particular joint's X-Z-Y coordinates are given relative to its counterpart on the parent bone I guess, and bone length would be the displacement between X1Z1Y1 and X0Z0Y0. Presumably the vertices for a specific bone are assigned to that bone's originating joint in Section 1-1. Maybe? Before I wikify this, I want to make sure it's accurate to everyone else's current understanding.
 

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on May 11, 2008, 12:28:42 pm
My understanding is that it's closer to this:

PJ PJ PJ PJ XR XR YR YR - ZR ZR XC XC YC YC ZC ZC
BI BI BI BI

Where...
 PJ = Index of parent joint (-1 if no parent)
 XR = X rotation (range: -4096 to 4095, where 4096 = 360 degrees)
 YR = Y rotation (range: -4096 to 4095, where 4096 = 360 degrees)
 ZR = Z rotation (range: -4096 to 4095, where 4096 = 360 degrees)
 XC = X coordinate in 3D space relative to parent joint
 YC = Y coordinate in 3D space relative to parent joint
 ZC = Z coordinate in 3D space relative to parent joint
 BI = Current bone index (-1 if current joint and parent joint do not form a bone)

Of course, I don't have that part of my import script working 100% yet, so the above should be taken with at least two grains of salt.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on May 12, 2008, 12:13:55 am
Awesome, I've put your model in the wiki for now Luminaire. That explains the FF FF values we see on occasion; I hadn't a clue what those meant before.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on May 12, 2008, 11:59:44 pm
General Theory of Chrono Cross Model Data

If everyone agrees, this will be carved into the Grand Obelisk of Chrono knowledge.

The Character Battle Model format consists of the following, in order:


MODEL HEADER
*Section 1
  Section 1 Header
   "Constructs"
    UV Map
    Vertex Pool
    VDDM (Vestigial Data that Doesn't Matter)
*Section 2 (Skeleton)
  Skeletal Units
*Section 3 (Yet Uknown; affects model shading and placement on the battlefield)
*Section 4 (Animations)
*Section 5 (Uknown)


MODEL HEADER:

#S #S #S #S S1 S1 S1 S1 - S2 S2 S2 S2 S3 S3 S3 S3
S4 S4 S4 S4 S5 S5 S5 S5 - S6 S6 S6 S6 EF EF EF EF
  Where...
  #S = Number of Sections in the model.
  S1 = Starting Offset of Section 1.
  S2 = Starting Offset of Section 2.
  S3 = Starting Offset of Section 3.
  S4 = Starting Offset of Section 4.
  S5 = Starting Offset of Section 5.
  S6 = Starting Offset of Section 6 (usually set to zero, making it de facto nonexistent).
  EF = End of File address.


Section 1
Section 1 is composed of a number of units I'll call "Constructs" for lack of a better term at the moment. Each "Construct" apparently ties together parts of the model's UV Map, Vertex Pool, the VDDM, and the skeleton defined in Section 2.

Section 1 Header:

#C #C #C #C C1 C1 C1 C1 - C2 C2 C2 C2 ... ?? ?? ?? ?? ?? ?? ?? ??
  Where...
  #C = Number of Constructs
  C1 = Starting Offset of the First Construct, relative to the beginning of Section 1.
  C2 = Starting Offset of the Second Construct, relative to the beginning of Section 1.
  ... = More starting offsets of additional Constructs, relative to the beginning of Section 1.
  ?? = There are four bytes of data that may be a checksum, followed by an additional four bytes
       of unknown purpose.


Construct Format:
Each construct consists of a Header followed by 8-byte mode vertex assignments, 16-byte mode vertex assignments, and a UV Footer.

Construct Header...

UM UM UM UM VP VP VP VP - VD VD VD VD
 Where...
 UM = Offset into the UV Map, relative to the beginning of Section 1;
      start grabbing texture pieces here.
 VP = Offset into the Vertex Pool, relative to the beginning of Section 1;
      start grabbing vertices here.
 VD = Offset into unknown Vestigial Data that can be zero'd out
      with absolutely no effect on the model.

8-byte mode vertex assignment header format: #A #A #A #A VO VO VO VO
8-byte mode vertex assignment format: NV NV JJ JJ
   Where...
    #A = Number of assignments that follow.
    VO = Offset into the Vertex Pool, relative to the VP offset given in the Construct Header.
    NV = Next NV Vertices are assigned to JJ JJ.
    JJ =Index of the joint to which the body of vertices is assigned.

16-byte mode vertex assignment header format: #A #A #A #A PP PP PP PP
16-byte mode vertex assigment format: NV NV 00 00 J1 J1 W1 W1 J2 J2 W2 W2
   Where...
    #A: Number of assignments that follow.
    NV: Next NV Vertices are assigned to J1 J1 and J2 J2.
    VO = Offset into the Vertex Pool, relative to the VP offset given in the Construct Header.
    J1: Index of the first joint to which the body of vertices is assigned.
    W1: Weight of the association between NV and J1 for animation purposes.
    J2: Index of the second joint to which the body of vertices is assigned.
    W2: Weight of the association between NV and J2 for animation purposes.

UV Footer: This tells the game engine where to look in the UV Map
     for the triangles and quads assigned to each construct.
#E #E #E #E TQ TQ ## ## UO UO UO UO...
  Where...
  #E = Number of 8-byte entries.
  TQ = First two bytes in the 8-byte entry. If it's set to 0x24, the next bytes refer to
        triangles; if set to 0x2C, the next bytes refer to quads.
  ## = Number of quads or triangles assigned to the Construct.
  UO = UV Map offset from which to start pulling the triangles or quads.
          Relative to the UM offset given in the construct header.
  ... = More TQ, ##, and UO information for each additional entry.



Section 2
Section 2 sets the model's skeletal orientation.

Section 2 Header

NB NB NB NB
  Where NB = Number of Bones


Bone format...

PJ PJ PJ PJ XR XR YR YR - ZR ZR XC XC YC YC ZC ZC
BI BI BI BI
 Where...
 PJ = Index of parent joint (0xFFFF, or -1 if this bone has no parent joint)
 XR = X rotation (range: 0XF000 ~ 0xFFF, or -4096 to 4095, where 4096 = 360 degrees)
 YR = Y rotation (range: 0XF000 ~ 0xFFF, or -4096 to 4095, where 4096 = 360 degrees)
 ZR = Z rotation (range: 0XF000 ~ 0xFFF, or -4096 to 4095, where 4096 = 360 degrees)
 XC = X coordinate in 3D space relative to parent joint
 YC = Y coordinate in 3D space relative to parent joint
 ZC = Z coordinate in 3D space relative to parent joint
 BI = Current bone index (0xFFFF, or -1 if current joint and parent joint do not form a bone)


Below are Serge & Guile's constructs mapped out for everyone's perusal. You can check Serge's Construct Map against the information we have in the wiki (http://www.chronocompendium.com/Term/Character_Battle_Models.html#Example_1:_Serge), and I'm going to map out all of Guile's UV Map & Vertex Pool based on his Construct info. If it works out, we'll have confirmed the model. Luminaire, hopefully this will help you fine-tune your model importer so that it can recreate all models properly. I think most of the problems would have originated from Section 1-1 (the "Constructs"), but the number of Constructs determine how many switchovers occur in the UV Map (from triangles to quads and vice versa) and the Vertex Pool (from 8-byte mode to 16-byte mode and vice versa), so I guess any problems encountered there would carry over into the results for Sections 1-2 and 1-3.

Color codes in the attached maps...
Regular text: Section 1 header
Grey background: Construct Header
Boxed, white background: 8-byte and 16-byte mode vertex assignment headers.
Yellow-Plum-Lime-Turquoise-Tan-etc. backgrounds: Vertex Assignments.
Red background: Construct Footer.

Serge's "Constructs"
(http://img171.imageshack.us/img171/2593/sergesection11mapxu4.th.png) (http://img171.imageshack.us/my.php?image=sergesection11mapxu4.png)

Guile's "Constructs"
(http://img329.imageshack.us/img329/4922/guilesection11mapgg1.th.png) (http://img329.imageshack.us/my.php?image=guilesection11mapgg1.png)


EDIT: Oh! I may have joints and bones mixed up in my model of Construct vertex assignments. Someone let me know if those should be bone indices and not joint indices.

EDIT: Also, I forgot to fit in our findings regarding the UV Map and Vertex Pool data formats, but they're still in the wiki as we described them months ago.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Akari on May 13, 2008, 01:15:34 pm
By the way, there is not such thing as bone at this stage. All bones was left during exporting model to native game format. Only matrix and their hierarchy left. They may be similar, but not exactly, please remember that.

Maybe "BI = Current bone index (0xFFFF, or -1 if current joint and parent joint do not form a bone)" is index to model part influenced by transformation matrix?

And  - 0xFFF not 4096, but 1 in 12 bit fixed point. It used in transformation packet in GTE.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on May 13, 2008, 08:21:41 pm
Luminaire, does Akari's info help things out any with interpreting Section 2 for model viewing purposes?

In other news, the General Theory works for all of Section 1 of Guile's model data, though once again I'm confuzzled as to what the indices mean exactly in Section 2 and as well as what order the rotations are supposed to be in. Attached to this post is a zip file with Excel spreadsheets mapping out Guile's model data as far as we can at this point.

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on May 13, 2008, 09:06:22 pm
I had reached the same conclusion about the Section 2 data in the last few weeks I think.

Hopefully I'll have some time to add the new knowledge to my script soon. I don't really expect it to improve the results I'm seeing with the current version, as I think it's the Section 2 data that really needs a second look.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on May 13, 2008, 11:36:56 pm
Luminaire and others, let me know if there's any tests I could run to confirm theories on any part of Section 2. Though I think my previous experiments just confused the hell outta me with regard to the rotation orders.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on May 13, 2008, 11:57:54 pm
One thing you might try is zeroing out all of the Section 2 rotation data and seeing what happens. (Hopefully that doesn't result in crashing the game.)
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on May 14, 2008, 02:25:28 pm
Serge's Extreme Yoga Workout continues!

(http://img396.imageshack.us/img396/6366/image1bx4.th.gif) (http://img396.imageshack.us/my.php?image=image1bx4.gif)

All the animations from Section 4(?) still act properly on the bones, but Serge is just a bit discombobulated. I'll work on getting some screencaps from choice angles so you can see the effects better.

EDIT: Perhaps we could get a nice static pose if I erased all the data in Section 4 (which I *assume* contains all the animations). Then we could test out the bone angles one at a time to see the rotation order.

EDIT: Here's a collage with more views of what happens when the bone angles in Section 2 are zero'd out.
(http://img379.imageshack.us/img379/1571/image1xp3.th.gif) (http://img379.imageshack.us/my.php?image=image1xp3.gif)

I need to do a bit of careful teasing to eliminate Section 4 animation data, because the game freezes if any headers are zero'd out there.  :oops:
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on May 14, 2008, 04:30:04 pm
NOW we're getting somewhere. I can get the standing animation eliminated for the most part, but interestingly, I only partially eliminated said animation and a few frames still seem to work.

This is with all the bone rotations eliminated as well, so no rotations and no animation frames applied in this pic:
(http://img396.imageshack.us/img396/2429/image1xb4.th.gif) (http://img396.imageshack.us/my.php?image=image1xb4.gif)

What will be eminently useful, perhaps, is if I get a standing-still Serge for you. It should essentially show exactly what your import script should produce!  :lee:

UBER EDIT FTW!
Here's Serge with no animation frames applied. However, note that I suspect Serge's weapon arm still has part of an animation applied, because that's the exact position his arm is in when he gets into battle stance once the un-eliminated frames of his standing animation play. I wonder about his non-weapon arm as well, so I'll go back and shave off as much animation data as I can without getting the model totally screwed up.


(http://img396.imageshack.us/img396/9039/image1mr5.th.gif) (http://img396.imageshack.us/my.php?image=image1mr5.gif)

(http://img396.imageshack.us/img396/4426/image2ie3.th.gif) (http://img396.imageshack.us/my.php?image=image2ie3.gif)

Next up will be Guile and Kid, because they each have special extensions -- Guile's long sleeves and Kid's hair braid.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on May 14, 2008, 05:22:37 pm
Excellent.

Are you still zeroing out the rotation data in Section 2? If not, I wouldn't mind seeing a screenshot of that with no animations applied. If the result looks like what my script produces when I ignore those Section 2 rotations, then I will know that I am on the right track.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on May 14, 2008, 05:37:31 pm
Zero'd bone rotations and no animations are the top pics in my post above, but I'm going to try that one again. Turns out I managed to shave off a little more animation so that Serge now looks pretty much exactly like what your script produces, though I can't tell from the angles I was able to get whether Serge's legs are really supposed to be "pitched forward" a bit or not. Working with the animation data is tricky, because the animation not only has a header that (perhaps) specifies the number of frames, but also affects the model's location on the battlefield or something -- eliminate too much data and Serge disappears underground (or so I believe currently).

For now, here's a shot of what Serge looks like with the maximum possible animation data removed:
(http://img396.imageshack.us/img396/1383/image3cm4.th.gif) (http://img396.imageshack.us/my.php?image=image3cm4.gif)
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on May 14, 2008, 09:43:58 pm
In the meantime, I think I've fixed some of the problems with the models. Click attachments and enjoy.


[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on May 14, 2008, 09:53:37 pm
AWWW YEAH! :D  Almost there -- just a few kinks in Guile's model. I didn't do any experiments with Glenn, but it looks like he's pretty much good to go. Here are my experimental results:

Discombobulated Serge: No rotations, no animation applied...
(http://img520.imageshack.us/img520/1971/sergediscombobib1.th.gif) (http://img520.imageshack.us/my.php?image=sergediscombobib1.gif)

Standing Kid: Rotations on, animation off...
(http://img520.imageshack.us/img520/7564/kidnoanimpj9.th.gif) (http://img520.imageshack.us/my.php?image=kidnoanimpj9.gif)

Discombobulated Kid: No rotations, no animation applied...
(http://img183.imageshack.us/img183/147/kiddiscombobpy8.th.gif) (http://img183.imageshack.us/my.php?image=kiddiscombobpy8.gif)

Standing Guile: Rotations on, animation off...
(http://img520.imageshack.us/img520/9021/magilnoanimbf6.th.gif) (http://img520.imageshack.us/my.php?image=magilnoanimbf6.gif)

Discombobulated Guile: No rotations, no animation applied...
(http://img519.imageshack.us/img519/797/magildiscombobbz1.th.gif) (http://img519.imageshack.us/my.php?image=magildiscombobbz1.gif)


EDIT: Shoot, I just now saw that we're still having the "leg syndrome" with both Guile and Glenn. Lemme take a look at Glenn's character model data, and if he's got the same number of Constructs in what we've been calling Section 1-1, I'd say that it has something to do with the number of switchovers between 8-byte and 16-byte mode vertices and triangles & quads as specified in those Constructs. I'll also get a closeup of Guile where you can see his feet, just to make 100% sure that the lack of Section 4 animation data isn't causing the problem.

EDIT: Here's a long view of Guile's legs, just for kicks.
(http://img501.imageshack.us/img501/6695/guilelongbw7.gif)
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on May 15, 2008, 12:19:47 am
 :mrgreen: It works! :mrgreen:

This is a HUGE milestone, because every battle model file that I have renders perfectly. That means Serge, Kid, Guile, Glenn, Dark Serge, Ozzie, Flea, and Slash. For now I've only provided Guile and Glenn as evidence.

There's a small bit of work to do with the UV data yet, but my script confirms that the structures of Sections 1 and 2 as we've listed them are accurate. I've attached version 0.3.0 of my script for archival.

BTW, the rotation order is XYZ after all.

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on May 15, 2008, 10:27:59 am
I AM SHEDDING TEARS OF UTTER JOY.

THREE CHEERS FOR LUMINAIRE85! BREAK OUT THE FIREWORK BUBBLY!
(http://img115.imageshack.us/img115/6721/image1ng3.th.jpg) (http://img115.imageshack.us/my.php?image=image1ng3.jpg)


THE PASSION OF YOUTH! WE HAZ IT!
(http://img115.imageshack.us/img115/8290/adventchildreniiihz3.th.jpg) (http://img115.imageshack.us/my.php?image=adventchildreniiihz3.jpg)
NO OBSTACLE IS TOO GREAT WHEN YOU'RE IN THE SPRINGTIME OF YOUTH.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: cornettheory on May 15, 2008, 12:39:01 pm
Hello, I am joining this forum because of this thread and specifically the post above.  I was literally playing through Chrono Cross and was thinking to myself that it's about time I try to break open the CDs and rip the models from the game.  I had wanted to convert them for HLDM years ago. And sure enough a google search comes up with someone currently doing the thing that I wanted.  neat! Talk about a technological singularity...

Anyway, my question is, do you plan on making available all of the models from the game in a format like ase or dxf so that anyone can use them?  Whichever format stores the UV, textures, and mesh data that is universal. 

Also I have a request, please rip the mini fire dragon model, this is the only one out of them all I want, and I really think he should have been a player character.  Thanks guys for doing this research, you rock.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on May 15, 2008, 12:55:54 pm
Welcome to the Compendium!

cornettheory, the export script will be made available at the very least, and ripping the files from one's own game discs is very easy. Whether the Compendium will host the character models in the format Luminaire's script produces will be up to Ramsus and ZeaLitY.

Do you have experience in writing model conversion scripts, cornettheory? If so, there's plenty more to be done. Would you like your Fire Dragon now or would you rather wait until we've got all its animations figured out?  :P

Speaking of which, Luminaire, is it possible to import animations into Blender via Python scripts? I've found the animations fairly easy to work with thus far, so perhaps we can figure them out relatively quickly...maybe. I'm really hoping that they're not compressed, since none of the other model data seems to be, but we'll see.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on May 15, 2008, 01:29:44 pm
Blender can handle animations (although I am largely unfamiliar with that aspect, so there would be some learning there), so in principle I don't see why we couldn't do animations.

I expect that the final results of this endeavor will be a set of .blend files (Blender's native format), one for each model, plus screenshot images for the encyclopedia. I could probably provide a few other 3D file formats if desired. Since Blender is free, anyone who wants will be able to download it and the .blend files and use them as they see fit. (The screenshots I've been posting really don't compare to seeing the models in glorious 3D.)

Once the importer is working 100% I will write another script to batch convert all of the model files to whatever 3D file formats we decide on. These scripts will also be freely available.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on May 15, 2008, 01:52:34 pm
Suh-weeet! We need a Grimmjow pic over here...

After I get the General Theory of Sections 1 and 2 wikified properly, I'll take a look at the animations in Section 4. Section 3 remains mysterious for the moment, but since it's short we should be able to figure it out eventually. In any case, it doesn't impact the viewability of exported models.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Boo the Gentleman Caller on May 15, 2008, 02:46:55 pm
Congrats all you hardworking data-teers (like musketeers, but with data instead of muskets)!
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on May 15, 2008, 02:55:29 pm
(http://img507.imageshack.us/img507/7066/datateersvr6.png)
One for all, and all for one!
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: ZeaLitY on May 15, 2008, 04:02:01 pm
Yeah. I could have never imagined today would be THE day. I can also imagine what the encyclopedia will be like now with these definitive images, like the ones Luminaire is producing; we'll make one for every single model in the game. They'll replace those horrible Ultimania scans with the real thing and downloads for the models, perhaps with animations included once that's cracked.

(http://chronofan.com/Zeality/gjlj2.png)

Nothing can stand in the way of willful dreaming and the springtime of youth. If the circumstances forbid success, you make your own circumstances. Believing in yourself is the power to change fate.  Know it, instinctively.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: BROJ on May 16, 2008, 12:11:50 am
Just stopping in to give my congrats--this is truly wonderful(in *all* senses of the word) work that has been done lately... this means we can do a 'true' Magus(geometry, poses, and the like), right?!  :D

BTW ZeaLity--no truer words of wisdom have been bestowed.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on May 16, 2008, 12:33:15 am
We can *export* models from Chrono Cross now, but *importing* is another question entirely -- or is it? I imagine a separate script would be needed to take a model through reverse conversion from .blend file format to Chrono Cross format. Luminaire, how difficult would that be to do? I'm going to give myself a crash course in Python over the summer, but I imagine I won't reach the level of expertise necessary for this sort of thing for awhile. Unless it's just a matter of literally switching lines of code around?

In any case, it'll take a bit to figure out exactly how Chrono Cross animations work.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on May 16, 2008, 12:45:39 am
I was wondering if anyone was going to mention the possibility of an exporter. I don't think it would be too hard to do, although there is the matter of fully determining what the unknown data represents. It would certainly be a separate script from the importer, and unfortunately not quite as simple as switching lines of code around.

But yes, definitely finish the importer first.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: x_XTacTX_x on May 18, 2008, 09:09:58 pm
Just popping in to congratuate everyone in the thread for the amazing work! Truly, you guys are like geniuses. There are no words that can describe how happy I am to have volunteered for a position ina project this will so greatly affect!

YOUTH POWER, HOOOOOOO!!!!!!
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on May 18, 2008, 10:21:42 pm
Thanks Tact!

Luminaire, after looking at the Glenn model I wonder if the problem isn't with your script, but with the texture itself. Seems like his bangs, at least, might not have a proper 0,0,0 RGB color scheme, causing black to show instead of transparency. Would it be possible to try a .GIF file or some other format that supports transparencies for the texture? Not sure if that'll help his bandanna ties though.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on May 18, 2008, 11:19:28 pm
That is only one of the UV issues I was referring to. For examples of some of the others, see the attached images. There seem to be four underlying issues, possibly related:

(1) Model files such as Serge's that have black space at the bottom of the corresponding texture have UV data that extend  into the black space. That's what is causing the black spots near Serge's wrists.

(2) Some of the UV coordinates appear to be off by one pixel. This is what causes the line down Serge's back and Flea's face.

(3) Once in a while I find a face with UV coordinates applied to the wrong vertices. This has the effect of making the texture of that face appear rotated from what it ought to be.

(4) Blender is unable to handle transparency in texture data. This is what causes the black in Glenn's bangs.

Not sure yet how to fix these things.

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on May 19, 2008, 01:03:48 am
That is only one of the UV issues I was referring to. For examples of some of the others, see the attached images. There seem to be four underlying issues, possibly related:

(1) Model files such as Serge's that have black space at the bottom of the corresponding texture have UV data that extend  into the black space. That's what is causing the black spots near Serge's wrists.

(2) Some of the UV coordinates appear to be off by one pixel. This is what causes the line down Serge's back and Flea's face.
These two are probably caused by the same thing; try adjusting UV coordinates by a half-pixel.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Dark Serge on May 19, 2008, 04:16:58 am
OH WOW this looks awesome!!! I can't wait to see the model for Lynx and Dark Serge!
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: halkun on May 19, 2008, 04:28:31 am
The Transparency thing in Blender is a known issue. The 3d modeler does not understand "transparent" unless it is a transparent material. (Not a UV map). Blender was designed as a 3d movie renderer that used materials to describe surfaces. UV mapping is not "complete" by game standards.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on May 19, 2008, 12:22:14 pm
Could a skilled modeler theoretically "cut out" the black stuff somehow? That's a tedious solution, but hopefully not too many models are in Glenn's situation.

Dark Serge, you can find Dark Serge here, though the model will probably look a tiny bit different once it's run through Luminaire's improved import script:
http://www.chronocompendium.com/Forums/index.php/topic,5163.msg90513.html#msg90513
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: syntax error on May 19, 2008, 01:48:36 pm
Perhaps someone could make a intermediate seperate version of the python script
that does remove the black parts.For now this is OK.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: halkun on May 20, 2008, 02:09:58 am
Perhaps someone could make a intermediate seperate version of the python script
that does remove the black parts.For now this is OK.

The problem is that "the black parts" are part of the model. In a PS1, the black zones are understood as being transparent, and in blender, it doesn't understand that UV maps can have transparent data. You can't "cut out" the black parts. All blender knows is "Make a triangle here" and "cover with this texture". It can't "look" at a texture and figure out what needs to be "cut". Blender can't "cut" things. It only make or remove triangles that are already there.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Unaisis on May 20, 2008, 02:30:18 am
Wow, amazing work @.@ brings a tear to my eye to see these simple yet marvelous models being uncovered from one of my most cherished games ^.^. Did anyone find the Dwarfs yet? :O those guys are my most favorite characters XD. they look like rotten peas with thimbles as helmets XD 
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Ozzie on May 20, 2008, 07:46:50 am
..or that "is it Johnny" thing that captivated everyone for awhile. Was it a polygon model of Johnny lying in the road, or part of the background? Perhaps unused models lying around in the game?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: secondrate on May 20, 2008, 08:24:20 am
Perhaps someone could make a intermediate seperate version of the python script
that does remove the black parts.For now this is OK.

The problem is that "the black parts" are part of the model. In a PS1, the black zones are understood as being transparent, and in blender, it doesn't understand that UV maps can have transparent data. You can't "cut out" the black parts. All blender knows is "Make a triangle here" and "cover with this texture". It can't "look" at a texture and figure out what needs to be "cut". Blender can't "cut" things. It only make or remove triangles that are already there.

So, you can't go back, and edit those portions into code "00", like back on page 12?
By the way- very well done! Reading this whole thread, was like trying to make sense of hieroglyphs...so to me, it was like magic! :?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on May 20, 2008, 12:40:39 pm
Shoot. Only thing I can think of is to "fake" the proper texture effect by replacing the black parts of Glenn's bangs with the very skin texture they're hanging over. But that would look ridiculous from certain angles, I imagine.

Unaisis, we've got all enemy battle models, including the dwarves. There's going to have to be some effort at sorting and labeling them, but it might be best to wait until we examine animations, so we can get the full packages, so to speak.

Ozzie, I *think* Johnny was part of the background, but now I'm unsure. At best it would be a field model (and not a battle model), but from what I've seen so far the formats are identical, it's just that the field models have less data and vertices and so forth.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: ZeaLitY on May 20, 2008, 01:14:48 pm
It's a model. A sure way to tell is to compare how it looks to the NPCs in Guldove who help you use those...rope thingies to get around. They look horribly simple and ugly, but Johnny looks very crisp lying on the road.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: halkun on May 20, 2008, 01:36:47 pm
Perhaps someone could make a intermediate seperate version of the python script
that does remove the black parts.For now this is OK.

The problem is that "the black parts" are part of the model. In a PS1, the black zones are understood as being transparent, and in blender, it doesn't understand that UV maps can have transparent data. You can't "cut out" the black parts. All blender knows is "Make a triangle here" and "cover with this texture". It can't "look" at a texture and figure out what needs to be "cut". Blender can't "cut" things. It only make or remove triangles that are already there.

So, you can't go back, and edit those portions into code "00", like back on page 12?
By the way- very well done! Reading this whole thread, was like trying to make sense of hieroglyphs...so to me, it was like magic! :?

Already been done.
 "00" == black color in blender.
 "00" == transparent color in a PS1.
Blender does not understand transparent UV maps. 
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Unaisis on May 20, 2008, 02:29:41 pm
After fiddling around with blender ::First time using:: i managed to export it in a format that i could use in the 3d program i have ::Cinema 4d:: in that program i was able to make an alpha for glens hair. although i doubt cinema 4d will be able to run animations originally from the game, or help you guys out in any way  T.T ....

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: justin3009 on May 20, 2008, 03:15:06 pm
O___O!  That look's so cool!
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Ozzie on May 20, 2008, 03:29:00 pm
I agree, it looks awesome, the models look excellent when in use, you can really see what a great job they did when creating them.

Also... I find it amusing that the first time human Glenn wonders out of Chrono Cross he winds up in extreme peril.  :lol:
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Unaisis on May 20, 2008, 03:36:04 pm
indeed, excellent produce from excellent workmanship ^.^.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: secondrate on May 20, 2008, 05:30:00 pm
Already been done.
 "00" == black color in blender.
 "00" == transparent color in a PS1.
Blender does not understand transparent UV maps. 

Sorry for making you repeat yourself...

I had another thought: I wonder...can a fourth UV coordinate be made, to transform the triangles into quads, and then overlay that coordinate to the 2nd UV coordinate?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on May 20, 2008, 06:14:29 pm
I may not be understanding the problem correctly, but I was under the impression that the major difficulty here is that the model uses a solid square or something for Glenn's bangs instead of modeling the hair pieces separately, to save on vertex space. Normally the black parts pasted over that polygon would be rendered transparent by the game engine, but Blender is incapable of transparencies. So extra polygons would have to be added, and then the UV coordinates would have to be changed such that they trace out the hair and apply them to the additional polygons.

Unaisis, what did you do exactly with Glenn's model (i.e., I don't know what it means to "add an alpha" :D)? If it's possible to re-export to Blender, the Compendium could archive the altered model.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Unaisis on May 21, 2008, 02:23:00 am
Well... an alpha in cinema 4d is just the same picture but in black and white ::white being the visible part and black as the  invisible part:: cinema 4d has an option for this @.@.

below is the alpha picture

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: jono on May 21, 2008, 07:17:21 am
I'd just like to ask a couple of questions about the current knowledge of the model file format. I'm slowly getting through the guide however some parts are bothering me.

In section 1 I'm having a little trouble understanding the following:

Code: [Select]
16-byte mode vertex assignment header format: #A #A #A #A PP PP PP PP
16-byte mode vertex assigment format: NV NV 00 00 J1 J1 W1 W1 J2 J2 W2 W2
   Where...
   #A: Number of assignments that follow.
   NV: Next NV Vertices are assigned to J1 J1 and J2 J2.
   VO = Offset into the Vertex Pool, relative to the VP offset given in the Construct Header.
   J1: Index of the first joint to which the body of vertices is assigned.
   W1: Weight of the association between NV and J1 for animation purposes.
   J2: Index of the second joint to which the body of vertices is assigned.
   W2: Weight of the association between NV and J2 for animation purposes.

Is PP simply the offset into the vertex pool? In other words, is PP equivilent to VO.
Also in the 16-byte assignments are the two zeroed bytes in the assignment format just zeroed bytes (packing to keep to the four byte allignment), or do they contain values and the '00' are a symbol that isn't defined here?

I only ask about the '00' being used as a symbol because lower in the document I believe it is.

If I understand correctly perhaps the VO should be changed to PP (or vise-versa) and maybe the VO and NV definitions could be swapped to better represent the order of the actual bytes. Also maybe the two zeroed bytes (if thats what they are) should have a note just to clarify that they are zeroed bytes or otherwise.

Sorry to nit-pick, you guys have done a fantastic job with all this, just looking for a little clarification :).

Cheers, Jono.

EDIT:

Also I was wondering where the '**' byte is in the vertex pool information. I understand its purpose but don't understand which byte is the direction reversal byte. I think I'm missing something, any explination would be much appreciated.

Code: [Select]
"8-byte mode" setup...
   ZZ ZZ YY YY XX XX 00 00 - ZZ ZZ YY YY XX XX 01 00
   ZZ ZZ YY YY XX XX 02 00 - ZZ ZZ YY YY XX XX 03 00
  "16-byte mode" setup...
   ZZ ZZ YY YY XX XX 00 00 - ZZ ZZ YY YY XX XX 00 00
   ZZ ZZ YY YY XX XX 01 00 - ZZ ZZ YY YY XX XX 01 00
    Where...
    ZZ: Magnitude of coordinate on the up & down axis on the screen plane
    YY: Magnitude of coordinate on depth axis; toward or away from you with respect to the
        screen.
    XX: Magnitude of coordinate on right & left axis on the screen plane
    **: A directional reverser byte. If 00, the vertex is placed in one direction on the axis,
        and if FF, the vertex gets placed on a coordinate the same "magnitude" but opposite 
        direction on that axis. (In actuality, it merely specifies whether the value is
        positive or negative in hex).
 00 00: The vertex index; two bytes per vertex.

Thanks again for all you hard work guys!
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on May 21, 2008, 11:45:56 am
Thanks for the astute observations, jono! Those were my wikification flubs, and have now been corrected.

1.) PP PP should be VO VO, just as you stated.
2.) The 00 bytes in the 16-byte mode vertex assignments are, indeed, just buffers.
3.) Oopsie, I did away with the directional reverser byte concept altogether when MDenham informed me that the 3D axis magnitude values include two bytes, and when it reads something like ?? FF or ?? FE, the magnitude is simply negative because it's a negative hex value.

Take a look at it again when you get a chance and make sure that all your points are now addressed.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: jono on May 22, 2008, 04:50:50 am
Quote
when it reads something like ?? FF or ?? FE, the magnitude is simply negative because it's a negative hex value

So I should read the x,y and z co-ordinates of the vertex as signed 16 bit numbers rather than as unsigned magnitudes with seperate information for direction. In other words the direction (-ve or +ve) of a vertex co-ordinate is given by the first bit of the second byte for that co-ordinate. Correct me if I miss understand :)

Sounds good, thanks for clearing that up, I'm still playing catch up with all that you guys have done and every bit of help is appreciated. 
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on May 22, 2008, 05:00:47 am
Quote
when it reads something like ?? FF or ?? FE, the magnitude is simply negative because it's a negative hex value

So I should read the x,y and z co-ordinates of the vertex as signed 16 bit numbers rather than as unsigned magnitudes with seperate information for direction. In other words the direction (-ve or +ve) of a vertex co-ordinate is given by the first bit of the second byte for that co-ordinate. Correct me if I miss understand :)
Well, correctly, they're not just a signed 16-bit number; they're a signed fixed-point (4.12, I believe) number.

Not like it matters a whole lot, but it's good to keep in mind (especially as rotations are in the same format - "1.0" = a full rotation).
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: jono on May 22, 2008, 06:45:47 am
Ahh, ok, I thought they would be fixed point but had wondered how they would be split. Signed 4.12 fixed point numbers, thanks mate.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on May 22, 2008, 03:00:42 pm
Alrighty, I'd better get the signed fixed-point info in the wiki. I'll have some reading to do here (http://en.wikipedia.org/wiki/Fixed-point_arithmetic) first. What's the significance of the number 4.12 with respect to the 3D coordinates, guys?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: halkun on May 22, 2008, 10:09:09 pm
Alrighty, I'd better get the signed fixed-point info in the wiki. I'll have some reading to do here (http://en.wikipedia.org/wiki/Fixed-point_arithmetic) first. What's the significance of the number 4.12 with respect to the 3D coordinates, guys?

The PSX had a 3D coprocessor called the Geometry Transformation Engine, or GTE. This device did various 3D maths (Dot products, matrix transformations, vector math, etc, etc) much faster than the normal CPU. The GTE used fixed point 16-bit numbers. the first 4 bits are the whole number part and the second 12 bits were the decimal part. (4.12) This means that when you loaded the GTE with number to preform math on, it had to be in 4.12 format.

Oops here a little vocabulary.

Fixed-point is a kind of format that computers use to express decimals. Computer, by themselves, are quite terrible at decimal math, so this is a way for them to "understand" what a decimal is. "Fixed point" means that the decimal does not move, and the whole/factional parts are "stuck" at a particular accuracy. With computers, fixed point math is really quick, but is prone to rounding errors. (That's why you see "warped" textures on the PSX sometimes... That and there is an actual bug in the GTE that Sony never fixed. On the other hand, if Sony fixed it, it would of screwed up all the games before it was fixed). The opposite of fixed point is "floating point"

Floating point is a number where the decimal point can float all around the number so the system is not limited to a particular whole/factional split all the time. The problem is floating point is *MUCH* slower and *much* more complex and expensive to implement in a computer. The PSX can not do hardware-based floating point math, and is stuck using a 4.12 format when it needs to do anything with a decimal quickly.

Does that make sense?

 
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on May 22, 2008, 10:13:30 pm
Crystal clear. Thanks as always!  :D
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Unaisis on May 23, 2008, 09:14:39 pm
I was just fooling around with some of these models @.@

they can look rather well detailed when put into the right lighting

http://ca.youtube.com/watch?v=tAfOxpVQNxw


as for the data exploration, i managed to get the dumping thing to work @.@ but as for decompressing the .out files to be importable to blender.... i must have missed how to do it while trying to read 30 some pages of forums @.@. i downloaded all attachments in this topic... now I'm just confused as to which one does the magic @.@. ... Dwarfs... i wan... I NEED Dwarfs @.@! lol



 i'm all about the dwarfs ; ; i even tried to make my own about 2-3 years ago XD
 
|
|
v


[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on May 23, 2008, 09:33:23 pm
No decompression necessary with the .OUT files, it's just a matter of choosing the correct ones. You see, there's battle textures, battle models, and weapon packs (which include weapon models and textures). Give me a little while and you'll have your dwarves. It's about time we go through and ID everything.

BTW, I just now saw your Gato model on Youtube, and it's godly. Nice job!

Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Unaisis on May 23, 2008, 11:03:09 pm
i see i see! there is so much other data in there that a % of me picking the right file is... low lol. I managed to find a few interesting stuff like the dragons and the big version of Starky @.@ Fargos parret and a porre soldier .... no dwarf... ; ;

Thank you! i like my gato model ^.^ its one of my favorites XD :)
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on May 24, 2008, 12:56:37 am
Ohhhh, sh*t: Luminaire, I'm looking through the enemy models, and I never reported earlier that enemy model textures can be as small as 128x128 pixels, and now I've got a Mama Komodo on my hands that uses two separate textures of 128x252 pixels each. Will this be a problem?  :mrgreen:

Ah, wait! In the Mama Komodo's case, the dual textures are stored one right after the other in the exact same file; it creates a 256x252 pixel grid when they're placed side-by-side, and since one byte can cover the maximum coordinate in either direction, maybe we'll be okay. I'm attaching the Mama Komodo texture and model now, and crossing my fingers...




[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Unaisis on May 24, 2008, 03:25:38 am
Yes!!! i found my Dwarf!! and his tank ::File 3383:: O.o... imma play with this for awhile :3. YAY!!!! oh... and i have another question XD. are the battle textures for playable characters encrypted? or are they somewhere among the vasts amount of pictures  i found from psicture? O.o i have most of the textures for monsters and such... its just that i dont know where to look for playable characters like Zoah ... XD


http://ca.youtube.com/watch?v=jlAxnL4o48Q
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: ZeaLitY on May 24, 2008, 03:51:26 am
IIRC the battle textures don't have the classic TIM header, so PSicture and TIMViewer don't pick them up. I've dutifully kept the ZIP FaustWolf made in my Compendium "OUT" folder (like, stuff that needs to get published when the time is right), and so I'll attach it here.

http://chronofan.com/Zeality/MainCharBattleTex.zip
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on May 24, 2008, 11:38:35 am
ZeaLitY is most correct about the battle textures not having the Classic TIM header. In fact, there's inconsistencies even within this "Altered TIM" format that Cross uses for battle textures. For example, the very large textures for giant enemies like Mama Komodo and the Dragons (even Ketchop, which surprised me) begin with the bytes 03 00 00 00, whereas most Altered TIMs start with 02 00 00 00; I think it's a reflection of the number of CLUTs or something. This could throw off a file scanning program.

Unaisis, that video is just godly. Compendiumites will shyte themselves when they see that on the next front page update. I know I did.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Unaisis on May 24, 2008, 10:31:11 pm
Thanks ZeaLity, Thanks FaustWolf ^.^ !!!!~


I've managed to get the tank in working order :D now i need to think of something to do with it XD. Many Thanks For helping me grab hold of my Wish for the Dwarf Hi-Ho Tank!!!! ~~~~~~~~~~~ EEEEEEEEEEEEEEEEEEEEEEE

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on May 24, 2008, 11:31:29 pm
Whoa, awesome. Since the Hi-Ho Tank was a "large" 256x252 texture, Luminaire's Blender import script works for all models!! :lee:

Did you find the other dwarves yet? OUTs 3332, 3335, and 3338 are the models, and the OUT directly preceding each is the accompanying texture.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Unaisis on May 25, 2008, 12:20:45 am
Sweet! thanks!!! :O

I am currently processing your request and i SHOULD have it read by tomorrow morning ^.^


Thanks again!!!
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on May 25, 2008, 12:47:35 am
Awesome, huge thanks for doing that!

On another note, I'm worried about transparencies that occur with models like MegaStarky and JellyBlubba. The texture for MegaStarky (and I assume little Starky)'s helmet, for example, is solid blue, but there's an alpha channel involved to make the helmet partially transparent. My guess is Blender isn't going to be able to do partial transparencies either. :? I've attached MegaStarky's model and texture in case anyone would like to test.

EDIT: Ah, hell, why not just try the Time Devourer and see what happens with the transparent crystal effect around Schala?

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Vehek on May 25, 2008, 01:13:02 am
I think you can see how it worked out when I tried it...
I don't really know how to use Blender though.

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on May 25, 2008, 01:47:42 am
Shoot, that's exactly what I expected, thanks Vehek. Such a shame -- maybe Unaisis can get the partial transparencies in his modeling program when he gets some spare time?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Unaisis on May 25, 2008, 03:06:16 am
i fiddles around with starky and i got his helmet under a different ::but the same:: texture and set it to have a 50% transparency. this is what i got :O

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on May 25, 2008, 10:53:56 am
Utter perfection! Unaisis, what formats can Cinema 4D export to? Anyone know if there's any format Blender can import that would retain the transparencies?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Unaisis on May 25, 2008, 01:37:10 pm
uhhh cinema exports:

.3ds
.obj
.fbx
.w3d
.wrl
.uzr
.3dm
.x
.dxf
.xml


but I'm not sure if it will export the way it has the textures setup @.@. Exporting could actually mess up the UV coordinates or the transparency may not work as it does in cinema 4d @.@



EDIT

Umm i tried to fiddle around with the TD and... .. it does not look like the textures line up D:



[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Cyberman on May 25, 2008, 02:15:10 pm
I believe the real situation is that blender doesn't support transparencies AND there is no way to automatically export transparent textures and or transparent materials no?

As halkun said how the Playstation treats transparent textures is very important. There is BLACK and transparent BLACK for example.  Additionally there are 4 different alpha modes the PS1 uses. I am very surprised blender won't accept transparent textures, for numerous affects those are very handy. :D

Cyb
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on May 25, 2008, 02:25:13 pm
Yeah, the script is in python, and there's just one that everyone's using, only Unaisis is re-exporting to Cinema 4D. I think?

Thanks for trying out the Time Devourer Unaisis. I did a bad texture rip obviously -- it's a bit difficult to determine how the game is "viewing" any given texture. Before I do a re-rip of that, would you mind attaching a .PNG of the Hi-Ho Tank texture you used, since that worked flawlessly?

EDIT: Actually, here's a revised Time Devourer texture. This is the only other way I think the game could possibly interpret it:

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on May 25, 2008, 02:47:33 pm
Well, it looks like Blender's renderer can handle some of the transparency anyway. See attached image.

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on May 25, 2008, 02:57:07 pm
Man, if it could just do that in 3D view somehow. This might help ZeaLitY get the views he needs for the encyclopedia at least, though since Glenn's nose is a bit off-color, there might need to be some cutting and pasting of screencaps. Unless we could feed the transparent models (shouldn't be that many, maybe 10 or so that I know of right now) to Unaisis, and ZeaLitY could use screencaps of the models processed in Cinema 4D.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on May 25, 2008, 03:11:15 pm
The reason that Glenn's nose is off-color is because the renderer uses lighting information to produce the image. If I were to actually set up appropriate lighting rather than the arbitrary single lamp I used, Glenn's nose would be properly colored.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Unaisis on May 25, 2008, 03:25:35 pm
hmmm i tried the new texture for the TD, but... errrr its still kinda messy :/ i figured that it was a big model and i got lucky with the Hi-Ho Tank BUT lol i got the Sky Dragon to work as well @,@



Also about glens nose, i noticed when i import the models into Cinema 4d. all the polygons are not conencted to each other which gives it a Rigged look to it. so i optimize it ::Connect all points and polygons together:: which gives it a smooth surface





[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on May 25, 2008, 03:36:01 pm
A continuation of my earlier post: If I turn off all shadowing in the Blender renderer, I get the attached image.


[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on May 25, 2008, 03:38:52 pm
VERY nice Glenn. Alright, then, the rendering process solves ZeaLitY's encyclopedia needs anyway.

Darn it, that Time Devourer texture is going to drive me insane! Unaisis, how, exactly, are you applying your big model textures? Did your Sky Dragon texture look like the one attached? Thanks again for testing.

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Unaisis on May 25, 2008, 04:54:56 pm
The Sky Dragon had two seperate textures as did the Hi-Hi Tank. altered the UV maps a bit to allow both textures appear in their right place.


EDIT!!!!!!!!!!!


I SEE THE PROBLEM!!!!! Hold on imma do somthing!



EDIT


I DID IT!!! :D the first texture were two pictures stuck together, i split them apart and reworked the UV maps and poof! ^.^







[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on May 25, 2008, 06:35:01 pm
Thanks again. Awesome job with the Time Devourer.

Question is, how the FARK does the game engine apply both textures to one model? I thought originally that the model data would use a 256x252 pixel matrix with the UV map, but that assumption was apparently amiss. How exactly are you inputting these into Blender, Unaisis? And how does the model data know where to put which pieces? Iz confuzzled.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Unaisis on May 25, 2008, 06:59:37 pm
Well.. i find the 3d data in the MISC folder, import it into blender, then export into Cinema 4d. i then find the Texture by using PSX Multi Converter [trial Version ._.] textures for big models are two different textures when ripped from there. When the model is in Cinema 4d, i just apply the texture to the model and its all ready to go ::Except where i have to apply the two different textures to their selected piece of mesh::
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on May 25, 2008, 07:32:35 pm
So you're applying the texture manually in the big model cases, Unaisis? I'd like to get a full understanding of how the textures are applied by the game engine, so further investigation into the Time Devourer's UV map is warranted.

halkun and Cyb, any idea if Final Fantasy 8 or Final Fantasy 9 used double textures like this? I still think the game engine would have to look at both textures simultaneously and use a 256x256 matrix for the UV map coordinates, but then again I'm inexperienced in this regard. Could there be some mechanism for switching which texture is "looked at" as the UV coordinates are fed into the GPU?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: halkun on May 25, 2008, 08:14:16 pm
Yup, The PSX video memory is split into different texture zones, (Texture caches), you select which cache to "view" by using a GPU command.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on May 25, 2008, 10:25:18 pm
Would those GPU commands be the "texture pages" you refer to in the PSX doc, halkun? And would we find those commands in the models themselves, theoretically?

And Unaisis, you wrote earlier that you used PSXMultiConverter to gather the textures for the Sky Dragon and Hi-Ho Tank. Do you know if the program gave you textures from the 3055 ~ 3687 range of OUT files? Or were the source textures from OUTs of lower numbers? If PSXMultiConverter can detect what I've been calling the Altered Format TIMs (ones undetectable by PSicture and TIMViewer), life will be a bit easier from here on out.

EDIT: Actually, I think I'm looking at the same textures you are right now. Could you report the STR#### you found your big model textures in, Unaisis? I assume you ran PSX Multi Converter directly on the game CD?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: ZeaLitY on May 25, 2008, 10:25:46 pm
FUCK, THAT IS A SEXY TIME DEVOURER PICTURE! Unaisis, can you take a screenshot like that with no shadowing, and saved in PNG format? And showing the whole model, since a little is cut off at the top. I'll try to rush out an update tonight or tomorrow and that will be the headliner along with the Glenn shot. ePSXe 1.7.0 was also just released, so that needs an update too. Also, FaustWolf, if you get a chance, PM me with short status updates on the remaining problems with Blender / problems with anything else. I'll follow the thread after that point in case some of these problems are fixed before the update (wow, that battle texture issue is amazing).

Don't worry; when the time comes, we'll definitely figure out a system for making standardized screenshots of the models, so it won't be like "hey
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Unaisis on May 25, 2008, 10:35:58 pm
What PSXMultiConverter does is just examines a cd and sees if there is any readable data in it. by using the whole cd, i could'nt tell where textures came from. so i just got .out files 3055-3687 and burned them onto a cd. i then put it through PSXMultiConverter and all it came up with were 250~ pics or so of weapon textures. i cant tell which files they were from tho. it just lists them as STR0001 to STR0330. ::Some files are unreadable::


to ZeaLitY, Thanks XD and will do! i've added a picture ^.^  pm me if you want another angle

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on May 25, 2008, 11:27:18 pm
Yeah, that pic looks delish. Hugacious thanks again for checking everything out, Unaisis. If PSXMultiConverter just found weapon textures, that's perfectly normal; the weapon textures are all in "Classic TIM" format, which is much more easily detectable. The weapon textures you're seeing are actually stored in every third OUT file, which seem to be packs of weapon models with up to 6 or seven textures/weapons per "pack." So OUT 3057 is Serge's weapon pack, OUT 3060 is Kid's, etc.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: cornettheory on May 26, 2008, 09:59:08 pm
I'm having issues extracting the data from my disc.  I'm getting "coundn't read block 12" and stuff.  The disc is clean, and the game plays fine, so is it a software thing?


Welp, I got it working... aces!

If no one has done yet, I think I'll compile a list of what each file is.
Guess not!
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on May 27, 2008, 12:17:26 am
I've got all the battle model files identified in the Chrono Cross data wiki (http://www.chronocompendium.com/Term/MISC_%3D_3054-3707_Misc.html). Also, I've attached a file list from the Terminus Traductions Tools (an alternate dumper, but uses the same numbering scheme as the Ramsus/Yazoo dumper I think). It's accurate, but there are a number of blanks where nobody's identified file types yet. I'm not really sure what would be the best way to do that either.

EDIT: I'm also attaching a version of the dump file with some of my English scribblings on it, which clarify some of the French descriptions. Some of my notes regarding potential pointer locations are misleading though; I've since dropped my search for pointer tables to techs and models in Chrono Cross, convinced that they are actually in the battle and fieldscripts, and possibly compressed. First thing's first though -- gotta get the model animation format figured out.

Also, note that some battle models are only present on the second game CD, and thus we still lack FATE, the various element-ators (Aquator, Terrator, etc), and those floating mask enemies that appear in the Sea of Eden.

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on May 27, 2008, 02:04:41 am
Okay, this bit of news will be worth a bump. Luminaire or someone else who can run Blender, try these textures for Serge and Flea and see if all the texture problems go away. Turns out I've been doing bad rips all along in TileMolester, because I was not byte shifting far enough, which prevented me from capturing the bottom few rows of pixels for each texture.  :oops:

If anyone wants a specific model, you can look it up in the Chrono Cross data wiki. The models are linked from the list of Yazoo's output folders, specifically MISC/OUTs 3055 ~ 3707. I will start a separate thread specifically for TileMolester training to get proper texture rips from the appropriate OUT files; I've just frittered away an entire non-work day by ripping ALL the enemy textures incorrectly, and will be unable to return to that task due to other pressing issues like figuring out model animations. Hopefully some others interested in hacking processes will be able to complete the task once I whip up a tutorial. D'oh!

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: cornettheory on May 27, 2008, 02:23:15 am
I would also like to kindly request someone who knows blender to post a link to the latest script, and directions on getting it going in blender.   Once I figured out how to import, I tried the large fire dragon, and the poor guy is jumbled still.

for me, whenever I try to use what I think is the latest script, I just get a "blender script error please see console"

Blender's interface is so alien to me I just wasn't selecting filenames. it was letting me import nothing!  hence the python script error about "out of range" in the console.  :|

anyway, now to try your textures because I'm up.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Unaisis on May 27, 2008, 02:35:59 am
may i Re-request the Time Devourer's texture? ^.^ i think Schala's mouth was cut out a bit on the last Texture @.@


Also. how does one use tilemolester O.o.. trying to get son-of-a-gun's texture but no luck on ripping it from 3406 out file with TIMviewer or psicture D: ::Psxmulticonverter has too many textures to look thru -.-;::
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: ZeaLitY on May 27, 2008, 02:50:59 am
Ahhh, damn, I'm on pins and needles! Good luck cornettheory!

(http://img151.imageshack.us/img151/7391/largeanimepaperscansblels5.jpg)
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on May 27, 2008, 02:54:28 am
The revised Time Devourer texture is attached.

I'm going to get a full TileMolester tutorial going tomorrow evening (so there'll be a day's wait, unfortunately). I'll have to feed interested parties a few textures at a time, because they MUST have some "buffer" data added to them to get 100% proper rips in a user-friendly manner. That means I've gotta run 'em all through a hex editor and add a few thousand bytes to the end of each. Square didn't make this easy.

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: cornettheory on May 27, 2008, 03:07:28 am
this ought to make you happy


however I'm now sure that I have the older script.  and flea's texture might still be off by one row because there is still a small line on her face

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: jono on May 27, 2008, 03:09:43 am
Well that would definitly explain the textures being misaligned, I was thinking it was a precision issue in the import script causing the tex-coords to be slightly off. Fantastic stuff FaustWolf.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Unaisis on May 27, 2008, 03:25:16 am
Wewt! Now this looks better :D

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on May 27, 2008, 11:37:19 am
Excellent. Cornetttheory, what were the dimensions of the texture you used for Flea? I originally attached one that was 128x255, then realized I could squeeze yet ANOTHER row of pixels out of it, and re-attached a 128x256 version. That's the one that's currently attached to my previous post.

Looks like the Time Devourer's solved, anyway.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Unaisis on May 27, 2008, 11:58:22 am
i kinda noticed something was amiss with the last texture. Schala had a unibrow, small mouth and almost no nose XD. this texture is perfect ^______^
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: cornettheory on May 27, 2008, 03:49:10 pm
I think part of the problem with people's blender renders, is that blender, by default, uses interpolation and mip maps on the textures.  But the textures in the game aren't interpolated.  so the very edge of flea's face texture is by a black row.  I turned off interpolation and I got a better result this time, but I still think the problem is with the mesh at this point.

It also is a possibility that knowing the limitations of PSX hardware, the original developers left the UV right on the edge like this just because they knew you can't see it in game.

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: cornettheory on May 27, 2008, 04:08:37 pm
Good news!

The small fire dragon can scratch his back with his feet!

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on May 27, 2008, 04:38:53 pm
cornettheory, you will have much better luck if you use the latest version of my script, which I have attached. Per your suggestion it turns off mipmapping and interpolation, plus takes the necessary steps to enable transparency in rendering.

A suggestion for future texture rips: save them as PNGs rather than bitmaps, since PNGs can handle transparency. Also for this context PNG will usually be smaller than BMP with no loss in quality.


[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on May 27, 2008, 05:12:52 pm
The 128x256 Flea rip is correct as far as I can tell. Luckily Flea's field battle model texture is identical to the battle model texture but in Classic TIM format, and thus detectable by PSicture and other programs. I mapped some of the UV triangles indicated in the battle model data over the field texture, and the triangles look good:
http://img142.imageshack.us/img142/4442/fleatestjt7.png

The field texture is attached, but it should be identical to the 128x256 texture I ripped last night. Hopefully any outstanding problems with the texture can be chalked away to the interpolation issue...

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: cornettheory on May 27, 2008, 08:21:09 pm
script works, now for those pesky textures...

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: cornettheory on May 27, 2008, 09:28:31 pm
Here are some things I noticed with flea at this point...

yea, the texture wasn't dumped with alpha so just ignore that

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on May 27, 2008, 11:08:21 pm
Hmm, the Flea result is starkly different from what Luminaire produced on May 18:
http://www.chronocompendium.com/Forums/index.php/topic,4770.msg96541.html#msg96541

That looked fine with the exception of the face line. Wonder what happened?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on May 27, 2008, 11:27:49 pm
What happened is Blender's render mode uses a few different settings than Blender's working mode (as it would be far too slow to do otherwise). At the moment this leaves a bit of a catch-22: either get the transparency right or get the overlapping faces right.

See attached for an example of what I mean. The box on the right Flea is a render preview; otherwise the two are identical.

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Unaisis on May 28, 2008, 01:06:14 am
i get the same problem too when they are imported to Cinema 4d, but i instinctively fixed the problem by manually moving the polygons and points @.@.... soo many models turn up like this XD i'm used to it. ::Models mostly from Square E-nix::
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on May 28, 2008, 04:48:43 am
After looking through the Blender manual, it looks like what's happening is, for whatever reason, the automatic normal-flipping process isn't being applied to models generated with the script.

See here (http://wiki.blender.org/index.php/Tutorials/Textures/Map_Input_Techniques), and look at the "Single sided faces (backface culling)" section - the "No V. Normal Flip" setting mentioned here might be on when it shouldn't be.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: tushantin on May 28, 2008, 10:17:27 am
Whoa, looks cool!! xD I wanna try ripping the models and using em! Although I've simply used Metsequoia and Animation:Master (I don't know em properly though) and just started using blender. Dunno how I can help you guys.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on May 28, 2008, 12:55:02 pm
Phew, well, guess we could use render mode for transparency issues and normal 3D viewing mode for most other models, for the time being at least. BTW, I see that I can set palette transparencies on my end with the .PNG files just like a .GIF. Luminaire, would it help any if I set all RGB = 0,0,0 colors to be totally transparent? Given what halkun said earlier, I'm not sure if it would make a difference.

tushantin, if you have a PC capable of handling Blender, you're already ahead of the game as far as I'm concerned. Even if you can just load up models with Luminaire's script and take screencaps, it's better than I can do right now -- I think my ATI Express graphics card chokes on the program, and when I fiddle with the graphics card settings, my PC tends to crash randomly.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: tushantin on May 29, 2008, 12:29:11 pm
tushantin, if you have a PC capable of handling Blender, you're already ahead of the game as far as I'm concerned. Even if you can just load up models with Luminaire's script and take screencaps, it's better than I can do right now -- I think my ATI Express graphics card chokes on the program, and when I fiddle with the graphics card settings, my PC tends to crash randomly.
Well I use Blender at my workspace normally, but I assume it works at home as well.  :lol:And besides, just this June I reckon I'll be buying a PC with 4GB DDR 2 RAM and GeForce 8800 GTS! So how do I do what I need to do?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on May 29, 2008, 01:33:16 pm
tushantin, you will need to download the latest version of my Blender import script, which is attached to a recent post of mine in this thread. The instructions for using the script are contained in the comments at the top of the file. Basically it's (1) install Blender, (2) put script in appropriate directory, and (3) use script from within Blender. If anything is not clear, let me know so I can elaborate in future versions of the script.

You will also need the battle model data and textures, of course. I only know a little bit about that, so I won't elaborate.

FaustWolf, I would go ahead and set all of the (0,0,0) black to transparent in the texture files if it's convenient to do. This is necessary for the Blender renderer to process the transparency.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on May 31, 2008, 05:35:04 pm
Time for some bumpage. Vehek, Unaisis and I discovered what appears to be a texture stretching issue with the import script. When, say, a 128x128 texture gets fed through the importer, it seems to get stretched to a 128x256 texture. See the results in the following posts:
http://www.chronocompendium.com/Forums/index.php/topic,5177.msg97464.html#msg97464
http://www.chronocompendium.com/Forums/index.php/topic,5454.msg97502.html#msg97502

Does your script currently assume a 128x256 texture Luminaire, and if so, is it plausible that it would stretch 128x128 textures to 128x256 textures as a side effect? Could this be changed easily? On the bright side, the script loads the 3D data of field models perfectly.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on May 31, 2008, 11:00:30 pm
My script currently assumes 256x128. This could certainly be changed; it would be easy if the only options are 128x128 and 256x128, or at least if the textures are always powers of 2.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on May 31, 2008, 11:22:28 pm
Something that can work with textures that have dimensions of powers of 2 would be safest. Though the vast majority are either 128x128 or 128x256, Alphabat has a texture that's 64x128 pixels, width x height. You know what? In light of the texture size issue, I'd better take a look at the UV data of a large enemy, just to make sure that they don't use one whole 256x256 texture after all somehow. I'll report on that later.

EDIT: Well, it does not appear that 256x256 textures are an option; somewhere along the line there must be a texture page switch command like the one halkun mentioned. So the largest the script should have to deal with at a time is 128 x 256, width x height.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: tushantin on June 01, 2008, 03:19:41 am
Okay, I'll download the script and install it now. One thing though. Where will I get the model files from? Or can I simply extract it from CD/ISO? If so, how/which?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on June 01, 2008, 12:34:04 pm
tushantin, I would guide you to the Ramsus/Yazoo dumper attached to the very first post of this thread. I just re-upped it with a readme, so hopefully you can use it to rip the models from your first game CD; if you run into problems, PM me and we can discuss.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: cornettheory on June 01, 2008, 02:22:56 pm
Ive figured out the issue with the big fire dragon.  The UVs are just layered over one another.  So somehow the model exporter needs to tell half of the model to use a different material.

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on June 01, 2008, 05:39:41 pm
Excellent, my guess is some of the unknown data might be a texture page command. I'll have to investigate this further.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Ozzie on June 03, 2008, 08:24:44 am
Starky renders so nicely in Bryce and 3ds max. I can imagine some of the neat wallpapers that will come of these.



[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on June 03, 2008, 10:47:30 am
Thanks Ozzie! Once we get everything figured out (including animations, preferably), we'll need a ton of renders for the Compendium encyclopedia.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Cyberman on June 03, 2008, 07:33:58 pm
Ok silly question time:
The script is in python, has it changed any since list 'utilized'?

I figure I can make it export to POV's format, that should create a very nice rendered output.

Cyb
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on June 05, 2008, 04:31:27 pm
Looks like there may need to be at least one more iteration of the model importing script Cyb, because we need to factor in the method by which the game engine is applying double textures to large enemies. So far I haven't found anything in the constructs; I suspect that the info is in fact in the UV Map area of the large models, and the way in which they specify the texture page isn't pretty. In any case, I'll have a report on that if I prove my current hypothesis to be plausible through experimentation.

Here's some info from Captain A, an experienced Blender user, that I wanted to forward to you all:

Quote
OK, to use transparency textures in blender you need either a grayscale texture that defines transparency or a texture with a alpha channel. assuming chrono cross uses something like pureblack = transparent or r=0,g=255,b=0 makes transparent, you might need to edit the textures in gimp before you can get the models in blender.
my advice would be using gimp's "select by color tool" set the threshold at 0 to select the color that is meant to be transparent. use this selection to make a new texture that has all the transparent areas black and the other ares white.

to put this texture into blender, goto the materials button and, on the far right there should be a column of buttons. they kind of work like layers in photoshop or gimp, except the top one is first to be applied and the bottom one is last. the default material has a texture called "tex" on the top button. click it. if you already have a texture on that slot you can move it down by first pressing the button that looks like a cursor pointing to a wall. then press the  lower slot and press the button of the cursor pointing away from the wall. this will copy the texture down to the 2nd slot.

now clear the first slot and "add new". goto the "map input" tab and select "UV". this will tell blender to apply the texture to the uv map of the model. now goto the "map input" tab. this tab's buttons tell blender how the texture will effect the model.
unselect the "col" button and select the "alpha" button.

to the right of the material preview, there should be a panel that in the middle says "render pipeline". under it are the buttons "halo" and "ztransp". make sure that the "ztransp" is pressed. this allows the material to have video game style transparency.

now on the top of the buttons window, press the button that looks like a cheetah skin. these are the "texture buttons". select the top texture and select the "texture type" to be "image". in the "image" panel press "load". now browse for the transparency map you made before.


And that should do it! Hope I make sense to you guys. if you have any questions go ahead and post them in this thread.

as for the uv map being off by a few pixels, can you tell me where did you get this uvmap? IE: did you make it yourself or did it come from the model export?

EDIT: there is a new version of blender, I suggest you guys download it .

EDIT2: I see that you are also having problems with transparent objects being in the 3d window. to make transparent objects transparent in the window goto the "object" button. it looks like a 3d axis. then in the draw panel, press the "transp" button.


The gimp stuff I should be able to do in my oldie-but-goodie Paint Shop Pro, so everyone let me know if this process looks like it could solve some problems. Interesting that there's a new version of Blender out -- anyone try it out yet? Maybe it has better capabilities than what we've been using so far?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Cyberman on June 05, 2008, 08:07:01 pm
The main advantage of POV is that it is a well documented format and easy to tweak and examine how the output looks etc.

As for the double textures, is that 2 128x256 16 bit textures or 2 128x256 8 bit textures?

For POV I would need to use TARGA fomat images likely (RGBA output) or some other easy to use format like that.
POV can use index files perhaps using PNG with a palette that has transparency added will work.

Stephen
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on June 05, 2008, 08:53:39 pm
The double textures are two 128x256 8bpp linear image bit-depth, but 15bpp BGR palette depth.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Satoh on June 14, 2008, 07:32:02 pm
First let me say, I'm new to the whole hex exploring, but I think I've found something regarding stats or something in the weapon packs...

starting at 2790 (in serge's weapons) there's a set of data that has a repeating pattern... it repeats 7 times, once for each weapon in Serge's list it looks like... now, some places are filled with 0 that others have a number, typically only one or two entries have a 00 byte at either the beginning or end that the others don't. I assume this is for things like special effects that weapons as individuals have, but other weapons of the same type(swallow) don't have. then again, it could be something as simple as a naming convention.... but there's 7 similarly structured entries in an even spacing from eachother, it may be worthwhile to look at it....

but like I said, it may just be the ramblings of someone completely inexperienced... I'm going to check other packs for similar data...

EDIT: this data pattern is present in the 3rd section of both Serge and Kid's weapons, about 15 lines from the beginning of the section.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on June 14, 2008, 07:58:32 pm
Excellent, you've found a stride of some sort. I shall take a look at it after I finish with some texture experimenting. To keep this thread as linear as possible Satoh, you may want to start another thread labeled CC Weapons Investigation or something. Then that thread and this can run in tandem without getting stats and visuals mixed together.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on June 21, 2008, 01:03:50 am
Alrighty, not sure how everyone's going to like this but we have what appears to be a working model for how texture pages are decided in the dual-textured models. Let's take a look at two quads from Dario's UV map. Although Dario is a human-size character, his model has enough detail to require two textures.

Quad Example 1:
000011D0                                    - 5B F3 57 F3 5C F1 57 F1
000011E0  F0 04 00 05 F8 01 18 02       

Quad Example 2:         
000011F0                                      - 36 EB 2F F5 2E E3 28 EC
00001200  81 12 21 13 88 09 D8 09       

The difference between these two quads is that the first, which has vertex index pointers with run-of-the-mill values, is mapped to the LEFT texture, whereas the second, which has 1s instead of 0s at the end of the first two vertex pointers, is mapped to the RIGHT texture.

Thus, an extra rule for quads:

If the first two vertex pointers end in a "1" instead of a "0" nybble, then the texture piece is pulled from the RIGHT texture.
If the first two vertex pointers end in a "0" instead of a "1" nybble, then the texture piece is pulled from the LEFT texture.

Luckily I've not seen any situation in which either of the first two vertex pointers ends in an "8" nybble, or we'd be in trouble.


The rule is the exact same for triangles, but keep in mind that there's a switcharoo in which the last two vertex index pointers go first and the first goes third. Thus, we tell the difference between a LEFT triangle piece and a RIGHT triangle piece as follows:

Triangle Example 1:
000006E0  15 23 11 0D 19 11 E0 03-E1 15 D1 07       

Triangle Example 2:
000006F0                           - 47 1E 39 1B 39 21 50 06
00000700  40 09 40 0C   

So the game engine reads the first two pointers first, then the third, or at least that's how I think of it. Thus, the top triangle is mapped from the RIGHT texture, and the bottom triangle is mapped from the LEFT texture.

Consequently, we should not see any "8" nybbles in the second and third vertex pointer slots of triangle pieces. I have never seen a "9" nybble where an "8" nybble should be, so I'm hoping the modeling program the developers used was careful where it placed its vertex indices.

I'm a bit miffed that a texture page indicator would be stuffed into vertex pointers, but it's an accurate indicator of which texture the game engine is looking at when it pulls UV pieces based on manual UV mapping exercises. Halkun, Cyb, and M, does this seem plausible? Luminaire, is this something that can be factored into the Blender script?
     
Also Luminaire, Satoh and I have been keeping an eye on the dimensions of the weapon, field model, and battle model textures we've been coming across. It appears that powers of two is the way to go. The weapon textures, for example, have dimensions of 32 x 128 if I remember Satoh's reports on those correctly.

Attached is an Excel spreadsheet that segregates Dario's UV map into triangle and quad sections based on the constructs and Dario's model data in the zip. The first texture attached is his LEFT texture, and the second texture attached is his RIGHT texture in case anyone wants to rummage through the data and see how this works firsthand.

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: cornettheory on June 21, 2008, 02:26:27 am
fantastic.  the dynamo of reverse engineering continues toward the horizon.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on June 21, 2008, 03:11:16 am
I'm a bit miffed that a texture page indicator would be stuffed into vertex pointers, but it's an accurate indicator of which texture the game engine is looking at when it pulls UV pieces based on manual UV mapping exercises. Halkun, Cyb, and M, does this seem plausible?
Makes enough sense to me, and I can understand why they did it that way (might as well use those unused bits for something, after all...).

The question then comes up, though, of "is there anything with more than two textures?" (referring specifically to battle models), as this system should support up to eight textures per model...
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Satoh on June 21, 2008, 04:04:56 am
A note about weapon textures, I never gave a number, as I never found evidence to the dimensione in the hex(I'm still learning structure) But textures as viewed through PSicture are 128x85 which is decidedly not your typical power of 2 texture... and they are 4bit. Also, to be clear, it is one texture per weapon.

All of this has more than likely been previously noted by some.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on June 21, 2008, 04:18:50 am
A note about weapon textures, I never gave a number, as I never found evidence to the dimensione in the hex(I'm still learning structure) But textures as viewed through PSicture are 128x85 which is decidedly not your typical power of 2 texture... and they are 4bit. Also, to be clear, it is one texture per weapon.

All of this has more than likely been previously noted by some.
Yeah, the original figure I was getting was 32x85 - which, unfortunately, is the result of something not being worded right in the description of how things work.  (There's eight bytes that run, for example, 80 01 00 01 20 00 55 00 - in Serge's weapon pack, the first time is at 0x00080 - which makes it look like it's 32x85.  Unfortunately, the "32" is the number of words per line, not the number of pixels...)

Since the texture data is enough to be 128x85, this would have made it seem like there were four textures per weapon.

(BTW, 85 isn't that odd of a dimension - it's 1/3 of 255 - but agreed on the "not your typical power of 2" obviously.)
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on June 21, 2008, 10:23:08 am
Aaack, that's what I get for trying to report things by memory. Yeah, the weapon textures are 128x85 pixels. It wouldn't be too much work to go through an add the necessary black space to make them 128x128 pixels though. I've been doing that with the 128x128s to "force" them into the 128x256s that the Blender script currently expects, and it works. So if powers of two saves you some major work Luminaire, I can accomodate manually as I gather textures. With the exception of the swallows and the weird weapons, lots are repeated among characters as it is, with just the weapon trails different.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on June 29, 2008, 10:30:37 am
I'm a bit miffed that a texture page indicator would be stuffed into vertex pointers, but it's an accurate indicator of which texture the game engine is looking at when it pulls UV pieces based on manual UV mapping exercises. Halkun, Cyb, and M, does this seem plausible? Luminaire, is this something that can be factored into the Blender script?

Now that you've identified how to tell how many textures go with each model and how to tell which vertices go with each texture, I should be able to someday (when I'm not so freaking busy with my current internship) program it into the script.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on June 29, 2008, 11:09:30 am
Suh-weet. Take your time, I've got a Chrono Trigger graphic insertion tutorial to write in the meantime, and we can also get animations figured out.

MDenham has already determined the entire header structure for animations and I've largely confirmed his findings with a tweak or two. The first frame of animations will be fairly easy to figure out I think, as the length of the first animation frame is dependent on number of bones. The succeeding frames will be a bit more difficult though. I'll post examples and Youtube videos by next weekend hopefully.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Boo the Gentleman Caller on June 29, 2008, 11:23:32 pm
Hey FaustWolf, do you think you could cook up some simple tutorials?  You're gonna need some help as far as programming, etc. goes, so I'm hoping to start helping soon.  Tutorials would help me get started (instead of learning by trial and error).
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on June 29, 2008, 11:56:19 pm
Boo, if you don't mind choking down some hexadecimal code and digesting it (really all I've been doing) I'd recommend that you first rip your first Chrono Cross CD according to the instructions here. (http://www.chronocompendium.com/Term/Chrono_Cross_File_Structure.html#How_do_I_rip_proper_game_images_from_the_Chrono_Cross_discs.3F) You'll need a 2352 byte/sector format file (commonly referred to as BIN format), but ironically it has to be named CD1.iso to work with the dumping utility here. (http://www.chronocompendium.com/Forums/index.php?action=dlattach;topic=4770.0;attach=3106)

If you're able to get a successful run of dump.exe according to the instructions in the linked .zip file, you'll be in a position to use further file dumping and decompression tools linked here. (http://www.chronocompendium.com/Forums/index.php?action=dlattach;topic=4770.0;attach=3215) The instructions for ripping the appropriate game image and using the dump.exe should be sufficient hopefully, but I'll need to give you more specific instructions on using the additional tools Ramsus compiled from Yazoo's source files. Drop me a PM in case you get stuck anywhere, and I'll convert our back-and-forth into a FAQ for getting started on Chrono Cross file exploration. It's high time I did something like that anyway.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Boo the Gentleman Caller on June 29, 2008, 11:58:12 pm
Crap.  My Chrono Cross game is in Alabama.  I won't be able to get it until next weekend.  But I will certainly get started on this ASAP.  I figure that as this project gets up and going, you're going to need more able hands involved in coding, programming, etc.  Why not have someone helping you who's been there since day one?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Schala Zeal on June 30, 2008, 12:03:47 am
In light of the day's wondrous turn of events, I'm starting a new thread dedicated to our findings regarding the files that the Ramsus/Yazoo dumper has produced. I can't very well recap everything that happened, so if you're reading this for the first time, check out the posts that start here: http://www.chronocompendium.com/Forums/index.php/topic,4729.msg83034.html#msg83034

This thread shall be dedicated to the basic findings that flow out of Ramsus' wonderful work. I've attached a number of files to this thread:

1st: The Ramsus/Yazoo dumper, which is what Zeality, Luminaire85 and I have used successfully to dump ALL of Cross' files. It's a tool originally created by Yazoo of Terminus Traductions that Ramsus modified so that it works more efficiently (and at all, in my case). Beware though, Ramsus will be making continual improvements to this program to make it even better!

2nd: More tools I received from Sephiroth 1311 in Italy. I'm not sure what's in here just yet, but there may be new tools we can use. Remember though, if there are any new tools in here, they haven't been optimized by Ramsus.

3rd: The rest of Yazoo's tools, written in C++ and compiled by Ramsus. The beauty of this is people don't have to compile themselves to check everything out since Ramsus has done that work for us. Inside you'll find all sorts of goodies including decompression utilities. To use them, run from the command line or (in my case, since I suck at command lines) simply drag the pertinent file over the .exe.

Remind me I owe you a megalixir ^_^
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Schala Zeal on June 30, 2008, 12:06:17 am
Crap.  My Chrono Cross game is in Alabama.  I won't be able to get it until next weekend.  But I will certainly get started on this ASAP.  I figure that as this project gets up and going, you're going to need more able hands involved in coding, programming, etc.  Why not have someone helping you who's been there since day one?

The pSX emulator comes with a tool called cdztool. It converts PSX CD ROMs into file images. Not only that but before I got CC on CD myself, I downloaded 2 files, 700 megs each. Each file was a CD image file. It ran slow but then again, it was ePSXe that I used... ick.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on June 30, 2008, 01:58:25 am
Schala Zeal, did you say you were familiar with C/C++?

I've successfully used a compression/decompression utility created by Terminus Traductions on Chrono Cross' LZSS-compressed dialogue files. However, they don't work on the compressed fieldscript, perhaps because the utilities do extra things like make the dialogue game text more readable in addition to the raw compression/decompression. It is my great hope that with some minor modification of the Terminus Traductions LZSS source code, we may end up with a general LZSS compressor/decompressor as opposed to one meant specifically for the dialogue files.

halkun and Cyb, if you're reading this I should report that the Terminus Traductions tools label all LZSS-compressed files in Chrono Cross "FF7V LZS." ...does this mean what I think it does? Could Squaresoft have realistically used the exact same compression routine for two projects separated by two years in terms of release?

Anywho, for all with coding skills who are interested, I'm attaching a sample LSZZ-compressed dialogue file and its uncompressed equivalent. These are labeled 0008.OUT and 0008.txt. Also in the attachment are two non-dialogue LZSS compressed files for comparison named 0003.OUT and 0007.OUT. In a subfolder within the .zip I've attached all the souce code for the Terminus Traductions tools. LZSS.C and LZSS.H are no doubt the most pertinent. Would it be possible to make a general LZSS compressor/decompressor with this code? If any C/C++ coders are willing to take a look at it, I can broach the compression utility topic in its own thread for further discussion and exploration.

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on June 30, 2008, 02:30:25 am
Out of curiosity, did you notice that the dialogue table for the debug room seems to be in there as well? :D

Looks like it's less of a "debug room" and more of a "debug flag"...

--

As far as the tools themselves, I'm looking at converting it to C# (nothing wrong with C++, but I should get a decent amount of experience in on C# for other things) and, incidentally, translating it to English (I know a little French, enough to be able to make out what's being said, but it's still a pain in the neck).

My initial reaction upon looking at their header files: dear God, why?!  Several "standard" includes are in every .h file.  :(  So it's not like the code couldn't stand a bit of tidying to begin with. :D

The C# route does open up another possibility for CC:DBT, though, in the future - a Windows and XB360 version.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on June 30, 2008, 02:38:27 am
Yeah, each dialogue script file contains the entire Debug Mode text as well. Seems oddly redundant to me at first glance, but as with most things in CC, I guess speed was of the essence.

What would the presence of a debug flag as opposed to a debug "room" tell us, M? I'm especially interested in the zoom function that the debug mode makes use of; my guess is the model size for each room is specified by the fieldscript, which is most likely one of the other LZSS-compressed files in each of the game's rooms.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on June 30, 2008, 03:09:23 am
What would the presence of a debug flag as opposed to a debug "room" tell us, M? I'm especially interested in the zoom function that the debug mode makes use of; my guess is the model size for each room is specified by the fieldscript, which is most likely one of the other LZSS-compressed files in each of the game's rooms.
Mostly what it'd tell us is that it's entirely possible to cue up the debug menu in basically any room of our choice.  It'd definitely be interesting to do it in the Developer's Ending; it'd be more than interesting to do it in the Models Saying Their Names room (can't remember the room number for it off the top of my head, but it's the Termina dock, with a bunch of models scattered all over it, and talking to each model gets a four-letter string out of them) because you could theoretically change the sizes of those models as well.

For what it's worth, it looks like rewriting the tools in C# ought to be much more useful, though I may need a small amount of help writing model export/import functionality.  Luminaire, do you have any C# experience, or is it just Python? :D

EDIT: gah, either Babelfish is being lousy, or they used French slang that it doesn't recognize. :D

EDIT #2: Seems like there's no IRC channel for the site that's readily accessible.  For what it's worth, people are welcome on my (hosted on my own home computer, which only goes down when things go wrong!) server if we need to have something a little more real-time than forum posting - konata.echoes-online.com is the server name (yes, I'm a Lucky Star fan) and pretty much any channel name is fair game.  Send a /msg to MDenham if you go on (chances are I'm at work on a weekday, but I'll get to you when I'm back from work).
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on June 30, 2008, 08:31:30 am
For what it's worth, it looks like rewriting the tools in C# ought to be much more useful, though I may need a small amount of help writing model export/import functionality.  Luminaire, do you have any C# experience, or is it just Python? :D

I don't know C#, but I know C++ very well (and Python kinda well now, of course).
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on July 02, 2008, 05:23:18 am
For what it's worth, it looks like rewriting the tools in C# ought to be much more useful, though I may need a small amount of help writing model export/import functionality.  Luminaire, do you have any C# experience, or is it just Python? :D

I don't know C#, but I know C++ very well (and Python kinda well now, of course).
How about French? :lol:

I'm in the process (very slow, for two reasons - one, my abysmal French, and two, their...  uh, peculiar programming practices - seriously, messy globals all over the place, other oddities, written entirely in regular C...) of translating the TT tools to English and C#, and at the rate I'm going at at present, I might have a working version sometime around the end of the year.  :shock:

If you feel up to trying to follow how I write code and/or learning C# (it really isn't that different from C++, aside from a few things that basically produce "safer" code), I'll see about making sure my home SVN server is functional and put the code in there.  (Actually, that goes for anyone - anyone interested in either learning C# and applying it, or who already knows C#, or who knows French and has done some programming before, lemme know.)

Oh, and BTW - once we have this version of the tools written up into a usable state, the next step is to give it an actual user interface, rather than making people resort to just command-line stuff.  The obvious conclusion of this is a full CC editor, but that'll require finding out what, if any, data is hard-coded in the engine itself...
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on July 02, 2008, 09:55:10 am
First Square Enix puts up a Chrono Trigger DS site, and now MDenham is writing a Chrono Cross editor. Can this week get any better? :lee:

M, one thing to keep in mind is that (to my knowledge) the Terminus Traductions tools does not dump all the game files as Yazoo's utility pack does. I think the TT tools are more designed for editing the dialogue files. However, it's highly possible I just haven't figured out how to work the TT tools properly yet. For example, there's got to be a video dump feature because there's a folder for the videos, but I haven't successfully dumped those yet.

In any case, the TT tools do dump all the room files, and is supposed to be capable of rebuilding a Chrono Cross game disc. And all the .OUT numbers we've got in our encyclopedia should still be applicable to what the TT tools prodces. Can you tell from your exploration so far if there's a general LZSS decompression function in the TT tools M?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on July 02, 2008, 08:39:29 pm
M, one thing to keep in mind is that (to my knowledge) the Terminus Traductions tools does not dump all the game files as Yazoo's utility pack does. I think the TT tools are more designed for editing the dialogue files. However, it's highly possible I just haven't figured out how to work the TT tools properly yet. For example, there's got to be a video dump feature because there's a folder for the videos, but I haven't successfully dumped those yet.

In any case, the TT tools do dump all the room files, and is supposed to be capable of rebuilding a Chrono Cross game disc. And all the .OUT numbers we've got in our encyclopedia should still be applicable to what the TT tools prodces. Can you tell from your exploration so far if there's a general LZSS decompression function in the TT tools M?
To be honest, I'm not entirely sure if it actually does dump all the game files or not (I haven't gotten that far in following the code).

As far as a general LZSS decompression function, I think "Lzss_D" is the command for that (with the new tools, it'll be "unpack-lzss" - longer but more readable commands are a plus, I think) - and just based on a quick once-over of its code, it doesn't seem to do any sort of special case stuff for the decompression.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on July 02, 2008, 10:23:14 pm
Suh-weeeeet. I think I was simply not able to get the LZSS_D and LZSS_C functions to execute properly because they're expecting very specific arguments, and I have no idea what to input at this point.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on July 02, 2008, 10:24:41 pm
Suh-weeeeet. I think I was simply not able to get the LZSS_D and LZSS_C functions to execute properly because they're expecting very specific arguments, and I have no idea what to input at this point.
It takes a string of file numbers/ranges, so something like:

Lzss_D 1-8;11;13-41;56-59;62

is what it'll expect.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Boo the Gentleman Caller on July 03, 2008, 12:41:07 am
I heart the Compendium.  I'm pumped the way this project is going and eternally grateful to find that MDenham is making the CC Editor!  WOOOOOOT!
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: yaz0r on July 03, 2008, 07:32:34 am
To be honest, I'm not entirely sure if it actually does dump all the game files or not (I haven't gotten that far in following the code).

My tools were able to dump all the game files, regardless of their type, as it was also able to regenerate a completly working CD from all the dumped files.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on July 03, 2008, 10:09:04 am
To be honest, I'm not entirely sure if it actually does dump all the game files or not (I haven't gotten that far in following the code).

My tools were able to dump all the game files, regardless of their type, as it was also able to regenerate a completly working CD from all the dumped files.
That's what I thought, but I wasn't entirely sure yet.  (It really wouldn't have made sense if it didn't dump everything!)

Oh, BTW, for anyone currently semi-frustrated with the whole "I need two separate ISOs of each disc, one for each set of tools" thing (I seem to recall one set of tools wants a raw image?) it looks to be fairly trivial to handle being able to read both formats as the difference is just additional error correction info, etc.  So the updated version of the tools, with any luck, should basically be "drop in any ISO of the discs and play around with it".
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: yaz0r on July 03, 2008, 10:16:01 am
It should be really trivial to modify my tools to handle other iso format.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on July 03, 2008, 10:29:48 am
It should be really trivial to modify my tools to handle other iso format.
Yeah, it looks to be.  It's just a matter of finding spare time (and occasionally trying to guess what the code is doing because, for whatever reason, I can't pick apart the French :D - I'm working at it, though) and slowly grinding away at it. :)
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: yaz0r on July 03, 2008, 11:24:30 am
All the code I wrote back then was very baddly written. It has been so many years now...
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on July 03, 2008, 10:58:02 pm
Oh, snap -- yaz0r's back. :lee: yaz0r, did you ever do an lzss-dec.exe? I've got an lzss-comp.exe and the source, but nothing for the decompression. All the LZSS-compressed files in Chrono Cross use the exact same compression routine, don't they? As soon as we get something that does general LZSS decompression, I imagine we can start tearing into the fieldscript and its in-battle equivalent.

Speaking of which, how does your script-dec.exe differ from general LZSS decompression? Are the script files still in a relative alphabet when they're decompressed, and the script-dec.exe needs to convert that relative alphabet into ASCII? I've tried running your script decompression tool on a non-dialogue LZSS compressed script and it couldn't process, so I imagine the utilities for script decompression have some extra functions built in to handle formatting of the data or something.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: yaz0r on July 04, 2008, 05:54:54 am
I have a CC LZSS decompressor somewhere (I'll have to look for it in my backup discs tonight). It's *probably* used elsewhere in the game (like the event scripts) but I can't say for sure, I never really worked on that. I suppose that all the files starting with the same magic as the text files are in the same lzss format.

There is no such thing as general LZSS decompression. LZSS is an algorithme and can be implemented in a lots of different way. CC LZSS is rather different than other implementation of LZSS. Usualy, you have a byte giving you the compression state of the next 8 blocs. In the case of CC, you just have one bit giving you the state of the following bloc.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on July 04, 2008, 12:09:33 pm
Ah, okay, it would have taken me awhile to figure that out. If you happen to find that CC LZSS decompressor, I would be forever greatful.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on July 06, 2008, 10:08:46 am
ROUND DISC 2!  FIGHT DUMP!

After mucking around a bit with the somewhat-easier-to-follow source to the version Ramsus worked on, I'm in the process of dumping Disc 2 right now.

First note of interest: some rooms that are on Disc 1 are dummied out on Disc 2!  The first one is (assuming we're referring to the room using 0356/0357/0358 as "Room 1") Room 55 - which indicates that the Room Modifier code is working off of an entirely different set of numbers from the rooms-as-loaded (I suspect "Room 55" is RMC #049, and so the initial order is "5, 8, 9, 10...").

With regards to my "short" Disc 2 image - it looks like all that's missing from it are videos, more likely than not (the last non-empty file I got is #5652, and it's followed by 84 empty files, #5653-5736...  and then the damn program decided to start spitting out a file of over 280MB, when I already had ~97% of the ISO's space accounted for!).  So that's some good news as well (it's entirely possible that there's actually nothing missing, and the larger CD2 ISO you have, FaustWolf, has over 100MB of empty space at its end. :D  You might want to check that).

dump.exe is attached; no matter which ISO you're dumping, make sure it's named cc.iso for the time being.  Works just like the other versions of the Ramsus-edited tool.  Debug-related stuff is included in case something goes wrong, which it probably shouldn't (though I got a rather interesting stack-thrashing error dumping CD1 with it).  CD2's dumping isn't nearly as informative as CD1's is, though - just a dumb (in the sense of "dumb terminal", folks, not "stupid! stupid! stupid!") progress display of periods rather than sectors/file #/file type.

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on July 06, 2008, 10:16:07 am
M, you are my hero. Does this dump.exe dump BOTH Disc 1 and Disc 2, or should I keep this separate from the dump.exe I'd been using to dump Disc 1?

We should be able to snag a few more battle models this way.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on July 06, 2008, 10:26:23 am
M, you are my hero. Does this dump.exe dump BOTH Disc 1 and Disc 2, or should I keep this separate from the dump.exe I'd been using to dump Disc 1?

We should be able to snag a few more battle models this way.
Yes, it works for both discs.  Name your Disc 1 ISO cc.iso, run it on that (you'll get the same results as with the old tool, BTW), then rename it back.  Then, just name your Disc 2 ISO cc.iso, and run it again.  Disc 2 will get lumped into ALL\disk 2\0000.out-5736.out or however far it goes with your ISO (I don't know why it wouldn't be the same, but it's something to keep in mind).  If it seems to stall for a long time after making 5736.out, you can always kill it with Ctrl-C and then delete the resulting 5737.out.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on July 06, 2008, 10:52:22 am
*Does the happy dance* Can't wait to try this out! Gotta free up some room on my hard drive first though.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on July 06, 2008, 11:27:32 am
And, with the aid of some programs that have been around since, um, 1983 or so...

Well, the filename should speak for itself.  It's the lists solely of files that are different (well...  the rooms-cd?.txt files are definitely that way, at least; the compare-cd?.txt files still have some ranges of overlap that I haven't bothered to clear out at this point).

But, just to let people know the main finding here:

Not only are some rooms disc-specific, some rooms are just flat-out different by disc (#452-463, which is then followed by a run of disc-specific rooms to 469; 470 is identical; 471 starts more disc-specific rooms, on out to 479...  and then 480 starts another run of "these rooms are not the same...").

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on July 06, 2008, 11:42:43 am
Thanks M. Your list confirms (I think) that the battle model files, at least, are not in alignment between discs. In Disc 1, 3055.OUT is Serge's battle model texture, which is 37,992 bytes in size. In Disc 2, 3055.OUT seems to be just over 2000 bytes in size. This means that once we've got Disc 1 documented skeletally, we'll have to do a full analysis of Disc 2 as well. Makes things just a bit more complicated, but it's good to know.

EDIT: Aha, battle model data begin @ OUT 3100 according to the Disc 2 list. There may have been more rooms stored on Disc 2 for some reason, pushing the battle models back a certain amount.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on July 06, 2008, 05:29:04 pm
EDIT: Aha, battle model data begin @ OUT 3100 according to the Disc 2 list. There may have been more rooms stored on Disc 2 for some reason, pushing the battle models back a certain amount.
Well...  sort of...

The difference is that there's a stretch of 15 dummied rooms (making up the 45-file difference) at the end of Disc 2's room files, while Disc 1 just jumps right into whatever the next thing is.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Vehek on July 06, 2008, 05:41:27 pm
When I tried to use the tool, I got an error message about the application configuration being incorrect.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on July 06, 2008, 05:44:57 pm
Yep yep, me too. I've notified M via PM.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on July 06, 2008, 06:06:35 pm
You know, it helps if I include the VC9 ('08) runtime DLLs.  :?

Anyway, here they are - at least, the debug versions - so that should fix things.  If it doesn't, well, complain at me again.

(Also attached are updated versions of compare-cd1/2.txt because I've tracked down the remainder of the differences.  There's a lot of stuff that's dummied out on CD1 and present on CD2.)

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on July 06, 2008, 06:27:07 pm
Do we need to put the DLLs in a specific folder, M? When I extract the DLLs to the same folder as dump.exe, I'm getting the same error.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on July 06, 2008, 06:28:44 pm
That's...  odd.  I'm heading out to Costco right now, so once I get back I'll figure out what's not right.

You might need .NET Framework 3.5.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on July 06, 2008, 08:39:49 pm
Okay, here's what you need:

Download this file (http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en) and run it.

Then, use the attached version of the program (not a debug version :D).  Same functionality, 25k smaller.

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on July 06, 2008, 09:14:20 pm
While walking through New York City a few summers ago, I saw a Jamaican guy breakdancing in the middle of the street shouting at the top of his lungs, "I LOVE LIFE!"

I AM NOW IN THAT STATE OF BEING!

Thank you M, the new-and-improved dumper works flawlessly! I'll need to restructure the File Structure wiki a bit to take into account the fact that we can now detail both CDs. Time to par-tay!
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on July 06, 2008, 09:21:04 pm
While walking through New York City a few summers ago, I saw a Jamaican guy breakdancing in the middle of the street shouting at the top of his lungs, "I LOVE LIFE!"

I AM NOW IN THAT STATE OF BEING!

Thank you M, the new-and-improved dumper works flawlessly! I'll need to restructure the File Structure wiki a bit to take into account the fact that we can now detail both CDs. Time to par-tay!
You know, it's fixing things up like this that make me want to ask for, as an addendum to the whole Guru of X structure, a "Mad Scientist" post as well. :D  Even if we just give it to Ramsus for the time being.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Unaisis on July 06, 2008, 11:26:16 pm
Ugh, been gone for awhile now @,@. Glad to see some progress on Disk two!!! ^.^ too bad i wont be able to get my hands  dirty until after an anime convention that i'm preparing for O.x  (First one EEEEEEEEEEEEEEEE) Good job everyone!
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Satoh on July 07, 2008, 01:47:39 pm
So we finally have disc 2 capabilities... looks like I have more work to do fixing textures...
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on July 07, 2008, 04:56:52 pm
Should just be a few models and textures we're missing. If I had the time to find them, right now I'd go through the wiki model list and see which ones were labeled "CD Make Dummy!", add 45 to those numbers, and then target the indicated files. I'll get around to it eventually though.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: ZeaLitY on July 07, 2008, 08:15:44 pm
Anyone who has Blender, can you look at Norris's model from a certain perspective and take a picture? It should match this perspective:

(http://www.chronocompendium.com/Forums/Themes/compendium/images/ranks/acaciadragoon.gif)

I'll resize it down myself. It's for the Black Wind Agent rank. I also need one of a regular Porre soldier from the same angle for the Porrean rank.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: cornettheory on July 07, 2008, 09:56:19 pm
I would help you out, but the wiki link that has the list of out files seems to be down. :?

Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on July 07, 2008, 10:56:20 pm
cornettheory, check your PMs.  :D
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: cornettheory on July 08, 2008, 01:28:31 am
here ya go

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on July 08, 2008, 01:39:34 am
Awesome renders!  :lee:
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Captain A on July 08, 2008, 03:20:33 pm
I see this is going well...
if you need any help, don't be afraid to ask.
tag
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: ZeaLitY on July 08, 2008, 03:49:09 pm
Thanks a ton. I noticed that the other single Cross ranks also look a little lonely, so if you are still able to help...

* Miki
* Solt and Peppor
* Dario
* Belthasar

That should round everything out with 2 or 3 characters. Thanks!
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on July 08, 2008, 03:54:02 pm
Just a warning to the modelers, Dario will require some manual labor until Luminaire has time to incorporate double texturing into his Blender script.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: cornettheory on July 08, 2008, 08:34:06 pm
photoshop can hold you over though

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: cornettheory on July 08, 2008, 08:52:23 pm
Here is miki, she was pretty straight forward

Belthesar, isn't ripped yet no he is a no-go

Solt and Peppor, are jacked up. So a newer version of the exporter might solve that in the future

I also noticed that the battle textures for solt and peppor are reversed... or the models are reversed, I forget which is Which.  Either way, the models don't match the textures in the way they are named in the rar.
In the screenshot they are rendered with the correct textures.

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on July 09, 2008, 12:33:17 am
You know what cornettheory, Solt and Peppor each have 128x128 textures, right? That's another feature that Luminaire can add when he gets the chance -- right now the import script only supports 128x256 textures. Add a 128x128 black square below each of their textures, reload the models, and that should do the trick for now.

I'll snoop around for a Belthasar model.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: ZeaLitY on July 09, 2008, 01:20:45 am
I ended up using both Porreans for the Porrean rank, so apologies; I have one more request: Grobyc! Then the ranks will be finalized.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Captain A on July 09, 2008, 09:16:04 am
do you need the renders to have a alpha background? or do you want them to look blue on the back?


and where can I get the blender import script?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on July 09, 2008, 12:27:18 pm
To my knowledge Captain, Luminaire's most up-to-date script was attached to this post:
http://www.chronocompendium.com/Forums/index.php/topic,4770.msg97191.html#msg97191
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: ZeaLitY on July 09, 2008, 02:24:56 pm
It doesn't really matter, I guess. I resize them to about 50 pixel height and then make the background transparent, eliminating any defects at that point.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: ZeaLitY on July 09, 2008, 04:30:45 pm
The code to activate the debug mode in-game using R1 is 8006B456 0101.

But it only works on disc one. Is there some way to find the equivalent for disc two?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on July 09, 2008, 09:24:02 pm
The code to activate the debug mode in-game using R1 is 8006B456 0101.

But it only works on disc one. Is there some way to find the equivalent for disc two?
More importantly, why does it even work on Disc 1?  The program files are the same between both discs...

I'll file this in the "things to figure out when rewriting the engine mostly to fix bugs" category (in other words, sometime after the editor gets written), unless someone figures it out before me. :D
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Satoh on July 09, 2008, 10:12:00 pm
The code to activate the debug mode in-game using R1 is 8006B456 0101.

But it only works on disc one. Is there some way to find the equivalent for disc two?
More importantly, why does it even work on Disc 1?  The program files are the same between both discs...

I'll file this in the "things to figure out when rewriting the engine mostly to fix bugs" category (in other words, sometime after the editor gets written), unless someone figures it out before me. :D

Debug room is specifically that, a room, I think. it isn't the program that would be missing from disc 2, but rather the room, the debug menus are all part of the fieldscript for that room, as I see it. Conjecture, but it would make sense.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: ZeaLitY on July 09, 2008, 10:36:30 pm
Ah, well the only strange rooms I found...

* I forget if it's Home or Another, but there's a room that doesn't exist in one of those dimensions in Marbule, yet it's in the game. I don't think exits worked though, so sadly I couldn't exit and see where I popped out of.
* In the upper 500s, there's a black room with the Chrono Cross logo on the floor.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Satoh on July 09, 2008, 10:41:37 pm
Ah, well the only strange rooms I found...

* I forget if it's Home or Another, but there's a room that doesn't exist in one of those dimensions in Marbule, yet it's in the game. I don't think exits worked though, so sadly I couldn't exit and see where I popped out of.
* In the upper 500s, there's a black room with the Chrono Cross logo on the floor.

That could be the intended debug room, like in FFVII... or i could be the title screen with no oceanside scene behind it...

It could even be the black room that is accessable only through the second door in the programmers ending...(which is always locked)
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on July 09, 2008, 10:50:06 pm
It'll be interesting to see whether the room dialogue scripts on Disc 2 have debug mode text. It would be utterly weird to have a debug mode only on one disc though, wouldn't it?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on July 09, 2008, 11:33:48 pm
The code to activate the debug mode in-game using R1 is 8006B456 0101.

But it only works on disc one. Is there some way to find the equivalent for disc two?
More importantly, why does it even work on Disc 1?  The program files are the same between both discs...

I'll file this in the "things to figure out when rewriting the engine mostly to fix bugs" category (in other words, sometime after the editor gets written), unless someone figures it out before me. :D

Debug room is specifically that, a room, I think. it isn't the program that would be missing from disc 2, but rather the room, the debug menus are all part of the fieldscript for that room, as I see it. Conjecture, but it would make sense.
The thing is, the debug menus show up in the dialogue tables for basically every room...  It really is, as I said a page or two ago, more of a debug flag that we're setting than any real debug room.

As far as the CC-logo-on-floor room...  hm.  That shows promise for other things, especially if it has any actual fieldscript attached to it.  It'd help if the room numbers from the modifier code (or even from the debug menu!) corresponded in any way I can figure out to the file sets, though.  Strike that.  The room numbers at the very beginning that crash/give black screens get filed in MISC.

NOTE TO EVERYONE: To convert from a room number in the debug menu to the file numbers, multiply by 3 and add 332.  This is the first file out of the set of three.

BTW, there aren't any actual rooms above #544 on Disc 1, or above #559 on Disc 2 (confirmed by way of examining files).  I'm not entirely sure what would happen if you tried loading rooms beyond that (for example, trying to load Room 545 on Disc 1 should load the pause screen effect, the pause screen text, and the status screen graphics and try and interpret it as room data) but I suspect the game simply crashes as the files aren't in the proper format.

Other things to note:

0001.out -  :shock:
BOOT = cdrom:\SLUS_010.41;1
TCB  = 4
EVENT = 16
STACK = 801fe000


That's the exact contents of it (aside from that what immediately precedes the equals signs is tabs instead of spaces).  Does changing this file actually change settings (the only one I'd recommend changing, ever, is the STACK line, and even then it's doubtful)?

0004.out - Has a lot of function names at the beginning, including many many kz_* functions, such as the following:

kz_CheckEquipGrandorion()
kz_CheckEquipBraveShield()
kz_CheckEquipBraveGoods()

and the great one:

kz_GetBeta()

0005.out - The first 303 bytes are all that's readily apparent as far as interesting things (note: I skipped the first 96 bytes as it's just file names + some junk):









 -----------------------------------
    %s

    <------------select------------->
  cd       mode
  pc       mode
  emulator mode
  psx      mode
  pcprog   mode
  cdprog   mode
  disk = 1
   disk = 2


0018.out - Shop-related stuff, along with status messages while saving/loading and the little save blurbs.  Why those are in the same file, who knows...  guess they decided those used a sufficiently similar interface to put all the data into one thing.  It's got a DRP header, though, like the second file out of any room triad.  (It doesn't form a full room, though, obviously.)

0015.out - Looks like it references eight models (?? Or perhaps just elements of some sort for the "screen" it produces), bit_ and bit2-bit7.  Again, DRP header, but not an actual room to the best of my knowledge.

It'll be interesting to see whether the room dialogue scripts on Disc 2 have debug mode text. It would be utterly weird to have a debug mode only on one disc though, wouldn't it?
You'd have to check one of the "unique to Disc 2" rooms - either where the file itself is a different size, or where it's just flat-out dummied on Disc 1.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on July 09, 2008, 11:44:22 pm
Ahh, thank you M! I'll get these contents noted on the File Structure Wiki next time I do my rounds. I might be able to simply use Excel to get all the rooms labeled in one fell swoop now that we know the relationship between ZeaLitY's debug mode rooms and the ones stored on the disc.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: ZeaLitY on July 10, 2008, 12:41:11 am
That poor smiley! He's lost amongst the Cross research!

(Yeah, I know how he got there.)

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: cornettheory on July 11, 2008, 11:58:26 am
a black room with a logo at the bottom sounds like a construct for a title screen to me.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Vehek on July 12, 2008, 12:30:01 am
I managed to use Lzss_D!

It loads from and writes to a folder called "30_Fichiers_Avant" in the directory above Chrono_cross.exe

Example:
Lzss_D directory|file #'s

(Directory seems to need a "\", and must be in 30_fichiers_avant)
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on July 12, 2008, 02:13:54 pm
OOOOH, Vehek, what exactly did you type in for the argument of the LZSS_D function? Was it literally:

LZSS_D 30_fichiers_avant\some subfolder\File # ?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Vehek on July 12, 2008, 02:18:29 pm
I think it needs the "|". It finds the directory name by reading until it finds a "|". It assumes the folder is in the 30_fichiers_avant folder.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on July 12, 2008, 02:20:29 pm
Alrighty, I'll try that out, as I had no clue about the "|" belonging somewhere. Holy cow, we could be digging into fieldscript soon...
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Vehek on July 12, 2008, 02:28:59 pm
An example:
Lzss_D /|3
This would load 0003.lzs in the 30_fichiers_avant folder.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on July 12, 2008, 02:47:20 pm
Okay, thanks. I'm having problems getting my CC_CD1.iso to dump now using Nemesis' tools, so it might be awhile before I figure this out.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on July 12, 2008, 07:21:53 pm
Onward, to the engine!

Open up 0000.out in the hex editor of your choice and head to 0x91700 - there's 176 pointers here, but I'm not sure to what.  The first three point to strings ("GET_CASTER", "GET_TARGET", and "GET_ACTOR" respectively), and then we run into pointers to actual functions.  However...  some of these functions land well outside where the program's code is (in fact, a relatively large portion) so there's obviously a second portion of the program being loaded as an overlay. 

0002.out has a similar table near the beginning (0x00144-0x00673, 332 entries) with a sizable number of repeats - it seems to be the overlay in question (loaded at (80)0a1200, as compared to the main program's (80)010000).

How many elements and techs, combined, are there in Chrono Cross (including ones that don't work to the best of our knowledge)?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: ZeaLitY on July 12, 2008, 07:39:04 pm
http://www.chronocompendium.com/Term/Elements.html

Count all the colored and then add it to the total number of Other Techs and Monster Techs.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on July 12, 2008, 07:56:15 pm
http://www.chronocompendium.com/Term/Elements.html

Count all the colored and then add it to the total number of Other Techs and Monster Techs.
Yeah, the only reason I hadn't done that was because for some reason those pages are loading a bit slowly for me.

EDIT: Hmm, looks like 281 total...  but that only counts Pip's techs, not any of the other characters'.  Throwing in everyone else's puts it up to 408, so neither of these pointer tables is the tech/element list (if they're separate lists, it's 125 elements, 283 techs - which might be the case, but it's a little messy to do that).
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Satoh on July 12, 2008, 08:03:20 pm
http://www.chronocompendium.com/Term/Elements.html

Count all the colored and then add it to the total number of Other Techs and Monster Techs.
Yeah, the only reason I hadn't done that was because for some reason those pages are loading a bit slowly for me.

EDIT: Hmm, looks like 281 total...  but that only counts Pip's techs, not any of the other characters'.  Throwing in everyone else's puts it up to 408, so neither of these pointer tables is the tech/element list (if they're separate lists, it's 125 elements, 283 techs - which might be the case, but it's a little messy to do that).

They take about 4 minutes to load for me, so I've been ignoring the non forum functions of late...
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on July 13, 2008, 01:00:52 am
They take about 4 minutes to load for me, so I've been ignoring the non forum functions of late...
Yeah, it's not quite that bad for me, but pages that take longer than 30 seconds to even start loading the HTML induce ADD in me. :D  I blame my cable modem for this - 8mbps downloads do that to me.

Z, not to pry too much into hosting-related matters, but have you looked into colocation?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: ZeaLitY on July 13, 2008, 02:13:33 am
Well, Ramsus would be better at answering that.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Cyberman on July 17, 2008, 09:03:56 pm
Silly question what is the latest script for import/export?

The next thing is a suggestion, if/when/how etc. the script changes someplace for finding or knowing when it's updated would be useful.  Erstwhile I did look at the script and I'm pretty sure the copy I have has likely seen modification ( a few times).  I plan on importing it to POV, I noticed there are normals associated with the model (or at least they appear to be).  Are these regular surface normals or something else?

Cyb
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on July 17, 2008, 09:28:51 pm
The latest version is 0.3.1, which I attached to a post buried several pages ago in this thread. I attached it again here; if you already have this version, there's no need to download again.

I'm not 100% convinced that set of data is normals, but treating them as such seems to work okay for the models we've looked at so far. If they are normals, then they are defined on a per-vertex basis.

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Cyberman on July 18, 2008, 08:16:21 am
You have not attempted to use smooth triangles with them (IE interpolated normals across them polygons)?
I'll see what I get with and without that in POV. That will have to be done when I have time I'll be late for work if I don't move it.

Stephen
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Vehek on July 25, 2008, 05:04:37 am
I think OUT 4 in the CODE folder made by RoomDecompress is the walkmesh.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Cyberman on July 26, 2008, 01:46:01 pm
Vehek more than I have done at least!

Now a more serious question (heh)
Battle model textures, although it's all fine and dandy to convert the TIM to the proper format for people or take the TIM of the texture and create it by hand then import that for the model, I would rather make my code do this itself, initially I will have to do what is currently being done.  However as stated my prefered method is to DIY in the code. So now the question, what is the association between a battle model and it's texture in the CC data files? Put differently, how do I find the battle models associated texture?

Luminair, I don't hate Python but it is a bit frustrating since I am use to C/C++ etc.  It's probably better to use Python for several reasons. When I finish the texture conversion feature you will be able to add that to the blender import script is one such reason.  Erstwhile I have to learn Python (in my case trial by error first then do things the normal route).

Cyb
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Vehek on July 26, 2008, 05:18:12 pm
This (http://www.chronocompendium.com/Term/MISC_%3D_3054-3707_Misc.html) shows that the texture of a battle model is the file before the battle model.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Luminaire85 on July 26, 2008, 06:14:54 pm
Musing here: Since one of the end goals of this work may yet be a Chrono Cross editor, perhaps us coders ought to decide on a single language to use so as to cut down on some of the work. Does this seem like a good idea to anyone else?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on July 26, 2008, 07:37:19 pm
Musing here: Since one of the end goals of this work may yet be a Chrono Cross editor, perhaps us coders ought to decide on a single language to use so as to cut down on some of the work. Does this seem like a good idea to anyone else?
Sticking with a single language isn't going to be absolutely necessary (this is part of why I'm personally using C#) - just choose a language that can compile to the CLI (in practice, this normally means C#, C++, and VB; however, there are other languages that have CLI compilers as well).

Specifically in your case, I think you might be interested in looking at IronPython (though you'll probably want to wait on actually using it until October or so).
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Cyberman on August 13, 2008, 10:43:14 pm
I've attached my 'datalist' of disc 1 for chrono cross
The application creates a list of 'files' and I want to be sure it has the correct data.
The list (datalist.csv) file is in CSV format with
Item, LSN (in hex), Size (decimal), type
If anyone could check a few of the items with the tools they have to verify it's reading the information correctly it would be appreciated.
I've tried to decipher how to find the last file with little success.  Suggestions anyone?

I've decided to take a different tactic to generating POV data. First get the data then extract it using a program source I'm familiar with (C++).

Is there more information in the compendium about the file types in chrono cross?

I would like to improve my VFS system enough to be able to drag files out of the file list into a real file system or something like that.  The other alternative is to read the file and convert it to a selected type (IE model to a model TIM to a PNG or BMP that can be either used as a texture or whatever).

Anyhow attached is a rar'd file of it (yes it's kind of long)

Cyb
addendum 1:
Was able to verify files are listed somewhat correctly.
Now I need to
addendum 2:
More fun, I found the difference in the number is the fact I include NULL records from the base directory this likely accounts for the difference in what I have and what is listed in the compendium.  As usual things get complicated.
addendum 3:
#'s rectified I am currently redoing the hex viewing in order to view VFS files in it.  This should make it easier for me to extract the textures from the battle archives.  I noticed the play battle models use ID 118 and enemy use ID 186. However I've noticed that these #'s do not always correspond exactly to 188 == TIM (and the above is not ALWAYS correct either).

Cyb

[attachment deleted by admin]
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Vehek on August 28, 2008, 03:37:33 am
The table at 0x834 in 0004.out seems to be related to battle.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Vehek on August 30, 2008, 08:26:30 pm
I've been looking at battlescript lately. During this, I may have found data related to Elements.
Using Cyberman's datalist, file_2669 (and maybe file_43; they're identical) contains this data. I think each Element is 0x2C bytes.

Information so far on this data:
0x04: Targeting
0x05: Element color?
0x10 of each Element's data: appears to be visual effect.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: MDenham on September 01, 2008, 06:27:26 am
I've been looking at battlescript lately. During this, I may have found data related to Elements.
Using Cyberman's datalist, file_2669 (and maybe file_43; they're identical) contains this data. I think each Element is 0x2C bytes.

Information so far on this data:
0x04: Targeting
0x05: Element color?
0x10 of each Element's data: appears to be visual effect.
Any chance of giving a .out file number for this? :D  I can probably confirm if it's the right length (if it's elements only, it'll have ~130 entries; if it's got techs as well, it'll be more like 300+ entries).
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Vehek on September 01, 2008, 02:20:02 pm
I don't know which .out it would be. I'm pretty sure it also contains techs. If it contains all the elements/techs listed in the script, then it's more like 512.
First two entries:
01 01 00 00 80 20 01 00 0C 00 00 00 14 00 00 00 26 00 77 00 FF FF FF FF 00 00 00 00 08 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00
01 01 00 00 80 20 03 00 14 00 14 00 14 00 00 00 2A 00 55 00 FF FF FF FF 08 00 00 00 08 00 00 40 00 00 00 00 00 00 00 00 00 00 00 00
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Captain A on October 25, 2008, 10:42:31 pm
so, how is this coming along? I just popped in here after awhile and wanted to see what you guys have done so far.
if you have any questions about Blender go ahead and ask.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Vehek on December 26, 2008, 10:04:54 pm
I'm still not absolutely sure which OUT the Element/tech data I found is in, but I think it might be in OUT 2541 or so.
(The hex data I posted earlier from it is not the exact beginning of the file.)
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: FaustWolf on December 27, 2008, 12:36:43 am
The graphical aspect of Elements and techs seem to be housed in the file range 3979-5597 on Disc 1 if that helps any; I'm wondering if there are pointers to any of these files in the data you guys are examining currently.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: ZeaLitY on December 27, 2008, 02:28:30 am
If anyone has spare time, I'd like shots of these models for miniaturizing into rank icons:

Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Vehek on December 27, 2008, 03:56:59 am
I don't really know how to use Blender. Is there an easy way to move or remove the tool Toma carries?

(http://i239.photobucket.com/albums/ff83/TtravelrKev/Chrono%20Cross%20Stuff/TomaModel2.png)
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Shadow D. Darkman on December 27, 2008, 04:28:41 am
Isn't Miki in the Magical Dreamer rank?
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: ZeaLitY on December 27, 2008, 04:31:58 am
The concept art, but I'd like the model.

Wow, I never even noticed that Toma's moustache was retained in Chrono Cross until now. Is Blender automatically anti-aliasing the edges of the model for that image? Either that, or you took the original image and resampled it down to a lower resolution...I guess use resize and try to turn off anti-aliasing.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Shadow D. Darkman on December 27, 2008, 04:36:18 am
*words fail him as he struggles to respond, and ultimately walks away*
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Vehek on December 27, 2008, 04:46:56 am
Doesn't this post have Miki's model?
http://www.chronocompendium.com/Forums/index.php?topic=4770.msg104585#msg104585

Edit: And it looks like the Magical Dreamer rank already has the model to me.


Edit 2: Here's my probably sloppy attempt to move the tool Toma has into his hand.
(http://i239.photobucket.com/albums/ff83/TtravelrKev/Chrono%20Cross%20Stuff/TomaModel3.png)
And without the tool:
(http://i239.photobucket.com/albums/ff83/TtravelrKev/Chrono%20Cross%20Stuff/TomaModel4.png)
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: ZeaLitY on December 27, 2008, 04:37:41 pm
Ugh, so it does...um...I guess cross out Miki.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Shadow D. Darkman on December 27, 2008, 05:54:10 pm
As was thought.
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: Vehek on December 29, 2008, 12:58:00 am
Is Blender automatically anti-aliasing the edges of the model for that image?
Anti-aliasing was indeed on in Blender.
Here's an image without anti-aliasing.
(http://i239.photobucket.com/albums/ff83/TtravelrKev/Chrono%20Cross%20Stuff/TomaModels.png)
Title: Re: CHRONO CROSS FILE EXPLORATION THREAD
Post by: ZeaLitY on December 29, 2008, 01:12:02 am
Perfection.