Ok, my map is damn big with an overhaul of brushes, apparently
(according to the compile log). So basically, the thing won't compile
or run (it actually runs an older version of the bsp because it can't
compile the newer one).

So here's my question: is it possible to change the maximum amount of
brushes a map can have present? Obviously, I bet most of you are
thinking, well why the hell not just delete a load of brushes. I'll
tell you why. Because I spent literally hours and hours fixing lights,
brushes here and there and, although lazy and pathetic, a fair bit of
carving. In most cases, clipping wouldn't have done any different to
carving so I opted for the less time-consuming option.

The trouble is, there are so many brushes that I carelessly covered
over with other brushes thinking there wasn't a limit. I hope someone
can help me out here.

If you wish to see my compile (although you'll probably just see what I
saw) just say, but I think that is all that is wrong. I just need to
get this mess-up fixed so I can move onto to next problem... :smile:

Cheers

The maximum brush count varries. When you compile bsp it splits brushes
into even more brushes, so an actual amount can't be really said.

That said the limit gets to be around 7500-8000 brushes that you have
in a map. Due note: thats its the compile tool that has the max brush
amount built into it (as not to overload the 256mb ram that people
have), not the engine.

Over at ES we're facing a similar issue of having 8000+ brushes in one
map to accomidate for two capital ships fighting one another. The coder
tells me that he can try to have a look at the compile code to increase
the max brushes, but nothing so far. So in short:

Post your compile log so we can seee if the max brushes error is comming up, or your just reading something wrong perhapse.

But if it is that your exceding the max brushes, I recomend that you
just take a step back from your map and have a good hard look at it and
ask yoruself if everything there is truly essential to having a
functional map.

---

Posting And You

Remember func_detail is your friend. Turn any brush that doesn't need to or shouldn't block BSP into a func_detail. Stairs for example, should be entirely func_detail for small sets of steps, and for full staircases should be a ramp with wedges for steps grouped together into func_detail entities. Never make stairs entirely out of world brushes, they steal BSP and VIS's lunch money and throw them in a trash can.

---

o

"I spent literally hours..."

welcome to the joys of mapping, my friend. (sorry couldn't resist :heee: )

Actually brushes don't have much to do with the polygons in the compiled level. No matter how much they split each other up, they're replaced by flat polygons by the compiler during vbsp. One brush stays one brush in Hammer. These limits are very high. If you reach them your map has probably a grave performance problem anyway. Try to simplify your architecture, use as few brushes as possible. Only use brushes for thick walls, ceilings ect. Anything smaller than a stair is very problematic and should be a) made a func_detail (for other reasons) and b) avoided or replaced by a model or well-placed texutre.

Maybe some Hammer screens could help us to give you more ideas of how to simplify the map :smile:

Well um... I think I know what I can get rid of in terms of archetecture, so that'll help a lot.

One little question (I'm embarassed to ask), what benfits to func_details give over regular brushes?

For personal reasons I don't feel comfortable with releasing screens of my work, sorry guys- it's nothing personal I'm just a little perfectionistic and rather annoyed with people in the past stealing my work that I've spent all my free time devoting to it. I've even had one person totally rip off one of my map ideas and publish a map looking 95% the same as mine before I released my version, from three screenshots in Hammer which I released on a forum I was a member of for about a week. So I really do apologise for that. I've heard you guys in this forum are kind to those who are just a little bit slower and more time-constrained than most mappers :smile:

I'll gladly post my log as one thing I want to do is get this darn thing fixed. I'm not on the computer that has the map on so I can't get the log up yet. I'll post it as soon as.

? quote:I've heard you guys in this forum are kind to those who are just a little bit slower and more time-constrained than most mappers :smile:

Wow, what a reputation,
We won't steal your maps and ban and insult anyone trying so, be sure of that.

func_details are ignored for vis leafs/portals. Imagine vbsp splitting your map up in 3D "areas" between each polygon corner (as complicate as it sounds). Now vvis calculates which "area" can be seen from the inside of every other area. That helps the insanely stupid engine to not render polygons that are hidden behind walls. The more complicate (=smaller) brushes are the longer vvis will run (this can be a difference from 8 hours down to 5 minutes!). Every brush, no matter how small it is splits the map up in new areas that have to be compiled. Also the result is often worse. func_details and other entities are ignored for vvis calculations.

For all the info you'll ever need on optimizing: http://www.student.kun.nl/rvanhoorn/Optimization.htm

func_detail abides by the laws that regular non-entity brushes abide
by. basically func_detail is like a regualr brush, only it doesn't cut
up surfaces, block vis, or "enclose" the map. And func_detail is less
of a strain on the engine than func_brush or func_wall does (less
settings to remember).

---

Posting And You