R_SPEEDS - Part 1 R_speeds eh? You may of heard of them, you may not. What ever happens they are one of the most important parts of editing. All they are is a way of telling how much detail is in your maps at one time. Bring down the console and type R_SPEEDS 1 and then look at the wpoly and epoly. The wpoly is what people quote when they tell you how high their r_speeds are. Mine are 1738 there and that is very high. Valve kept theirs under 800 because they made it for software mode as well and if the r_speeds go over 800 things disappear. But in this day and age of 3D cards I it doesn't affect you too much if you are making a SP map. They need to be low on CS maps tho because of lag and the face that people expect to be able to play that in software mode. If they are really high then your map will slow down on some PC's. There are some tricks to lowering them and have lot's of detail. Let's look at those now: Ok first of all we have a pipe touching the walls, a very common part of maps. Notice the steel flanges on the pipe. These can either be your worst enemy or your best friend. Let's take a look at the right-hand side one. All looks normal so far. They are all World brushes there and what is happening is the pipe is cutting into the flange and the flange is cutting into the wall. To see what I mean bring down the console and type GL_WIREFRAME 2. What this will do is display what the engine is well erm displaying. ARGH! Look at how it is cutting the wall up into slices! That one cylinder becomes many pieces as does the wall. Simply eats r_speeds for no reason. Now let's look at the other end: With GL_WIREFRAME 2 turned on you can immediately see the improvement. How? Well it's a well known fact that enitities don't break up walls like world brushes do. So just make the flange a FUNC_WALL and then the wall remains normal as does the flange itself. Cool huh? Leave the actual pipe itself a world brush because entities don't block light and shadows always look cool so use flanges. So you understood the first part? Good good. Now we are gonna need to understand what VIS is to carry on in this tutorial. VIS stands for Visible Information Set and what it does when it compiles is work out what parts of the level are drawn at any time the player is there. So if the engine can "see" a huge open area then it is gonna take longer to compile and r_speeds are gonna rise. Let's look at an example. I set up a very basic area for this example. At this point the engine is drawing the room we are in, the corridor and the room down the end there with the crates in it. Take note of the r_speeds at this point. Now one thing we must remember is that the engine draws areas even when the player can't see them. To find out what it is drawing at any point type gl_wireframe 2 in the console. (r_draworder 1 for software mode) As you can see the far room is being drawn by the engine even though we cannot see it. This is very important to remember so always check with the console command. Right, how can we lower the r_speeds in this situation? Add a door? nope, as a door would be an entity and rather unfortunatly entities don't block VIS. There is a way though, cast your eyes below. As you can see I have deleted the old corridor and added a bend. Let's see what this can do for us now. As you can see the engine is drawing much less then before, and for the final verdict: As you can see the r_speeds have been cut by almost 50%. Plus having a U-shaped corridor is far more interesting then a straight one. When you are making your maps always think about what the engine can see, as CS is multi-player and every r_speed you can knock off will reduce lag. Experimentation is key.
[ 本帖最后由 Simen.sllove 于 2007-11-20 09:23 编辑 ] |