CHRONO CROSS FILE EXPLORATION THREAD

[FaustWolf]

The judges were cool -- cool enough for me buy the game finally, now that I'm interested in model viewing and game resource collection.

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.

[Cyberman]

The judges were cool -- cool enough for me buy the game finally, now that I'm interested in model viewing and game resource collection.

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

• Things you need to live (eat sleep brush teeth etc.)
• Things you need to on inorder to live after the next few weeks (School)
• Personal life (see your parents relatives before they expire etc.)
• Playing with data in Chrono Cross

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

[FaustWolf]

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. 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?

[Cyberman]

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

[FaustWolf]

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.

[Cyberman]

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.

[nightmare975]

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.

[FaustWolf]

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.

[nightmare975]

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).

[FaustWolf]

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.

[nightmare975]

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.

[FaustWolf]

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.

[FaustWolf]

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:



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:


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:


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

[Luminaire85]

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?

[Sora]

the nes uses 8x8 squares to draw. maybe this is the same? but i doubt it as psx is 52 bit.