30 | The following file specification concerns the WAD3 file format used 31 | Valve's famous GoldSrc Engine. The file extension is ".wad". 32 | Contrary to the BSP v30 file format that has been derived from the Quake 33 | 1 BSP (v29) format, the WAD3 format is tecnically fully compatible with 34 | Quake's WAD2 files. 35 | WAD files are used to store game related files in some kind of archive. 36 | Somehow they seem to contain only textures, although they are capable of 37 | holding different kinds of data. 38 |

41 | This file spec uses constructs from the C programming language to 42 | describe the different data structures used in the WAD file format. 43 | Architecture dependent datatypes like integers are replaced by 44 | exact-width integer types of the C99 standard in the stdint.h header 45 | file, to provide more flexibillity when using x64 platforms. 46 | Basic knowledge about textures in the BSP file is recommended. 47 |

50 | #include <stdint.h>
51 |

Header

55 | Like almost every file also a WAD file (WAD3) starts with a specific file header which is constucted as follows: 56 |

59 | typedef struct _WADHEADER
60 | {
61 | char szMagic[4]; // should be WAD2/WAD3
62 | int32_t nDir; // number of directory entries
63 | int32_t nDirOffset; // offset into directory
64 | } WADHEADER;
65 |

67 | The first 4 bytes of a WAD archive identify the file (the so-called 68 | magic number) with the 3 character string "WAD" followed by a version 69 | numer as ASCII char. Compatible formats include "WAD3" as well as 70 | "WAD2". 71 | As with the BSP file also a WAD file starts with some kind of directory 72 | containing entries similar to the lumps of the BSP file. 73 | The major difference is that a WAD file may have an arbitrary number of 74 | entries. This value is stored in the nDir member of the header followed 75 | by the offset to the array of directory entries within the file, which 76 | is usually located somewhere at the ned of the WAD file. 77 |

Directory entries

82 | The directory of a WAD file is basically an array of structures. Every archived file has an associated entry in this directory: 83 |

86 | #define MAXTEXTURENAME 16
87 |
88 | typedef struct _WADDIRENTRY
89 | {
90 | int32_t nFilePos; // offset in WAD
91 | int32_t nDiskSize; // size in file
92 | int32_t nSize; // uncompressed size
93 | int8_t nType; // type of entry
94 | bool bCompression; // 0 if none
95 | int16_t nDummy; // not used
96 | char szName[MAXTEXTURENAME]; // must be null terminated
97 | } WADDIRENTRY;
98 |

100 | The first value is the offset of the raw data of the archived file 101 | within the WAD file followed by the size of data used by the it in its 102 | current form. 103 | Additionally nSize stores the size of original file, if it has been 104 | compressed. This is indicated by the bCompression boolean value. If it 105 | is false, no compression is used which is mostly the case. 106 | The nType member would give as information about the type of file, that 107 | is associated with this entry. As WAD files usually contain only 108 | textures, this information may be ignored. 109 | The nDummy short integer is not used when loading textures and i have 110 | not found any information about this member. 111 | Finally the entry contains a name for the file which can be a string of 112 | maximum 16 chars including the zero termination. In case of textures, 113 | this is the name referred by the BSPMIPTEX structs of the BSP file. 114 |

Files in a WAD File - Textures

119 | The actual files in the WAD archive, the textures, also start with a file header which may look familiar: 120 |

123 | #define MAXTEXTURENAME 16
124 | #define MIPLEVELS 4
125 | typedef struct _BSPMIPTEX
126 | {
127 | char szName[MAXTEXTURENAME]; // Name of texture
128 | uint32_t nWidth, nHeight; // Extends of the texture
129 | uint32_t nOffsets[MIPLEVELS]; // Offsets to texture mipmaps BSPMIPTEX;
130 | } BSPMIPTEX;
131 |

133 | This struct equals the one of the BSP file exactly. 134 | The name of the texture as not needed actually, as it equals the file 135 | name in the directory entry. 136 | The next members are of particular interest. They give the size of the 137 | texture in pixel as well as the offsets into the raw texture data. 138 | The first value of the offset array points to the beginning of the 139 | original texture relativly to the local header (the BSPMIPTEX struct). 140 | From this point follows a nWidth * nHeight bytes long array of indexes 141 | (0-255) pointing to colors in a color table. 142 | The other three offsets are used the same way, but with the diference 143 | that the width and height of the image are cut in half with every 144 | further offset. 145 | These represent the so-called mipmap 146 | levels of the original image. 147 | After the last byte of the fourth mipmap there are two dummy bytes 148 | followed by the actual color table consisting of an array of triples of 149 | bytes (RGB values) with 256 elements. 150 | The indexes of the image are plugged into the color table array to 151 | receive the corresponding RGB color value for the pixel. 152 |

17 |

Unofficial BSP v30 File Spec

18 | 19 |

Table of content

20 |

Introduction
Header
LUMP_ENTITIES
LUMP_PLANES
LUMP_TEXTURES
LUMP_VERTICES
LUMP_VISIBILITY
LUMP_NODES
LUMP_TEXINFO
LUMP_FACES
LUMP_LIGHTING
LUMP_CLIPNODES
LUMP_LEAVES
LUMP_MARKSURFACES
LUMP_EDGES
LUMP_SURFEDGES
LUMP_MODELS

39 | 40 |

Introduction

41 | 42 |

43 | The following file specification concerns the BSP file format version 44 | 30, as it has been designed by the game developper Valve and used in 45 | their famous GoldSrc Engine. The file extension is ".bsp". 46 |

47 | 48 |

49 | Important: The following informations do NOT rely on any 50 | officially published file specification from Valve Corporation. 51 | The file format is still in use by the proprietary Half-Life Engine 52 | (better known name of the GoldSrc Engine) implying that there is no 53 | public source code of either the file loader or renderer. 54 | The following specification has been put together based on informations 55 | from the open source project Black Engine as well as the compilers included in the Half-Life SDK which also contains their source. 56 |

57 | 58 |

59 | This file spec uses constructs from the C programming language to 60 | describe the different data structures used in the BSP file format. 61 | Architecture dependent datatypes like integers are replaced by 62 | exact-width integer types of the C99 standard in the stdint.h header 63 | file, to provide more flexibillity when using x64 platforms. 64 | Basic knowledge about Binary Space Partitioning 65 | is recommended. 66 | 67 | There is a common struct used to represent a point in 3-dimensional 68 | space which is used throughout the file spec and the code of the hlbsp 69 | project. 70 |

71 | 72 |

| #include <stdint.h>

| 

| typedef struct _VECTOR3D

| {

|     float x, y, z;

| } VECTOR3D;

|

80 |

Header

81 | 82 |

83 | Like almost every file also a BSP file starts with a specific file header which is constucted as follows: 84 |

85 | 86 |

| #define LUMP_ENTITIES      0

| #define LUMP_PLANES        1

| #define LUMP_TEXTURES      2

| #define LUMP_VERTICES      3

| #define LUMP_VISIBILITY    4

| #define LUMP_NODES         5

| #define LUMP_TEXINFO       6

| #define LUMP_FACES         7

| #define LUMP_LIGHTING      8

| #define LUMP_CLIPNODES     9

| #define LUMP_LEAVES       10

| #define LUMP_MARKSURFACES 11

| #define LUMP_EDGES        12

| #define LUMP_SURFEDGES    13

| #define LUMP_MODELS       14

| #define HEADER_LUMPS      15

| 

| typedef struct _BSPHEADER

| {

|     int32_t nVersion;           // Must be 30 for a valid HL BSP file

|     BSPLUMP lump[HEADER_LUMPS]; // Stores the directory of lumps

| } BSPHEADER;

|

110 |

111 | The file header begins with an 32bit integer containing the file version 112 | of the BSP file (the magic number). This should be 30 for a valid BSP 113 | file used by the Half-Life Engine. 114 | Subseqently, there is an array of entries for the so-called lumps. A 115 | lump is more or less a section of the file containing a specific type of 116 | data. The lump entries in the file header address these lumps, accessed 117 | by the 15 predefined indexes. A lump entry struct is defined as 118 | follows: 119 |

120 | 121 |

| typedef struct _BSPLUMP

| {

|     int32_t nOffset; // File offset to data

|     int32_t nLength; // Length of data

| } BSPLUMP;

|

128 |

129 | To read the different lumps from the given BSP file, every lump entry 130 | file states the beginning of each lump as an offset relativly to the 131 | beginning of the file. Additionally, the lump entry also gives the 132 | length of the addressed lump in bytes. 133 | 134 | The Half-Life BSP compilers also define several constants for the 135 | maximum size of each lump, as they use static, global arrays to hold the 136 | data. The hlbsp project uses malloc() to allocate the required memory 137 | for each lump depending on their actual size. 138 |

139 | 140 |

| #define MAX_MAP_HULLS        4

| 

| #define MAX_MAP_MODELS       400

| #define MAX_MAP_BRUSHES      4096

| #define MAX_MAP_ENTITIES     1024

| #define MAX_MAP_ENTSTRING    (128*1024)

| 

| #define MAX_MAP_PLANES       32767

| #define MAX_MAP_NODES        32767

| #define MAX_MAP_CLIPNODES    32767

| #define MAX_MAP_LEAFS        8192

| #define MAX_MAP_VERTS        65535

| #define MAX_MAP_FACES        65535

| #define MAX_MAP_MARKSURFACES 65535

| #define MAX_MAP_TEXINFO      8192

| #define MAX_MAP_EDGES        256000

| #define MAX_MAP_SURFEDGES    512000

| #define MAX_MAP_TEXTURES     512

| #define MAX_MAP_MIPTEX       0x200000

| #define MAX_MAP_LIGHTING     0x200000

| #define MAX_MAP_VISIBILITY   0x200000

| 

| #define MAX_MAP_PORTALS     65536

|

165 |

166 | The following sections will focus on every lump of the BSP file. 167 |

168 | 169 |

The Entity Lump (LUMP_ENTITIES)

170 | 171 |

172 | The entity lump is basically a pure ASCII text section. It consists of 173 | the string representations of all entities, which are copied directly 174 | from the input file to the output BSP file by the compiler. 175 | An entity might look like this: 176 |

177 | 178 |

| {

| "origin" "0 0 -64"

| "angles" "0 0 0"

| "classname" "info_player_start"

| }

|

185 |

186 | Every entity begins and ends with curly brackets. Inbetween there are 187 | the attributes of the entity, one in each line, which are pairs of 188 | strings enclosed by quotes. The first string is the name of the 189 | attribute (the key), the second one its value. The attribute "classname" 190 | is mandatory for every entity specifiying its type and therefore, how 191 | it is interpreted by the engine. 192 |

193 | 194 |

195 | The map compilers also define two constants for the maximum length of key and value: 196 |

197 | 198 |

| #define MAX_KEY     32

| #define MAX_VALUE   1024

|  

202 |

The Planes Lump (LUMP_PLANES)

203 | 204 |

205 | This lump is a simple array of binary data structures: 206 |

207 | 208 |

| #define PLANE_X 0     // Plane is perpendicular to given axis

| #define PLANE_Y 1

| #define PLANE_Z 2

| #define PLANE_ANYX 3  // Non-axial plane is snapped to the nearest

| #define PLANE_ANYY 4

| #define PLANE_ANYZ 5

| 

| typedef struct _BSPPLANE

| {

|     VECTOR3D vNormal; // The planes normal vector

|     float fDist;      // Plane equation is: vNormal * X = fDist

|     int32_t nType;    // Plane type, see #defines

| } BSPPLANE;

|

223 |

224 | Each of this structures defines a plane in 3-dimensional space by using the Hesse normal form: 225 |

226 | 227 |

228 | normal * point - distance = 0 229 |

230 | 231 |

232 | Where vNormal is the normalized normal vector of the plane and fDist is 233 | the distance of the plane to the origin of the coord system. 234 | Additionally, the structure also saves an integer describing the 235 | orientation of the plane in space. If nType equals PLANE_X, then the 236 | normal of the plane will be parallel to the x axis, meaning the plane is 237 | perpendicular to the x axis. If nType equals PLANE_ANYX, then the 238 | plane's normal is nearer to the x axis then to any other axis. This 239 | information is used by the renderer to speed up some computations. 240 |

241 | 242 |

The Texture Lump (LUMP_TEXTURES)

243 | 244 |

245 | The texture lump is somehow a bit more complex then the other lumps, 246 | because it is possible to save textures directly within the BSP file 247 | instead of storing them in external WAD files. This lump also starts with a small header: 248 |

249 | 250 |

| typedef struct _BSPTEXTUREHEADER

| {

|     uint32_t nMipTextures; // Number of BSPMIPTEX structures

| } BSPTEXTUREHEADER;

|

256 |

257 | The header only consists of an unsigned 32bit integer indicating the 258 | number of stored or referenced textures in the texture lump. After the 259 | header follows an array of 32bit offsets pointing to the beginnings of 260 | the seperate textures. 261 |

262 | 263 |

| typedef int32_t BSPMIPTEXOFFSET;

|  

266 |

267 | Every offset gives the distance in bytes from the beginning of the 268 | texture lump to one of the beginnings of the BSPMIPTEX structure, which 269 | are equal in count to the value given in the texture header. 270 |

271 | 272 |

| #define MAXTEXTURENAME 16

| #define MIPLEVELS 4

| typedef struct _BSPMIPTEX

| {

|     char szName[MAXTEXTURENAME];  // Name of texture

|     uint32_t nWidth, nHeight;     // Extends of the texture

|     uint32_t nOffsets[MIPLEVELS]; // Offsets to texture mipmaps BSPMIPTEX;

| } BSPMIPTEX;

|

282 |

283 | Each of this structs describes a texture. 284 | The name of the texture is a string and may be 16 characters long 285 | (including the null-character at the end, char equals a 8bit signed 286 | integer). 287 | The name of the texture is needed, if the texture has to be found and 288 | loaded from an external WAD file. Furthermore, the struct contains the 289 | width and height of the texture. 290 | The 4 offsets at the end can either be zero, if the texture is stored in 291 | an external WAD file, or point to the beginnings of the binary texture 292 | data within the texture lump relative to the beginning of it's BSPMIPTEX 293 | struct. 294 |

295 | 296 |

The Vertices Lump (LUMP_VERTICES)

297 | 298 |

299 | This lump simply consists of all vertices of the BSP tree. They are stored as a primitve array of triples of floats. 300 |

301 | 302 |

| typedef VECTOR3D BSPVERTEX;

|  

305 |

306 | Each of this triples, obviously, represents a point in 3-dimensional space by giving its three coordinates. 307 |

308 | 309 |

The VIS Lump (LUMP_VISIBILITY)

310 | 311 |

312 | The VIS lump contains data, which is irrelevant to the actual BSP tree, 313 | but offers a way to boost up the speed of the renderer significantly. 314 | Especially complex maps profit from the use if this data. This lump 315 | contains the so-called Potentially Visible Sets (PVS) (also called VIS 316 | lists) in the same amout of leaves of the tree, the user can enter 317 | (often referred to as VisLeaves). The visiblilty lists are stored as 318 | sequences of bitfields, which are run-length encoded.
319 | Important: The generation of the VIS data is a very time 320 | consuming process (several hours) and also done by a seperate compiler. 321 | It can therefore be skipped when compiling the map, resulting in BSP 322 | files with no VIS data at all! 323 |

324 | 325 |

The Nodes Lump (LUMP_NODES)

326 | 327 |

328 | This lump is simple again and contains an array of binary structures, the nodes, which are a major part of the BSP tree. 329 |

330 | 331 |

| typedef struct _BSPNODE

| {

|     uint32_t iPlane;            // Index into Planes lump

|     int16_t iChildren[2];       // If > 0, then indices into Nodes // otherwise bitwise inverse indices into Leafs

|     int16_t nMins[3], nMaxs[3]; // Defines bounding box

|     uint16_t firstFace, nFaces; // Index and count into Faces

| } BSPNODE;

|

340 |

341 | Every BSPNODE structure represents a node in the BSP tree and every node 342 | equals more or less a division step of the BSP algorithm. Therefore, 343 | each node has an index (iPlane) referring to a plane in the plane lump 344 | which devides the node into its two child nodes. The childnodes are also 345 | stored as indexes. Contrary to the plane index, the node index for the 346 | child is signed. If the index is larger than 0, the index indicates a 347 | child node. If it is equal to or smaller than zero (no valid array 348 | index), the bitwise inversed value of the index gives an index into the 349 | leaves lump. Additionally two points (nMins, nMaxs) span the bounding 350 | box (AABB, axis aligned bounding box) delimitting the space of the node. 351 | Finally firstFace indexes into the face lump and spezifies the first of 352 | nFaces surfaces contained in this node. 353 |

354 | 355 |

The Texinfo Lump (LUMP_TEXINFO)

356 | 357 |

358 | The texinfo lump contains informations about how textures are applied to 359 | surfaces. The lump itself is an array of binary data structures. 360 |

361 | 362 |

| typedef struct _BSPTEXTUREINFO

| {

|     VECTOR3D vS; 

|     float fSShift;    // Texture shift in s direction

|     VECTOR3D vT; 

|     float fTShift;    // Texture shift in t direction

|     uint32_t iMiptex; // Index into textures array

|     uint32_t nFlags;  // Texture flags, seem to always be 0

| } BSPTEXTUREINFO;

|

373 | This struct is mainly responsible for the calculation of the texture 374 | coordinates (vS, fSShift, vT, fTShift). This values determine the 375 | position of the texture on the surface. The iMiptex integer refers to 376 | the textures in the texture lump and would be the index in an array of 377 | BSPMITEX structs. Finally, there are 4 Bytes used for flags. Somehow 378 | they seem to always be 0; 379 |

380 | 381 |

The Faces Lump (LUMP_FACES)

382 | 383 |

384 | The face lump contains the surfaces of the scene. Once again an array of structs: 385 |

386 | 387 |

| typedef struct _BSPFACE

| {

|     uint16_t iPlane;          // Plane the face is parallel to

|     uint16_t nPlaneSide;      // Set if different normals orientation

|     uint32_t iFirstEdge;      // Index of the first surfedge

|     uint16_t nEdges;          // Number of consecutive surfedges

|     uint16_t iTextureInfo;    // Index of the texture info structure

|     uint8_t nStyles[4];       // Specify lighting styles

|     uint32_t nLightmapOffset; // Offsets into the raw lightmap data

| } BSPFACE;

|

399 |

400 | The first number of this data structure is an index into the planes lump 401 | giving a plane which is parallel to this face (meaning they share the 402 | same normal). The second value may be seen as a boolean. If nPlaneSide 403 | equals 0, then the normal vector of this face equals the one of the 404 | parallel plane exactly. Otherwise, the normal of the plane has to be 405 | multiplied by -1 to point into the right direction. Afterwards we have 406 | an index into the surfedges lump, as well as the count of consecutive 407 | surfedges from that position. Furthermore there is an index into the 408 | texture info lump, which is used to find the BSPTEXINFO structure needed 409 | to calculate the texture coordinates for this face. Afterwards, there 410 | are four bytes giving some lighting information (partly used by the 411 | renderer to hide sky surfaces). Finally we have an offset in byes giving 412 | the beginning of the binary lightmap data of this face in the lighting 413 | lump. 414 |

415 | 416 |

The Lightmap Lump (LUMP_LIGHTING)

417 | 418 |

419 | This is one of the largest lumps in the BSP file. The lightmap lump 420 | stores all lightmaps used in the entire map. The lightmaps are arrays of 421 | triples of bytes (3 channel color, RGB) and stored continuously. 422 |

423 | 424 |

The Clipnodes Lump (LUMP_CLIPNODES)

425 | 426 |

427 | This lump contains the so-called clipnodes, which build a second BSP tree used only for collision detection. 428 |

429 | 430 |

| typedef struct _BSPCLIPNODE

| {

|     int32_t iPlane;       // Index into planes

|     int16_t iChildren[2]; // negative numbers are contents

| } BSPCLIPNODE;

|

437 |

438 | This structure is a reduced form of the BSPNODE struct from the nodes 439 | lump. Also the BSP tree built by the clipnodes is simpler than the one 440 | described by the BSPNODEs to accelerate collision calculations. 441 |

442 | 443 |

The Leaves Lump (LUMP_LEAVES)

444 | 445 |

446 | The leaves lump contains the leaves of the BSP tree. Another array of binary structs: 447 |

448 | 449 |

| #define CONTENTS_EMPTY        -1

| #define CONTENTS_SOLID        -2

| #define CONTENTS_WATER        -3

| #define CONTENTS_SLIME        -4

| #define CONTENTS_LAVA         -5

| #define CONTENTS_SKY          -6

| #define CONTENTS_ORIGIN       -7

| #define CONTENTS_CLIP         -8

| #define CONTENTS_CURRENT_0    -9

| #define CONTENTS_CURRENT_90   -10

| #define CONTENTS_CURRENT_180  -11

| #define CONTENTS_CURRENT_270  -12

| #define CONTENTS_CURRENT_UP   -13

| #define CONTENTS_CURRENT_DOWN -14

| #define CONTENTS_TRANSLUCENT  -15

| 

| typedef struct _BSPLEAF

| {

|     int32_t nContents;                         // Contents enumeration

|     int32_t nVisOffset;                        // Offset into the visibility lump

|     int16_t nMins[3], nMaxs[3];                // Defines bounding box

|     uint16_t iFirstMarkSurface, nMarkSurfaces; // Index and count into marksurfaces array

|     uint8_t nAmbientLevels[4];                 // Ambient sound levels

| } BSPLEAF;

|

475 |

476 | The first entry of this struct is the type of the content of this leaf. 477 | It can be one of the predefined values, found in the compiler source 478 | codes, and is litte relevant for the actual rendering process. All the 479 | more important is the next integer containing the offset into the vis 480 | lump. It defines the start of the raw PVS data for this leaf. If this 481 | value equals -1, no VIS lists are available for this leaf, usually if 482 | the map has been built without the VIS compiler. The next two 16bit 483 | integer triples span the bounding box of this leaf. Furthermore, the 484 | struct contains an index pointing into the array of marksurfaces loaded 485 | from the marksufaces lump as well as the number of consecutive 486 | marksurfaces belonging to this leaf. The marksurfaces are looped through 487 | during the rendering process and point to the actual faces. The final 4 488 | bytes somehow spezify the volume of the ambient sounds. 489 |

490 | 491 |

The Marksurfaces Lump (LUMP_MARKSURFACES)

492 | 493 |

494 | The marksurfaces lump is a simple array of short integers. 495 |

496 | 497 |

| typedef uint16_t BSPMARKSURFACE;

|  

500 |

501 | This lump is a simple table for redirecting the marksurfaces indexes in 502 | the leafs to the actial face indexes. A leaf inserts it's marksurface 503 | indexes into this array and gets the associated faces contained within 504 | this leaf. 505 |

506 | 507 |

The Edges Lump (LUMP_EDGES)

508 | 509 |

510 | The edges are defined as an array of structs: 511 |

512 | 513 |

| typedef struct _BSPEDGE

| {

|     uint16_t iVertex[2]; // Indices into vertex array

| } BSPEDGE;

|

519 |

520 | The edges delimit the face and further refer to the vertices of the 521 | face. Each edge is pointing to the start and end vertex of the edge. 522 |

523 | 524 |

The Surfedges Lump (LUMP_SURFEDGES)

525 | 526 |

527 | Another array of integers. 528 |

529 | 530 |

| typedef int32_t BSPSURFEDGE;

|  

533 |

534 | This lump represents pretty much the same mechanism as the marksurfaces. 535 | A face can insert its surfedge indexes into this array to get the 536 | corresponding edges delimitting the face and further pointing to the 537 | vertexes, which are required for rendering. The index can be positive or 538 | negative. If the value of the surfedge is positive, the first vertex of 539 | the edge is used as vertex for rendering the face, otherwise, the value 540 | is multiplied by -1 and the second vertex of the indexed edge is used. 541 |

542 | 543 |

The Models Lump (LUMP_MODELS)

544 | 545 |

546 | Array of structs: 547 |

548 | 549 |

| #define MAX_MAP_HULLS 4

| 

| typedef struct _BSPMODEL

| {

|     float nMins[3], nMaxs[3];          // Defines bounding box

|     VECTOR3D vOrigin;                  // Coordinates to move the // coordinate system

|     int32_t iHeadnodes[MAX_MAP_HULLS]; // Index into nodes array

|     int32_t nVisLeafs;                 // ???

|     int32_t iFirstFace, nFaces;        // Index and count into faces

| } BSPMODEL;

|

561 |

562 | A model is kind of a mini BSP tree. Its size is determinded by the 563 | bounding box spaned by the first to members of this struct. The major 564 | difference between a model and the BSP tree holding the scene is that 565 | the models use a local coordinate system for their vertexes and just 566 | state its origin in world coordinates. During rendering the coordinate 567 | system is translated to the origin of the model (glTranslate()) and 568 | moved back after the models BSP tree has been traversed. Furthermore 569 | their are 4 indexes into node arrays. The first one has proofed to index 570 | the root node of the mini BSP tree used for rendering. The other three 571 | indexes could probably be used for collision detection, meaning they 572 | point into the clipnodes, but I am not sure about this. The meaning of 573 | the next value is also somehow unclear to me. Finally their are direct 574 | indexes into the faces array, not taking the redirecting by the 575 | marksurfaces. 576 |

577 |

Unofficial WAD3 File Spec

Table of content

Unofficial BSP v30 File Spec

Table of content