Call of Duty 4: d3dbsp

The .d3dbsp structure, Call of Duty 4's variant on the well-known BSP format, is rather difficult to decipher. Since it's a binary file you can't simply read it. A hexadecimal editor is the best tool in this case.

I am still deciphering it myself, I will post anything I happen to get known of regarding the file format.

Be sure to read here and here before you even try to decipher it. Knowing what the technique is that BSP formatted maps use, could be handy as well.

Every number ending with an 'h' indicates its a number using the hexadecimal count system. For other numbers one can assume the decimal count system is used.

Header & Lump index

The file starts with 3 DWORDS: the header 'IBSP' indicating this is a BSP file originally designed by ID software, the version number 22 (16h) (the one CoD4 uses (which is different from CoD2)) and the number of lumps (varies from 37 (a real map) 24 (18h) or 23 (17h) if you don't compile light (test maps)).

Then there is an array of the length the 3rd DWORD in the header describes, filled with DWORD pairs, indicating the lump's id and length respectively. No absolute offsets are stored in the lump index (in contrast to previous CoD BSP versions). Each lump is connected and one can determine the offset by taking the previous lump's offset + length (padded to a multiple of 4). The first lump's offset is (3 + (number of lumps * 2)) * 4.

 Note: there can be a difference of number of lumps per map. If a map has a leak
(no solid skybox or not everything is IN the skybox) the bsp only has 24 lumps (or even 23 if light is not
compiled). The bsp description yet only supports the 37-lumps version (a valid map).

Example

Offset calculation of the first lump:

00 00 00 00  |  B0 C7 00 00
     ↓       |       ↓       - Little Endian transfrom
00 00 00 00  |  00 00 C7 B0
     ↓       |       ↓       - hex to dec
     0       |     51.120
  Lump ID    |   Lump length


Start offset = Header length + Lump index length
             = (3 + (39 * 2)) * 4
             = 324

End offset   = Start offset  + Lump length
             = 51.120 + 324
             = 51.444

Start offset | End offset
    324      |   51.444
     ↓       |     ↓         - dec to hex
    144      |   C8 F4

Lump[0x00] texture filename + flags

Texture information is 72 bytes long per texture. The first 64 bytes are used for the texture name. Then we have an DWORD for flags, and another DWORD for content flags.

Lump[0x01] - Lightmaps

3145728 bytes per entry?

Lump[0x02] - Light Grid Points

4 bytes per entry.

Lump[0x03] - Light Grid Colors

168 bytes per entry.

Lump[0x04] - Planes

16 bytes per entry.

Lump[0x05] - Brush Sides

8 bytes per entry.

Lump[0x0A] - Vertex Data

ID 0Ah = 10
68 bytes per entry.

Lump[0x19] - Bounding Box?

ID 19h = 25
112 bytes per entry.

Lump[0x1B] - Nodes

ID 1Bh = 27
36 bytes per entry.

Lump[0x1C] - Leafs

ID 1Ch = 28
24 bytes per entry.

Lump[0x1D] - Leafbrushes

ID 1Dh = 29
4 bytes per entry.

Lump[0x27] entities

ID 27h = 39
Varying bytes per entry depending on size of entity. Basically a char[] terminated by a binary zero (=string). The entities lump is readable and stored almost the same way described in the .MAP file structure.

Lump[0x29] - Reflection Probes

ID 29h = 41
128 kilobytes per entry (131.140 bytes per).

Lump[0x2B] - Primary Lights

ID 2Bh = 43
128 bytes per entry.

Lump[0x2C] - Light Grid Header

ID 2Ch = 44
50 bytes per entry.

Lump[0x2D] - Light Grid Rows

ID 2Dh = 45
16 bytes per entry.

Lump[0x30] - Vertex Data

ID 30h = 48
68 bytes per entry. - Redundancy??

Lump[0x34] - Light Regions

ID 34h = 52
1 byte per entry.

Made by Daevius, CoDEmanX & Silicone_Milk