Maximum r_speeds on modern machines


(Krischan) #1

Hi there,

just a question I couldn’t find out and I need to know this to keep on working on my map.

How many r_speeds should I consider TODAY on modern machines?

At the current milestone I have about 10000-20000 in a local detailed area, but this could go up to 30,40,50000 later in areas hard to VIS block. That gives me on my two year old laptop (Core2 2,53GHz, nVidia 9600M GT) still up to 500 FPS and on an old Core 1.6GHz, Intel GMA 945 at least 50-150 FPS. So how high COULD I go today without serious FPS problems for players, I know less is always better and the old tutorials say 15000-25000. So 50000? 100000? The map will be designed for 16-64 players.

And does the r_speeds only affect the local performance of the client or the connection speed, too (lags)? Added a screenshot with a view into the critical area.


(shagileo) #2

Can’t help you on the subject, but that screenshot looks damn awesome !


(twt_thunder) #3

yeah, never saw anything like the upper part…:eek:


(ischbinz) #4

dunno for sure - but if you have a look on the fueldump mod i did some time ago -
( http://www.splashdamage.com/forums/showthread.php?t=22614 )
there are more tris/verts if you are in range of the tank…


(Cambodunum) #5

… maybe this is helpfully
http://www.surfacegroup.org/tutorials/wet/render_speeds/


(ischbinz) #6

btw i forgot - to see the chaninging in your map you should type /con_drawnotify 1 - then you see the speed without console :slight_smile:


(Krischan) #7

> you should type /con_drawnotify 1

Oh WOW didn’t knew this - very cool thank you! very useful!


(ischbinz) #8

you can find this on you hdd:

/Wolfenstein - Enemy Territory/Radiant-1.4/docs/Level Designers Reference/index.html


Wolfenstein: Enemy Territory Documentation
© 2003 Splash Damage, Ltd. All Rights Reserved.
	
Compiling Maps
The following console commands are useful when testing a map built for Enemy Territory:

/cg_draw2d
This cvar command toggles the display of all the HUD elements except the gun.

/cg_drawfps
This cvar command toggles the display of the current frames per second that the map is running at. This is displayed under the map timer.

/cg_drawgun
This cvar command toggles the display of the weapon model.

/cg_drawreinforcementtime
This cvar command toggles the display of the next respawn time. The counter is displayed next to the map timer. Extremely useful for timing when the next wave of team mates might arrive or when would be a good time to tap out to the limbo menu for a respawn.

Cg_thirdperson 2 will keep the player model in view at all times. This is extremely useful for checking the light values in a map because the player face will reflect the density of the light grid. (You will also need to also change the cg_thirdpersonangle to 180.)

/cg_thirdperson
Cg_thirdperson switches the player's viewpoint between first and third person. This can be useful when checking new player skins/models and the relative scale of the map geometry to the player model. The default value is 0 - first person.

/cg_thirdpersonangle
By default the thirdperson view is of the character from behind. Use cg_thirdpersonangle to alter the angle at which the player model is viewed. The angle is given in degrees where 0 is the default and a value of 180 degrees will give the player a view directly from the front of the player model.

/cg_thirdpersonrange
The default distance that the player model appears from the camera when in thirdperson perspective is 80 units. This value can be altered using /cg_thirdpersonrange. The greater the value the further the camera will appear from the player model.

/con_drawnotify
This command allows developer commands such as r_speeds to display in the main game view and not just in the console. The command is toggled between 0 and 1 where 0 displays the developer commands in console only and 1 displays them in-game also.

/con_notifytime
Ideally set to at least 5 this cvar allows the developer to determine how long (in seconds) the command is displayed onscreen.

/g_scriptdebug
Prints to the server console every line of script that is executed, along with the scriptname of the entity which is calling the script, and the time it was executed at. This is extremely useful for tracking down strange script bugs.

/g_debugconstruct
This will speed up all construction times for quick construction checking.

/r_speeds
The r_speeds cvar displays rendering information which can be helpful in determining what may be having an effect on fps. The default value is 0 which will not display the r_speeds.

r_speeds 1 displays the following information:

xxx/xxx shaders/surfs xx leafs xxxxx verts xxxxx/xxxxx tris x.xx mtex x.xx dc

The renderer batches up drawsurfaces (map drawsurfaces, such as terrain chunks, walls, floors, model sections; model surfaces like players and weapons, and effect surfaces) into a large array before doing render passes. The "shaders" value is actually how many batches there are. Each batch can require one or more rendering pass. For example, weapon shaders often require two: a diffuse/texture pass to add details and an environment pass to make them shiny.

The "surfs" value indicates the number of drawsurfaces visible.

The "leafs" value indicates the number of BSP leafs that are visible in the scene. A leaf is the final, smallest BSP node which contains actual renderable data.

The most important value, "verts" shows the number of vertexes batched up to be rendered in the shader/batches to be calculated, transformed, lit etc. Ideally, the verts count should be as close to 1024 x the shaders (batches) count. Realistically, it will be difficult to achieve this target due to the amount of unique shader effects that only get rendered once.

The number of triangles visible in the scene is indicated by the "tris" value. Ideally the ratio of tris to verts should be as high as possible since you want to maximize the number of tris compared to the number of verts.

/r_lightmap
Setting this cvar to 1 will turn off textures on light mapped surfaces so that they appear white. This makes it easier to see how shadows affect these surfaces. All drawn surfaces not pastel white are vertex lit and are not affected by the external lightmaps.

R_lightmap 2 will re-colour the map surfaces in light intensity values. This has to be done before the map is loaded. (3 does it in the logical red is hot and has a higher intensity)

/r_shownormals
Normals indicate the direction a triangle is facing. Use r_shownormals to display normals.

r_shownormals 1: shows you the vertex normals on everything being drawn
r_shownormals 2: shows you the origin, direction and colour of the lighting on entities. This lets you debug the lightgrid.

/r_showtris
The r_showtris cvar displays the triangles drawn by the game engine. There are three r_showtris levels: 0 - 2. The default value is 0 which does not display triangles.

r_showtris 1 displays depth-buffered triangles, i.e. only those triangles which can actually be seen. This lets the developer see the outline of brushes/models more easily and is especially useful when checking un-VIS'd maps or those with complex geometry.
r_showtris 2 displays all triangles in view which the engine is currently rendering. (This is recognizable as the old Q3 r_showtris 1 cvar).

/r_triscolor
This cvar sets the colour of the triangles displayed by the r_showtris cvar. The default value is "1.0 1.0 1.0 1.0" which will draw solid white lines around all triangles drawn on screen. The first 3 values are the RBG colour and the final value is the alpha-blend value. This command is useful if you are debugging snow style maps which involve a lot of whiteness.

/god
In God mode the player will be invulnerable to anything in the map that would normally hurt them, such as damage from a weapon, high falls or remaining under water for long periods of time. Please note that some triggers in the game will still hurt the player regardless of god like status. The trigger_hurt entity has a spawnflag setting to override god player status.

/map_restart
This command will restart the level and will respawn the player. It will also reload the script file for the map from disk again and reset all construction items in a map. This is useful for tweaking and testing scripts without having to reload the map from scratch each time.

/nofatigue
When the player is sprinting it will use up stamina. This is indicated by the green bar on the lower right of the HUD. When it reaches the bottom the player will slow down. By setting /nofatigue to 1 will allow the player to continue to sprint even when out of stamina.

/noclip
Setting noclip to 1 allows the developer to pass through otherwise solid geometry and anything that has been player-clipped.

/screenshot
Takes a screenshot from the current view and writes it to the 'etmain/screenshots' folder.

/timelimit
This command sets the length of time (in minutes) that the game will run for before it automatically ends if the offensive objectives haven't been completed. After this time the next level will load. If you need to test a map over a long period of time then set timelimit to 0.

/timescale
Useful when checking large maps and scripted sequences, the timescale cvar will alter the speed at which the game is running. A value of 2, for instance, will run the map at twice the normal speed. (Please check the developer config's for examples of how this command can be useful if bound to several keys.) 

very useful stuff :slight_smile:


(CyburK) #9

it could get hard with players in there firing up airstrikes, smoke grenades etc. 20000 is good. but 40 or 50 000 is too much i guess. i try to keep it around 30000 as a maximum. vis blocking is essential for ET.


(Krischan) #10

The map is already hinted very well but I have a large outdoor area part I can’t tile anymore and I need to know how far I could get with details there. 30000 sounds good, I think I can build this area below 35000 and keep it below 15000-20000 in other areas.

@ischbinz: oh I think i have to install the old radiant first to see this because I’m using NETradiant for this map - works fine and stable in Windows 7. The rspeeds section you posted is very interestingm thanks!


(MrLego) #11

I’ve always used ~36,000 as a good target.

There are areas in Fueldump that are around 36,000 that play fine on a 32 player server.

I’ve had a map that had around 40,000 in one area that got really choppy with 4 of us throwing air strikes at the same time.

I think that some of it depends on your game machine, connection, ping, etc. - a player with a bad connection can suck the joy out of a game as much as slightly higher r_speeds can.