MAP (file format): Difference between revisions

From Valve Developer Community
Jump to navigation Jump to search
Line 61: Line 61:


==== Quake I (Valve220) ====
==== Quake I (Valve220) ====
{{todo|explain}}
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 [ Tx1 Ty1 Tz1 Toffset1 ] [ Tx2 Ty2 Tz2 Toffset2 ] rotation Xscale Yscale
( x1 y1 z1 ) ( x2 y2 z2 ) ( x3 y3 z3 ) TEXTURENAME [ Tx1 Ty1 Tz1 Toffset1 ] [ Tx2 Ty2 Tz2 Toffset2 ] rotation Xscale Yscale
</pre>
</pre>
{{todo|Explain the arrays}}
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.


=== Patch meshes ===
=== Patch meshes ===

Revision as of 15:19, 20 September 2023

Stub

This article or section is a stub. You can help by expanding it.

The MAP file format is a plain-text file format used by GoldSrc GoldSrc, id Tech 2 id Tech 2, id Tech 3 id Tech 3, and id Tech 4 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 id Tech 3id Tech 4) patch meshes.

Template:ModernWarning

Variants

Header text Supported by Information
Quake Quake I (Legacy) Most tools, except Hammer Hammer 4.x The original format.
Quake Quake I (Valve220) All GoldSrc GoldSrc tools, most modern Quake Engine Quake Engine tools, and Hammer Hammer 4.x Variant of the Quake 1 (Legacy) format with additional texture UV precision
Quake II Quake II (Legacy) All Quake II Engine Quake II Engine tools, and most id Tech 3 id Tech 3 tools Variant of Quake 1 (Legacy) format which optionally stores three additional WAL metadata flags
Quake II Quake II (Valve220) J.A.C.K. J.A.C.K., NetRadiant-Custom NetRadiant-Custom, and TrenchBroom TrenchBroom Variant of Quake 2 (Legacy) format with Valve220-style UVs
Quake III Quake III (Axial Projection) All id Tech 3 id Tech 3 tools Variant of Quake 2 (Legacy) format with support for patch meshes ("curves")
Quake III Quake III (Brush Primitives) Most id Tech 3 id Tech 3 tools, except TrenchBroom TrenchBroom Variant of Quake 3 (Axial Projection) format which stores brushes differently
Confirm:As vertices instead of planes?
Quake III Quake III (Valve220) J.A.C.K. J.A.C.K., NetRadiant-Custom NetRadiant-Custom, TrenchBroom TrenchBroom Variant of Quake 3 (Axial Projection) format with Valve220-style UVs. Not yet standard.
Doom 3 Doom 3 (Legacy) All id Tech 4 id Tech 4 tools Variant of Quake 3 (Axial Projection) format which can store patch meshes differently [Elaborate?]
Doom 3 Doom 3 (Valve220) TrenchbroomBFG Variant of Doom 3 (Legacy) format with Valve220-style UVs

Entities

Stub

This article or section is a stub. You can help by expanding it.

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 (Legacy)

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 Xoffset Yoffset rotation Xscale Yscale
  • ( 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.
  • Xoffset Yoffset offsets the UV coordinates of the plane, resulting in shifting the texture on the X and/or Y 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].
  • Xscale Yscale stores the texture scale. 1 means the texture is displayed at 1 texel per quake unit.

Quake I (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 [ Tx1 Ty1 Tz1 Toffset1 ] [ Tx2 Ty2 Tz2 Toffset2 ] rotation Xscale Yscale
Todo: Explain the arrays

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.

Patch meshes

See also