This article's documentation is for the "GoldSrc" engine. Click here for more information.
Quake1-16px.png
Quake2-16px.png
Quake3-16px.png

BSPX

From Valve Developer Community
(Redirected from Bspx)
Jump to: navigation, search

Stub

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

BSPX is a standard for adding new lumps to id Tech 2 id Tech 2, id Tech 3 id Tech 3, and GoldSrc GoldSrc BSP files, which are used to add additional features to be used by source ports or custom renderers without breaking vanilla compatibility. As BSPX lumps are placed at the end of the BSP file, they are not loaded by vanilla engines, so a BSP with BSPX lumps is backwards compatible.

Structure

typedef struct {
	char lumpname[24]; // up to 23 chars, zero-padded
	int fileofs;  // from file start
	int filelen;
} bspx_lump_t;
typedef struct {
	char id[4];  // 'BSPX'
	int numlumps;
	bspx_lump_t lumps[1];
} bspx_header_t;

Lumps

Blank image.pngTodo: More info; see FTE FTE and Ericw-tools source codes

DECOUPLED_LM

"Decouples" lightmap scale, alignment, and rotation from those of texels.

Compile with ericw-tools using _world_units_per_luxel KV in worldspawn or -world_units_per_luxel # in QBSP, wherein # is the luxel scale (like in Hammer Hammer 4.x's face edit window).

The 2023 Quake II Quake II remaster uses DECOUPLED_LM with a luxel scale of 8 on all maps except for the Quake II 64 maps.

Unnecessary and possibly incompatible with Quake III's BSP format and derivatives, which store lightmaps as pages in the BSP file (or externally) instead of paginating at load time, and has no direct correlation between texel size and luxel size. Q3Map2 and some games support -lightmapsize switch to use external TGA lightmaps, but for vanilla Quake III, use the q3map2_lightmapsize parameter in the given material; see explanation.

LIGHTGRID_OCTREE

An Wikipedia icon octree-formatted 3D grid of RGB888 color values[confirm], used by dynamically lit models instead of being lit based upon the nearest (worldswawn) lightmap luxel or light_environment entity.

This is used by all non-N64 maps in the 2023 Quake II Quake II remaster.

Icon-Important.pngImportant:Does not store any directionality; consider implementing a variant that stores 6 values per point (like Source's ambient cubes) or stores an additional vector indicating direction (like GoldSrc's light_environment).

Unnecessary with Quake III's BSP format and derivatives, which already contain lightgrids.

LIGHTING_E5BGR9

Used for HDR lightmaps. Functions similarly to the RGBE8 lightmaps in Source Source, but with an additional bit of precision per color instead of having the exponent be 8 bits.

ENVMAP

Defines where cubemaps are found (Does not store the cubemaps themselves). Can be generated (alongside SURFENVMAP) from env_cubemap entities by loading the BSP in FTE FTE and running the mod_findcubemaps console command.

The following FGD entry represents the expected syntax:

@PointClass color(0 0 255) iconsprite("sprites/editor/env_cubemap.spr") = env_cubemap : 
	"An entity that creates a sample point for the Cubic Environment Map."
[
	size(choices) : "Cubemap Size" : 0 : "Resolution of the cubemap." =
	[
		0   : "Default"
		1   : "1x1"
		2   : "2x2"
		4   : "4x4"
		8   : "8x8"
		16  : "16x16"
		32  : "32x32"
		64  : "64x64"
		128 : "128x128"
		256 : "256x256"
	]
]

In the compiled lump, each envmap reference is stored much the same way:

struct
{
	vec3_t origin;
	int cubesize;
} envmaps[];

SURFENVMAP

Used alongside ENVMAP lump to store what cubemap index each brush surface should use. Pretty simple:

struct
{
	unsigned int envmapindex;
} persurface[];

BRUSHLIST

Store actual brush information for collision, like Quake II Quake II, Quake III Quake III, and Source Source, allowing for arbitrary hull sizes. This also bypasses max clipnode limits without requiring an upgraded format such as BSP2.

Struct for each bmodel is like so:

struct {
	unsigned int ver = 1;
	unsigned int modelnum;		//inline model number. 0 for world, obviously.
	unsigned int numbrushes;	//size of following array.
	unsigned int numplanes;		//total count. for validation.
	struct
	{
		vec_t mins;
		vec_t maxs;
		signed short contents;
		unsigned short numplanes;
		{
			vec3_t 	normal;
			float 	dist;
		} planes[numplanes];
	} brush[numbrushes];
} permodel[];

Contents are stored as a signed short, matching the existing runtime contents values. Axial planes are not stored, but rather inferred based upon their normal, distance, and the brush's mins and maxs.


Only practical for clipnode-based formats like BSP29, BSP30, and BSP2 (BSP38 and derivatives store this information already).

ZIP_PAKFILE

A ZIP file, used like Source BSP's pakfile lump. For best compatibility, should be Wikipedia icon Deflate or uncompressed, and should be the last lump in the BSP.

The name of this lump is theoretical; the only id Tech 2 id Tech 2 source port which supports zip files embedded in the BSP is FTE FTE, which just looks for concatenated zip files, regardless of if they are formatted as a proper lump.

RGBLIGHTING

Equivalent to the 24-bit lightmap lump from a BSP30. Used as an alternative for external LIT files when using BSP29 or monochromatic BSP2, while maintaining a 8-bit monochromatic fallback for Quake engines that don't support this lump.

Only practical for Quake Quake and Hexen II Hexen II engines; GoldSrc GoldSrc, Quake II Quake II, and Quake III Quake III map files store 24-bit true color lightmaps already.

VERTEXNORMALS

Stores vertex normal data for brushes, necessary for accurate smoothing when using real-time light sources instead of prebaked lightmaps. Surfaces that are shaded smooth should have the surface flag 0x00000800 set in their texinfo entry; surfaces without that flag are flat-shaded.

FACENORMALS

Used by ericw-tools instead of the VERTEXNORMALS lump.

Blank image.pngTodo: How does it work? Does it work for the same purpose, or is it less precise?

LIGHTINGDIR

"Deluxemaps", designed for use with normal mapped surfaces that have lightmaps. Effectively a normal map which is stored like the lightmaps.

Warning.pngWarning:This can "result in some ugliness if there's shadows"[sic], to quote lead FTE dev Spike. If creating your own lightmap compilers, consider taking a page out of Source's book, and create a derivative of the DECOUPLED_LM lump containing separate lightmaps for each of the three normal direction.

LMSTYLE16

Upgrade to the deprecated LMSTYLE lump, supporting up to 65k lightstyles. The number of styles per-face is variable (inferred via lump size vs surface count). These two changes make it suitable to be used even without LMSHIFT.

Deprecated Lumps

These BSPX lumps have been deprecated by newer BSPX lumps.

LMSHIFT

Obsolete-notext.pngDeprecated:Deprecated by DECOUPLED_LM.

Defines lightmap scale for each surface. Renderers supporting this lump must support 256x256 (really 255x255) lightmaps, instead of only the usual 16x16 (really 15x15).

Unnecessary and possibly incompatible with Quake III BSPs and derivatives.

LMOFFSET

Obsolete-notext.pngDeprecated:Deprecated by DECOUPLED_LM.

Required when using LMSHIFT to maintain compatibility with engines/renderers that do not support LMSHIFT.

LMSTYLE

Obsolete-notext.pngDeprecated:Deprecated by LMSTYLE16.

Stores the 4 lightstyle indices for each surface; only makes sense when used in conjunction with LMSHIFT.

External links