Difference between revisions of "Track element building"

From Stunts Wiki
m (Track element assembly moved to Track element building: Calling things "assembly" at this stage is confusing =D)
(No difference)

Revision as of 18:35, 5 March 2010

This article aims to present what is currently know on how Stunts stores the data which is used to assemble track elements such as roads, bridges, loops and scenery. The ultimate goal is to be able to effectively modify the existing elements and create new ones. There is still much to learn before that becomes possible, though - which also means there will be large gaps on this article for the time being.

General observations

Track elements have two different models. The graphical model consists of a 3D shape stored in either of GAME1.P3S or GAME2.P3S . Like any regular 3D shape, it can be modified using stressed. The graphical model, however, only controls the looks of the element. Actual physical behaviour is determined by a physical model. The physical model data appears to be spread over a number of files, and only parts of such data were located thus far. Briefly, track elements are made of potentially several plane surfaces, whose description is stored at the plan resource of GAME.PRE . Such plane surfaces, which are in principle boundless, are then weld together by a set of rules stored elsewhere. Another important piece of data which is not in plan is the type of surface associated with each plane (asphalt, grass, etc.). It is important to notice that plane surfaces in plan are not unique - for instance, the same planes are used for creating hill slopes and bridge ramps, and thus alterations to the plane surfaces will be reflected in both elements. The difference between the two elements is merely one of assembly - that is, where the planes are cut within the track tile in order to result in the track element shape. A similar situation is observed for the cork l/r and the pipe round surface. GAME.PRE also contains the wall resource, which stores data for non-drivable surfaces (such as bridge and building walls) in a poorly understood format.

GAME.PRE data

The plan resource

plan is composed of 536 structures of 34 bytes each, each associated with a plane which in turn forms part of a drivable surface. The structures consist of:

struct PLANE {
    WORD angleYZ;
    WORD angleXY;
    VECTOR origin;
    VECTOR normal;
    VECTOR[3] rotationMatrix;
};

In the above, WORD = 2-byte signed integer and:

struct VECTOR {
    WORD x;
    WORD y;
    WORD z;
};

origin sets a point in space belonging to the plane (coordinate system is the same track tile system of the 3D shapes in GAME1/2), and normal sets a normal vector to the plane "normalized" to a length of 8192. These two vectors are enough to define a (boundless) plane. angleYZ and angleXY appear to contain the inclination of the planes (given in units of 360/1024 degree, with values ranging form 0 to 1023). Since such data is made redundant by origin and normal and the values have no obvious effect on the surface behaviour their actual function is unknown. Finally, rotationMatrix appears to be a rotation matrix (of column vectors "normalized" to 16384) which changes the orientation of the car normal vector when it changes surfaces. It must be correctly set so that the surface displays reasonable physical behaviour.

The 536 structures in plan are arranged in 134 sets of 4 plane surfaces. Each plane in these quartets corresponds to the same part of the associated track element(s), the only difference being orientation relative to the track grid. The order on each quartet is predictable: the first one is in S->N orientation (pointing to +z) and the others correspond to counter-clockwise rotations (for pieces of bridge corners and banked roads, the first plane of the quartet is from the corner going S->W, the second one E->S and so on.).

List of planes

Collapsed table - use the "show" button to view it.

The wall resource

wall is composed of the following structures:

struct WALL {
    WORD angleXZ;
    WORD x;
    WORD z;
};

The data in these structures appear to be ground-plane projections of wall segments, with x and z making endpoints and angleXZ defining segment angles. Verification of that, and identification of wall pieces, is best performed by plotting the x and z values. There must be additional pieces of data involved in wall assembly through, as there is no info on wall heights, nor any obvious link to data in plan; also, simple alterations to wall pieces associated with elements such as block houses or slalom blocks do not work as intended.

External links