Lightmap width and height of size 0


I’m not sure if this is totally relevant to this forum but I’m posting this here because I cannot register to quake3world forums…

I’m trying to load BSP lightmap data for my own renderer and I’ve noticed that some maps I make with GTKRadiant 1.6.5 or some RTCW maps have lightmap width or height of size 0. I was wondering what could cause this? I don’t think there is an error in loading the BSP data. I’m using q3map2 (final) to compile the maps.


It happens on BSP draw surfaces that use vertex lighting instead of a lightmap. You can check the lightmap number to see if vertex lighting should be used.

#define LIGHTMAP_2D         -4   // shader is for 2D rendering
#define LIGHTMAP_BY_VERTEX  -3   // pre-lit triangle models
#define LIGHTMAP_NONE       -1

For planar, patch, and flare surfaces; LIGHTMAP_BY_VERTEX is used for vertex lit surfaces, otherwise it should have a lightmap number greater or equal to 0 for an actual lightmap. See the next section for triangle surfaces.

LIGHTMAP_2D should not appear in BSP files. It’s used internally by the engine. LIGHTMAP_WHITEIMAGE uses a solid white lightmap; I don’t think it’s used by q3map or q3map2 but I’m not 100% sure.

The original q3map uses LIGHTMAP_NONE for vertex lit misc_model triangle surfaces. Lightmapped misc_models are not supported. Q3 and RTCW engines force all BSP triangle surfaces to use LIGHTMAP_BY_VERTEX regardless of the actual lightmap number. LIGHTMAP_NONE is also used internally by the engine for 3D models and does not render correctly on BSP surfaces.

q3map2 uses LIGHTMAP_BY_VERTEX or a real lightmap (the same as the other surface types) for BSP triangle surfaces. ET engine supports vertex lit and lightmapped BSP triangle surfaces.

So in my Spearmint fork of ioquake3 for instance, I treat LIGHTMAP_NONE on BSP triangle surfaces as LIGHTMAP_BY_VERTEX and support all other lightmap numbers as usual in order to support maps made with q3map and q3map2.

1 Like

Problem is that both width and height are 0, but the index is also 0 so it is supposed to be a lightmap. I created a simple box brush with 4 light entities for testing and this is the console message I get for q3map2 final with bounce:

   7326 luxels used
   32768 luxels stored (22.36 percent efficiency)
   0 solid surface lightmaps
   0 identical surface lightmaps, using 0 luxels
   0 vertex forced surfaces
   0 vertex approximated surfaces
   2 BSP lightmaps
   2 total lightmaps
   1 unique lightmap/shader combinations

   6 diffuse surfaces
   0 total diffuse lights
   0 brush diffuse lights
   0 patch diffuse lights
   0 triangle diffuse lights
   No diffuse light to calculate, ending radiosity.

Hmm, I don’t know. The Q3 engine doesn’t actually use surface lightmap width or height though. It uses the lightmap number from surface and lightmap image coords (0.0 to 1.0) from the vertex data.

Edit: In Q3’s maps there are flare surfaces with lightmap 0 and width and height are 0. Seems unlikely your map has flares though.

Well I am using the info on the Q3 BSP format taken here:
For the BSP Face data we have the following:


int texture Texture index.
int effect Index into lump 12 (Effects), or -1.
int type Face type. 1=polygon, 2=patch, 3=mesh, 4=billboard
int vertex Index of first vertex.
int n_vertexes Number of vertices.
int meshvert Index of first meshvert.
int n_meshverts Number of meshverts.
int lm_index Lightmap index.
int[2] lm_start Corner of this face’s lightmap image in lightmap.
int[2] lm_size Size of this face’s lightmap image in lightmap.
float[3] lm_origin World space origin of lightmap.
float[2][3] lm_vecs World space lightmap s and t unit vectors.
float[3] normal Surface normal.
int[2] size Patch dimensions.

I am reading lm_size[0] for width and lm_size[1] for height. Those values are greater than 0 for the vast majority of faces in the RTCW maps I have been loading.