FF7 Crisis Core - File Format and Data Investigation

  • Thread starter Thread starter koral
  • Start date Start date
Status
Not open for further replies.
It should work, have you tried selecting the samples?



It looks ugly without textures, but it's the Banora Outskirts map and you can see the vertex-shading they have used.

RINOA uses DX9 permanently now, so it should work fine on vista and everything.
Could anyone confirm for me if the viewer works properly for them? I know it works for me, but I may have done something weird again  :oops:
 
ah, i remember now. I used to have aproblem where only your samples would work, and my files wouldn't, even though they were the same.... i'll have to try and remember how we sorted that out...
 
Great work again, koral. :) I'm looking forward to browsing through some of the locations.
 
I'm gonna check this out, too... Downloaded it two times... Please update first post with new version. :)
Thanks for your awesome work! :)
 
2 Koral
BTW is it possible to rip Bike model from exebition floor in Shin-ra building? And use it in FF7 bike level? :?
 
If you'll pardon me for answering...

Surely it can be ripped, as for using it in the bike minigame, I can't say with any certainty... I've never seen anyone specifically replace that model. (By this I mean I myself haven't seen it. I do not imply anything about whether or not it can be done.)


*Exhibition.

Ahh... every time I come through Tech-Related I get a bit sad about my inability to rip things like some of the rest of you... I have so many games I want investigated, but no time, or skill, necessary.

Koral and MrAdults specifically, you two are my model decoding heroes. I've never seen anyone else get so much done so fast. Is there a secret you have? Like being aliens?
 
If you'll pardon me for answering...

Surely it can be ripped, as for using it in the bike minigame, I can't say with any certainty... I've never seen anyone specifically replace that model. (By this I mean I myself haven't seen it. I do not imply anything about whether or not it can be done.)
I saw bike model by my self(when tried Kimera program) in minigame LGP archive.I'll try to find it someday later.

Actually i wanted to replace it with THIS model from PSX FFVII International Bonus Disc:
snap2.jpg

snap4.jpg

 but looks like there no PSX model ripper/viewer :cry:
 
Sorry about the half-hearted releases, but my life is really touch-and-go at the moment so I can only work on it at random spurts any chance I get  :|

I have fixed the issue with the textures now, so here is the new version of the RINOA viewer (v0.5 pre-release beta): http://www.mediafire.com/?dolini4ljyg

So now it is possible to flick through all the map-models and character models, complete with textures.
But there are still some major issues with the interlacing, and random "noise" also seems to have crept in, resulting in little black (or odd coloured) pixels littering the scene.

Notes:

  • No export options (it uses DX9 if you really want to rip them)
  • Press SPACEBAR to toggle between 1st-person camera and overview camera
  • G and H keys toggle file-select-window visibility
.
I had also forgotten to mention that [GT], [ATEL] and [MBD] files are not currently viewable in this new viewer tool (hence the beta status), I will get around to it later.

And there are some maps which never load, and simply crash the viewer.
Those Blacklisted files are:
.
Code: [Select]
Code:
2016202420272037204520622063207821052138


squallff8
the vehicles are part of the Shinra-museum(ground floor) map, so probably can be ripped if you extract the entire map.

I dont have the FF7 Bonus disc so I cant look into those nice models you have shown us, but if you (or anyone) could upload some of the data files then I might check it out.


x-dina
dont forget the legendary Quimm and his band of merry FF7 (de)coders!
Without those awesome guys, we wouldn't be here discussing this stuff!  :-D
 
In 00004 there is a pattern,

t the beginning at column 9 there is an increase when scrolling down
at 00006320g to 00006350g there is a sequence from efgh to u

I use Ultraedit...

By the way, in the wiki there is no information on the ATEL and MBD docs, could anyone post them?

Edit:

Also in the 8703 there is this pattern;

      0 @      4@      @@
    1@       5@      A@
  2@       6@      B@
3@      7@      C@
 
Karlislie check the first post, that is where I had initially dumped all my findings before I had received access to the Wiki.
Everything there isn't in the wiki, and vice-versa.
(in other words, all the known ATEL and MBD findings should still be there)


Sorry for bumping, but incase my previous post got ignored  :lol:

I have released a new version of RINOA (v0.5beta) which can show fully textured map-models.
For more info, check link: https://www.ff7catalog.com/posts/75936/
 
Sweet, but I can't load my own maps, but oddly i can load my own characters. only map i can load is 02109, banora, the one that came with the RAR...
 
As mentioned in my post earlier toy can see in 00004 there is a pattern
00004.png


And in this screenshot you can see another alphanumeric pattern

By the way koral, would you mind sharing Rinoa's sourcecode? I know I sure would love to develop it further.
 
Last edited:
Sorry Karlislie, but RINOA will remain closed source as my own personal project  :wink:
But all the information (as we have discovered) is out in the open, so you shouldn't have difficultly writing your own tool(s) for specific purposes.

Those screens look like [MBD] scripts, ignitz posted the codes for them here: https://www.ff7catalog.com/posts/75720/

But they could just as easily be numbered indices or offsets or something else. :-P
 
hello koral  :lol:

Thanks for the link and for answering, never hurts to ask   :-)

With that post almost of the files are documented except for [ATEL] itself....

Could you post how to open [ATEL]? or how those bytes, dwords on [ATEL]  :?
Since some of the games interesting content seems to inside them :-P
 
Last edited:
*Exhibition.

Ahh... every time I come through Tech-Related I get a bit sad about my inability to rip things like some of the rest of you... I have so many games I want investigated, but no time, or skill, necessary.

Koral and MrAdults specifically, you two are my model decoding heroes. I've never seen anyone else get so much done so fast. Is there a secret you have? Like being aliens?
I used to wonder how people did it, too, back in my early programming days. :) There's no real trick, it's just a matter of having a wide base of knowledge to narrow down the possibilities. If you know what you're looking for before you start looking, you'll find it faster. On the other hand, you can't be too focussed on a single possibility, or you'll waste a lot of time looking for the wrong thing.

Some practical examples on what to look for in terms of vertex or triangle data (assuming your data set is not compressed/encrypted to start out with, which is another different set of issues):
Usually you can find triangle lists by searching a file in 1-byte-offsets for shorts or ints backed up against each other, all within a specific sanity range (where the maximum value would be the highest vertex index). If that fails (triangle indices may not be back-to-back) you can can try searching for specific geometry bits in different pattern orders, like groups of 3/4 indices. The list goes on into all kinds of different and weird/more obscure indexing modes.

Vertices are usually trickier. If UV's or positions are in floating point, it's pretty easy. Just search for valid floating point value ranges in a specific stride, or back-to-back in the case that each vertex component is in its own array. Bytes, shorts, and ints, on the other hand, can blend in with all kinds of data when utilizing their full ranges. In that case, you can try some patterns based on known index values, or if you don't have known index values, you can check value ranges and failures to comply with those value ranges outside of a given stride. If all of that fails, you usually have to start manually looking through the hex and interpreting values, and just trying to find patterns and/or consistently recognizable values in the interpreted data. The biggest thing to know, regarding the whole picture, is that the more pieces of a file you document, the easier it becomes to narrow down the rest. Since if you already know what some piece of data is, it can't be the other piece of data you're looking for. :)

Then outside of scanning for raw values, you have cases where there is some obvious header data with offsets to specific pieces of data (like the Crisis Core models), or cases where the file is broken up into chunks with a common chunk header, like the Dissidia/GMO models. Those things are pretty easily visible by interpreting the data as raw shorts/ints/etc. and just taking a look at the kind of data that's at the offsets (finding offsets is, I guess, mostly a matter of intuition and trial-and-error - if it's in a storage type that can hold up to the filesize, and the value is less than the number of bytes in the file, then maybe it's an offset :)). If you're lucky enough to have that kind of data at your disposal, it's much easier to interpret each specific chunk/offset of the file for a specific type of data, rather than having to bruteforce through the whole thing. On the other hand, there are also much more complicated methods of breaking files up into sections, and games will often have complete sub-filesystems within files for given types of files, or bits of files that are compressed, or all kinds of other things. Dealing with all of the scenarios just requires a comprehensive base of knowledge, so it's one of those things that you just get better at doing with the more you learn about storage techniques and other areas of development (for mesh data specifically, knowledge of rendering, more-so of rendering on the model's target platform(s), is most useful).

I guess I'm getting a bit off-topic there. I just wanted to take the opportunity to de-mystify the process a little bit for anyone interested. :)
 
Mr Adults
Your reply is surely worth wikifying somewhere!  :lol:
I could never explain such things as clearly and precisely as you do, I tend to just speak (type) my mind, never becoming too formal when posting stuff.

My mantra is more along the lines of "trial and error", logically filtering through all possibitilies of the data (as I understand it) until either I reach a conclusion asto its purpose, or I ignore it altogether.
So far I have been lucky, but with Ehrgeiz I realised my methodology isn't failsafe  :-D


Karlislie
I dont know anything about the [ATEL] files really  :-P
All I found out was that if I scanned the first 8-bytes every 16-bytes, I would come across known file-types eventually (such as MBDs and SSCFs).

The MBDs are the most interesting so far, because they contain the game scripts and are organised in such a way that we know what kind of data might be near it.
For example, during a cut-scene event, an NPC might say something and perform a specific animation, so we can find the precise MBD which shows us the file and the location where that dialogue was said, and we can look around to find the other information related to that event.

There would be camera information somewhere too!

Come to think of it, maybe those [&&] files were actually Animation data?!
There were hundreds of them mixed in with the ATEL files!!
 
Well I meant the code about ATEl, because RINOA must have some sort of code that allows it to understand and see what the ATEL contains, I was hoping that you could post that snippet...
 
I was talking about [ATEL] files, but I dont know anything about it so I ended-up talking about MBDs and animations :lol:

I dont know how much you know about c++, but a minimalistic program to scan an ATEL file for MBD chunks would be something like this:

Code: [Select]
Code:
#include <stdlib.h>#include <stdio.h>#include <fstream>#include <iostream>void main(){// Open the file std::ifstream *File = new std::ifstream( "ATEL_File.raw", std::ios::binary);// Read bytes until End of File while( !File->eof() ) { // read in 16 bytes of this line  unsigned char c[16] = {0};  File->read( (char *)(c), sizeof( unsigned char ) * 16 ); // check for [MBD] file start by comparing first three bytes  if( (c[0] == 0x4d) && (c[1] == 0x42) && (c[2] == 0x44) )  {   printf( "found [MBD] at offset: %ld", unsigned int(File->tellg()) - 16 );  } }// Close and Delete File->close();  delete File;}// Job done!!  ^_^
I just wrote this quickly right now from the top of my head, so it may not compile or work as expected.  :oops:

But all the essential functions are there, from reading in a file, recursing through its data, then closing it again.
What you do with that data (and how you show it in a meaningful way to the person running it) is something I cant really help you with.  :-)
 
Status
Not open for further replies.
Back
Top