Ok, here goes: question, why is a LEAK bad? Created 1 year ago2022-12-17 01:41:34 UTC by Sjaak-atijd-raak

Hey all,

Wanted to ask this for some time. I've been avoiding LEAKS for years, reading a lot about it. Mostly I just saw rants about 'noobs not able to fix their leaks', or how to avoid it. Cool! I know how to avoid leaks.

Now I'm here: I have a handful of maps, that look BETTER with a minor, controlled, leak. I know which 1" is the leak.

The lighting is right where I'd want it to be, although maps with skies are slightly darker, but just what I wanted. Shadows work fine, textures are the same, compiling times are a blessing and these maps ran fast and without problems in a (nostalgic) LAN party this weekend.

Don't burn me at the stake, but here goes: which advantage is there in a map WITHOUT vs. WITH leaks?

Thanks for the info!

As far as I know, the smallest possible leak into the void will cause a fullbright map, A.K.A. a fast trip to Uglyville. Given this as the popular understanding, it's usually considered a major fault for a leak to be inside a map.

On deeper thought, I can't really fathom the possible benefits of a leak despite the proper lighting compiling occurring.

So either we have different definitions of leaks or what you've said is honestly new to me. But even then I still can't see a benefit. If a leak somehow compiles lighting without causing fullbright, what possible effect could it have, one way or the other?

Show us a concrete example of that "leak". A leak only counts if the compilers complain about it and prevent you from compiling the map further. I've had "pseudo leaks" where it was actually an enclosed space between my hallways, but it was all NULL faces and nobody ever really noticed. Still doesn't count as a leak, because the compiler didn't yell "LEAK IN HULL 0" or anything.

The disadvantages of leaks are, as Zegfalt said, having your map fullbright, cuz' compilers generally stop at the BSP stage when you have a leak, and so VIS & RAD won't execute. But that's the least of your concerns.

VIS won't execute, meaning most, if not all of your map, will be rendered at once, and this also means all entities are sent at once. This breaks all engine limits (256 max visible entities for example) if your map is large enough.

Maybe it's not as noticeable with a very fast modern computer, but back in the day, Half-Life and Quake required a very powerful computer to run smoothly. People were lucky if they got 10 frames per second at 640x480. When a map is compiled, visibility is calculated, so that when you play, only a small part of the map is rendered, otherwise the entire map is rendered and those people would have got 1 frame per second instead. I think leaks prevent the visibility from being calculated properly. When you seal the inside of the map, the compilers can discard all the faces facing void, saving light map memory and other resources.

When a map has a leak the compiler can't tell which parts of the map are inside and which are outside. The visibility and radiosity compilers won't run so the game can't determine which parts of the map are visible and which aren't, so the entire map (including the normally discarded exterior) is rendered at the same time. The map is also fullbright since there is no lighting data.

This will also affect networking since entities are checked for visibility using the data that won't exist so it will always be deemed visible, so if you have a lot of visible entities you'll end up with invisible entities.

The compile tools need the map to be sealed so the outside can be discarded. Otherwise you'd have calculations that expect to hit a brush face at some point that just keep going off into the void forever (or until they hit the maximum map size).

The wiki article on Quake 1 explains this stuff as well: https://en.wikipedia.org/wiki/Quake_engine#Engine_design_and_milestones

You don't really notice how important this is until you run a map on an older computer (very early 2000s or older). A modern computer can brute force render the entire map, unless it has poor immediate mode OpenGL support and the map has dynamic lights which causes graphics performance to drop significantly.

Great, thanks all for the info! Your four replies complemented each other pretty well, I think I have a grasp of the concept.

For the sake of giving an example of what made me to ask this question, I made two screenshots. I was working on a capture-the-flag style map and compiled it 1) without leaks and 2) with a small leak (I left a tiny unnoticeable spot open somewhere in the sky).

Without the leak, so the 'proper' version, some annoying spots of shadow popped up I can't seem to get rid of, and compiling times skyrocketed. With the leak, this wasn't the case so it made my life easier. Plus the maps looked almost identical - so I thought, no loss there, let's stick with the leak if it seems to have a positive effect.

But I wanted to know if there'd be a catch, and which mechanics are behind it, and you four explained that very well. I begin to see the consequences and limitations by not having VIS performed. Besides, some friends I play with have older laptops as well, so I'll aim for proper maps with this in mind.

Thanks again for the quick and clear explanation, cool!

First screenshot of the map, the 'proper' version without a leak:

Second screenshot, with leak, which looks almost identical:

Sounds like you were using older compilers, these tend to slip things through and compile the map anyway.

A more technical explanation of what happens:
What you actually lose with leaking is something called "outside filling". Normally, the process of BSP filling would strip out all unseen surfaces:That's kinda the beauty of BSP. These X'ed faces get removed. Nowadays we got tool textures like NULL to forcibly do this, but they don't really make a difference if your map is compiled without leaks, unless in some more special situations like with func_detail.

Everything that is considered to be the "outside" of the map is erased. Point entities (player spawns, lights etc.) dictate what's considered "inside", and the world geometry is used to then figure out what's outside from there.

However, with a leak, the compiler can no longer figure out what's inside & what's outside, so ALL faces stay. You get 6x more polygons in the map and it decimates performance basically.

This majorly increases the usage of the following resources, that can be seen if you compile with the -chart option:

• AllocBlock
• clipnodes
• worldleaves
• map surfaces

So basically, a map that would normally fill up 20% of these limits would, with a leak, fill like 60% or even more.
I hope you now have a bit of a better insight as to how leaks "work".

Looks like you are using the compilers from 1998 that came with Valve Hammer Editor. People have upgraded these compilers many times over the years, the most popular ones nowadays are VHLT 3.4

Leaks cause defects in the rendering of the compiled map, most notably in the lighting.

If your lighting improves with a leak, then you're not lighting your maps optimally. You shouldn't use a mistake to increase the overall brightness of your map; two wrongs do not make a right.

True, true, normally I'd avoid leaks, in this case it got me wondering. And thanks @bruce and @admer! I'll upgrade to VHLT 3.4, good to know.