Showbudget

Stub

This article or section is a stub. You can help by expanding it.

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. You can bind it to an key by typing bind "F12" "+showbudget" in the console, if you want it on F12-key.

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, you'll 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:

Unaccounted

Lag caused by other programs (e.g. virus scanner, Winamp, Hammer). Shut them down if the lag is too big.

Also, limiting the framerate with fps_max can also potentially contribute to the unaccounted lag total. If you see a huge "unaccounted" bar and aren't running any other applications, the chances are that your fps_max setting is causing the engine to pause before rendering the next frame. The Showbudget panel counts this controlled delay as "unaccounted" lag.

World rendering

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.

Displacement rendering

Lag due to Displacements. 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

Game

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 neccesairy. (one entity can trigger multiple others)

NPCs

Artificial Intelligence.

Server Animations

Unknown (by me)

Client Animations

Unknown (by me)

Physics

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.

Light cache

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

Shadow rendering

Lag due to rendering of prop-shadows. Remedy this by disabling shadows, remove props or use hints/ func_areaportals to hide them. func_occluders don't work for shadows, strangely enough

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.

Particle/effect rendering

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.

Ropes

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.

Networking

Lag due to the network. To remedy, reduce the network-traffic your map generates by removing any unneccesairy entity. For example it may help to use prop_physics_multiplayer and func_physbox_multiplayer instead of prop_physics and func_physbox.

Sound

Lag due to sounds, remedy by reducing the sounds in your level

VGUI

Lag due to Graphical User Interface. It's due to HL2 menu's, HUD and console (and the showbudget-screen!)

FileSystem

I think this is due to lag in retrieving info from models\sounds\etc from your harddisc. Try defragmenting if this lags your map.

Prediction

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.

Interpolation

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.

Swap buffers

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.

AINET

Probably has to do something with AI networks. E.g. info_node paths and pathfinding.

Occlusion

Cost of func_occluders and maybe func_areaportals too. Solution: remove the occluding entities, make sure they gain more than they cost!

Overlays

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.

CLagCompensationManager

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.

CViewRender::Render

No idea

3D Skybox

Lag due to anything in your 3D skybox. Reducing stuff in it is the only way to battle this.