Snarkpit Forum Index » Source engine editing » compile
compile
1
Post Reply
Quote
 Re: compile
Posted by Drunken Munkey on Thu Sep 7th at 5:45pm 2006

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... <img src=" SRC="images/smiles/icon_smile.gif">

Cheers




Quote
 Re: compile
Posted by omegaslayer on Thu Sep 7th at 8:50pm 2006

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



Quote
 Re: compile
Posted by Naklajat on Fri Sep 8th at 4:30am 2006

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



Quote
 Re: compile
Posted by reaper47 on Fri Sep 8th at 6:40pm 2006

"I spent literally hours..."

welcome to the joys of mapping, my friend. (sorry couldn't resist <img src=" SRC="images/smiles/heee.gif"> )

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 <img src=" SRC="images/smiles/icon_smile.gif">



Quote
 Re: compile
Posted by Drunken Munkey on Fri Sep 8th at 8:03pm 2006

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 <img src=" SRC="images/smiles/icon_smile.gif">

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
 Re: compile
Posted by reaper47 on Fri Sep 8th at 8:34pm 2006

? 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 image

Wow, what a reputation, image
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



Quote
 Re: compile
Posted by omegaslayer on Fri Sep 8th at 8:35pm 2006

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




1
Post Reply