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.
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.
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.
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.
Founded in 2004, Leakfree.org became one of the first online communities dedicated to Valve’s Source engine development. It is more famously known for the formation of Black Mesa: Source under the 'Leakfree Modification Team' handle in September 2004.
