Call of Duty 4: d3dbsp: Difference between revisions
No edit summary |
mNo edit summary |
||
Line 10: | Line 10: | ||
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)). | 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. | 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 <code>(3 + (number of lumps * 2)) * 4</code>. | ||
[[Image:Lightbulb.png]]'' Note: there can be a difference of number of lumps per map. If a map has a leak | [[Image:Lightbulb.png]]'' Note: there can be a difference of number of lumps per map. If a map has a leak |
Revision as of 00:40, 16 February 2009
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 | 51120 Lump ID | Lump length Start offset = Header length + Lump index length = (3 + (39 * 2)) * 4 = 324 End offset = Start offset + Lump length = 51120 + 324 = 51444 Start offset | End offset 324 | 51444 ↓ | ↓ - 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[0x06] - unknown
Lump[0x07] - unknown
Lump[0x08] - unknown
Lump[0x09] - unknown
Lump[0x0A] - Vertex Data
ID 0Ah = 10
68 bytes per entry.
Lump[0x0B] - unknown
ID 0Bh = 11
Lump[0x18] - unknown
ID 18h = 24
Lump[0x19] - Bounding Box?
ID 19h = 25
112 bytes per entry.
Lump[0x1A] - unknown
ID 1Ah = 26
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[0x1F] - Nodes
ID 1Bh = 31
Lump[0x21] - unknown
ID 21h = 33
Lump[0x22] - unknown
ID 22h = 34
Lump[0x23] - unknown
ID 23h = 35
Lump[0x24] - unknown
ID 24h = 36
Lump[0x25] - unknown
ID 25h = 37
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[0x2F] - unknown
ID 2Fh = 47
Lump[0x30] - Vertex Data
ID 30h = 48
68 bytes per entry. - Redundancy??
Lump[0x31] - unknown
ID 31h = 49
Lump[0x33] - unknown
ID 33h = 51
Lump[0x34] - unknown
ID 34h = 52
1 byte per entry.
Lump[0x35] - unknown
ID 35h = 53
Lump[0x36] - unknown
ID 36h = 54
Note: If not listed, either missing or ID not in use.
Made by Daevius, CoDEmanX & Silicone_Milk