Call of Duty 2: d3dbsp

From COD Modding & Mapping Wiki
Revision as of 09:18, 15 January 2009 by CoDEmanX (talk | contribs)
Jump to navigation Jump to search

The .d3dbsp structure, Call of Duty 2'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.

Numbers are stored in little-endian.


Header

The file starts with 2 DWORDS: the header 'IBSP' indicating this is a BSP file originally designed by ID software and the version number 4 (4h).

Then there is an array, filled with DWORD pairs, indicating the lump's offset and length respectively. The array ends with 2 empty (zero) DWORDs. Each lump that has size 0 in the list is simply not filled / not used.

 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).


Lump[0] texture files

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.

struct
{
    char texture[64];
    int  [2];
};


Lump[1] lightning

Contains most of the pre-processed lightning. Not present if compiled without lightning, otherwise a multiple of 4.096 KB.


Lump[4] planes

Each plane is defined by 4 DWORDs, 3 for the normal vector and 1 for the offset of the origin. Planes are faces with infinite length, we suspect they have to do with the rendering system.

struct
{
    float normal[3];
    float distance;
};

Lump[5] Brushsides?

under investigation


Lump[6] Brushes?

under investigation


Lump[7] face-vertex groups

It's like the missing link between the faces and vertex lump. It refers to both of them creating (more logical?) groups. Possibly one entry per texture, but not confirmed for complex maps yet.


Lump[8] vertexes

Every vertex is 17 DWORDs long (98 bytes). First 3 DWORDs define the position (x y and z). Next 3 DWORDs define the normal vector of the vertex (x y and z) (WHY?!), then a DWORD which defines the colour (BGR) and the opacity (A). Then 2 DWORDs which have to do with texture shifting, and 2 more DWORDs for something yet unknown. At the end we have 6 DWORDs having to do with texture alignment (rotation?).

struct
{
    float position[3];
    int   normal[3];    
    char  bgr[3];
    char  a;
    float shift[2];
    float [2];
    float [6];
};


Lump[9] faces

A face is made up of 3 vertexes, giving a triangle.

struct
{
    int vertex_id[3];
};


Lump[23] Bounding Boxes?

Assumed to be the Skybox.


Lump[36] VIS

Present if VIS has been calculated during the compile process.


Lump[37] entities

The entities lump is readable and stored (almost) the same way described in the .MAP file structure.

struct
{
    char entities[];
};


Web Links


Made by CoDEmanX and Daevius