 |
 |
 | ||||
 |
||||||
| ||||||
 | ||||||
|
|
| |||||||||
 |
 |
||||||||||
| |||||||||||
| |||||||||||
|
|
| |||
 |
|||||
| |||||
| |||||
r_speeds
|
Every map author you have ever admired or who has inspired you to want to map has paid endless attention to something called "r_speeds" in the id Software engines. I hope the information in this tutorial benefits mappers from all quake based engines but I am solely focusing on Return to Castle Wolfenstein: Enemy Territory today as that is the game I am working presently with. What this tutorial is notThis is not attempting to create a standard for what is tolerable or acceptable. I simply hope to educate you and provide you with the tools I've created to analyze and compare my data to the maps of others. Also, please do not expect this tutorial to highlight tips or techniques used to improve the efficiency of your map. I will write a tutorial that offers some tips at a later date. First things firstRegardless of what anyone else says I only care about Frames Per Second "FPS" and believe that is the only specification any mapper should strive for. FPS can be seen in your life each day. The human eye requires 24 FPS [source] to see smooth animation. If you have ever played with Macromedia's Flash format you've no doubt seen that the default frame rate of 12FPS brings sluggish animation. Step the frame rate up to 24 FPS and you will enjoy the perfect balance of file size and frame rate. So, without going into extensive thought or study you can just about shoot for a minimum frame rate of 24 frames per second to achieve smooth animation and flow in your map. But, don't stop there. Greater FPS will yield even greater results but you don't need to shoot for 60+ FPS like some mappers would have you believe. So, what is your map's FPS? That's not so easy to guarantee. Performance in a map, like cars, motorhomes, planes, refrigerators and people is tied to too many variables that are not in your control; however, using the r_speeds command will allow you to view the variables that are in your control: what the game draws to the screen. You can have a map that draws nearly nothing to the screen but if it is running on a PC without the horsepower or gigantic programs in the background you will never achieve the ideal FPS you hunger for. Now, let us take a moment to view the FPS and r_speeds in any map. If you are mapping, I suggest using your map to further enhance your understanding of what your really seeing. |
Here's a download
I wrote an Excel macto to help me analyze the overall r_speeds of my map and compare it to the maps of others. This Macro has saved me hours and I hope it can help you too. Download the Map Report Macro for Excel |
|
Go to the console for ET by pressing the tilde key " ~ ". Once the console appears in-game, simply type "/r_speeds 1". This will turn on the output of the efficiency information in your console. To turn this information off , type "/r_speeds 0". Running any map, you will see all kinds of data streaming and changing as your view of the world you've created shifts direction or focus. But what does it all mean?That is exactly why I wrote this tutorial. I searched endlessly for a good resource but found none. So, here goes. 308/1675 shaders/surfs 294 leafs 26335 verts 18234/23501 tris 8.66 mtex 0.00 dc The above line was taken from my in-process level and represents the highest visible triangles. The following line is from the Battery map officially released with Enemy Territory and represents the highest triangles visible in that map. 226/2865 shaders/surfs 277 leafs 33518 verts 25311/37590 tris 7.87 mtex 0.00 dc This first bit of information we want to focus on is the triangles visible. Now, I assume the next sentence and have not found a credible resource to verify. In the battery map you can see the engine drew 25,311 triangles to the screen but 37,590 triangles were actually visible by the engine. Confused? Don't worry. You can see exactly what I am talking about with some more commands. To experience this information for yourself execute the game and type "/bind kp_5 cycle r_showtris 0 2" That syntax tied the command to the Number 5 key on your 10-key (right side of the keyboard) to toggle through the three states of r_showtris which are: off, immediately drawn triangles and total triangles rendered. The third state is what we're focusing on in this tutorial and is what most mappers focus on. |
|
|
The second state-the immediately drawn triangles-shows lines for each triangle, patch and model you can see with the naked eye. This command is great for allowing you to see what the compile process did to your map and how other mappers created objects or environments you admire. The third state-total triangles rendered-show lines for everything you can and can not see rendered by the engine. To be short and sweet the engine draws everything in the visible leafs weather you think you can see it or not. Structural brushes separate one leaf from another (as do hint brushes) but that is another tutorial. So, even though you are walking behind a cliff or mountain often times the engine is just hiding thousands of triangles from your immediate view. This practice exists because you are probably going to see these triangles in a moment as you turn the corner or jump up from a trench. |
Note: On a side note, compiling does not always stay true to what you mapped. There are techniques you can use to change this behavior but that is for another tutorial. Searching the www.splashdamage.com forums for posts by ydnar can shed light into this. |
|
Now that you understand what 99.99% of all mappers and forum posts are talking about when they say r_speeds we can navigate to some of the lesser discussed and fairly easy to understand specifications communicated by the r_speeds command. These other commands won't receive much attention as I believe they are common sense. |
|
|
226/2865 shaders/surfs 277 leafs 33518 verts 25311/37590 tris 7.87 mtex 0.00 dc The moment the above line was written to the log the number 226 refers to the total number of shaders drawn by the engine. If you are not familiar with shaders they are the configuration files that control the behavior and effects behind each texture you see in the game. Shaders can be a huge impact on your FPS. Watch out for some special effects like reflection for example. Reflection can cut your FPS in half no matter what amount of triangles are visible. |
|
|
226/2865 shaders/surfs 277 leafs 33518 verts 25311/37590 tris 7.87 mtex 0.00 dc Here, 2,865 surfaces were drawn by the engine. Every plane you can shoot, walk on, walk through, or anything else is a surface. |
|
|
226/2865 shaders/surfs 277 leafs 33518 verts 25311/37590 tris 7.87 mtex 0.00 dc Back to the subject of leafs. Leafs are the regions which triangles reside in. If you are drawing a leaf you are drawing every triangle in the leaf weather you immediately see it or not! Using hint brushes and good placement of structural brushes will reduce the leafs drawn which also reduces the triangles drawn. Placing hint brushes is somewhat of an art and is unique to the environment you create. |
|
|
226/2865 shaders/surfs 277 leafs 33518 verts 25311/37590 tris 7.87 mtex 0.00 dc Finally, mtex and dc are specifications that I do not understand and at the writing of this tutorial I was not able to find any information on the Internet. I invite you to e-mail me if you have more information on these specifications. |
|
|
External resources and references Source: Simland /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. Source: Americans Library.gov Information on frame rates required for animation. Source: Return To Castle Wolfenstein & Enemy Territory 4 Newbies Treat tris and FPS like money. Everything you include in your map comes at a cost. Make sure it's worth it. Be frugal about where you make your players draw tris and lose FPS. There are great maps out there that never get a second look because they are simply unplayable. The benchmarks I used were a steady 76 FPS on my machine and r_speeds less than 20K. Tris and FPS efficiency up front, lets you add in more goodies at the backend. Source: QERadiant GL_Showtris/R_Speeds/FrameCounter Toggle (Based in part on an article by orginal author MD) The "gl_showtris" and "r_speeds" commands allow you to see the number and location of polygons (surface triangles) in your view. Showtris draws a white line around each triangle used to create the world when it is a part of a map's potential viewable set (PVS). This is especially effective tool, since it shows the triangle outlines of map areas that are being "seen" by the engine, which are not always just the ones that the player sees. Depending on your video card, this may work well, or it may not. For some (like the Matrox cards, it comes with a huge performance hit). This output is one of the more valuable reports you can get on a map. The numbers show you the numbers that can tell you what kind of real visual costs you are encounter. Combined with other commands that turn features like entities, curves, and multi-pass texturing on and off, you can get a realistic idea of where you're having problems. Here's what those cryptic numbers mean. When r_speeds = 1, the numbers read as follows (where the # sign equals a number) # / # shaders/surfs # leafs # verts # / # tris #.## mtex #.## dc # / # shaders/surfs is the number of shaders in view, followec by the number of surfaces in view. # leafs is how many leaf nodes are potentially visible. # verts is how many vertexes are in view # / # tris is the number of trangles drawn by the renderer in a single pass single pass followed by the number of triangles drawn by the renderer with all passes. These are the numbers that are most often implied when someone talks about "r_speeds." If the r_ext_multitexture variable is off, the numbers will reflect a more accurate accounting of the real triangle count (see multi-pass texturing section below). # .## mtex #.## dc [definition under construction] There is a tendency for rate of frame display to become a sort of god (or at least a "greatest good") for some players. Their quality of play, whether real or psychological, revolves around how fast their computer is flipping through screen updates. Everything else, to them, is throw away. While the design and complexity of a map can affect this, so can many features that are outside of the designer's control. For that reason, frame rate is not a particularly good way to judge the quality of your map. The "cg_drawfps 1" command gives you instantaneous frame rate readout. Use this command string to toggle the three at once. Include the following lines in your Debug Config script: set r_showtris 0 bind "your key" "toggle r_showtris;toggle r_speeds;toggle cg_drawfps" Lock the PVS Table (Author: MD) "PVS" means "potential viewable set." The PVS includes all the polygons that can be seen from a particular location in the map (i.e., where you are standing now). The game engine updates what is visible and what is not as you move through the map. You can stop this updating process, and see just how far the engine can see by moving until you find an area of the world that's not being drawn. Use this to debug views where the frame rate drops below an acceptable level. Go to a place where you get a bad "fps" reading. Execute this command. When the PVS Table is locked, you can walk through the map and see exactly how far your view extends. Surfaces in view will be drawn as normal. Non-seen surfaces will show up as the Hall of Mirrors effect (unless the fast sky or r_clear options are also set). Use the information as a guide for changing what can be seen in a view. This command string script toggles the use of the PVS table to let you do this. It also toggles on the r_clear option, so instead of Hall of Mirrors the void beyond the world is seen in fashion doll pink. set r_lockpvs 0 set r_clear 0 |
Problems, Comments, Queries > Forum
Tutorial by CrazedFan www.elevatedgaming.com
 |
 |
 |
