Skybox Optimization

From Valve Developer Community
Revision as of 02:47, 2 November 2009 by Lost (talk | contribs)

Jump to: navigation, search
Layoututh.jpg
Every mapper has done this incorrectly - myself included - where we create the skybox in our maps by simply making a block and hollowing it out to surround the entire level, or make the brushes individually to create the classic box shape around our maps.

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.

Note:Keep in mind these are basic examples and CAN/SHOULD be improved upon.

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.

Improperskyboxexample.gif

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:

Properskyboxexample.gif

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

That compile difference I was speaking of, even with a simple layout as this you can see how much of a change its made: Vviscompare.gif

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.

Towerk.jpg
I've placed a tall brush into the middle area as you can see on the right, however if the skybox is left as it is then that tower will appear/disappear when people walk around due to the construction of the skybox. Therefore trimming it down in spots is required to have the visleaf containing the tower visible from the angles one should be able to see it from.

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:

Towerop1.jpg

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:

Towerop2.jpg

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 Benefits

The 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.

See Also

Category:Optimization (Level Design)

Category:Level_Design_FAQ