MAP (file format): Difference between revisions
SirYodaJedi (talk | contribs) m (→Variants) |
SirYodaJedi (talk | contribs) m (→Entities) |
||
| Line 62: | Line 62: | ||
Each plane can be summed up like so: | Each plane can be summed up like so: | ||
<pre> | <pre> | ||
( x1 y1 z1 ) ( x2 y2 z2 ) ( x3 y3 z3 ) TEXTURENAME | ( x1 y1 z1 ) ( x2 y2 z2 ) ( x3 y3 z3 ) TEXTURENAME Uoffset Voffset rotation Uscale Vscale | ||
</pre> | </pre> | ||
* {{code|( x1 y1 z1 ) ( x2 y2 z2 ) ( x3 y3 z3 )}} is the set of three points in 3D space that define the plane. | * {{code|( x1 y1 z1 ) ( x2 y2 z2 ) ( x3 y3 z3 )}} is the set of three points in 3D space that define the plane. | ||
* {{code|TEXTURENAME}} is the name of the [[texture]] (or in later engines, the [[material]]) that appears on the face. | * {{code|TEXTURENAME}} is the name of the [[texture]] (or in later engines, the [[material]]) that appears on the face. | ||
* {{code| | * {{code|Uoffset Voffset}} offsets the UV coordinates of the plane, resulting in shifting the texture on the U and/or V axis. These are projected onto the face using axial projection. | ||
* {{code|rotation}} doesn't store the actual rotation of the texture, but rather how much the texture has already been rotated{{clarify}}. | * {{code|rotation}} doesn't store the actual rotation of the texture, but rather how much the texture has already been rotated{{clarify}}. | ||
* {{code| | * {{code|Uscale Vscale}} stores the texture scale. 1 means the texture is displayed at 1 texel per quake unit. | ||
{{note|The original Quake I compilers only supported integer coordinates, but most forks and all subsequent compilers support floating point coordinates in addition to integer coordinates. Nonetheless, it is preferable to only store brushes using floating point when necessary, to avoid floating point precision loss errors. This is less important for point entities, which cause fewer issues when off-grid.}} | {{note|The original Quake I compilers only supported integer coordinates, but most forks and all subsequent compilers support floating point coordinates in addition to integer coordinates. Nonetheless, it is preferable to only store brushes using floating point when necessary, to avoid floating point precision loss errors. This is less important for point entities, which cause fewer issues when off-grid.}} | ||
| Line 76: | Line 76: | ||
The original Quake MAP format uses axial projection to apply textures onto faces. This results in undesirably stretched textures on slanted surfaces. To rectify this, Valve came up with the Valve220 format, which stores the texture offsets as 1-dimensional arrays, instead of singular numbers, as so: | The original Quake MAP format uses axial projection to apply textures onto faces. This results in undesirably stretched textures on slanted surfaces. To rectify this, Valve came up with the Valve220 format, which stores the texture offsets as 1-dimensional arrays, instead of singular numbers, as so: | ||
<pre> | <pre> | ||
( x1 y1 z1 ) ( x2 y2 z2 ) ( x3 y3 z3 ) TEXTURENAME [ | ( x1 y1 z1 ) ( x2 y2 z2 ) ( x3 y3 z3 ) TEXTURENAME [ Ux Uy Uz Uoffset ] [ Vx Vy Vz Voffset ] rotation Uscale Vscale | ||
</pre> | </pre> | ||
The first three values of each texture offset array are | The first three values of each texture offset array are the normal vectors of the U and V axes. The third value is the offset itself, like the axial projection format. | ||
{{modernConfirm|Make sure this explanation of the offset arrays is actually accurate.}} | {{modernConfirm|Make sure this explanation of the offset arrays is actually accurate.}} | ||
Revision as of 18:11, 20 September 2023
This page covers all major variants of the MAP file format, beyond that which is used by
GoldSrc, to provide a comprehensive overview of the file format as a whole and explain why compatibility isn't trivial.The MAP file format is a plain-text file format used by GoldSrc, 
id Tech 2, 
id Tech 3, and 
id Tech 4, which stores entities and level geometry in a format which can be understood by the map compilers (and in the case of id Tech 4, the game itself).
At its core, the format consists of several entities, each of which is optionally capable of storing one or more brushes and (only in ) patch meshes.
Variants
| Header text | Supported by | Information |
|---|---|---|
| Quake I (Legacy) |
Most tools, except  Hammer 4.x |
The original format. |
| Quake I (Valve220) |
All GoldSrc tools, most modern Quake Engine tools, and Hammer 4.x |
Variant of the Quake 1 (Legacy) format with additional texture UV precision. Introduced by  Worldcraft 2.0; now standard.
|
 Quake II (Legacy) |
All Quake II Engine tools, and most id Tech 3 tools |
Variant of Quake 1 (Legacy) format which optionally stores three additional WAL metadata flags. |
| Quake II (Valve220) |
 J.A.C.K.,  NetRadiant-Custom, and  TrenchBroom |
Variant of Quake 2 (Legacy) format with Valve220-style UVs. Introduced by J.A.C.K.; now standard.
|
| Quake III (Axial Projection) |
All id Tech 3 tools
|
Variant of Quake 2 (Legacy) format with support for patch meshes (IdTech's equivalent to displacements that use bezier curves), and which can store brushes as primitives instead of a set of planes (allowing for more precise vertex coordinates).
While Quake 3 MAP files can technically store both standard brushes and brush primitives, map editors usually require selecting one or the other to write the file as. The Quake 3 MAP format still supports the metadata flags from Quake 2, including on patch meshes and brush primitives, although only the detail flag (0x08000000) is ordinarily used; this information is instead usually stored in the material definitions. |
| Quake III (Brush Primitives) |
Most id Tech 3 tools, except TrenchBroom
| |
| Quake III (Valve220) |
J.A.C.K., NetRadiant-Custom, TrenchBroom |
Variant of Quake 3 format with Valve220-style UVs. Introduced by J.A.C.K.; not yet standard.
|
| Doom 3 (Axial Projection) |
All id Tech 4 tools
|
Variant of Quake 3 format which can store patch meshes and brush primitives differently [Elaborate?].
Like Quake 3, a map can technically store both standard brushes and brush primitives, but editors write the files as one or the other. Standard brushes are generally considered deprecated in favor of brush primitives. |
| Doom 3 (Brush Primitives) |
Most id Tech 4 tools, except TrenchBroomBFG
| |
| Doom 3 (Valve220) |
TrenchBroomBFG | Variant of Doom 3 (Legacy) format with Valve220-style UVs for standard brushes. Introduced by TrenchbroomBFG; not standard. |
Entities
KeyValues
Brushes
In most versions of the format, brushes are stored as a set of planes, rather than a set of vertices. Each plane is defined via three points, and the intersection of these planes determines where edges and vertices lay. Due to this, brushes cannot be concave, and a missing face will result in other faces continuing infinitely, causing compiler errors.
Quake I
A simple 6-sided brush in the original Quake 1 format would look like this:
{
( 256 64 16 ) ( 256 64 0 ) ( 256 0 16 ) mmetal1_2 0 0 0 1 1
( 0 0 0 ) ( 0 64 0 ) ( 0 0 16 ) mmetal1_2 0 0 0 1 1
( 64 256 16 ) ( 0 256 16 ) ( 64 256 0 ) mmetal1_2 0 0 0 1 1
( 0 0 0 ) ( 0 0 16 ) ( 64 0 0 ) mmetal1_2 0 0 0 1 1
( 64 64 0 ) ( 64 0 0 ) ( 0 64 0 ) mmetal1_2 0 0 0 1 1
( 0 0 -64 ) ( 64 0 -64 ) ( 0 64 -64 ) mmetal1_2 0 0 0 1 1
}
Each plane can be summed up like so:
( x1 y1 z1 ) ( x2 y2 z2 ) ( x3 y3 z3 ) TEXTURENAME Uoffset Voffset rotation Uscale Vscale
- ( x1 y1 z1 ) ( x2 y2 z2 ) ( x3 y3 z3 ) is the set of three points in 3D space that define the plane.
- TEXTURENAME is the name of the texture (or in later engines, the material) that appears on the face.
- Uoffset Voffset offsets the UV coordinates of the plane, resulting in shifting the texture on the U and/or V axis. These are projected onto the face using axial projection.
- rotation doesn't store the actual rotation of the texture, but rather how much the texture has already been rotated[Clarify].
- Uscale Vscale stores the texture scale. 1 means the texture is displayed at 1 texel per quake unit.
Note:The original Quake I compilers only supported integer coordinates, but most forks and all subsequent compilers support floating point coordinates in addition to integer coordinates. Nonetheless, it is preferable to only store brushes using floating point when necessary, to avoid floating point precision loss errors. This is less important for point entities, which cause fewer issues when off-grid.Valve220
The original Quake MAP format uses axial projection to apply textures onto faces. This results in undesirably stretched textures on slanted surfaces. To rectify this, Valve came up with the Valve220 format, which stores the texture offsets as 1-dimensional arrays, instead of singular numbers, as so:
( x1 y1 z1 ) ( x2 y2 z2 ) ( x3 y3 z3 ) TEXTURENAME [ Ux Uy Uz Uoffset ] [ Vx Vy Vz Voffset ] rotation Uscale Vscale
The first three values of each texture offset array are the normal vectors of the U and V axes. The third value is the offset itself, like the axial projection format.
Confirm:Make sure this explanation of the offset arrays is actually accurate.The Valve220 format was introduced for Half-Life, and is required for GoldSrc compilers. Since the BSP format used by all IdTech engine games store UV coordinates that are at least as accurate as Valve220 (and sometimes moreso), the Valve220 format has mostly supplanted the legacy axial projection format by mappers, as many modern compilers for IdTech engines support Valve220.
The worldspawn KeyValue pair "mapversion" "220" indicates that a MAP file uses Valve220 texture projection. This KV should be stripped from the compiled BSP by compilers, as the lack of a preceding underscore means it will be read by the game engine. Map decompilers that output to Valve220 should in turn add the KV if it is not already present.
Patch meshes
See also
- VERC/MAP file format - casual explanation of the Quake 1 Valve220 MAP format
- VMF
- RMF
