Node builder
From DoomWiki.org
A node builder is a WAD authoring tool.
The VERTEXES, LINEDEFS, SIDEDEFS, and SECTORS lumps fully describe the structure of a map, and it is relatively straightforward for a level editor to create them. However, for rapid rendering and game simulation, the Doom engine needs information on how these structures interrelate. Depending on the algorithm and level of complexity, the binary space partition of the map, the REJECT data and the BLOCKMAP can take a long time to generate.
Using the basic lumps, a node builder creates the NODES, SEGS, SSECTORS, REJECT and BLOCKMAP lumps (and will likely also add to the VERTEXES lump). Having these structures precalculated and stored in the WAD file, rather than determining them at run time, is key to the speed of the engine.
The node builder used by id Software is called DoomBSP, but often referenced as idbsp due to an early port of the source code being called this.
The process of node building is described in some detail in the Unofficial Doom Specs. As detailed in that document, many different partitions of a level are possible, because the choice of partition lines is somewhat arbitrary. There are two competing goals when creating the BSP tree: to have a balanced tree (having about the same number of subnodes on each side) and to minimize the number of splits (breaking linedefs into multiple segs). Thus, different node builders will likely produce different results for a given level.
Contents
Node formats[edit]
Doom level format |
---|
Extensions:
|
There exist several different node formats.
Regular nodes[edit]
The nodes described in the NODES, SEGS and SSECTORS lumps, used by the original version of all Doom-engine games. They suffer from certain limitations, such as a limit of 32768 (or 65536) for the number of segs and vertices and a lack of precision for node coordinates (they are stored as integers, rather than fixed-point values) which results in many slime trails.
DeeP nodes[edit]
To remove the limits of regular nodes, the DeePBSP nodebuilder uses a different format which can be recognized by a starting signature of "xNd4\0\0\0\0" (0x784E643400000000) in the NODES lump. DeeP nodes use 32-bit signed values to reference vertices and segments, pushing the limits from 64K to 2G. However, they still suffer from lack of precision. DeeP nodes are supported by Risen3D, as well as PrBoom+ 2.5.0.7+, ZDoom 2.5.0+, GZDoom 1.5.0+, Crispy Doom 2.3+ and Doom Retro 1.8+.
GL nodes[edit]
OpenGL renderers have additional requirements for the nodes that the software renderers can ignore, as they are much stricter on their need for subsectors to be convex and precision of coordinates is paramount. The glBSP nodebuilder provides a standard for GL nodes, which are stored in additional lumps so as not to conflict with regular nodes: GL_VERT, GL_SEGS, GL_SSECT, GL_NODES and GL_PVS. These lumps may be in a separate file from their associated level, allowing the distribution of "GWA" files which contains prebuilt GL nodes for commercial levels without having to distribute modified versions of the levels themselves. To match the nodes with a level, a GL_LEVEL lump is used, generally containing a checksum of the level data to make sure the nodes are attributed properly.
There are five different versions of GL nodes. Versions 1, 3 and 4 are considered deprecated now. Versions 2 is the preferred format, with version 5 used for maps requiring higher limits. GL nodes are supported by all OpenGL ports, though the extent of the support may vary, since the GL_PVS lump is considered optional and only V2 and V5 are required to be supported for an implementation to be considered valid.
ZDoom extended nodes[edit]
ZDoom's extended nodes, built by ZDBSP, use 32-bit unsigned values to refer to vertices, segments and subsectors, pushing the limit to 4G for each. In addition, all structures are listed in the same lump (NODES), including additional vertices created by the nodebuilder. The SEGS and SSECTORS lumps are left empty. ZDoom extended nodes can be compressed or not; if uncompressed they start with an "XNOD" signature (0x584E4F44), if compressed with a "ZNOD" one (0x5A4E4F44). ZDBSP also offers extended GL nodes. They are also stored in a single lump (the SSECTORS lump in a Doom- or Hexen-format map, the ZNODES lump in UDMF) and use a starting signature of XGLN or XGL2 for uncompressed, ZGLN and ZGL2 for compressed. XGLN/ZGLN is used for normal maps, XGL2/ZGL2 is used for maps with more than 65536 linedefs (which are only possible in UDMF). ZDoom compressed nodes are supported by ZDoom and all derivative engines as well as Crispy Doom 2.3+. Uncompressed extended nodes, a more recent addition, are so far supported by ZDoom 2.5.0+, GZDoom 1.5.0+, PrBoom+ 2.5.0.7+, Eternity Engine 3.39.20+, Crispy Doom 2.3+, Doom Retro 1.8+, Woof! 1.2.1+, Doom Legacy 1.48.10+, and Rum and Raisin Doom.
List of node builders[edit]
DOS | Windows | Macintosh | *nix | OS/2 | First release | Last updated | |
---|---|---|---|---|---|---|---|
AJBSP | No | Yes | No | Yes | No | 2018-06-02 | 2023-01-03 |
BSP | Yes | Yes | No | Yes | Yes | 1994-03-28 | |
BSPCOMP | Yes | No | No | No | No | 1995-11-13 | 1995-11-13 |
DeePBSP | Yes | Yes | No | No | No | 1994 | |
DoomBSP | No | No | No | Yes | No | ||
glBSP | No | Yes | No | Yes | No | ||
glVIS | No | Yes | No | Yes | No | ||
IDBSP | Yes | No | No | No | No | 1994 | |
MacBSP | No | No | Yes | No | No | ||
machexbsp | No | No | Yes | No | No | ||
NanoBSP | No | No | No | No | No | 2023-12-08 | |
NBLD.EXE | Yes | Yes | No | No | No | ||
VigilantBSP | No | Yes | No | Yes | No | 2022-04-05 | 2023-04-12 |
WAD Auxiliary Resource Manipulator (WARM) | Yes | Yes | No | Yes | Yes | 1995-01-30 | 1996-01-29 |
ZDBSP | Yes | Yes | No | Yes | No | 2003-09-12 | 2016-01-07 |
ZDRay | No | Yes | No | No | No | ||
ZenNode | No | Yes | Yes | Yes | No | 1994-10-26 | 2004-05-30 |
ZokumBSP | No | Yes | No | Yes | No |