R_speeds

SnakeUb · July 2003

<div class="IPBDescription">how can i improove them</div> it was pointed out that on my map (ns_2fortsb5) the r_speeds were a bit poor and it was causing lag although this didnt cause any problems on my pc it is lagging up sum ppl making it not very server friendly how can i improove the r_speeds and the fps in my map.

CaLFiN · July 2003

You want the mapping forum.

General causes of high r_speeds:

- Unscaled textures (not that much really)
- Very large open areas
- Very complex brushes
- Lots of entities in one area
- Moving entities (doors, trains, fans)
- Very large func_walls/func_water etc

Shadowics · July 2003

Calfin, what you pointed out are things that can cause lag and slowness. Not necessarily high r_speeds.

When people say the r_speeds are bad they are generally referring to the w_ploys, which is the main cause of low fps. What causes high w_ploys is being able to see large areas. I saw the screenshots of your map, snake, and this is most likely the problem, you a large outdoor area by the looks of it and so you can see a long distance. Thing about how many large open areas there were in the official maps, hardly any. Because of the basis for your map I'm not really sure what you can do to reduc your w_polys however, maybe I'll take a look at your map and see.

I just took a look a your map and I think it's obvious what the problem is, let me double check in game and I'll get back to you, this should be fixable.

XiaoXiao · July 2003

For more information about r-speeds, goto <a href='http://www.karljones.com/halflife/r_speeds.asp' target='_blank'>http://www.karljones.com/halflife/r_speeds.asp</a>
And now back to the presentation....

Shadowics · July 2003

Ok, the problem is rather complex. The basis is bad map design, you don't have proper vis-blockers, you're whole level is basically open. Here are some specific things you can do that will help : Those 2 func_walls you have, turn them into back into worldbrushes. I don't see any reason for them to be entities and making them worldbrushes will reduce wpolys as well as fixing some of the glaring lighting errors. Probably the biggest problem you have is that thing at the bottom of the lake. That's contributing a ton of wpolys for something players aren't likely to see much anyway. I would definately recommend replacing it with something made out of fewer brushes. And make That a func_wall, instead of worldbrushes. If you do both of those you're wpolys will still be high, especially in the marine start, but they'll be a bit better.

Also, why on earth do you have your tiled textures scaled down? You tiled wall textures like NOS_SUBWALL2I3 and out_w5 should be 1x1 scale or larger. When you scale down textures you create more wploys, so you shouldn't scale down unless it's for good reason.

CaLFiN · July 2003

</span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Shadowics @ Jul 9 2003, 07:56 PM)</td></tr><tr><td id='QUOTE'> Calfin, what you pointed out are things that can cause lag and slowness. Not necessarily high r_speeds. When people say the r_speeds are bad they are generally referring to the w_ploys, which is the main cause of low fps. What causes high w_ploys is being able to see large areas. I saw the screenshots of your map and this is most likely the problem, you a large outdoor area by the looks of it and so you can see a long distance. Thing about how many large open areas there were in the official maps, hardly any. Because of the basis for your map I'm not really sure what you can do to reduc your w_polys however, maybe I'll take a look at your map and see.

I just took a look a your map and I think it's obvious what the problem is, let me double check in game and I'll get back to you, this should be fixable.  </td></tr></table><span class='postcolor'> 
It's not my map <img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'> (thank you, thank you, thank you :x :x :x)

Another thing that causes really bad r_speeds is having brushing touching other brushes. If you have a small square brush on top of a larger square brush, vis will cut the large block up into segments at each place a corner touches (proper name is vis_leafs (lowering these also makes your map compile a lot faster.)) That's what gives you those little pixely white lines you might see around on some maps.

Solutions:
- Make things touching walls/floors/ceilings a func_wall (best for small things such as signs.)
- Move the object 1 pixel from the wall/floor/ceiling.

Shadowics · July 2003

</span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (CaL_FiN @ Jul 10 2003, 01:02 AM)</td></tr><tr><td id='QUOTE'>It's not my map <img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'> (thank you, thank you, thank you :x :x :x)</td></tr></table><span class='postcolor'>
Edited for clarity, happy?

Brush fragmentation is a complex issue, it's done to by the compile tools to increase frame rates, even though it increases w_polys at the same time. This isn't much of a problem on this specific map however, as the geometry is rather blocky. The way his level is set up I believe that changing the existing func_walls but to worldbrushes, though it would cause fragmentation, would improve frame rates. The thing at the bottom of the lake however, is not only high-poly but is causing quite a bit of fragmentation. Turning this into a func wall would be an improvement.

Also making it an entity, as opposed to moving it 1 unit away, is a better solution because by moving it 1 unit you're essentially tricking the compilers. Though the best solution of course is to design your map so you don't need to worry about things like this.

CaLFiN · July 2003

</span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'>Also making it an entity, as opposed to moving it 1 unit away, is a better solution because by moving it 1 unit you're essentially tricking the compilers. Though the best solution of course is to design your map so you don't need to worry about things like this.</td></tr></table><span class='postcolor'>

Moving something one unit away is entity saving, especially because people do not notice anyway, if you have a large entity map it's best to do it than make lots of func_walls. I don't see how tricking the compiler effects anything? < That's not meant to sound bitchy <img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'>

Shadowics · July 2003

Ok, Here's an example. A bit oversimplified prehaps but it illustrates the point. Go down and look at the attached image now because I'm going to talk about it next. Back? Ok. First off, yes those are the actual frame rates my pathetic laptop got. Really though, you can see how the brush fragmentation caused by having worldbrushes touching jacks up the wploys. Now while leaving the 1-unit gap improved wploys it didn't actually improve performance, this is because the gap tricks vis into thinking you can see under and over the brush. The engine is rendering fewer, but bigger faces. Also there's a little bit of light leaking visible through the gap, the the image compression blurred it so it's hardly noticeable. The func_wall is an extra brush entity, and with the soft limit at 400 I can see how you might run out. However it's virtually indistinguishable from the worldbrush version, and better than leaving the gap.

SnakeUb · July 2003

Thanks 4 ur advice i will try out the suggestions made

SnakeUb · July 2003

ive tried out ur suggestions
and this is wot i did
- Removed tram from under water
-uped scale of textures
- made blocks not touch
- removed the 2 func_walls
- lowerd vis distance to 4500

this is wot happened
- peak wpolly fell from 900 to bout 580
- file size more than halved for bsp
- compile time fell from 1hout 10 mins to 2 mins
- my fps rose from 40 avg to 95

thanks guys
a rerelease is gona happen now

<img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'> <img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'> <img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'> <img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'>

SnakeUb · July 2003

ok its been rereleased now

<a href='http://www.angelfire.com/ns2/snake_ub/ns_2fortsb5.htm' target='_blank'>http://www.angelfire.com/ns2/snake_ub/ns_2fortsb5.htm</a>

if ne1 has any problems with it that they know how i can fix plese tell me <img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'>

thank you all for your help i have learnt a lot about mapping this last few days

(NB ive been mapping for 1 1/2 weeks lol)

CaLFiN · July 2003

Good work snake, that's very interesting Shadowics, never knew <img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'>

Shadowics · July 2003

Looks better. Removing the tram was probably what reduced you compile time so much, and reduced wpolys. Scaleing the textures and removing the func_walls also helped wploys. I hadn't even looked at you MaxRange though, I didn't expect you to change it from the default. Why is it set so high? If you reduced that to something like 2560 you could probably reduce your wploys a little more with no visual errors or anything.

SnakeUb · July 2003

</span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Shadowics @ Jul 10 2003, 12:30 PM)</td></tr><tr><td id='QUOTE'> I hadn't even looked at you MaxRange though, I didn't expect you to change it from the default. Why is it set so high? If you reduced that to something like 2560 you could probably reduce your wploys a little more with no visual errors or anything.

 </td></tr></table><span class='postcolor'> 
i didnt change it at all b4 then hammer must have generated a high distance cus of the large room i just lowered it when i was looking for things to downgrade weird.

R_speeds

Comments