Skybox Optimization: Difference between revisions

From Valve Developer Community
Jump to navigation Jump to search
No edit summary
(I've made some of the article more understandable. Some phrases have been re-worded.)
Line 2: Line 2:
[[Category:Tutorials]]
[[Category:Tutorials]]
[[Category:Skybox]]
[[Category:Skybox]]
[[File:Layoututh.jpg|right]]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 <i>"Box Method"</i> 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.
<b>NOTE: </b><i class="grey">Roof brushes of maps used in the tutorial are hidden for tutorial purposes.</i>


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. 
[[File:Layoututh.jpg|right]]Every mapper - myself included - has incorrectly created the skybox of a map by simply making a block and hollowing it out to surround the entire level, or making the brushes individually to create the classic box shape.
{{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. <i>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.</i>
Either way, this <i>"Box Method"</i> 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.


With the <i>"Box Method"</i> this would then appear like the image below.
Now, to show you why the <i>"Box Method"</i> 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. 
{{note|Keep in mind these are basic examples and can/should be improved upon.}}
 
It isn't the fanciest of maps but it serves to illustrate my point nonetheless. <i>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.</i>
 
With the <i>"Box Method"</i> applied, the map would appear like the image below.


[[File:Improperskyboxexample.gif]]
[[File:Improperskyboxexample.gif]]


The displacements are fading in and out for a reason, thats because I wanted to get your attention that they are not <i>really</i> 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.
The displacements are fading in and out for a reason; I wanted to get your attention that they are not <i>really</i> 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 lets take a look at a more proper method for creating a skybox with this layout example:
Now let's take a look at a better method for creating a skybox, with this layout as an example:


[[File:Properskyboxexample.gif]]
[[File: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 (<b>DRASTICALLY</b> 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
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 (<b>DRASTICALLY</b> 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:


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


Line 38: Line 42:
<i>VisDataSize:</i> <b>2048</b> »» <b>196</b>
<i>VisDataSize:</i> <b>2048</b> »» <b>196</b>


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?
For such a small map, these differences are enormous, and will dramatically increase the performance of the map.


== When Not To Build Sections ==
== 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.
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.


[[File:Towerk.jpg|right]]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.
[[File:Towerk.jpg|right]]I've placed a tall brush in the middle area of the map, as you can see on the right. However, if the skybox remains as it is then that tower will appear/disappear when people walk around due to the construction of the skybox. Trimming down the skybox in places is required to make sure that the tower is visible from all angles that the player is 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:
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:


[[File:Towerop1.jpg]]
[[File:Towerop1.jpg]]


<i class="grey">Roof Brush(s) Hidden for tutorial Purposes</i>
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:
 
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:


[[File:Towerop2.jpg]]
[[File: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 [[Hammer_Cordon_Usage|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.
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 [[Hammer_Cordon_Usage|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.


<p class="blue" style="font-size: 13px"><b><u>Other Benefits</u></b></p>The benefits other than the already stated VVIS optimization and better breakup of your level into rendered areas range from:
<p class="blue" style="font-size: 13px"><b><u>Other Benefits</u></b></p>
<ul class="green"><li>Easier Areaportals Use
Some more benefits of creating a map-optimizing skybox can include:
<li>Soundscape Triggers easier to organize
<ul class="green">
<li>Detail Props on displacements can be rendered in larger numbers
<li>Easier use of areaportals</li>
And so on.
<li>Easier organisation of soundscape triggers</li>
<li>Rendering of larger numbers of detail props on displacements</li>
</ul>
</ul>



Revision as of 10:10, 22 July 2010


NOTE: Roof brushes of maps used in the tutorial are hidden for tutorial purposes.

Layoututh.jpg

Every mapper - myself included - has incorrectly created the skybox of a map by simply making a block and hollowing it out to surround the entire level, or making the brushes individually to create the classic box shape.

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.

Note.pngNote:Keep in mind these are basic examples and can/should be improved upon.

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.

Improperskyboxexample.gif

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:

Properskyboxexample.gif

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:

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

Towerk.jpg

I've placed a tall brush in the middle area of the map, as you can see on the right. However, if the skybox remains as it is then that tower will appear/disappear when people walk around due to the construction of the skybox. Trimming down the skybox in places is required to make sure that the tower is visible from all angles that the player is able to see it from.

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:

Towerop1.jpg

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:

Towerop2.jpg

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.

Other Benefits

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

See Also

Category:Optimization (Level Design)

Category:Level_Design_FAQ