Optimization (Non-Geometry): Difference between revisions

From Valve Developer Community
Jump to navigation Jump to search
m (removed excess linkage & general tidy & avoided disambiguation page)
m (made redir)
Line 1: Line 1:
This article deals with map optimizations that do not involve manipulation of geometry or the [[BSP]]. For those, see [[Optimization (Geometry)]]. For the main article, see [[Optimization (level design)]].
#redirect [[Optimization (level design)]]
 
== Physics ==
 
One of the neat things about Source is its use of physics simulation, and physically-simulated objects will certainly have a place in the vast majority of maps. However, simulating several physics objects simultaneously can lead to performance drops, especially in multiplayer.
 
In singleplayer mods such as [[Half-Life 2|HL2]], you can safely use a lot of physical simulation in your maps. Check [[showbudget]], the ''Physics'' meter, for an indication of whether you're using too much. Keep in mind that physics objects in motion are more expensive than they are when at rest. Additionally, physics constraints cost too.
 
In multiplayer mods such as [[Half-Life 2: Deathmatch|HL2DM]] physics come at even more of a cost, since a lot of data needs to be sent across the network, which in turn causes a slow-down for everyone. As a general rule, use fewer physics objects in multiplayer than you would in singleplayer. You might notice that simulation quality is reduced for multiplayer (for example, a moving platform looks like it's moving smoothly, but if you try to ride it you will discover that it is jerky--especially if it's going upwards); this is to reduce the network traffic and client-side processing (see later section). For physics objects, you have the option of sacrificing more simulation quality for more speed: by using a [[prop_physics_multiplayer]] instead of a [[prop_physics]], that object is easier on the network. Some models might have problems with this (sawblades, for example, if I remember correctly) and in this case you might be better off using something that can handle being a [[prop_physics_multiplayer]].
 
In either multi- or singleplayer, whenever you have multiple physics constraints acting on an object you should assign them all to a constraint system ([[phys_constraintsystem]]). This simplifies the engine's work, resulting in both faster and smoother simulation.
 
If an object does not need to be physically simulated (it's not going to move, or it will move only because it's parented to something else) then it should not be a physics object. In the case of props, convert them to [[prop_dynamic]] or [[prop_dynamic_override]]. In the case of brushes, instead of [[func_physbox]] use a [[func_brush]] (if it moves passively because it's parented to something else) or [[func_movelinear]] (if it's just supposed to move along a straight line) or whatever is appropriate. Most any func_''whatever'' is cheaper than [[func_physbox]].
 
== Shaders ==
[[Shader]]s are a class of nifty new technology featured in the newer versions of DirectX. They allow some really nice special effects--in Source they have primarily been used to make things either reflective or refractive or both. For example, water in Source is a particularly complex shader, especially "expensive" water. Other examples of the use of shaders include the wavy glass in some doors, lenses such as glasses or the magnifying glass in Dr. Kleiner's lab, and those strange tanks full of transparent goo.
 
Overuse of shaders can be expensive, though, especially depending on the video card (although Valve has done a lot to try to make shaders cheaper for people who have less-advanced video cards). You can tell when shaders are causing a slow-down in your map by consulting [[showbudget]]: the ''Swap Buffers'' meter will be to the right.
 
Water is a special shader, and can be especially problematic when used incorrectly. There are two types of water: "cheap" water and "expensive" water. The cheap water is faster to draw, but the expensive water looks nicer (it reflects, for one thing). If you have water in your map you should use a [[water_lod_control]] to control how far away from the viewer the graphics engine is allowed to use cheap water instead of expensive.
 
Other than water, if shaders are slowing you down you should either reduce the number of shader-using materials and entities, or rig it so there are fewer per [[PVS]].
 
== Client-side/Server-side ==
This section applies only to multiplayer mods. Network traffic is expensive, and a mapper for  multiplayer mods should keep this in mind when doing anything tricky with, say, physics, logic entities, and chained input/output. The main thing to keep in mind is that your map, while being played, exists in three places:
* It is being simulated on the server. This is '''server-side''' work.
* It is being simulated on each client (players' computers). For simplicity we consider only one client at a time as an abstract of what's happening for each client. This is '''client-side''' work.
* Lots of information is being sent across a network so that the client-side and server-side versions of the world stay the same. This is '''network traffic'''.
 
The network is usually the slowest part of a multiplayer game, and it is very expensive to send information across it (this is most true for modem users, but also for broadband, and to a lesser extent for LANs). Many events that can occur in maps will generate network traffic; it will be to your map's benefit to restrict this as much as possible. One way the Source engine helps is by letting the client-side do things that it can do unsupervised by the server. For example, the client can draw a crate just fine without the server's help, so all drawing of crates is done client-side, instead of having the server draw it and send the picture across the network to the client. Other things must be done on the server, such as keeping track of where bullets are flying. The Source engine and mods decide what things should be done server-side and what others should be done client-side. As a mapper you have no control over this, but should understand that it is true.
 
How does this help in map optimization? Let's start with an example (this is a real example, as it's something I've done in a map). Suppose we want a red blinker atop a tower in our [[skybox]]. It's far away, so we don't actually use a [[light]] entity, just a sprite ([[env_sprite]]) since that looks fine and doesn't involve the cost of dynamic lighting. Unfortunately, the sprite isn't animated, so we have to make it blink ourselves. The first way that comes to mind is to use a [[logic_timer]] to turn toggle the sprite every second. This works fine... but what happens when the timer fires? Does the server have to send a message to the clients to tell them to toggle the sprite? Or is the timer simulated client-side, and no message needs to be sent? I actually don't know (if the timer is named, it's probably server-side; otherwise, perhaps not, but I'm not sure) but I do know a way that's certain to be done purely client-side, without any network traffic: instead of using a [[logic_timer]], just go into the sprite's properties and change it to ''Slow Strobe''. This is a purely visual effect, and can therefore be done on the client side. Did we save any network traffic? Maybe, maybe not, but hopefully the example illustrates how one can be try to prevent problems.
 
So some guidelines and suggestions:
* Objects without names are less likely to involve network traffic. Don't name objects unless you have reason to.
* If you want a single-use timer rather than a periodic one, don't use [[logic_timer]]--use the ''Delay'' setting on an Output instead.
* Avoid network-intensive objects (see Physics section above).
* Whenever an Output results in something observable happening (a noise, a spark, a door opening, etc), network traffic will be involved.
* If an entity has no Outputs (besides the OnUser ones), then it is probably purely client-side unless named. See, for example, [[env_spark]]. This might not apply if you use the OnUser outputs.
* If an entity has no Outputs or Inputs (except OnUser and FireUser ones) then it is almost certainly purely client-side, as there's no way for the server to send it a useful message. This might not apply if you use OnUser/FireUser.
* Don't use OnUser/FireUser outputs--that's what [[logic_relay]] is for. Usually it wouldn't hurt, but in some cases it might try to make something a network object that shouldn't be. (This is not experimentally verified, but [[logic_relay]] is better anyway.)
 
However, the network is there to be used, so don't overdo attempts to optimize in this regard. This topic is mostly informational; see the Physics section for a more practical example of how the network effects maps. If you want to seriously optimize on this point, be sure to discuss it with a coder for the mod in question.
 
== Dynamic lights ==
The Source engine is not well-suited to drawing dynamic lights. While they can look nice, you should limit their usage if you care about your framerate. As a guideline, you should have no more than one dynamic light per [[PVS]].
 
Most lighting in Source is precalculated--that's what the [[RAD]] step of compilation does. Lighting is slow, but extremely important towards making a map look nice; therefore the majority of lighting is done ahead of time, during compilation, so that maps can look nice ''and'' run fast. The limitation is that lights, being precalculated, aren't allowed to change over time. Dynamic lights are used to get around this limitation: they can flicker, move around, or whatever. But remember that lighting is slow; trying to do lighting calculations in-game is possible, but not cheap. So avoid it whenever you can. If you simply ''need'' the effect, use as few dynamic lights as possible.
 
The most obvious cause of dynamic lights is the [[light_dynamic]] entity. Any [[point_spotlight]] with the ''No Dynamic Light'' flag unchecked is also a dynamic light.
 
The easiest way to tell whether dynamic lights are a problem is to use [[showbudget]] and examine the ''Dynamic Light Rendering'' meter.
 
[[light]] and [[light_spot]] are normally static lights, but if they have names they become what I'll call '''switchable lights'''. Switchable lights are, in one sense, dynamic lighting, but they do not have the in-game performance cost of true dynamic lights. They do, however, considerably increase the time to run RAD. A PVS with a single switchable light will take twice as much processing as the same PVS if the light were not named. With two, it takes four times as much processing, and with three, eight times. If there are too many switchable lights in a PVS the compiler will refuse to proceed.
 
This is not the end for lightswitches in maps, however. Switchable lights that share a name are treated almost as a single light. They take much less time in RAD than if they each had unique names. The trade-off is that they can only be turned on/off together. So in the case of three switchable lights in a PVS, if they all have the same name they will only double the RAD processing rather than octuple it.
 
[[Category:Level Design]]

Revision as of 14:36, 16 September 2008

Redirect to:

Retrieved from "https://developer.valvesoftware.com/w/index.php?title=Optimization_(Non-Geometry)&oldid=94904"