Call of Duty 2: d3dbsp: Difference between revisions

From COD Modding & Mapping Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 39: Line 39:
==Lump[8] vertexes==
==Lump[8] vertexes==
Every vertex is 17 DWORDs long (98 bytes).
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 opacity and the colour (BGR). Then 2 DWORDs which have to do with texture shifting, and 2 more DWORDs for something yet unknown.
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.


<pre>struct
<pre>struct
Line 45: Line 45:
     float position[3];
     float position[3];
     int  normal[3];     
     int  normal[3];     
     char  colour[3];
     char  bgr[3];
     char  opacity;
     char  a;
     float shift[2];
     float shift[2];
     float [2];
     float [2];

Revision as of 02:23, 13 December 2008

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[5] planes

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

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

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.

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

Lump[37] entities

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

struct
{
    char entities[];
};

Made by CoDEmanX and Daevius