BSP flags (Source)

This is a draft page. It is a work in progress open to editing by anyone.
Remember to check for any notes left by the tagger at this article's talk page.

public/bspflags.h defines bitfields used to tell the game engine and compiler how a brush face should be drawn in-game (surface flags), and what should be inside the brush (contents flags). They are descended from the method used by Quake II.

These are normally defined via Material map compile flags, but they can also be applied directly into a VMF's brush face, using "contents" "####" for contents flags and "flags" "####" for surface flags (wherein #### is the bitfield represented in base 10 form). Some values are also defined via other means, such as func_detail for CONTENTS_DETAIL.

Important: Hammer 4.x strips these values! Put applicable geometry in an instance to avoid issues.

Confirm: Hammer++ might keep the values.

List of flags

Surface flags

Surface flags on different faces of a brush generally do not need to match. If two or more conflicting flags are assigned, then the flag with the lowest bit value will take priority.

Unlike Quake II, surface flags are stored as a 16-bit value instead of a 32-bit value. This is because most information about how to draw the surface can be determined instead at runtime via the VMT.

Bit	Flag name	Dev comment	Description
0x0001	SURF_LIGHT	value will hold the light strength	Normally set on any surface that matches a RAD file entry. Confirm:Can the value field be set in a VMF, or does it require regressing to MAP instead?
0x0002	SURF_SKY2D	don't draw, indicates we should skylight + draw 2d sky but not draw the 3D skybox	Shows only the 2D skybox. Set via $Compile2DSky
0x0004	SURF_SKY	don't draw, but add to skybox	Shows both the 2D and 3D skybox. Set via $CompileSky
0x0008	SURF_WARP	turbulent water warp	Confirm:This was for Quake I-style water/slime/lava in ; does this still work?
0x0010	SURF_TRANS	(None)	Surface is translucent, either via $translucent or $alpha. {{modernConfirm|Might also apply to $alphatest.
0x0020	SURF_NOPORTAL	the surface can not have a portal placed on it	Set via %NoPortal
0x0040	SURF_TRIGGER	FIXME: This is an xbox hack to work around elimination of trigger surfaces, which breaks occluders	Set via %CompileTrigger {{modernConfirm|Might also do something if VRAD is run with -nodrawtriggers.
0x0080	SURF_NODRAW	don't bother referencing the texture	Set via %CompileNoDraw
0x0100	SURF_HINT	make a primary bsp splitter	Set via %CompileHint
0x0200	SURF_SKIP	completely ignore, allowing non-closed brushes	Set via %CompileSkip. Should never be used on anything except a hint brush.
0x0400	SURF_NOLIGHT	Don't calculate light	Face is unlit. Set via %CompileNoLight if using or newer or . Confirm:Might be set automatically on UnlitGeneric materials.
0x0800	SURF_BUMPLIGHT	calculate three lightmaps for the surface for bumpmapping	Implied by $bumpmap. This is probably why ssbumps are cheaper to render than regular normal maps.
0x1000	SURF_NOSHADOWS	Don't receive shadows	Confirm:Might be dictated by info_no_dynamic_shadow?
0x2000	SURF_NODECALS	Don't receive decals	Given by $nodecal VMT parm, as well as %nopaint in Portal 2 and later.
0x4000	SURF_NOCHOP	Don't subdivide patches on this surface	Set via %CompileNoChop. Has the side effect of affecting triangulation, as well.
0x8000	SURF_HITBOX	surface is part of a hitbox	[Why?]

Content flags

Content flags on different faces of a brush almost always need to match. Mismatched contents will result in Compiler errors, and leaves it up to the Compiler to decide what contents a brush should have. If two or more conflicting flags are assigned, then the flag with the lowest bit value will take priority.

Bit	Flag name	Official description	Notes
0x00000000