How do you reduce r_speeds?

I have two maps that i recently submited. Op4_harbor, and op4_abby. Both maps are compleate, but my r_speeds are awfule. I would like to know how to reduce them, and what causes high r speeds so i dont do it in the future. Thanks

you are going to recieve all kinds of advice, but i suggest, you load up a few maps, pay attention to what works, and what doesn't.

thats the best advice there is.

limit what can be seen from any given location.

Another piece of advice:

Solid`s with many faces (IE: Cylinders) should remian 1 inch above the ground, not able to be seen by the player, but just enough to reduce face cut-ups.

AND to add to Vash's statement, if your mod/compile tools support the Null texture then use that on the face that's facing the wall/floor. Null is a texture that is deleted when compiled, so it removes that poly. Use it anywhere the player will never normally be allowed to see.

small objects that are sitting on something and really don't affect the light much, convert them into func_walls to prevent brush break-ups. (Go the extra step and make them destroyable for the fun of all :biggrin: )

Awsome, thanks for the help guys, i will do what i can to fix it

The most important method to reduce your r_speeds is VISblocking. This is where you limit what can be seen by the engine by blocking its line-of-sight. A basic way to do this is to put bends in the corridors between rooms:

[simg]http://snarkpit.com/pits/gollum/Forum screens/base.jpg[/simg]

[simg]http://snarkpit.com/pits/gollum/Forum screens/connect1.jpg[/simg]

[simg]http://snarkpit.com/pits/gollum/Forum screens/connect2.jpg[/simg]

[simg]http://snarkpit.com/pits/gollum/Forum screens/connect3.jpg[/simg]

Heh :smile:

Also take into account the scaling of your textures. Every time a texture tiles, thats 1 wpoly, so a smaller scaled texture will result in more wpolys than a higher scaled one.

Also bear in mind that 256*256 textures act a little differently if they are stretched to fit a face. e.g 1 side of a crate with a 256*256 texture stretched to fit will result in 4 wpolys, as the HL engine chops at 240*240. That probably makes no sense at all! I'll try and write a tutorial this weekend regarding this as i've been meaning to for a while now :smile:

Good advice - though I think an understanding of how to best use HL's texture-chopping is a little beyond the scope of beginner mappers.

Simple advice: don't let the game see too much stuff at once. Everything else is "tweaking". You can use tweaks to make you r_speeds a little better, but only good VISblocking will stop them from being terrible in the first place.

At this point I fully expect someone to bust in with "Use Hint brushes". :heee:

I keep on seeing hint brushes being mentioned, and I've seen the texture but what do they do?

They force HLBSP to make a BSP split (a division into visible portals) at that point. Basically, it gives you control over how the map is cut up by the compile tools. This can sometimes lead to better r_speeds or the elimination of strange VIS errors.

However, in any map that has a significant "3D" element (like, it isn't easy to plot clearly on a top-down view), the chances are low of you understanding where to place optimal BSP splits. The process of partitioning 3D space is horribly complex, and I reckon it is rare for a human to control it better than a computer.

I've succesfully used hint brushes to cut r_speeds when I made a small level with really short hallways. It kept the game from rendering the entire map because the tools were too dumb to figure out where one room ended and another began. If you suspect you have this problem, run around with gl_wireframe 2 on and you can see what is being rendered everywhere, this will help you place hint brushes to remove those areas from sight.

But yeah, it's confusing as hell to use them when you're trying to do three dimensions. Deciding where you can see rooms above and below is too much of a pain to really justify the work involved. Use hint brushes to further reduce r_speeds if you can figure out how, but they won't fix all your problems for you. That's what visblocking is for.

one word - entites. In one map i made the r_speeds went through the roof due millions of entites. Damn

matt said:
one word - entites. In one map i made the r_speeds went through the roof due millions of entites. Damn

/me pets gmdm2 in a slightly dodgy fashion :kitty:

matt said:
one word - entites. In one map i made the r_speeds went through the roof due millions of entites. Damn

Not necessarily true. Only certain types of entities add to polys of both kinds.

Gorbachev said:

matt said:
one word - entity's. In one map i made the r_speeds went through the roof due millions of entity's. Damn

Not necessarily true. Only certain types of entities add to polys of both kinds.

epolies and wpolies are always separate animals, func_walls and their ilk still only ever count toward the wpolie limit.

epolies can and will drive up r_speeds, but have about 5 times the limit before doing so (1000wpolie,5000epolie)

reducing the visibility of either will always reduce the r_speeds, assuming you have a full compile and successfully applied vis-blocking.