r_speeds and what to do :)

[Bullet]

i seem to hear a helluba lot about these whenever a map is mentioned.

personally i dont knonw much about them...i jst know that they r the amount of polys that the games having to draw.....and that u shud try keep em below 900 at all times.

now how to solve em.....tips ne one?

some websites say use func_walls to connect shapes the walls (like flanges on pipes)....but sureley jst where the floor touches a wall ur gonna get another poly made....and also func_walls dont block light

1 website said that resizing textures helps cos the walls are broken into 1 shape for each full size of the texture....

and then another website said move things like crates and furniture etc 1 block off the floor, as no one will notice and it will stop the polys being broken up?

so what do YOU lot do to solve r_speeds ?

[Wintermute]

If you check the Handy Vandal's Almanac, there's some info on there.

This also looks like a decent explaination: http://www.cariad.co.za/twhl/tutorial.php?id=38

FWIW, you want to keep them as low as possible in busy areas (less than 1000 should be fine), having said that, some areas of cs_proof go up to 1500, but I've not noticed any real problems there.
The main problem with info you find on the net is that it's not always up to date, so I reckon sub-1000 should be quite playable with modern PCs; and you can get away with it being higher in some places.
- I wouldn't get too worried by numbers up to 1500 until you've tried it to see if it causes problems.

When you compile the map, it's broken down into polys - If you want to get really advanced, then you can use VIS blocks to actually manually control how your map is broken down (I used this technique in one or two areas of cs_proof with some success - the 1500 poly area was originally jumping up to 2500 before I used a few VIS blocks).
But I'd only use VIS blocks as a last resort, after you've optimised as much as possible using normal techniques.

If you want to actually see what your map 'looks' like to the computer, switch to software rendering (instead of OpenGL or DirectX); and type r_drawflat 1 in the console. This can be useful if you can't understand why the r_speeds are getting higher in some areas.
Another technique (using OpenGL mode) is to use gl_wireframe 1 or gl_wireframe 2 which also shows you the polys that are being drawn.
Note: Both these techniques only work if you start a 1 Player Local Server, you can't use them when playing multiplayer.

One technique that's widely used is to leave a 1 unit gap between your brushes (e.g. move a crate 1 pixel off the ground); you can usually use this without anyone noticing and the ground won't get split where your crate is.
Alternatively, make it a func_wall, but as you mention this does have some side-effects.

Another technique is to scale up your textures where possible.
So for example, with grass, rocks, etc, change the texture scale (X and Y) from 1 to 2 and see how it looks. With textures that do not require much detail it's worth scaling them up as much as possible as this will reduce your r_speeds - don't go too far or your map looks 'blurry' - give it a bash and you should see what i mean.
I believe there are some tools you can get to do this for you, although I've never tried them.
I've also read that going 'too far' with texture scaling can actually slow things down, so the best bet is to try a few values and see what happens.


At the end of the day, most r_speed problems are down to poor deisign.
The front of the house in cs_proof has high r_speeds - because when you enter the front garden you can theoretically see into almost every room in the house (and all the details like beds and tables, etc).
This is because I didn't think things through before designing it.

By means of a comparison, consider cs_estate - how much of the house can you see through the doors and windows ? virtually none, almost all windows and doors face a brick wall, which means good r_speeds.

HTH

[-=Alex=-]

winter, you could have added curtains to your windows .

Another thing to remember is to check r_speeds and make demo maps of areas that you are adding so you can check what is happening. I had 1 map that was playing fine then went to pot as i added one bit and then had to remove it, as it shot my r_speeds over 2000 . I prefer making small parts of maps as i always find things to do with them later on in other maps i have ideas for.

[Sputnik]

I second everything Winter said gl_wireframe 2 is incredibly useful.

Although personally I would be worried about r_speeds of 1500 - I get uneasy about anything over 800 and upset over anything above 900, but be aware that it may very well not cause any noticeable problems. R_speeds are not the only cause of lag (texture memory is a limit I've spent a long time trying to balance, for example), and unlike exceding other engine limits they only cause a gradual degradation of performance.

One underestimated consideration is 'how many things will be going on in this area that a player can see?' - a huge room may have 400 wpolies but if you're going to get 18 people using paras in there you should be playing Wolfenstein or Doom instead Epolies are very important and can easily be overlooked (dvf_clash, or the above hypothetical example).

You can and definitely should spend hours and hours removing polygon after polygon with the many small-scale r_speed reduction techniques, but as Winter said there is no substitute for good vis blocking. (I'm not talking about hint/skip brushes to artificially block vis, I'm talking about placing big walls in the middle of rooms etc). Of course there's a balance between r_speeds and common sense / gameplay / realism / prettiness here.

In answer to that "what do I do to reduce r_speeds" question - everything Let's have some bullet points:

• Sensible brush creation, as above
• Hint brushes, like Winter said, are very useful but should be very carefully used and thoroughly tested as they can make things worse
• The 1 unit gap rule. Very important, and often invisible to the player. Chances are the once-hidden face will still not be rendered by the engine, but just incase, use the null texture (see below).
• The brush entity rule. Turn a brush into an entity and it no longer splits up adjacent brushes. Magic. But there are disadvantages, and the engine doesn't deal with funcs as well as it does world brushes. Remember that you can always make the func opaque if light blocking is important to you, but this makes HLRAD so much slower.
• The flange rule. A combo of the above two that works and looks pretty well/good
• Texture scaling. Very, very important - just look at the map with gl_wireframe 2 on to see how many polygons a simple wall can take up. Don't have a tiny texture tiling over a massive wall, and scale it up if you can get away with it. Be aware though that faces are split every 240 units anyway, so a 1x 256^2 tex will be 4 polies anyway. Annoyingly this suggests that the ideal big texture size is 240^2, but you really don't want them this size for other reasons.
• The null texture. This is such a useful tool Using Merl's latest build of ZHTL you can put a texture named Null on any face you want the engine to delete. Magic!
• The wedge rule. Got a fence post with four sides that people can't get behind? No you haven't, you've got a triangle-based fence post with 3/4 of the polies
• Limit detail. If you have a pillar that's only going to be seen from fair distances, why would it need 16 sides? Rad smoothing can make even 6-sided objects look cylindrical from a distance.
• Use models. A tricky one, as it requires that you learn how to model, which takes a lot of work. Remembering to keep an eye on epolies, take a complicated table from the world to a model and you have a nice reduction in wpolies. Just remmeber that models do not clip (block) the player.

That's it from me I think R_speed management is a real art, and an impossible one to master - just experiment and test

An yes, Winter could have used curtains, but they'd have to reach the floor, and if it was going to be passable it would be an entity and thus vis-through-able Unless he used this very clever technique.

[Wintermute]

An yes, Winter could have used curtains, but they'd have to reach the floor, and if it was going to be passable it would be an entity and thus vis-through-able Unless he used this very clever technique.

Nice

[Bullet]

so thats how they made the area near the APC on prodigy able for you to climb onto the railings next to the sky and not be able to see the roof of the corridors on the other side.



that also brings me to summat else, that having not used hammer r anythign special, i am unlearnded in.....the ZHLT lightflags and setting to opaque....is this an option in the editor in in ZHLT....cos if its in editor i think i know how to do it in quark....if its in ZHLT i aint got a feckin clue.

o also.....BSTRDS AND UR PREFABS BUILT INTO HAMMER...I HAVE TO DO EVERYTHING MYSELF IN QUARK, LAZY SO N SO'S!

[Sputnik]

Prefabs are pure evil anyway, its best that you are forced to make things yourself

ZHTL flags are set in the editor - the expert fgd for Hammer makes it nice and easy, but if you use Quark that's not much use

I dunno how Quark works but in Hammer the flag you want is zhlt_lightflags and a value of 2 will be opaque.

[Bullet]

as all of half life uses the same settings and the only way to do HL Mods in quark afaik is to just select the extra entities from a list (in this case the CS section).

at the bottom of all the entities theres little buttons saying TFC...n some of em say ZHLT, im assuming its in there then.

[Bullet]

tried out the 1 block gap on a small deathmatch map tnight.

j_streetsofrage

highest r_speeds i found was 214, right in the middle.....the lowest i foun was 20!