Call of Duty 2: d3dbsp: Difference between revisions
No edit summary |
No edit summary |
||
| Line 24: | Line 24: | ||
==Lump[8] vertexes== | ==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 opacity and the colour (RGB). Then | 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 (RGB). Then 2 DWORDs which have to do with texture shifting, and 2 more DWORDs for something yet unknown. | |||
<pre>struct | |||
{ | |||
float position[3]; | |||
int normal[3]; | |||
char colour[3]; | |||
char opacity; | |||
float shift[2]; | |||
float [2]; | |||
int [6]; | |||
};</pre> | |||
==Lump[37] entities== | ==Lump[37] entities== | ||
Revision as of 02:09, 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.
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.
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.
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 opacity and the colour (RGB). 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 colour[3];
char opacity;
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.
Made by CoDEmanX and Daevius
