Optimization Tutorial: Difference between revisions

From Valve Developer Community
Jump to navigation Jump to search
No edit summary
m (Fixing double redirect. This action was performed by a bot.)
Tag: Redirect target changed
 
(29 intermediate revisions by 17 users not shown)
Line 1: Line 1:
{{wip}}
#REDIRECT [[Optimization/Level Design]]
 
 
'''By zombie@computer'''<br>
'''Wikified by Battle Bott'''
 
View original at: http://www.student.kun.nl/rvanhoorn/Optimization.htm
 
 
There are a lot of ways you can optimize your map. I will try to deal with all of them, in one, orderly tutorial. There are two things you can optimize with this tutorial, the compile time (especially with vvis you can save hours) and offcourse the map itself while running it ingame<br>
What I will discuss (be prepared: this is everything I could find about optimization!):
 
==General Notices==
First things first, the easiest way to optimize your map is carefull building. A few tips:<br>
<br>
Don’t enclose your entire level in one box (saves both compile times and map speed)<br>
This will generate extra leafs, lightmaps, clipping hulls, faces to be drawn, etc.<br>
This includes skyboxes! The ideal skybox is as small as possible:<br>
 
<table height="433"><tr><td height="429">
http://www.student.kun.nl/rvanhoorn/Optimization/skybox.JPG</td><td height="429"><table><tr><td height="120">
This is the best solution, but not ideal (for instance: you cant see the big building from the other skyboxes) in all cases.<br>
If you think you can get away with it, go right ahead. It'sby far the most economical option.</td></tr><tr><td height="140">
This is still an acceptable solution. Allthough some hinting may be required to make this map
run smoothly, its still a very good skybox</td></tr><tr><td height="120">
This is bad. The redmarked sides of this skyline (the bottom ones) will be drawn while they shouldn't, and the green parts will create more work for vvis, or more for you if you try to use hints to fix this. Also, rad has to do more work for all those extra
faces, and any environment lighting will also light the city from below the ground.</td></tr><tr><td>
 
In other words: Don't do this!</td></tr></table></td></tr></table><p>
 
===Fix leaks (increases map speed)===
With leaks vbsp wont be able to divide your level into leafs (see chapter "hints"), so it wont create a portal file. Therefore, you can't use vvis or Glview. Leaks also make vbsp not know which faces it can skip, making your map only laggier and bigger, and vrad will not be able to light your map as good as without leaks. Water will also not work.
Leaks are holes in you map. Since the compilers will try to find out what the inside is of your level (so they dont have to create the outside) they will not be able to do that if the inside of your level is in contact with the outside. Think of your map as a spaceship: only when it's hull is completely air-tight, people (all the entities) will be able to live inside. If there's a hole leaking into space (the void) everybody will die. On our spaceship that is. Not in Hl2...<br>
<br>
How to find leaks?<br>
First of all, vbsp will write an error in the compile log. The leak error doesn't stand out, but if you look carefull you can see something like:<br>
<br>
<nowiki>**** leaked ****</nowiki><br>
Entity info_player_deathmatch (22.94 -64.44 17.00) leaked!<br>
<br>
It will report an entity (e.g. info_player_deathmatch) and some coordinates.
Now, when you go to [map->load pointfile] and load your pointfile (usually hammer can find it, if not, youll have to search manually for it (it's called "[mapname].lin" or "[mapname].pts")) a red line will appear, starting at the stated entity, and ending outside your level (in the black space, called the "void"). If you just follow that line, it will eventually pass through your leaking hole. If you cant find the entity the line starts, go to [tools-> go to coordinates] and fill in the coordinates mentioned in the log. Remember entities and displacements cant block leaks, therefore its easiest to hide all entities and displacements so you can spot the leak easier (you might have turned a wall into an entity which was supposed to seal your level for instance). In space you can't seal holes in a spaceship with humans, in maps you can't seal holes with entities. Simple as that. Better use vis-groups to hide all the entities and displacements. Removing the mentioned entity will only help if the entity itself is outside the level, but the level itself is sealed (e.g. when a person from our sealed spaceship is going for a space-walk). Also, leaks may be caused by invalid use of areaportal(window)s (in our spaceship, areaportal(window)s are airlocks inside bulkheads), but more on that later. If you've fixed the leak, there may still be another one. Therefore, unload the pointfile (under [menu] )and recompile.
If there's another leak, simply load the pointfile again. Keep doing that untill there are no more leaks.<br>
<br>
===Don't make world-brushes overlap.===
Vvis doesn't like it, and it may create extra faces. It will also make your map less orderly. Your choice.<br>
<br>
===Don't overdo dynamic lights. (increases map speed)===<br>
Simply don't because they are quite hard to render. Hl2 simply isn't doom3. Also, if you are using point_spotlights, check the "no dynamic light"-flag, to see a big increase in performance.<br>
<br>
===Make brushes standard sizes.===
Not only will it be easier for you to use them, but its also easier to find and prevent (small) leaks.<br>
*Standard sizes are 8, 16, 32, 64, 128, 256, 512, 1024 units.<br>
Some values inbetween (48, 96 etc) can also be "valid" for some textures. Using standard sizes will also enable you to stay on the grid and use textures without the need to shrink or stretch them to awkward values. This is not a hard rule, but it will make your life so much easier. To help doing this, I suggest you use a big grid (16 units) and only decrease its size when your making detail brushes.<br>
Also, don't forget to keep your brushes on the grid, not doing so will result in a less orderly, bigger map.<br>
<br>
===Don't use carve for any non-square brushes.===
And if you do, tidy it up after. If a wall consisting of dozens of brushes due to carving of a cylinder in it wont slow down you map, I don't know what will. The keypoints here are to:<br>
<br>
*minimize brushes and faces as much as possible
*making sure all points are on the grid and prefeably as straight as possible so they are easier to handle, and less prone to make errors.
http://www.student.kun.nl/rvanhoorn/Optimization/carve.JPG<br>
<pre> Yuck! Ohhhhh, smooth....hmmmm</pre>
<br>
===Don't overdo water. (increases map speed)===
On multyplayer-maps water usually is a no go, because it means a lot of lag. (unless some steam update fixed that) So think twice before you try to use it.<br>
If your still set on using it, but find it creates (a little too) much lag, you can do the following things:
*change the type of water to cheap water. Either use the water_lod_controls-entity or just stick a water-texture with "cheap" in its name on the waterbrush.
<br>
the water_lod_controls entity changes the water from expensive to cheap as soon as the player is far enough from the water
(you specify that distance in this entity)
<br>
*reduce the size of your waterbrushes. Make waterbrushes as small as possible, NEVER let them overlap world-brushes, because they will still be rendered
but never be seen. Also, when dealing with displacements, remember water continues under them but the player will probably never see it.
*stick as few entities inside as possible. Any model touching the water (its bounding box to be exact) will be rendered with water-visibility-features, but they come with a higher price (they are essentially rendered TWICE. To reduce load, make sure model-entities that are outside the water don't touch the water with any part of their bounding box, if you dont want them to. Also remember when your water runs under displacements and you have some model sticking through the same displacement, it might still touch the water:
http://www.student.kun.nl/rvanhoorn/Optimization/water.JPG<br>
like in this picture, where the green line is a displacement and the blue is a water brush. The pink object sticks in the water, meaning it needs to be rendered heavier, even though you wouldn't be able to see it sticking inside the water. Also, this waterbrush is much bigger that it has, it could stop at the place where its top and the displacement (green) meet.<br>
<br>
Use "mat_showwatertextures 1" in the console to find out which entities are rendered twice because they touch the water-surface.<br>
<br>
===Map wisely===
If the entire map can be seen from one point, theres not a lot of optimization you can do. Try to avoid large, open area's since you can't optimize them. Instead, try to block the player's view (that of vvis to be exact) with buildings or walls to make sure you can actually hide parts where the player isnt looking. (with or without the use of entities and hints) Also, adding lost of corners instead of straight hallways may enable you to optimize your map better, but it comes at a cost: Will your map still be any fun? Will it still look great? (did it ever?)<br>
<br>
If these general rules don't help you, youll need heavier stuff. Bring in the artillery!!<br>
===

Latest revision as of 15:21, 21 January 2024

Redirect to:

Retrieved from "https://developer.valvesoftware.com/w/index.php?title=Optimization_Tutorial&oldid=381431"