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 small little FY maps where one can see the entire map at once. Aside from those we should all be creating the skybox properly.
Now to show you why this is bad I'm going to take the layout seen on the right and use both methods to it. Its a simple layout, a few paths with 3 large areas and walls separating them all.
Not the fanciest of maps but serves to illustrate my point nonetheless. Also notice how the ground through the entire level is made from displacements sewn together as thats quite common and you'll see how that effects the skybox in a moment.
With the "Box Method" this would then appear like the image below.
The displacements are fading in and out for a reason, thats because I wanted to get your attention that they are not really there in a complete sense. Displacements do not block visibility and as such VVIS will not calculate visleafs that stop at the displacements surface, they will just go right through it. So if you had a wall made of displacements, your computer will still render all the models, players and geometry behind them. Only the world geometry - in this case the walls - will block vvis and create the visleafs that control rendered items.
Now lets take a look at a more proper method for creating a skybox with this layout example:
See how the skybox conforms with the outline of the level along with nodraw being used in all areas underneath the walls instead of more toolsskybox brushes? This will reduce the amount of calculations needed (DRASTICALLY lowering your compile times) because the skybox doesn't contain all that empty space from the previous one. Why the nodraw is there? well thats because we don't need to create light beneath the level, or in this case the displacements as that will create visual errors along the edges of them as light can pass through the back of a displacement. Also, light from the sky should be coming from above and not below don't you think :P
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 a map with very little in it this is a huge difference! How can you not want to create a skybox in this way now?
When Not To Build Sections
Conforming to the paths of your level shouldn't be done all the time but only where appropriate. There are a few cases where you leave it open to view past it into the next area, and I've included that within my layout example as well.
So removing the walls separating the paths from the middle area and filling it with nodraw texture between - don't use toolsskybox as we don't need to emit light upwards - and then modifying some of the others so that there is no cut off from the other two larger areas we end up with something like below:
Roof Brush(s) Hidden for tutorial Purposes
This is only ONE option you can do in this situation, another is to try and limit as much of the area the tower is in from being rendered as possible by simply raising the height of the walls in some areas so that it blocks the view normally from close distances to the wall, but allowing the tower behind it to be seen from a distance. Like so:
Basically, the re-structured skybox along with some smart level design can create some extremely high performance levels with lots of detail still in them. A good thing to do is when your first building your level don't make a giant skybox for the map via a box, but use the cordon tools until you've reached a level where you want to start your skybox set-up so that you can get onto the optimization part of your map.
Other BenefitsThe benefits other than the already stated VVIS optimization and better breakup of your level into rendered areas range from:
- Easier Areaportals Use
- Soundscape Triggers easier to organize
- Detail Props on displacements can be rendered in larger numbers And so on.