FF7PC Field File stuff.

[Kero]

Thanks ficedula.

Here comes more accurate decription of section 3
Field file - section 3
======================

This section is about data for showing 3d objects actually to screen, to do that you need some external data and names of files for these data is what is stored here.
Note to position: I am changing sign or something like that so, if you will take x,y,z and change signs according to me, you will get correct position in walkmesh. I just load walkmesh. coordinates [x,y,z] in walkmesh are just x,y,z. No change.

Code: [Select]


typedef struct {
  S16   blank; //  always zero
  S16   numchar; // number of characters
  S16   size;    // same as size
  object charinfo[numchar];
} sec3;


Lets dig in. Sec3 is structure for complete file.
blank - always zero.
numchar - number of 3dobjects in field. Although it is named char(acters), it can be anything, savepoint, treasure box...
size -- everywhere I lookes was same as size after .HRC (look below for more info), but nothing happend if I changed it(PC version). I thought it is maybe backup if size is not define after HRC then use this. Again wrong. Well, I dont know what it is for, just give it same size as you give after ????.HRC. It doesnt resize walkmesh either. Maybe obsolete from development when they thought it would be nice to have one resize for all and after that they thought it would be nice to let every object have different resize.

Code: [Select]

 
typedef struct {
  S16   charnamelen;
  chars charname[charnamelen];
  S16   blank;     // 0 end of string?
  char  skeletname[12];  // AAAA.HRC1024 or AAA.HRC512\0 - just 12 chars, no ending zero
  U16   numani;        // number of animation or whatever it is. see ani[]

  light_s light[3];  
  U8      ambientred;
  U8      ambientgreen;
  U8      ambientblue;
 
  animation ani[numani];
} object;



After few necessary information comes numchar * structure object. It has all information for 3dobject - name of skeletonfile, animations and such.
charnamelen - lenght of name for this object. Not really sure, whether there are some rules, but every name I have seen was something like [name_of_location_file][description_of_object_or_its_name][separator, is always 0x2E]char -> eg. condor1main_n_cloud\0x2Echar .charname is string without ending zero, only characters of string.
blank - seems to be always zero
skeletname - every skeleton file for field is 4 chars long (eg. AAER). Then there is separator 0x2E, chars HRC and after this is number of maximum four digits (often 512 or 1024 ). This number define resize value. Every skeleton has some lenght of bones, its .p files have vertexes with some coordinates for x,y,z. These coordinates and lenghts are to be multiplied by this number. TO sum it up, this number define how bigger object will be than is in original files (I hope, I maybe there is some sort of fixed point, but bigger this number is, bigger object on screen). (look ar http://www.ms.mff.cuni.cz/~havlj3am/FF7/condor1_hrc768.png and compare with http://www.ms.mff.cuni.cz/~havlj3am/FF7/condor1_hrc1024.png)
numani - number of animation for this object

Code: [Select]


typedef struct {
  U8         red;         // composition of light for spotlight
  U8         green;
  U8         blue;
  vector3S16 pos;         // position. I walkmesh [-x,-y,z]
} light_s;


light[3] - every object has three light sources, you can choose its position (distance from [0,0,0]: square often use something around 4103+-5, I have seen 2095... just use imagination) and intensity of each component of light. The bigger is vale for some component the more it will take effect (you can use red for bloodfiled ^__^). Position has to be adjusted.

Code: [Select]


  pos.x = -x;
  pos.y = -y;
  pos.z = z;


after lights with source, there is ambient light (light that is everywhere, no shading), again, you can define intensity of each component. Picture will show how does ambient light look, so I dont have to explain.

Code: [Select]


typedef struct {
  S16 lenght;  // how long will be anme of next animation
  char name[lenght];  // ACFE.aki | ADCC.tor | ????.yos // . == 2E
  S16 unknown; // often 0x0001 - maybe end of string?
} animation


And last part of are animation. There is numani * structure animation.
lenght - lineght indicator for animation
name - string without zero at the end. [name_of_animation_file][separator 0x2E][aki^yos^anm] like GWIE.anm, HOJD.yos, AAGA.aki ...What is meaning in different suffixes I dont know.
unknown - seems to be always 0x0001

Created by Kero ([email protected])
If you find error, PM me or mail me.
I spent some time researching and writing this (10hrs, light were nasty), so if you find this usefull and write program be so kind let me know.
Thx goes to ficedula, halkun, alhexx..

EDIT:
TODO
sec3.blank - always zero.
sec3.object[].blank - zero or 1.  Nothing changed even if I set it to 0x11. Dont know purpose.
sec3.object[].ani[].unknown - various values from 0 to +-200

Link to simple convertor from sec3 to human readable format and it's source
You may need to use section divider (src).

[Kero]

Field file - section 8
========================

Gatways - thats how I call areas on which you step and you are transffered to another location.
Every every offset is here relative, 00 is at the start of section 8 (after lenght indicator).
Gateways and related data are stored in section 8 of field files. Section 8 is always 740 bytes long, maximum of gatways for one location is 12.
Stucture of section>
 * header
 * gateways
 * triggers
 * singles
 * triangles

 

Code: [Select]


typedef struct {
  S16 x;
  S16 z;
  S16 y;
} vector3S16;

typedef struct {
  S16 left;
  S16 bottom; // maybe top, I dont know/care Its nearly always centred
  S16 right;
  S16 top;    // maybe bottom.
} range;


header
======

Code: [Select]


typedef {
  char name_of-location[8];
  U32 movement;
  range picture;
  U32 blank;
  range range1;
  U32 blank1[6];
} sec8header`


movement - what direction will character go if you push up, down,left,m right. 128 (0x80) is key-direction (up-up, right-right, down-down, left-left), for 64 (up-right,right-down,down-left,left-up), 32 (up-leftup,right-leftdown,down-rightdown,left-topright)....i dont know how these directions are called.

range picture - you have noticed that your character stays in the center of screen, unless you are near of borders of picture(if you are there, character wont be in the middle, but can move to the very border of image ... well if you define range of picture smaller than is walkmesh, you character can walk out of screen and you wont see it at all). This is what define these borders. Values are in pixels, range if defined from the center of background image (bg image is 300*200 and you define left = - 145, right = 145, top = 98, bottom = -98).

range 1 - well, I dont know if it really is range, just unknown values, probably not, but better than writing four unknown values, every is 1024.
blank,blank1 - seem to be zero, have to run statistical test.

Thats all about header.


Gateways
========
 gateways starts on offset 0x38 from the start of section.

Code: [Select]


struct {
  vector3S16 corner1;
  vector3S16 corner1;
  vector3S16 pos; // place where char will apear after transfer.
  S16 destindex; // index in maplist
  U32 unknownl; // 0x84848484 ot zero ?
}gateways;


corner 1 and corner2 defines two corner of 3D area in which if you go, you will trigger the gateway and will be transferred do destination. pos is position in destination (x,y,z) where you will appear. Just look at walkmesh value and choose some number so you are ON walkmesh and not BELOW. also you have to snad on some polygon of walkmesh (obviously).
destindex is index destination. Every location has its index defined in maplist (or something like that). In maplist are first 64 +-1 destinations on worldmap. If you swap two destinations in maplist, nothing happens, it is probably only for referrence and doesnt actually determine index of location. As every part of sectio 8 has 12 structures. If destination is 7FFF {maximum positive number for S16} then gateway is not active.


Triggers
===================
from offset 0x158 till 0x218 - size of 1 item is 16

Code: [Select]



struct {
  vector3S16 corner1 ; // 6
  vector3S16 corner2 ; // 6 12
  U8 enterstate;   // I have more or less faith into defaultstate, but not these two
  U8 leavestate;   // names are probably wrong
  U8 defaultstate; //
  U8 sound; // index zvuku, ale v jake databazi?
} triggers



if you step in/out area between corner1 and corner2, you will
 * hear sound with id sound (dont know where is table for indexes)
 * there will be chage in background (mostly used for opening/closing doors)
 
  enterstate - what sprite show if you enter into area
  leavestate - what sprite show if you leave area
  defaultstate - what sprite show at the start
   These three values are somehow connected to background, at first I thought they define what part of script shoud be called if stepper into/out, but it doesnt seems so (nearly sure, I changed script and changes of background stayed). Still not toos sure about WHAT they are indexing. Have to research section 9 properly.

Singles
======
from offset 0x218 till 0x224
one byte for one item. Dont know what these are for. Values 1 or 0


triangles
==========
from 0x224, lenght of setion 192 -> 16 bytes per item.
This part determines where the red triangles showing where is gateway in the game appear on the screen.

Code: [Select]



struct {
  S32 pos.x;
  S32 pos.z;
  S32 pos.y;
  S32  visible; // is it visible? 01 true 00 false
} triangles;



pos - position in walkmap. No sign changes necessary.
visible -  0 - trinagle is not visible
           1 - triangle is red
           2 - trinagle is green
          >2 - trinagle is red
        - I am not really sure if all bytes from U32 are used only for visibility - >run statistical correction

TODO:
triggers[].*state
triangles[].unknown
rest of header
statistical correction for visible
spelling&grammar check

Now we can sum it all.
Field  files - we know how sections are defined.

Every section stores specifical data.
section   purpose
1         Dialogs and game scripts
2         Camera,its direction and position, FieldOfView
3         Names of files for loading 3d models - meshes, skeletons, animations  
4         Palette
5         walkmesh
6         Junk data
7         random enemies
8         Gateways
9         Background images and sprites

Section 1 scripts ect. are not decoded enough, I dont think we can make our own.
Section 2 - meaning of values decoded from 90%, interpretation from 70%. atribut size somehow define viewvolume, unfortuantelly not enough for practical use.
Section 3 -  enough for practical use. 95%
Section 4 pallete - compleatly decoded
Section 5 walkmesh - decoded.
Section 6 - trash, just copy from another field file

I checked section 6 and it really is pure trash. More correctly, I replaced 25 000 bytes long section 6 in wutai with 2 500 bytes long from condor1 and hadnt see any difference in behaviour of filed. Maybe I just didnt pay enough attention, but for now, lets call it junk, trash....

Section 7 random enemies - I have seen it decoded somwhere, but dont know where
Section 8 enought for practical use.
Section 9 - havent looked enought into this, but I dont think document ficedula&qhimm  wrote is enough (I would like to see sources of 7mimic),

I think I did good job in decoding. But still not enough for good field file editor.

[Cyberman]

Interesting stuff, the fact they used ambient lighting interests me.  Perhaps they planed on using this to make the person look like they are in a light or dark place. In other words in shadow or outdoor light, or maybe that was there intention and they never got around to it as well. (Yet another than to add to the engine (Check ambient lighting for ambient lighting affects ).

The walk meshes seem a bit large for just one field location.  Are they for a single or multiple field locations?  There must be 'gateways' located within the mesh's bounds.  What is the purpose of red versus green triangles. I don't recall that in the game.

This is of course for the PC version of the game (section 1 - 9 are different on the PSX). However it is very good you provide this information I can examine the PSX data and compare results
I just started ploinking on my viewer and have been improving it's basic functionality bit by bit.  I'll post some fun things I have been informed of in another thread (FF8 related).

I suppose my next task is finding the walk mesh in the PSX data.  It appears that section 9 is located in the ??.MIM files and the remaining sections are located in the ??.DAT files. Do you know where the field models are kept in the game? Maybe section 6 is a redundant copy of the PSX field model information (??.BSX files)? Just a possibility you might not have considered.


Cyb

[Kero]

Interesting stuff, the fact they used ambient lighting interests me.  Perhaps they planed on using this to make the person look like they are in a light or dark place. In other words in shadow or outdoor light, or maybe that was there intention and they never got around to it as well. (Yet another than to add to the engine (Check ambient lighting for ambient lighting affects ;) ).

I dont think so, ambient lightning is normally replacement for radiosity, but it takes much less time(and results are of course far from real, but sufficient), and is used (ambient light) in most games I have seen.  OpenGl model for light:

Emitted, Ambient, Diffuse, and Specular Light
Emitted light is the simplest - it originates from an object and is unaffected by any light sources.

The ambient component is the light from that source that's been scattered so much by the environment that its direction is impossible to determine - it seems to come from all directions. Backlighting in a room has a large ambient component, since most of the light that reaches your eye has bounced off many surfaces first. A spotlight outdoors has a tiny ambient component; most of the light travels in the same direction, and since you're outdoors, very little of the light reaches your eye after bouncing off other objects. When ambient light strikes a surface, it's scattered equally in all directions.

Diffuse light comes from one direction, so it's brighter if it comes squarely down on a surface than if it barely glances off the surface. Once it hits a surface, however, it's scattered equally in all directions, so it appears equally bright, no matter where the eye is located. Any light coming from a particular position or direction probably has a diffuse component.

Finally, specular light comes from a particular direction, and it tends to bounce off the surface in a preferred direction. A well-collimated laser beam bouncing off a high-quality mirror produces almost 100 percent specular reflection. Shiny metal or plastic has a high specular component, and chalk or carpet has almost none. You can think of specularity as shininess.

Although a light source delivers a single distribution of frequencies, the ambient, diffuse, and specular components might be different. For example, if you have a white light in a room with red walls, the scattered light tends to be red, although the light directly striking objects is white. OpenGL allows you to set the red, green, and blue values for each component of light independently.

The walk meshes seem a bit large for just one field location.  Are they for a single or multiple field locations?  There must be 'gateways' located within the mesh's bounds.  What is the purpose of red versus green triangles. I don't recall that in the game.

I dont recall red x  green either, its just color. I dont understand what do you mean by "walk meshes seem a bit large"? One walkmesh is for one field file (although some locations use same walkmesh, but every field file has its own). You just see part of location and move on it. Character stays in the center of screen (excpet : see header of  section 8: range picture).  Walkmesh is defined through vertexes and triangles. Each gateway is defined through two coreners of block.  These corners are defined in walkmesh. If walkmesh is onw triangle (x,y,z, left handed coordinates) [0,0,100],[-100,0,-50],[100,0,50] and you define corner one and two as [-10,0,10]x[10,10,-10] then if you step in the middle of triangle you will be transffered into different location.

I suppose my next task is finding the walk mesh in the PSX data.  It appears that section 9 is located in the ????????.MIM files and the remaining sections are located in the ????????.DAT files. Do you know where the field models are kept in the game? Maybe section 6 is a redundant copy of the PSX field model information (????????.BSX files)? Just a possibility you might not have considered.

I have never seen FF7 in PSX version, so I cant help at all.
In PC version field characters are stored in  /data/field/char.lgp. You can view them in ilfana.

[Cyberman]

I dont think so, ambient lightning is normally replacement for radiosity, but it takes much less time(and results are of course far from real, but sufficient), and is used (ambient light) in most games I have seen.  OpenGl model for light:

Hmmm I'm not sure they used lighting for any of the battle models.  I also don't  recall if the characters lighting changes at anytime during the game.

Lighting information removed I know quite a bit about lighting types and differences in them etc.  Phong (specular diffuse) Tarus Sparrow models (similiar to Phong only closer to reality) etc etc. I did a few papers on it over 15 years ago  I still even dabble in it but I don't have as much time as I use to.  Anyhow what I was really asking is there more than one ambient light definition and if so is it based on the triangles in the walk mesh.  I doubt they have any real light sources, though it is possible to do that on the PSX hardware (just slow).  

I dont recall red x  green either, its just color. I dont understand what do you mean by "walk meshes seem a bit large"? One walkmesh is for one field file (although some locations use same walkmesh, but every field file has its own). You just see part of location and move on it. Character stays in the center of screen (excpet : see header of  section 8: range picture).  Walkmesh is defined through vertexes and triangles. Each gateway is defined through two coreners of block.  These corners are defined in walkmesh. If walkmesh is onw triangle (x,y,z, left handed coordinates) [0,0,100],[-100,0,-50],[100,0,50] and you define corner one and two as [-10,0,10]x[10,10,-10] then if you step in the middle of triangle you will be transffered into different location.

So basically each field file stores the entire walk mesh for the area it's in with new exits and and camera information for each.  That makes sense.

I have never seen FF7 in PSX version, so I cant help at all.
In PC version field characters are stored in  /data/field/char.lgp. You can view them in ilfana.

Are those just the character models? (They are stored as <NAME>.BCX on the PS1 version.)  Do you know if that includes the different field models for each field location? Each fiel d location has a unique set of field models that appear at that location. Such as wutai and midguard.  Characters are stored seperately.   Combat dialogs such as the ProudClod scene are just that combat models and are not in Field models.  It means for example in the Shinra building top floor there are President Shinra Rufus and any other model of a NonPlayer Character stored in it that is at that field location.
I believe Micky posted the information reguarding the field models etc.

In any case it's not a big deal.

Cyb

[halkun]

I think I did good job in decoding. But still not enough for good field file editor.

It's not so much an editor that would be cool, but a "player" would be kind of nice. That's where I think efforts should be aimed towards.

[L. Spiro]

It is all good and useful as well.
I will need it for my engine, but you go too fast.

I haven’t started programming this into my engine yet, because, to be honest, at times your notes are very confusing.

In the beginning I simply could not follow your notes, but I know that since then you have rewritten things, and if I take the time to read this entire post I can probably put it all together.

Whenever you’re done with this, figure out the battle animation format.

I will look over this all in more detail when I am ready for this addition to my engine, but for now it seems to be nice work that (seemingly) no one else here could do.


L. Spiro

[Kero]

It is all good and useful as well.
I will need it for my engine, but you go too fast.

Dont worry, there is nothing wrong with it. I did walkmesh 3 months ago and then was long pause and I did something again.

I haven’t started programming this into my engine yet, because, to be honest, at times your notes are very confusing.

I guess (especially the one from 2004-09-27 13:35 ).  Mostly I add a lot of new information and post new reply while old one if still there.

Well, the worst is field scripting, without it this cant do nearly anything. Field scripts are the core, but PSX version is far more suitable for that. Oh well.

Anyhow what I was really asking is there more than one ambient light definition and if so is it based on the triangles in the walk mesh. I doubt they have any real light sources, though it is possible to do that on the PSX hardware (just slow).

Every character is rendered with three spotlights (probably just descover intensity in corners of triangles and then gourard (phong is too difficult for PSX I think)) and ambient light. Every character  have definition for these lights, although it is same for character in file I have seen,  I can be defined per case. They are not based on triangles (or at least I dont know)

[ruby54501]

I was told by Eidos Support that this is why the company stop support for FF7 six years ago cause they could'nt fix the crash! Did some one else? I have use all the downloads no go! Or can I just skip this!