Showbudget is the replacement of the r_speeds meter in half-life1. Basically, it shows per category how much lag is generated bu that category. It is advised to run through your map with showbudget on atleast once, to see where your map lags and what causes it. so you can take measures (see Controlling Geometry Visibility and Compile Times )
showbudget is toggled on by typing "+showbudget" in the console. You toggle it off with "-showbudget".
It is great to use in combination with commands that toggle certain things to see their inpact, e.g.
- r_occlusion 0/1
Toggles func_occluders on and off, to see their effect.
- mat_bumpmap 0
Turns off bumpmapping, so you can see what kind of impact is has on your map ("mat_bumpmap 1" to put it back on)
- mat_specular 0
Turns off reflections, so you can see what kind of impact they have on your map ("mat_specular 1" to put it back on)
along a small FPS-indicator, youll see this screen appear. Above is a graph of the total amount of FPS, under that are indicators for the lag created by each group:
Here's a list of the groups, their cause and possible fix of lag created by them:
- 1 Unaccounted
- 2 World rendering
- 3 Displacement rendering
- 4 Game
- 5 NPC's
- 6 Server Animations
- 7 Client Animations
- 8 Physics
- 9 Static prop rendering
- 10 Other prop rendering
- 11 Light cache
- 12 Brush model rendering
- 13 Shadow rendering
- 14 Detail prop rendering
- 15 Particle/effect rendering
- 16 Ropes
- 17 Dynamic light rendering
- 18 Networking
- 19 Sound
- 20 VGUI
- 21 FileSystem
- 22 Prediction
- 23 Interpolation
- 24 Swap buffers
- 25 AINET
- 26 Occlusion
- 27 Overlays
- 28 CLagCompensationManager
- 29 Cview-Render::render
- 30 3D Skybox
Lag caused by other programs (e.g. virusscanner, winamp, hammer). Shut them down if the lag is too big.
Lag due to rendering of worldbrushes. To remedy this, use hints, or func_areaportal( window)s to hide them. You can also use an env_fog_control to set the max rendering distance (clipping distance) and use the fog to hide the clipping. Just reducing or simplifying brushes works too offcourse.
Lag due to dispacements. Counter it by reducing the amount of dispacements, or set their "power" to a lower number. Making sure you can't see the leafs they are in helps even more, so you can also use hints or func_areaportal( window)s
Any lag caused by logic_entities and other such basic calculations. Removing them is the only option, be sure to not use more logic_entities than nessesairy! ( thanks to klaus viehöfer )
I guess this is AI handling
Unknown (by me)
Unknown (by me)
Lag due to all the physics. If this lags too much, either remove physics-objects or try to switch some to multiplayer-props
Static prop rendering
Lag due to static props. This can be remedied by using hints, areaportals or occluders to hide the entity, or use its fade-properties (turn on helpers in hammer, they are the two circles, one for fade to start, the other for fade to end and make the prop invisible. Between fadestart and fademax theres no performance-gain, youll gain only outside the fademax) you may also try to convert small (unimportant) ones into prop_details
Other prop rendering
Same for static props, only for all other props (except detail-props). Only be warned that if entities can move, small fademax's may make them invisible when they shouldn't.
I think this is the cache for prop-lighting. If it is, reduce it by reducing props, or the amount of lightstyles on them.
Brush model rendering
Lag due to brush-based entities. (triggers, doors, func_brushes, etc.) Solve it just like world-brush lag
Detail prop rendering
Rendering of detailprops (prop_detail is an entity that is only drawn if your machine can handle it, therefore it should only be used on small, non-essential models). To remedy, see static props.
Lag due to any particles you have, e.g. dustmotes, things coming from env_rotorshooters. Remedy this by reducing the number of particles, or their life-length. This shouldn't be a problem for most people.
Lag due to ropes, can be remedies by reducing the ropes or by decreasing the number of subdivisions.
Dynamic light rendering
Lag due to dynamic lights. Dynamic lights are quite a heavy load for the engine, and so should only be used sparsely. Also, the point_spotlight has the "no dynamic light"-flag off by default. Make sure you turn in on to reduce some serious lag.
Lag due to the network. To remedy, reduce the network-traffic your map generates (prop_physics->prop_physics_multiplayer may help, or func_physbox->func_physbox_multiplayer) by removing any unneccesairy entity. I don't know why, but when your playing your own map on your own pc (no network involved) there's stil some lag.
Lag due to sounds, remedy by reducing the sounds in your level
Lag due to Versatile Graphical User Interface (yes, I googled). I think its due to HL2 menu's, HUD and console (and the showbudget-screen!)
I think this is due to lag in retrieving info from models\sounds\etc from your harddisc. Try defragmenting if this lags your map.
Lag created by a system tries to predict actions before verifieing. Definition elsewhere on this wiki:
The Source prediction system is designed to minimize the impact of latency on a gamer's experience. Rather than experiencing a delay when the player presses a button (so the command can go to the server and back), the Source prediction system simulates the effect of the button press on the client immediately. When the response finally does come from the server, the client's speculative simulation is either determined correct or incorrect.
- 99% of the time, the client's speculation is correct. In that case, the client can go along happily as though he/she has no latency to the server.
- If the client's speculation is incorrect, then the client goes back and resimulates all of the commands it ran with mistaken data. In this case, the client will experience a small hitch in his/her view position, weapon animation, and such. Luckily, if the code is written correctly, then this case is fairly uncommon.
My guess at the moment is that Interpolation has something to do with physics. Ive made a test-map, and saw this value go over the top when I rpg'ed two hundred physics barrels. I think this predicts the actions of physics before they actually happen, or calculates trajectories of projectiles.
This can be anything, from water (try reducing it to cheap water if it is) or fire, smoke or steam, glass or other transparent textures. Apart from reducing visibility of the leafs, try to reduce their quality or quantity, but only if it really gets out of hands. Also, if you have it enabled, bump-mapping is also a cause. In my personal experience, lots of reflective surfaces also increase swap bufers lag (especially the combine metals). Anyway, any use of any kind of shaders will make this category lag.
Probably has to do something with AI networks. E.g. info_node paths and pathfinding.
Cost of func_occluders and maybe func_areaportals too. Solution: remove the occluding entities, make sure they gain more than they cost!
Lag due to overlays and maybe even decals. Large ones cost more than small ones, overlays cost more than decals. Removing a few might do the trick.
Apart from the name (Lag Compensation Manager) I don't know anything about this value. Maybe this is a program that tries to make the game fluid even though theres lag (e.g. physics-stuff?) Reducing lag should help I guess.
Lag due to anything in your 3D skybox. Reducing stuff in it is the only way to battle this.