User:Nicolas.le-guen/BSP (file format)

From WikiProjectMed
Jump to navigation Jump to search

.BSP is a map file extension used in games such as the Quake series, and games that use the Source engine, such as the Half-Life series and Portal series. .BSP files use binary space partitioning to generate levels that can be rendered quickly while minimizing the number of polygons that need to be redrawn every time the screen refreshes. One of the biggest problems with the .BSP file format is that large open areas do not work well due to the nature of the partitioning algorithm used.

Unlike the maps used in Unreal Tournament, .BSP files work by defining the edges of the map objects, as opposed to defining the hollow areas. .BSP files can be produced by compiling .MAP files using tools such as Q3Map2. .MAP files can be generated using exporters for such modelling tools as 3D Studio Max or using game-specific tools, like GtkRadiant. A .BSP file includes everything necessary to display the map, except the textures (with the exception of Quake and, optionally, Half-Life, BSP versions 29 and 30, respectively). Games such as Quake III Arena, James Bond 007: Nightfire and the Call of Duty series store the textures in separate assets files, contained in archive files such as .PAK, .PK3, .007, .IWD, etc. This map file format is also used in RenderWare (as version 11) for levels of the game such as Sonic Heroes, Shadow the Hedgehog, Tony Hawk's Pro Skater 3 and others.

Lumps

Lumps are chunks of data, the offsets and lengths (in bytes) of which are defined in the file header, which may also contain the version of the BSP. The number of lumps in a BSP differs from version to version, and the version used differs from game to game. For example, Quake II uses version 38 with 19 lumps, whereas James Bond 007: Nightfire uses version 42, with 18 lumps. For this reason, there are compatibility issues between games, and though conversion is possible, it is quite difficult.

Although the number of lumps, and therefore their functions, changes from version to version, most versions of the BSP contain lumps with similar functions, and sometimes even have identical formats. These include:

  • Entities – defines where objects such as weapons, enemies, etc. are placed, as well as containing the scripting information for AIs to follow, telling sounds to play, or even doors to open or close. They all are handled as a basic type called "entity".
  • Planes – defines infinite planes, each one of which cuts the space it passes through into two spaces, hence binary space partitioning. The planes only divide the space within the node(s) that use them.
  • Nodes – this lump simply makes use of the planes, and indexes the spaces created by them. This lump may also specify whether the node is further subdivided by additional nodes or if it is a leaf.
  • Leaves – These are the convex polyhedra that are the end result of space partitioning using node planes. This lump defines what these polyhedra are made of (solid, liquid, empty, etc.), usually through use of another lump such as brushes. One major disadvantage of using this type of data structure, known as the BSP tree, is that concave regions of space cannot be described by a single leaf, they must be subdivided into multiple convex regions. The regions of space falling outside the map are usually represented with a single shared leaf to conserve space.
  • Visibility – Since there can be a large number of leaves in a map, it could be quite costly for the hardware to redraw the entirety of them many times a second, because areas not seen would be drawn only to be overdrawn later. The visibility list reduces this by defining what is potentially visible to a player from a specific leaf. Since there can be a great number of leaves in a map, it is stored as a binary array, each bit defining whether any specific leaf is potentially visible or not (1 or 0, respectively), further RLE encoded. This method saves a great amount of space in temporary memory, as well as storage space of the map itself.
  • Textures – this lump is a list of textures, which is indexed for ease of applying them to each individual leaf face.
  • Faces – since leaves are many-sided polygons, any side, or faces, of that polygon can have a texture applied to it. This along with lighting effects, and other things that affect the look of the face is handled by this lump.
  • Vertices and Meshes – These two lumps (or in some cases, one Meshverts lump) are used by faces to split textures into triangles for better application onto a face. These triangles don't necessarily have to be congruent, and this method is actually understandable. Triangles can be used to form any two-dimensional polygon.

Other lumps are used by different versions to manipulate these lumps in many ways, and can be used to get nearly, if not exactly, the same effect in any version of the BSP.

Compilation

Compiling tools are used to convert plain-text .map files into .BSP files.

  • First, a level is passed through the bsp program. This program uses the brushes to create the architecture of the level. It also places all entities where they should go based on the .map file. This program writes the initial .BSP file.
  • Second, the level passes through the vis (Visible Information Set) processor, which determines what polygons are rendered and what lights appear where. Since the engine uses portal based rendering to determine what is visible at any given time, this program creates the portals by dividing the map into convex regions with visibility data.
  • Finally, the level passes through the rad program. This program computes the lighting of the map, including pseudo-radiosity, resulting in more natural-looking lighting. If there is a leak in the level, only standard lighting will be computed - radiosity will not be simulated, resulting in faker/harsher lighting. If the mapper doesn't run the rad application, the level will appear as full-bright (without static shadows or lighting of any kind, with every texture being fully lit). If the level is to be compiled with HDR lighting enabled, the level must pass through an additional stage of rad compiling—one stage to calculate normal (LDR) lighting, and a second stage for calculating HDR lighting.

With games using the GoldSource engine, there were four steps in the compilation. BSP is preceded by CSG (constructive solid geometry), which parses the brushes, places entities, indexes textures, and sets up the general framework of the level for the BSP pass which generally only performed space partitioning. In the Source engine, the plain-text .vmf map file stores the files in a CSG format, rather than vertex based, and lets the BSP tool handle all the entity placement tasks, so the CSG process has effectively been merged into BSP.

See also

External links


Category:Computer file formats

Retrieved from "https://mdwiki.org/wiki/User:Nicolas.le-guen/BSP_(file_format)"