This article needs to be cleaned up to conform to a higher standard of quality because:
The narrative is kind of roundabout, there's some minor inaccuracies. It just doesn't look like a usual wiki page and it isn't using making a very good use of markup. Also POV.
This article should be converted to third person to conform to wiki standards.
Either way, this "Box Method" is not the way you should form your skybox; far from it actually, as the only maps that could get away with doing this are little FY maps where one can see the entire map at once. Aside from in those maps, skyboxes should be created properly.
Now, to show you why the "Box Method" is bad, I'm going to take the layout seen on the right and use two skybox-creating methods on it. It's a simple layout: a few paths with three large areas and walls separating them all.
It isn't the fanciest of maps but it serves to illustrate my point nonetheless. Also, notice how the ground throughout the level is made from displacements sewn together. This is quite common, and we'll see how this affects the skybox in a moment.
With the "Box Method" applied, the map would appear like the image below.
The displacements are fading in and out for a reason; I wanted to get your attention that they are not really there in the complete sense. Displacements do not block visibility and VVIS will not calculate visleafs that stop at the surface of displacements; the visleafs will go straight through them. If you had a wall made of displacements, your computer would still render all the models, players and geometry behind them. Only the world geometry - in this case the walls - will block visibility and create the visleafs that control the items to be rendered.
Now let's take a look at a better method for creating a skybox, with this layout as an example:
The skybox now conforms with the outline of the level, and the nodraw texture is used in all areas underneath the walls and floor, instead of the toolsskybox texture. This reduces the amount of calculations needed (DRASTICALLY lowering your compile times) because the skybox doesn't contain all that empty space generated by the previous method. The nodraw texture is used because we don't need to create light beneath the level, and we don't want rendering errors that will occur when light hits the displacements from below.
All these methods make for a drastic change to the compile:
Portal Clusters: 73 »» 16
Numportals: 201 »» 19
Total Clusters Visible: 3981 »» 134
Average Clusters Visible: 54 »» 8
Average Clusters Audible: 73 »» 13
VisDataSize: 2048 »» 196
For such a small map, these differences are enormous, and will dramatically increase the performance of the map.
When Not To Build Sections
Conforming the skybox to the paths of your level shouldn't be done all the time, but only where appropriate. There are a few cases where you should leave gaps to see through, so you can view the next section of the map, for example.
By removing and trimming walls so that the tower can be seen from any angle, and by using the nodraw texture on the bottom of the map where we don't want light to emit upwards, we end up with a result similar to this:
You can also try to limit the area in which the tower will be rendered. Simply raise the height of some walls, so that when you are near a wall and the tower is behind it, the tower cannot be seen due to the wall's height:
Well-produced skyboxes with some smart level design incorporated can create some extremely high-performance levels with lots of detail. It isn't a good idea to create a giant box-shaped skybox when you start building a level. Instead, use the cordon tools until you've reached a stage of map development where you want to start setting up your final skybox and optimizing your map.
Some more benefits of creating a map-optimizing skybox can include:
- Easier use of areaportals
- Easier organisation of soundscape triggers
- Rendering of larger numbers of detail props on displacements