Decent FF7 Model Viewer

[nixmahn]

I don't know if this helps but if your looking for more info on the TIM format.  

http://rveach.romhack.org/


The page contains a PSX TIM viewer/extractor/insertor,  the author of the tool may be of some help and he posted other information in the INFO PSX TIM section

[Kislinskiy]

Texturing seems to be more complicated. Obviously we have to read in some TIMs from right to left or use this formula: "fU = 1.0f - fU". I should code a more comfortable editor before I continue to decrypt this file format.

Merry X-mas and a happy new year!

[Cyberman]

Yes.. I'm still trying to figure a way around open GL's  binary size requirements for textures.
Makes this kind of stuff a pain I'm going to work on 'depaletizing' the texture The palette play I think is what is giving me troubles with OGL.  This reduces everything to 1 256x256 texture for me, so I have a 'new' time method that reads the time texture assuming color 0 is transparent anything else is opaque.  I think this will work for me though it does require yet another rewrite (sigh), it will only need to be done once.

Cyb

[ficedula]

Palettised textures are going to be a pain with OpenGL, because it doesn't (as you know) support them natively; there's an extension, which most modern cards don't support, because nobody uses paletted textures any more...

Converting them to 32-bit textures as you read them in is the best choice by a long way. When you're decoding the file format yourself, as you will be for TIM's, it's not really extra effort anyway.

The binary size requirement for OpenGL textures shouldn't give you any problems, though. If no polygon uses multiple palettes, then you can have one texture per palette, and each polygon uses one texture. If for some reason you REALLY need to have non-power-of-two-dimensioned textures (NPOTD), then there is an OpenGL extension to support that (at least one extension, maybe two), but your program isn't going to be fully portable if it uses that. Quality will suffer, too: there's good reasons why graphics cards prefer POTD textures.

[Cyberman]

Palettised textures are going to be a pain with OpenGL, because it doesn't (as you know) support them natively; there's an extension, which most modern cards don't support, because nobody uses paletted textures any more...

Converting them to 32-bit textures as you read them in is the best choice by a long way. When you're decoding the file format yourself, as you will be for TIM's, it's not really extra effort anyway.

The binary size requirement for OpenGL textures shouldn't give you any problems, though. If no polygon uses multiple palettes, then you can have one texture per palette, and each polygon uses one texture. If for some reason you REALLY need to have non-power-of-two-dimensioned textures (NPOTD), then there is an OpenGL extension to support that (at least one extension, maybe two), but your program isn't going to be fully portable if it uses that. Quality will suffer, too: there's good reasons why graphics cards prefer POTD textures.

My current method needs improving what I do is go through each part and check for textured triangles and quads then use the edges of where the trinagles and quads are to choose the texture information.  I 'assume' anything black is transparent. This is probably wrong but I couldn't think of any more convienent way

Unfortunately now my application just closes when I try viewing with OGl. I wish it left some error or the like darn it so I knew why it was being a whiner.

Cyb

[Cyberman]

Raw data from structure

Code: [Select]


Parts[35] =
{
//OFFSET ID UNKNOWN DATA
  000000  0 FFCE ff ce 1111111111001110
  000124  1 FF1F ff 1f 1111111100011111
  0003C8  2 FF69 ff 69 1111111101101001
  000B7C  1 FF21 ff 21 1111111100100001
  000000  4 FFC4 ff c4 1111111111000100
  000000  5 FF23 ff 23 1111111100100011
  001A44  6 FEEC fe ec 1111111011101100
  001D58  7 FFCC ff cc 1111111111001100
  000000  8 FF6A ff 6a 1111111101101010
  001FEC  7 FFC8 ff c8 1111111111001000

  000000 10 FF6A ff 6a 1111111101101010
  0020F0  7 FFC8 ff c8 1111111111001000
  000000 12 FF6A ff 6a 1111111101101010
  0021F4  7 FFCC ff cc 1111111111001100
  000000 14 FF6A ff 6a 1111111101101010
  0022F8  1 FF21 ff 21 1111111100100001
  000000 16 FFC4 ff c4 1111111111000100
  000000 17 FF23 ff 23 1111111100100011
  0023FC 18 FEEC fe ec 1111111011101100
  002710 19 FFCC ff cc 1111111111001100

  000000 20 FF6A ff 6a 1111111101101010
  0029A4 19 FFC8 ff c8 1111111111001000
  000000 22 FF6A ff 6a 1111111101101010
  002AA8 19 FFC8 ff c8 1111111111001000
  000000 24 FF6A ff 6a 1111111101101010
  002BAC 19 FFCC ff cc 1111111111001100
  000000 26 FF6A ff 6a 1111111101101010
  002CB0  0 FFD8 ff d8 1111111111011000
  000000 28 FEBB fe bb 1111111010111011
  002DB4 29 FF00 ff 00 1111111100000000

  002F88 30 FF6E ff 6e 1111111101101110
  0031EC  0 FFD8 ff d8 1111111111011000
  000000 32 FEBB fe bb 1111111010111011
  003670 33 FF00 ff 00 1111111100000000
  003844 34 FF6E ff 6e 1111111101101110
}

Inspection results of data

Code: [Select]


FF7 Object ENEMY019.LZS
LOC ID PART DESCRIPTION
0 0 NONE uncertain
1 1 1 Waist
2 2 2 Chest
3 1 3 Head
4 4 NONE uncertain
5 5 NONE uncertain
6 6 4 Right shoulder
7 7 5 Right Gun Hand
8 8 NONE uncertain
9 7 6 Left Talon?


10 10 NONE uncertain
11 7 7 Middle Talon 1?
12 12 NONE uncertain
13 7 8 Middle Talon 2?
14 14 NONE uncertain
15 1 9 Right Talon?
16 16 NONE uncertain
17 17 NONE uncertain
18 18 10 Left Shoulder
19 19 11 Left Gun hand

20 20 NONE uncertain
21 19 12 Right Talon?
22 22 NONE uncertain
23 19 13 Middle Talon1?
24 24 NONE uncertain
25 19 14 Middle Talon2?
26 26 NONE uncertain
27 0 15 Left Talon?
28 28 NONE uncertain
29 29 16 thigh?

30 30 17 shin?
31 0 18 foot?
32 32 NONE uncertain
33 33 20 shin?
34 34 21 foot?


After some careful tweaking through the unknown area you'll notice some information I've gathered. ID is not the object ID to be honest it's behavior is rather inconsistant with that possibility. My guess is it's more likely the parent.  The object format in FF7 is quite complicated (way too complicated I think hehehe) I've detailed an example of ENEMY019.
I can't get textureing working yet so I'm toying with this some trying to figure it out.
Anything with a REAL object on it has the offset > 0  almost always a non object referencing member has the same ID as it's index in the array. (Self referencing) they don't seem to mean ANYTHING at all actually
I think ID is actually PARENT information notice the arms and talons they all form a heirarchy.
How to string everything together is anyones guess. I think the none object referencing stuff merely indicates a 'break' in a group of objects.  This however gives no positional information. I've also noticed they throw in zero's at random seemingly into the array of references.  That I believe is elsewhere in the file. Pretty much section zero is resolved as far as I can tell
 The flag/whatever area is still the whatever area to me.. I've yet to make sense of it.
I think I'll have to next try and figure out the other sections (other than the TIM one).

[Desaigy Ouimate]

ok, i really shouldnt post because i have no idea what im talking about, but that said. what about viewing a full thingy. like all of tifa? or is that like, not possible?

[Cyberman]

ok, i really shouldnt post because i have no idea what im talking about, but that said. what about viewing a full thingy. like all of tifa? or is that like, not possible?

You're right you probably shouldn't post hehehe
No it's not.. I'm trying to figure out how it arranges the skeletal information and where that information is stored.  I have an idea it will just take a little while beating the data out of it.

Cyb

[mirex]

Desaigy Ouimate: it is possible, on FF7 PC

[Cyberman]

Desaigy Ouimate: it is possible, on FF7 PC

Oh.. yes forgot that.. what tool does that? I forget.

Kislinskiy:
No good fortune as yet, however the 'structure' hid in unknown 'makes' sense. It however doesn't give rotation and offsets.

However...
Section[0] contains
bone structure heirarchy
vertices
textured trii's
textured quads
tri's
quads

Something I've noticed about
Section[1]
it's ALWAYS about the same size. The bigger the model it grows bigger It doesn't vary a lot so the information contained in it is fairly static.  This I believe is the section that contains pertinent information about the model and it's sections. As the number of sections increase it increases in size. Thus I think it contains some important information. It's largest on the character models.

Hacking time Ciao

[Cyberman]

And now for something completely different.
First ALL the weapon models are stored with the character model.
The END of the character model is the TIM image in the file. However everything beyond that is a model for there weapons.  No Changes to decoding of the section need to be made, it decodes it as is just like section 0 is decoded. TADA!

That's IT I can view the weapons just dandy this way.

And here is the image to prove it!
Image removed Site is gone
PS only one.. we don't need all the weapons to see this fact.
PPS Each Character has 16 weapons.. low rez Sephiroth has 16 Masuami's for example.

[Kislinskiy]

That's a good news.  

Currently I have no time to look at the file format because i want to learn more on advanced OOP first (patterns, composition, delegation, interfaces etc.). Then I will try to code a well designed model viewer for this file format to continue decyrption more comfortable.  

[Cyberman]

That's a good news.  

Currently I have no time to look at the file format because i want to learn more on advanced OOP first (patterns, composition, delegation, interfaces etc.). Then I will try to code a well designed model viewer for this file format to continue decyrption more comfortable.  

Oh.. I take the other approach to things get something working for a bit then rebuild it after I see how far I can push it. I suppose I should try and make it more balanced. I've already had to introduce multithreading just so I can scan a disk without the form freezing.  I probably should do that for reading models as well. Lots of improvements to make.

Although I think soon I should be able to break the bone format, it's coming bit by bit. Now that I know what those extra things are past the TIM image are, I can focus on what's between the TIM and the model data.  Section 1 is the most suspicious one of these It contains a number of odd short ints and ints I think they are a list of offsets, there also seem to be a list of short ints later on.. I suspect they are bone offsets and rotations.

Anyhow glad you aren't dead.

I went back to my original 'extraction' method for textures (go through the textures and use the correct palette) this works correctly now.  My only problem is I need to blend the textures with the polygons now like decals in OGL

Cyb

[Kislinskiy]

A few things on textures:



Forget that about U = 1 - U.
Forget that about U/V correction.



fU = 1 / Width * U
fV = 1 / Height * V



HICLOUD-TIM (256x192, 8 bit):

0) 0...127,128...255
1) 0...127,128...255
...
191) 0...127,128...255

convert to:

0) 128...255,0...127
1) 128...255,0...127
...
191) 128...255,0...127

(Any other models with 8 bit TIM? Swap them too?)



CLUT information stored between textured triangle/plane data:

4 bit:

00 78 = CLUT 0
40 78 = CLUT 1
80 78 = CLUT 2
...

8 bit:
14 30 = CLUT 0



Evt. further changes of U/V mapping. Look at first textured part of ENEMY019.

[Cyberman]

Well I have the texture ordering almost right.. (heh)
So it reverses the UV coordinates on an 8bpp bitmap as oposed to a 4bpp bitmap? that's bizare. Of course as one person I heard say 'FF7 file formats are horribly complicated and the guy making them must have been horribly confused'

Cyb

[Kislinskiy]

Solution of the "Last Object Missed Problem"

"unknown structures" of ENEMY165:



number of structs
structs
point of interest

There is a UINT32 after the "unknown structures" and before the coordinates of the first visible object. This is an offset to a visible object like the first UINT32's of the "unknown structures".

Now we should not look at the "unknown structures" in this way:

number of structs
struct 0
struct 1
...
struct n
struct m

We should look at it in this way:

number of structs
offset 0 <- connector 0 -> offset 1 <- connector 1 -> ... <- connector n -> offset m

[Cyberman]

So basically it's a list of the number of 'information' structures surrounded by pointers?
I remember going through it Quite meticulously

So what we really have is

N Entries
One 32 bit empty pointer at the begining and
<heirchy> U16
<flags> U16
<Offset> U32
There always seems to be a reference to the last object as well.
So looking at it that way may make more sense (Shift the whole array by 4 bytes)
I know what you are (originally) saying however there are no links to anything real otherwise. If you shift it by four bytes and refer to it as that array then the data makes a bit more sense. Let me tinker with it and see if I can get anything useful.

Still haven't found the Structure of Section 1 yet but I think it has to do with the model standing still.

None of the numbers as yet make sense but I believe it's critical to knowing how to piece together the model (correctly). There are a series of short ints and long ints. Then what might be coordinates. I guess I continue to beat on the data tell I decipher it?

I looked at the data (the way I tweaked it) seems to make sense now really (with the offset at the end and skiping to an offset 12 to start looking at the structure).

Cyb

[PumpkinPieman]

Has anyone fully rendered Jessie? I remember going through with a model viewer and finding a Jessie model somewhere in there.

[Cyberman]

Has anyone fully rendered Jessie? I remember going through with a model viewer and finding a Jessie model somewhere in there.

These are battle models, scene models are included with the scenes they are in (IE say the reactor at the begining of the game or the train station).  Cloud Jesse Barret etc are all included in the actual scene. For battle the game loads in a different set of models (that look totally different as well). At the moment these models haven't been found or extracted by anything I've made

Cyb

[PumpkinPieman]

Yeah, the Jessie model I saw was a battle model; it was only the top half of Jessie so I assumed the viewer couldn't fully render the model.

[Cyberman]

Yeah, the Jessie model I saw was a battle model; it was only the top half of Jessie so I assumed the viewer couldn't fully render the model.

Jessie is not possible to have in a battle thus it can't be a battle model.  I've never seen Jessie in a battle in all the times I've played FF7 through the part Jessie is still alive. Jessie is never in  your battle group either. The only thing I can think of is someone extracted Jessie from a scene file and put it in a battle sccene (quite doable).

Sounds like something Ficedula would do with Zanan.

I made a 'exporter' plugin module for that and POV Ray, I suppose if I understood FF7 battle scenes well enough I could make something like Zangan.

Cyb

[PumpkinPieman]

By scene model you mean the low-poly model that you use to navigate the game right?

The model I saw was the top half of what appeared to be a battle model, or something that could have been possibly used in a battle sequence.

[Contra]

That model was used in the scene where you and Jessie are standing in front of the monitor, and she explains the Midgar rail system to you. I've seen it in the PC version, using I believe Ifalna. There is one of Cloud in the same scale.

-Contra-

[ShinRa Inc]

the highly detailed Cloud and half-Jessie models are never used in the game.  It's been theorized that Square was going to make higher-resolution models throughout the game, but gave up, leaving what you see there.

[Contra]

Are you *sure* they aren't used when Cloud and Jessie are looking at the railway map?

I mean, I could be wrong, but I really think they are.