I can help with the PC version; you load the models from Section 3; structure,
struct FF_MODEL_LOADER
{
U32 sectionLength;
U16 _blank;
S16 nObjects;
U16 size;
std::vector<FIELDOBJECT> fieldObjectSet;
};
Each object has this structure;
struct FIELDOBJECT
{
S16 nameLength; // Length of string "szName"
_STRING szName; // Object name (purely representative; doesn't correlate to a physical file)
S16 _blank;
CHAR szSkeletonName[12]; // Model file the object uses
U16 nAnims; // Number of animations found in animSet
LIGHT light[3]; // Three point lights
COLOR<U8> ambient; // Ambient lighting
std::vector<ANIMATION> animSet; // Animation files this object uses
};
/// Lights used for field models, containing colour and position
struct LIGHT
{
COLOR<U8> col;
VERTEX<S16> pos;
};
/// Holds name length, and name, of an animation file
struct ANIMATION
{
S16 nameLength;
_STRING szAnimName;
S16 _unknown;
};
/// Holds a colour triple
template <class type>
struct COLOR
{
type r, g, b;
};
(For the object name: at a guess, the models were originally previewed, lit and animated using a seperate tool/app, then linked into the field file, with their original filenames preserved. It doesn't serve any purpose in the game).
Each field object is linked to a particularly entity if that entity has a CHAR as its first opcode in its first script. Take a look at my explanation of the
CHAR opcode on the wiki for more information; basically, while scanning through the script if you encounter a CHAR opcode, assign the next field object to the current entity (whose script you are scanning) and advance the 'field object pointer' to the next entry in the field object set. Ignore the CHAR argument as it has no bearing on the field object loaded for that model; the second example on the wiki entry demonstrates the numerical argument doesn't represent an offset into the model list.
In addition the PC opcode defines a playable character though I'm not 100% on how it works; I tweaked it around a little and the sole argument seems to follow the standard Character IDs (0: Cloud, 1: Tifa, 2: Barret and so on), but this would appear to override the field object's model file setting, so I'm not too sure.
Doors aren't 3D, they are part of the background, and linked to entities that open/close the doors using BGON and BGOFF opcodes to switch parts of the background on and off (i.e particular doors), as well as Triggers from Section 8 which, when crossed, run the particular scripts containing said BGON/BGOFF in the entity that manages the door. There's (usually?) one entity per door.
Not sure about max. number of objects on the field. Theoretically I suppose you could have 256 on a field, since the section 1 "number of visible entities" variable is a byte value.
[Edit] Thought I should also mention, most field objects have an XYZI to initially position them on the walkmesh, but not all. For example, often Cloud doesn't have one, because he can be positioned by the previous field when the player crosses a Gateway (section 8.) which contains the coordinates that the character should be at when the next field loads up. If you get all these factors right I reckon it should look a little like so;
Blue squares being field objects, light blue lines of the same colour are the scripted LINE opcodes.
