Some Secrets of Binary Space Partition Files

by | January 31st, 2010 | Articles | 1 Comment »

What makes one map larger than another? The amount of brushes? The number of models? The lighting? Displacements? The pakfile?

Well, you can find out exactly how much each of these contributes to your map’s size using several programs, I like to use GCFScape for this though, you can find that here

Just open up any .BSP file (either from your maps folder or from one of the valve GCF files located in your steamapps folder)  and navigate to the lumps folder, sort by size and take a look at the biggest lumps

Commonly large lumps (>1MB):

Lump number Usage
40 Pakfile
8 Lighting
53 Lighting HDR
34 Displacement lighting
29 Physics collision data
7 Faces
58 Faces HDR
35 Game-specific data
33 Displacement verticies
27 Original faces

So what do all of these lumps actually contain?

Lump 40 is commonly large for custom maps, the pakfile, this lump contains all of the custom stuff people put into their maps. New textures, models, sounds. This lump can easily hit 50MB and is single handedly the largest contributor to large .bsp file sizes. If you’re aiming for streamlined downloading it will be worth looking at what elements you really need, what you can optimize and what can be done in a different manner (Texture re-colours for example can be done to a limited degree via .vmt proxies)

Lump 8 and 53 contain the lightmap data for every brush face in the map. Compiling only LDR will eliminate lump 53 entirely, often saving ~10MB; however this should only be considered in a dire pinch. The 8 and 53 lumps are often exactly the same size, they’ll start to differ once you start making lights different for HDR.

The key thing to remember with lighting is luxel size, the bigger the luxels on any particular face, the less information stored about it and the smaller the lump. Faces that don’t have any strong change in light should have their lightmap scale increased to reduce the number of luxels. Ceilings, roofs, walls entirely in shade, all are good candidates for lightmap optimization, but that’s for another tutorial.

Lump 34 is very similar to 8/53 in nature: it stores the lighting for displacements, it seems to be much smaller than the normal lighting lumps though. Size is probably tightly proportional to the number of displacement vertices.

Lump 29 contains all the data about your solid brushes and models. Depending on the number of props, displacements and brushes you have, your physics lump can be several MB. Reducing the size of this lump just comes down to making more props non-solid. A tricky one to optimize.

Lumps 7 and 58 contain all the info about the faces after vbsp.exe has spliced them up. There are two versions because of the lighting information stored, all lightmap data is in lumps 8/53 but there is some extra data stored in 7/53. These two shouldn’t get over a few MB at most.

Lump 35 holds game specific data, lists of all the prop_static entities are in here too, they’re not in the entity lump (lump 0) Less props used, smaller game lump. Not often a large lump though, certainly not one to actively try and cut down.

Lastly the original faces lump, 27, can be pretty hefty. By pretty hefty I mean ~1MB. This one contains all the faces of brushes as you see them more like in hammer instead of ingame. It still has all the void-touching faces culled and probably doesn’t contain skip faces either. If this lump is very large you may have some inefficient brushwork going on inside hammer, your faces and faces HDR lumps (7/58) are also going to be larger.

In conclusion:

The lumps you’ll want to concentrate on when optimizing are the pakfile and lighting lumps, cutting out custom content, increasing lightmap scales and removing dynamic lights. The displacement lighting lump is next on the list but generally quite a bit smaller than the lighting lumps; Lower scale displacements, higher lightmap scales.

If you’re interested in the other lumps and more detail, please refer to the Valve Developer Wiki which has a list of all the lumps and more detailed info on the format each.

Tags: , , ,

One Response to “Some Secrets of Binary Space Partition Files”

  1. chickenm4n says:

    this is just a springboard for many filesize optimization tutorials.

    it’s also a springboard for lumpiness.

Leave a Reply

You must be logged in to post a comment.