Map compiles under SDK 2007, but won't compile under SDK 2013


I’ve got an odd issue with one of my maps I’m working on. I’m running into an issue with trying to compile the loop mod version of bm_c2a2a with the new tools. Specifically, the map will compile with no errors under the 2007 SDK, but the EXACT SAME .vmf will fail under SDK 2013 with a max brushsides error. What’s really baffling about this is that the limit seems to be significantly lower in the 2013 sdk, to the point where I’ve cut large portions of the map, and yet I’m still getting a max brushsides error.

Anyone have any idea what might be going on? Corrupt geometry? Something else? Any help would be appreciated.


The deeper I dig into this issue, the weirder it gets. The uncut version of the map compiles fine in sdk 2007, but the heavily cut version throws a max brushsides error in both 2013 AND 2007. That’s right, the version with huge pieces torn out of it hits the brush limit, yet the version not cut at all DOESN’T (at least, not in SDK 2007).


Another update. I figured out how to get the heavily cut version of the map to compile in the 2013 SDK. It turns out that hammer still counts brushes in deactivated visgroups towards the total (for some unknown reason), and when I deleted the contents of the hidden brush groups, the map would compile. So now here’s the compilation results of the identical map in both 2007 and 2013.

2007 SDK:

[code]Ready to Finish

Object names Objects/Maxobjs Memory / Maxmem Fullness

models 137/1024 6576/49152 (13.4%)
brushes 6220/8192 74640/98304 (75.9%)
brushsides 59958/65536 479664/524288 (91.5%) VERY FULL!
planes 46414/65536 928280/1310720 (70.8%)
vertexes 26928/65536 323136/786432 (41.1%)
nodes 7185/65536 229920/2097152 (11.0%)
texinfos 8879/12288 639288/884736 (72.3%)
texdata 479/2048 15328/65536 (23.4%)
dispinfos 32/0 5632/0 ( 0.0%)
disp_verts 2720/0 54400/0 ( 0.0%)
disp_tris 4480/0 8960/0 ( 0.0%)
disp_lmsamples 27004/0 27004/0 ( 0.0%)
faces 15032/65536 841792/3670016 (22.9%)
hdr faces 15032/65536 841792/3670016 (22.9%)
origfaces 11323/65536 634088/3670016 (17.3%)
leaves 7323/65536 234336/2097152 (11.2%)
leaffaces 20493/65536 40986/131072 (31.3%)
leafbrushes 12080/65536 24160/131072 (18.4%)
areas 26/256 208/2048 (10.2%)
surfedges 115202/512000 460808/2048000 (22.5%)
edges 73414/256000 293656/1024000 (28.7%)
LDR worldlights 466/8192 41008/720896 ( 5.7%)
HDR worldlights 466/8192 41008/720896 ( 5.7%)
leafwaterdata 6/32768 72/393216 ( 0.0%)
waterstrips 1854/32768 18540/327680 ( 5.7%)
waterverts 0/65536 0/786432 ( 0.0%)
waterindices 34929/65536 69858/131072 (53.3%)
cubemapsamples 122/1024 1952/16384 (11.9%)
overlays 161/512 56672/180224 (31.4%)
LDR lightdata [variable] 11561692/0 ( 0.0%)
HDR lightdata [variable] 11561692/0 ( 0.0%)
visdata [variable] 91737/16777216 ( 0.5%)
entdata [variable] 533660/393216 (135.7%) VERY FULL!
LDR ambient table 7323/65536 29292/262144 (11.2%)
HDR ambient table 7323/65536 29292/262144 (11.2%)
LDR leaf ambient 33632/65536 941696/1835008 (51.3%)
HDR leaf ambient 33556/65536 939568/1835008 (51.2%)
occluders 0/0 0/0 ( 0.0%)
occluder polygons 0/0 0/0 ( 0.0%)
occluder vert ind 0/0 0/0 ( 0.0%)
detail props [variable] 1/12 ( 8.3%)
static props [variable] 1/147164 ( 0.0%)
pakfile [variable] 13140781/0 ( 0.0%)
physics [variable] 2071405/4194304 (49.4%)
physics terrain [variable] 9344/1048576 ( 0.9%)

Level flags = 0

Total triangle count: 40910
Writing d:\program files (x86)\steam\steamapps\common\black mesa\bms\mapsrc\loopmod\maps\bm_c2a2a_d7_t2.bsp
58 seconds elapsed[/code]2013 SDK:

[code]Ready to Finish

Object names Objects/Maxobjs Memory / Maxmem Fullness

models 137/1024 6576/49152 (13.4%)
brushes 6220/8192 74640/98304 (75.9%)
brushsides 65490/65536 523920/524288 (99.9%) VERY FULL!
planes 58082/65536 1161640/1310720 (88.6%) VERY FULL!
vertexes 27169/65536 326028/786432 (41.5%)
nodes 7411/65536 237152/2097152 (11.3%)
texinfos 8893/12288 640296/884736 (72.4%)
texdata 479/2048 15328/65536 (23.4%)
dispinfos 32/0 5632/0 ( 0.0%)
disp_verts 2720/0 54400/0 ( 0.0%)
disp_tris 4480/0 8960/0 ( 0.0%)
disp_multiblend 2720/0 217600/0 ( 0.0%)
disp_lmsamples 27032/0 27032/0 ( 0.0%)
faces 15096/65536 845376/3670016 (23.0%)
hdr faces 15096/65536 845376/3670016 (23.0%)
origfaces 11344/65536 635264/3670016 (17.3%)
leaves 7549/65536 241568/2097152 (11.5%)
leaffaces 20723/65536 41446/131072 (31.6%)
leafbrushes 12191/65536 24382/131072 (18.6%)
areas 26/256 208/2048 (10.2%)
surfedges 115639/512000 462556/2048000 (22.6%)
edges 73715/256000 294860/1024000 (28.8%)
LDR worldlights 0/8192 0/819200 ( 0.0%)
HDR worldlights 466/8192 46600/819200 ( 5.7%)
leafwaterdata 6/32768 72/393216 ( 0.0%)
waterstrips 1882/32768 18820/327680 ( 5.7%)
waterverts 0/65536 0/786432 ( 0.0%)
waterindices 35175/65536 70350/131072 (53.7%)
cubemapsamples 122/1024 1952/16384 (11.9%)
overlays 161/512 56672/180224 (31.4%)
LDR lightdata [variable] 0/0 ( 0.0%)
HDR lightdata [variable] 13090183/0 ( 0.0%)
visdata [variable] 93043/16777216 ( 0.6%)
entdata [variable] 533660/393216 (135.7%) VERY FULL!
LDR ambient table 7549/65536 30196/262144 (11.5%)
HDR ambient table 7549/65536 30196/262144 (11.5%)
LDR leaf ambient 7549/65536 211372/1835008 (11.5%)
HDR leaf ambient 32501/65536 910028/1835008 (49.6%)
occluders 0/0 0/0 ( 0.0%)
occluder polygons 0/0 0/0 ( 0.0%)
occluder vert ind 0/0 0/0 ( 0.0%)
detail props [variable] 1/12 ( 8.3%)
static props [variable] 1/169786 ( 0.0%)
pakfile [variable] 19195719/0 ( 0.0%)
physics [variable] 2604765/4194304 (62.1%)
physics terrain [variable] 0/1048576 ( 0.0%)

Level flags = 6

Total triangle count: 41140
Writing d:\program files (x86)\steam\steamapps\common\black mesa\bms\mapsrc\loopmod\maps\bm_c2a2a_d7_t2.bsp
12 minutes, 29 seconds elapsed[/code]There’s a discrepancy of 5532 brush sides between the two compilers!

I think I may have actually stumbled across a compiler glitch. I’ll try and investigate further when I have the time. Until then, if anyone has any idea what might be causing this, please tell me.


Why are you using sdk2013 to do the compile when BMS retail has its own Hammer and compile tools in the Bin folder ???


This. Retail BM Source engine has doubled many limits that 2013 or even 2015 Source branches have.


You should join the source modding discord.
Plenty of experienced mappers there.


Sorry for the confusion. When I say 2013, I mean the Black Mesa beanch of the engine.


Yeah, see, I meant DOTA2.


So, an update for you all. I still haven’t figured out the exact cause of the issue, but I’ve made some progress in narrowing it down. Whatever’s happening, it’s definitely happening in VBSP. The phantom brushsides appear immediately after compiling the vmf with the Black Mesa retail VBSP, and immediately disappear when compiling with the SDK 2007 VBSP (for the mod version).

The good news is that I have eliminated several theories as to why this might be happening:

  • Both compilers count skip brushes towards the limit, despite the fact that VBSP ignores them during compilation (I actually have to hide skips to be able to compile on the Black Mesa Source branch, that’s how close I am to the brushside limit).
  • Both compilers count player clips, brush entities, and trigger brushes towards the limit (annoying, since trigger brushes aren’t really brush entities as I know them).
  • Both compilers chop the level the same amount of times (still not exactly sure what a ‘chop’ is in the context of VBSP, but I know they both arrive at the same number thanks to -verbose).
  • Both hammer editors show the vmf as having the same amount of objects (so I know it’s not on hammer’s end).
    I’ll continue to keep you guys updated as I work on this. The next thing I’m going to try is compiling a different vmf in both engines, to see if the phantom brushsides appear there as well. That way I can figure out if this issue is something unique to this level, or if it’s a widespread problem.


Tried compiling a different map (bm_c2a1a). Found something interesting.

See, bm_c2a1a has 4,286 phantom brushsides. My version of bm_c2a2a has 5,532. That’s a difference of 1,246 brush sides. So the number isn’t constant per map. It varies, for seemingly no reason.


From what I’ve read, the .vmf’s that come with the game aren’t actually up to date. Also, if you used a decompiler then it can’t automagically recreate toolbrushes that are removed at compile.


Right, but I wasn’t comparing the bsp I compiled to the bsp that comes with the retail version (although that IS a good idea), I was comparing it to a bsp of the same map compiled with the other vbsp tool. Therefore, since both maps came from the same vmf, the only way the brushsides could be changing is because the two versions of vbsp are doing something differently, and I intend to find out what that is.

I am beginning to think it’s likely something to do with brush entities.


Ah, yes, this problem. This was definitely something I struggled with when I tried porting c2a2a into 2013. I mentioned in the loop mod development thread that I had this issue but I forget if I’ve brought it up in other places because I come here so rarely nowadays.

But now I’m curious: Did you manage to get c2a2a to compile in 2013? I ask because I didn’t the last time I tried and what’s on the workshop now is compiled under 2007 (I’d be over the moon if it worked in 2013).


I have a version that compiles in 2013, but that came at the cost of cutting quite a lot of detailing. I started to see where I could optimize the map, and I converted quite a few brush-hogs to models, but that wasn’t enough to restore the detailing I cut. So, I decided to try and re-detail what I could.

Then things… got a little out of hand. I started making more substantial changes. I aligned the loop to the 16 scale hammer grid, re-added the electrical wire from Half-Life’s c2a2a, blocked off the shortcut hatch to the bridge, and then I began to re-detail the security room and elevator hall.

I actually have some WIP screenshots from a lighting test earlier today.

The elevator hall:

The initial loop junction:

The slightly reworked (and incomplete) track control:

The wire strikes back:

The removal of the shortcut hatch:

So yeah, it runs in the Black Mesa Source engine, but not without modifications to bring it below the limits.


Huh. Interesting that you decided to detach that downed pipe near the bridge (I think). I can remember my reason for reattaching it was because there were a ton of brushes there in the case of the downed pipe. I still cite it as the only significant change that I made to dev areas (actually, I figure this might be why you did it as a reversion to how it is originally downed).

I’ll be interested to see what this ends up looking like in the end~


Any changes you made to the dev maps that I undid were almost certainly not done so intentionally. The only exception I can think of is cutting that fork in the track you added near where the wire is now. I really didn’t want to get rid of that one, but the brush limit gave me no choice.

Any other changes only happened because when I started working on porting the map, I took the existing loop version of c2a2a and deleted all of the areas from the decompiled mod version c2a2a, and then took what was left and stuck it to the source vmf of the retail version of the level. Any changes you made to the dev level that I didn’t specifically try and preserve were lost during this process. The reason I did that in the first place was because I theorized you were running up against the brush limits because the decompiler had inefficiently recreated the level, and that using the official source vmf might fix that. Unfortunately, I was wrong, and it didn’t help with that, but it does mean that I don’t have to worry about differences between the mod and retail version of the map anymore.

As for the pipe, I believe I know what brushwork you’re speaking of. I actually did take care of that, though I’m not really happy with how it’s turned out. If you look closely in the picture I uploaded, you’ll notice there’s a weird texture where the pipe would meet the wall. That’s because I converted all of that detail brushwork to a single model, which has caused some… issues with textures. When I get around to fixing that, I’m going to convert the detailing into as many models as needed; not one. I also went ahead and replaced the drawbridge and electrical equipment with the model substitutes you’d created to further reduce the brushside count. In this process, I found something I think you may have overlooked: the giant vent near the top of the drawbridge room is made of quite a few complex detail brushes. Converting that to a model didn’t result in any significant or noticeable decrease in lighting quality, and gave me around a hundred more brushsides to use.

Right now, I believe I’ve carved out a budget of about… 200 brushsides, give or take. I think that might allow me to add a single, non-complex room to the map further down the line. If a technique with displacements I’m experimenting with works out, I might be able to bump that up even further (and maybe even restore a few cut areas). For now though, my primary focus is getting the look and feel of the elevator hall and track control room to a place I’m happy with, along with playtesting and making gameplay tweaks where I think they’re necessary.


I know that vent. I also converted that to a model when I did stuff during development. What the hell?

If you did removed that track, I would suppose that change will get reflected in the switchboard (if it’s even still there in your version; it looks like it is but it’s a bit hard to see from that angle).


I mean, It’s possible I may be mis-remembering. I’ll double check when I get to my home computer in a bit, but I’m fairly certain I checked in the vmf you’d given me to see if I could just use the pre-existing model, only to find there was none.

And yeah, I’m waiting to update the switchboard until I get everything finalized. Whatever layout I settle on is what it will show.