Skybox Optimization: Difference between revisions
(cleanup notice) |
(Updated article to attempt to remove POV from, still could use some revisions.) |
||
Line 3: | Line 3: | ||
[[Category:Skybox]] | [[Category:Skybox]] | ||
{{cleanup|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.}} | {{cleanup|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.}} | ||
{{ | {{ModernNote|Roof brushes of maps used in the tutorial are hidden for tutorial purposes.}} | ||
[[File:Layoututh.jpg|right | [[File:Layoututh.jpg|thumb|right|250px|An example layout of a small map]]Most inexperienced mappers tend to create a large box around their level and texture it with the <code>tools/toolsskybox</code> texture, then carve it outwards to create a literal 'sky'''box''''. Most mappers do this because they are not experienced with how a skybox works and its effects, or could do this simply because they do not want any leaks in their map. | ||
Either way, this <i>"Box Method"</i> is not the way you should form your skybox | Either way, this <i>"Box Method"</i> is not the way you should form your skybox, as they can cause more issues than they solve. 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. | ||
To show you why the <i>"Box Method"</i> should not be used for standard maps, a small map will be created for the purpose of this article. It's a simple layout: a few paths with three large areas and walls separating them all. | |||
{{ | {{ModernNote|Keep in mind these are basic examples and can/should be improved upon.}} | ||
This isn't the most complicated map but it serves to illustrate the point nonetheless. Also, notice how the ground throughout the level is made from displacements sewn together. This is quite common, and you will see how this affects the skybox and map optimization in a moment. With the <i>"Box Method"</i> applied, the map would appear like the image below. | |||
[[File:Improperskyboxexample.gif]]<br/> | |||
{{ModernNote|You may notice that the origin is in the middle of the level. This is a bad practice, as hammer will automatically cut visleafs along the axis of the origin. Instead, this should be moved into one of the 4 quadrants of the x/y axis.}} | |||
[[ | The displacements are fading in and out for a reason; to demonstrate that they are not actually taken into account by [[VVIS]]. 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/brushes - will block visibility and create the visleafs that control the items to be rendered. | ||
An example of a properly created skybox is as follows: | |||
[[File:Properskyboxexample.gif]] | [[File: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 ( | 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 <code>tools/toolsskybox</code> texture. This reduces the amount of calculations needed (lowering your compile times significantly) 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 | All these methods make for noticeable changes to the compile: | ||
[[File:Vviscompare.gif]] | [[File:Vviscompare.gif]] | ||
Line 43: | Line 41: | ||
<i>VisDataSize:</i> <b>2048</b> »» <b>196</b> | <i>VisDataSize:</i> <b>2048</b> »» <b>196</b> | ||
For such a small map, these differences are enormous, and will dramatically increase the performance of the map. | For such a small map, these differences are enormous, and will dramatically increase the performance of the map in-game. | ||
== When Not To Build Sections == | == 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. | 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. | ||
A tall brush has been plafced in the middle area of the map, as can be seen below. 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: | 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: | ||
Line 54: | Line 52: | ||
[[File:Towerop1.jpg]] | [[File:Towerop1.jpg]] | ||
One can also try to limit the area in which the tower will be rendered. Simply raise the height of some walls, so that when the player is near a wall and the tower is behind it, the tower cannot be seen due to the wall's height: | |||
[[File:Towerop2.jpg]] | [[File:Towerop2.jpg]] | ||
{{ModernNote|When your map's outer borders are still in development, it is more beneficial to 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> | <p class="blue" style="font-size: 13px"><b><u>Other Benefits</u></b></p> | ||
Some more benefits of creating a map-optimizing skybox can include: | Some more benefits of creating a map-optimizing skybox can include: | ||
<ul class="green"> | <ul class="green"> | ||
<li>Easier use of areaportals</li> | <li>Easier use of [[Areaportals|areaportals]]</li> | ||
<li>Easier organisation of | <li>Easier organisation of {{ent|env_soundscape}} triggers</li> | ||
<li>Rendering of larger numbers of detail props on displacements</li> | <li>Rendering of larger numbers of [[Prop detail|detail]] props on displacements</li> | ||
</ul> | </ul> | ||
Revision as of 15:17, 10 January 2023

Most inexperienced mappers tend to create a large box around their level and texture it with the tools/toolsskybox
texture, then carve it outwards to create a literal 'skybox'. Most mappers do this because they are not experienced with how a skybox works and its effects, or could do this simply because they do not want any leaks in their map.
Either way, this "Box Method" is not the way you should form your skybox, as they can cause more issues than they solve. 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.
To show you why the "Box Method" should not be used for standard maps, a small map will be created for the purpose of this article. It's a simple layout: a few paths with three large areas and walls separating them all. Template:ModernNote
This isn't the most complicated map but it serves to illustrate the point nonetheless. Also, notice how the ground throughout the level is made from displacements sewn together. This is quite common, and you will see how this affects the skybox and map optimization 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; to demonstrate that they are not actually taken into account by VVIS. 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/brushes - will block visibility and create the visleafs that control the items to be rendered.
An example of a properly created skybox is as follows:
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 tools/toolsskybox
texture. This reduces the amount of calculations needed (lowering your compile times significantly) 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 noticeable changes 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 in-game.
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.
A tall brush has been plafced in the middle area of the map, as can be seen below. 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:
One can also try to limit the area in which the tower will be rendered. Simply raise the height of some walls, so that when the player is near a wall and the tower is behind it, the tower cannot be seen due to the wall's height:
Other Benefits
Some more benefits of creating a map-optimizing skybox can include:
- Easier use of areaportals
- Easier organisation of env_soundscape triggers
- Rendering of larger numbers of detail props on displacements