Well, i had the intent to document my experiences with all those errors (and how to fix them) anyway.
Thing is, i probably need visual examples, be it drawings or map snippets to explain this in detail.

But, for those errors to appear in thousands, you prolly have to raise the machine epsilon first.
Try a value of -epsilon 0.0125, raising in 0.0025 steps.

I compile often, just to look at the output, not loading the map in engine. I do this regularly, after adding rooms, rockwork, special detailed structures..

So i am able to nail those errors down very early, not having to check whole maps afterwards.

Next thing to check are those suspicious coords like having a vertex at 800 -64 - 128.0000023.

Those are the bane mostly, locking them to grid fixes portal cut away errors, at least for me.

When i find a portal error i cant fix with above methods/precautions, i make a new small brush at the specified coords, and look to "expand" existing brushwork to cover that brush.

Can be anything, pillars, more rocky wobbles, anything. Usually this all leaves me with no errors in the end.

I admit, the "real" reason for those is cloudy to me too, looking at the src left me shaking my head til dizzyness. :)

More later, must consult a friend. 

floating point stuff is the main reason for those errors to appear, just reassured. Build stuff on grid! 

Thanks a ton, man! I'll try to put that into practice on my next map and see what happens... Clean compiler output would be nice for a change. :P 

You should read the Quake mapping Holy Bible, the Q1 tooltips from aguirRe (http://user.tninet.se/~xir870k/tooltips.txt) 

I recite that before going to sleep. Everyday. Out of my head...! 

You are forgiven, sinner ! 

Don't remember that page, looks like a gem! 

And as it states, those portal cut away errors are not critical, you may end up with a total errorfree BSP that still has those errors when compiled.

Nowadays compilers aren't vulnerable to those errors, thanks to rebb and ericw!

Still you may find missing faces, small HOMs, nonsolid floors, all that jazz.

So better stackenblock* all on grid.

*stackenblocken 

Well, it's less the compiler I'm concerned about and more the engine. I'm sure those errors don't help with mysterious collision problems and such. 

As you said. Fuck. 

"Try a value of -epsilon 0.0125, raising in 0.0025 steps. "

As a side note, Eric's QBSP has never heard of "-epsilon" ... 

Eric? 

I'll add -epsilon to the next build though 

 

Hmm.... Warnings = no fucks given :P 

OBJ2MAP -> Warning generator 

seriously though, even if i was falling through the ground... i'd just put a func_wall with skip over the invisible hole rather than bother trying to fix anything. it's faster and just as effective, not to mention transparent to the player. 

 

Drop the teenage rebellion attitude and go finish that dragon fortress! 

I always build on grid unless it's some weirdly shaped or twisted construction and rarely get cutnodeportals warnings. Most common problems they cause are small invisible walls and falling through the floor.

If there's no way to stay on grid, converting the brush(es) to func_walls will fix it, or if already on grid just smooth over with a clip brush. 

Well I cheated a little, but I was able to get the level vis'd. I just built a box around the entire level, and then stretched the external walls from the level to meet the faces of the box's walls (that way all outer walls are closed, and are see-through when I noclip)
An amateur approach, I know, but it worked.

I'll ignore the clip warnings for now, but they are pretty annoying. Sorry mfx, I have a ghetto set up with no home internet so I'm using my phone to talk to you guys. I'll remember to send you the clipping warning when I get home. 

That expanding wall technique is a good approach, i do this too, especially on sky/closing brushes. 

Wait, so was qbsp writing a pointfile or not? 

It doesn't always. I've had leaks with no pointfile before. Those are SUPER DUPER fun. 

I'm just making double sure the new guys know about that sweet red leak-finding line. I didn't know about it for like the first six months of making Quake2 maps, and when someone told me about it on IRC it was like seeing the face of god.


Look for "load pointfile" under 'file' or somesuch menu, it varies by editor. Every compile that leaks (in theory) writes a yourmap.PTS or .LIN file that lists coordinates of the centers of all leaves connecting the edge of the grid to whatever entity the test hit first (it assumes all entities are inside the map, which they should be), in order.

That line (in theory, 99% of the time, unless you're doing REALLY wacky hyperdetailed slanty things) always goes right through whatever accidental microtunnel you left between brushes. If the leak appears to go through an otherwise solid brush, that brush may be fucked up somehow and getting tossed out by the compiler (there will be accompanying warnings), it may be an out of date leakfile and you didn't actually get a new one after all, or your brushwork is just amazingly dangerous.

It's also a good reminder when you just forget to build a ceiling.