it's in the help document
help->Shaping Brushes->Clipping->Clipping Modes 

Check this post by Pritchard for a better understanding of the clipping tool: http://www.celephais.net/board/view_thread.php?id=60908&start=2389 

Thanks topher, I should have checked that help file out, very handy.

I'm wondering about overlapping brushes - do they "plug leaks" say if I copy and past a bunch of brushes and rotate them so they're all intersecting, then drag a sky brush down to their top most point (and say they intersect with the floor brush) would these overlapping brushes cause a leak? are overlapping brushes generally considered a no-no? 

ah...
i don't know yet.

and put a screenshot i didn't understand either ,

i will ask the last question as well.
are overlapping brushes generally considered a no-no?

i think that overlapping brushed don't cause leaks, because leaks are holes. i don't know if they affect the lights.

i'm just cutting brushes, resizing them, merging them, etc,, for now. 

You can overlap brushes, some things benefit more from being clean cut but do not be concerned so much with that. Just be aware of z-fighting with textures.

Clipping is the best way to split a brush in TB. You can press CTRL+ENTER to cycle clip modes. 

Leaks are caused by either an exposure to the void or an entity with its origin in the void.
Overlapping brushes aren't very good practice, mostly because of Z-fighting and increased compile time. It's better if you can avoid it. Doesn't really matter if they're made func_detail though since these are ignored during compile. 

Overlapping brushes aren't very good practice, mostly because of Z-fighting

Doesn't z-fighting only happen with moving brushes (doors & plats) that move to the same coordinates as other brushes? Surely the compiled .bsp doesn't "know" if two world brushes have their faces on the same plane, because what texture is displayed gets resolved during the compile process.

Sorry, my terminology is probably all wrong, but hopefully you know what I mean... 

Go place two brush inside one another, each with a different texture. Compile it, run it in game, and report back to us with your findings. 

I've done it countless times with no ill results.

From a post by necros from 2010 (http://www.celephais.net/board/view_thread.php?id=4&start=10212&end=10212):

i don't know why, but overlapping brushes will cause zfighting in newer engines like q3 and d3. in quake, qbsp will manage to remove overlapping WORLD brushes without any issues. (overlapping func_ or other visible bmodels WILL cause zfighting with other bmodels or the world).
afaik, it doesn't cause any problems once the bsp is in the engine.

i'm not sure where we are atm concerning the compiling aspect of overlapping brushes. i don't overlap because i like to work clean, but it's just personal preference.

(emphasis mine) 

Now go do it in Hammer/Source ;)

Its just a bad habit that you wouldnt want to carry into other game engines. 

Had overlapping brushes for the pillar lights at the end hanging from the ceiling. Other than that it was an excellent map. *nit pick* *nit pick* 

Overlap corners, don't overlap faces.

Also, someone actually referenced something I said as advice! Neat. 

Thanks for all the help all.

I've had an error compiling my current build, not too sure what a "non convex face" is, or how to fix it, but it seems to be the problem:

http://imgur.com/EHxdeAB

I tried deleting all the recent brushes I had added, but it still seems to happen. Any idea what I should be looking for so it compiles?

The map is currently wide open, void everywhere - is there a limit to how open a map can be to compile? can I plug gaps / skies later on? or even just make a sky box enclosing the limits of the map? cheers 

"CheckFace: Face with too few (a) points at (x y z)"
"CheckFace: Healing degenerate edge at (x y z)"
"CheckFace: Healing point (x y z) off plane by a"

I have no solution for it but maybe readme and check the related polygon in the map file. 

The map is currently wide open, void everywhere

with surounding walls, bottom and sky. 

Why would you want to seal your map if you're not running vis? I tend to leave the areas I'm working on open until I'm ready to move on to the next one - I only bother sealing them then.

As to non-convex faces, I'm not sure how you managed to achieve that but an editor shouldn't let you create an invalid brush like that. If you do find the culprit, and you're using a modern editor like J.A.C.K. or TrenchBroom, I'm sure the developers would be interested in seeing it...

Which -options are supported by that compiler? I would see if there's any way to get more information out of it. It's strange that it doesn't provide any coordinates in the error. 

Any of you guys know of an extended runic/metal texture set? I've found a few more in kdmtex.wad but more choice never hurts. I'd especially like to find all the different runic tiles in both glowing red and "switched off" versions (id1 is missing some in each variant). 

I always build fully sealed and error free as I go. I only run a full vis every so often, but I like to know the map will compile properly without errors before putting too much more work into it. Fixing problems is the least fun part of mapping and I wouldn't want them to pile up. 

http://www.quaketastic.com/files/texture_wads/rmq_darkmet.wad

rmq mqade some runic addons. there are more, idk where to look atm.

rick does it right. 

Also yeah, so far I've done just like Rick. 

provide leaks in early stage.

@mugwump: Might not be the same wad but why not try Runewad? 

A workflow discussion: I can't nail down a specific time frame but a general estimate is every 10 minutes or so I do a full compile. Yes I vis everything and light everything dozens of times per mapping session. Reason being is my current map is probably about the size of one of the large id levels. Vis'ing takes well under a minute maybe a tad longer. But I work on everything in a map at once. Geometry comes first, then game play and then tweaks to lighting and texturing, then back to gameplay. It's very chaotic way to work. (I know.) I ask this here because I'd like to hear other people's workflow in the hope of getting my act together. I'm not looking to get faster per se but I have a lot of room for improvement and I am always open to new ways of working. As far as saving... I save as much less often. It seems that each new area becomes a save point and if I don something risky that could cause a leak or break logic or expose a bug in the editor, I will do a new version of the map. 

Well I managed to fund the culprit - a single brush seemed to be preventing compiling. I'm not really sure why though. I'll just keep test compiling as I go to make sure I'm staying on track.

Interestingly the non-convex face error comes up even when the map compiles and runs fine... not too sure what the issue is there but it doesn't seem to be "structural" 

If you open the map with a text editor,
you can view the structure of the map file.
A rough trade is looking at the warnings
and see if the brush consists of six sides.

If I want to make really sure why a polygon keeps "troubling"
I change all texture names behind the six polygons with a white texture.
When opening the map in an editor I can see which brush in particulary is causing the error.

Of course I use ericw compilers. 

My workflow changes as I learn more mapping techniques but to answer some of your questions:

I compile whenever I want to test something I just set up. This could be a few monster spawn triggers, to a new lighting placement, or even a single brush I want to see in action! When working with lighting, I often always do -extra4 and -soft to ensure I can see what the final product will look like but sometimes just -soft if a minor change was made.

If I do not have a leak, then I always compile with the -fast VIS just to save time. When I want to do a full playtest (Start to finish) I will do -level 4.

If by save you mean physically save the map file then I do that probably every time I add something that I know will stay for the time being. Ctrl+S is muscle memory and TB handles autosaving for the grievous mistakes.

As I stated above, my workflow changes but I am starting to see grey boxing out large sections is the way to go. Like G1ftmacher said before, if you can get through the basic layout then you can get to the more personal mapping phase.

So my workflow would be at this time:

-Brainstorming, mind layouts, inspiration.
-Basic layout of large sections
-Basic texturing of said sections
-First pass detailing
-First pass lighting
-First pass gameplay
-Detailed texturing
-Major detailing and lighting
-Then it gets to a hodgepodge of all of the above but fine tuning.

I am always curious to see what other people do.