Hurk. So much misinformation mixed into this thread... I'm just going to answer everything straight from the top. So some of this may be repeated.
1. If more polygons means greater workload, what is the cost to clipping brushes? Is it more optimized to cut one brush into eight in order to put nodraw on one of the faces than it is to leave it one polygon?
This depends on what you are doing. If you simply slice one brush into several, the compile will merge the faces back together and split them according to how the compile wants. If you slice them and make a "hole" in the middle that you nodraw, because, say, you have a pillar on a floor, that will result in more faces but the lighting will look better if it's a func_detail pillar. (see the 'eliminating excess' part of
this for why this is good) If the pillar is a world brush, it doesn't matter anyway because if world brushes touch the slice each other by default.
2. if I have a texture on a face that isn't touching a visleaf and isn't used anywhere else in my map, will it still be loaded into memory by the client?
All of the following situations will have the faces removed during compile and they will not exist:
Touching the void.
Two world brushes touching each other.
Two brushes touching each other that are part of the SAME entity.
Two brushes touching each other that are in DIFFERENT entities will not be affected. (except for shadows, but that's another subject)
3. A smaller lightmap scale means longer compile and bigger filesize, but does it also affect performance?
The larger amount of lightmap data that needs to be loaded into memory will affect performance. However, it is negligible when compared to the amount of data for all the other textures. Lightmaps aren't something to worry about as far as run-time performance, but it's always good to use as big of a scale as you can without making bad shading.
4. How does lots of visleaves affect performance? Does func_viscluster merge leaves?
Again, the affect on performance will be negligible. The func_viscluster does not merge them, but effectively tells VVIS that all leaves touching the cluster can be
considered as one when building the visibility table. You should rarely use these, as it means any time you see a leaf that was touching the cluster, ALL leaves touching the cluster will be rendered (and conversely, if you are IN a leaf of the cluster, all leaves that can be seen from ANYWHERE in the cluster will be rendered). The
only purpose of this entity is to cut down on compile time, and it will
never improve in-game performance.
A good example of where to use them can be seen if you look at the badwater VMF. There are visclusters up in the sky above the playerclip. The player cannot ever enter the cluster, and there is absolutely nothing to render in the cluster's leaves. Therefore it will have no negative impact during runtime but it will speed up the compile by not having to calculate visibility for a bunch of empty leaves.
5. Why does func_detail exist when there is func_brush? Is it cheaper to render?
An extremely common misconception is that func_detail is an entity. It is
not. They are a special type of world brush that is classed as detail. When VBSP is building the BSP, any func_detail have their entity info discarded and the brush is placed into the detail lump (a bsp file has many 'lumps' that store different types of data). For all intents and purposes they work exactly the same as a world brush with two exceptions: because they aren't in the world lump they won't used when VBSP creates the leaves (and thus are not seen by VVIS), and they won't split or cull faces.
Again, not an entity. Except in Hammer because it was the easiest way to mark detail brushes. (as opposed to coding a whole separate detail brush interface)
On the other hand, func_brush is an entity like any other, and can be disabled, enabled, killed, color changed, parented, and any number of things you may wish to do with a brush.
6. Is a polygon more expensive than a smaller polygon with the same texture and resolution?
Honestly I don't know. This is deeper into the engine mechanics than I've looked, and may even depend on the hardware being used.
1. There is no gravity in the void, but what if the map is leaked?
There is always gravity, you are just stuck in place.
2. The 2D skybox isn't drawn in the void, but what if a map is leaked?
The skybox is always drawn at the bottom layer if a toolsskybox brush is being rendered. You can have an enormous hole in your wall that peers into the void, but if you have even a 1x1x1 cube of toolsskybox being rendered there will not be a hall of mirrors, but the skybox instead.
3. Is it possible to force tonemaps in the void when a map is leaked?
Yes and no. If you are experiencing hall-of-mirrors void, a tonemap won't do much of anything. If you have what I said above with the skybox the tonemap should work as usual.
4. Is there a limit of how far the player can move in the void?
Yes and no again. You can move infinitely in any direction but once you move beyond the maximum bounds everything pretty much stops working/existing. i.e. if you make a door near the edge of the grid, and have it extend out beyond the edge and attempt to walk out on it the moment you cross the edge you will fall through because it doesn't exist anymore.
I agree with 'don't carve', but it would be exciting to have a map in the void. Like, a map set in outer space, where a toolsskybox shaft would be so pedestrian. You'd be able to say "THIS IS THE VOID, BITCHES", which is as chilling as the setting.
I can't believe I'm saying this, but carving is actually better than having a leak. If you have a leak then VBSP cannot create the leaves/portals, which means VVIS can't run (which means the ENTIRE map will be rendered at all times), and without vis data VRAD can only do direct-cast lighting and your shadows will be 100% black and in general everything will look horrible.
Also, fewer brushes, good tip. But it doesn't hurt to have lots of brushes "internally", as in, two brushes for every wall, right?
They'll be merged. Unless you have different textures on them. But as I said near the top, the inside touching faces won't exist regardless.
Also, one other thing: In what kind of circumstances does skip work? If you apply it to one face of a world brush, does it make the brush nonsolid like with a glass window or is the skip texture visible? And is it possible to make one-way shooting walls with skip and blockbullets?
Skip should NEVER be applied to any brush other than by itself or with hint. Brushes have "contents" determined by the materials applied to them, and there are several mixtures that cannot go together, usually when you are using tool brushes. Using skip with something other than hint will usually result in an unbounded volume error (because the one side of the brush "doesn't exist") which ends up with the same issues as a leak... VBSP doesn't know what is inside and outside.
To make something one-way you would have to use a displacement, which only have collisions on the visible side.
and lastly, to fubar... skip faces do
almost nothing. They do actually have some affect on a map, and I've been meaning to right an article about their peculiarities.