View Full Version : How to reduce polys [Basic level]

13-02-2003, 09:25 AM
The best way to reduce polys is to not make too many walls that make an intersection, 1 wall can be used to make an insection and then you can change the side textures accordingly.

Heres some shots to explain.

The first image if you scroll down shows you a bad way to map, the second one is a good way to reduce polys and do the same job with less polys:-


[sorry freeservers wont let me link, so just go to my site to see.]

As you can see the second image uses less walls and also acts as 2 walls. Paint the wall textures accordingly to the coridoor or wall face you want.

Also remember that creating walls you have to consider all dimensions not just plain 2d X,Y but the Z direction. When you first make a map, make a plain birds eye view then mark off which walls which can share to make other walls, but also do it in the up/down direction. Then youl find that you can reduce wpolys by 30%.

If you look at the 3rd image, this again is a bad way to map, because your using 3 polys in place, when the BSP[Binary Space Partition] utility does its job it splits all the polys down into chunks to the basic single polys by intersection, the best way to help the BSP process is to map correctly so that the BSP utility only splits the polys we want. The last image is a good way to map as it shows you the same job but done with 2 polys. When you create a room dont make the side walls fit into each other, this only creates more polys and taperering them doesnt do much either. Make the walls touch each other so thier only sharing 1 point at the corners, like in image 2 & 4.

Another great tip is to place your map away from the direct center of the axis, this reduces bsp spliting, this would take a lenthy explanation to explain, so please trust me it works.

This is all for a basic level of how to reduce polys and lower w_poly rates. This should help you to make creative yet simple and quick maps. Remember these techniques are used by the Pros and im giving you an incite to how they make complex maps seem to able to run on low spec systems.

Hope this helps.



26-02-2003, 05:43 AM
U can also reduce ploys with vertex editing.

ASCII demonstration (dont mind the "." the drawing would simply collapse without them)

corner of a room.

.............|| this is bad 8 vertex's drawn ingame

..................|| only 4 vertex's drawn ingame

UNDEADENEMY: Actually this is overhyped. Vertex editing does have it's uses though such as aligning textures at 90 degree angles.

26-02-2003, 09:38 PM
Just about anything I hang on the wall I turn into a func_wall. I'm paranoid against those ugly shading lines across brushes from poly splitting. I also func_wall table and shelf legs, and sometimes boxes. The problem is if it's a big object, you will notice that it doesn't cast a shadow and will look wierd. I also turn lots of small objects (like a wall of pictures) into one big func_illusionary so the player doesn't get caught on the sticky-outy signs, while still saving polys. I ALWAYS make cylanders that touch stuff an entity, because of the spiral of shading lines.

That's all for 'Kelpy's Tip Of The Day'

06-03-2003, 04:20 AM
hmmm gotta keep that in mind ;)

06-03-2003, 05:15 PM
It sure helps to work symetric (spelling?) so the brushes will flow into eachother wich creates less brushes and that way less r_speeds.

06-03-2003, 08:18 PM
if u got zoners (if u don't why not?) set the shade level in your enetitys propites, and that way big objects cast shdows, just don't make pushable, or brable objects have shadows, as they don't move with the enity

07-03-2003, 02:50 AM
Could you give us in-game examples with gl_wireframe 2 ?

07-03-2003, 05:09 AM
Heres something about R_speeds vs. Detail (http://www.vlatitude.com/tutorials.php?tutID=35)

17-03-2003, 02:48 AM
I shows alot of images and I got here it in 1 image explained.

The blue circled is good and the red is bad.

Image Sample (http://www.decksix.com/~dutchtux/pics/rspeeds.gif)

17-03-2003, 05:03 AM

from http://amckern.actionrealm.com/resource/tuts/cs.html


17-03-2003, 11:15 AM
I see that some of you are still tapering/mitering them, and what i can say about that is that your creat problems[When your level gets complicated], by tapering them your create a splits in several ways which then splits the whole map via that way creating even more spliting, thats if you tapering a hull and not interia wall and func_wall object. The less spliting in the BSP process the better. Make sure that the outer hull is enclosed but also make sure they are connected by only 1 point.
This creates a partition which the bsp simply ignores and only concerntrates on internal partitions.


The Green-Mamba
17-03-2003, 03:07 PM
Not to be the antagonist here, but the mitering of corners is a myth. It in fact DOESNT reduce r_speeds as has been proven in several articles. One can be read at the Valve Collective.

Here's the link: http://collective.valve-erc.com/index.php?doc=1047005525-19966900

However, if you're like me, the mitering of corners has become and unbreakable habit and you just can't stop doing it.

The only ways I can think have already been mentioned:

-Func_wall gets past vis as an entity
-Over-scaling textures reduces the poly count
-Making complex brushes that could be connected to another complex brush, spaced by one unit.

19-03-2003, 01:48 PM
If mappers need some basics they can read my guide :


22-03-2003, 09:28 PM
If you really want it analyzed:

Mitered joints might not reduce r_speeds.

"During the compile process the engine discards all unseen faces, and breaks the remaining surfaces up into polygons based entirely the visable flat planes. These polygons ignore the underlying brushwork."

I could be wrong here, but the keyword seems to be surfaces. Unless you really know how the hlengine communicates with the graphicscard to render polygons with texures it's hard to tell which is the fastest. Well, unless you do some serious benchmarking. My speculations...I've never done any 3dcoding. So as I said, I could be wrong.

23-03-2003, 05:29 AM
1 thing i lately come upon is to NOT fit a 256 texture on a wall or crate. The engine breaks it up at a 240 unit square, so with a 256 texture you'll end up with 4 faces for 1 side of the wall / crate !

Therefore I reworked my custom crates. Main texture is 240x240 now and i added a 16 pixel area (1 color) on all sides, so i get a 256 texture again. In WC i fit the texture onto the crate and then i overscale the texture by 10 %. That way the crate is covered by the 240 area of the 256 texture only, which won't break the crate up into 4 faces - i placed a room full of the new crates and it really makes a difference. For every crate you'll save up to 15 faces !
10 crates (quite common) save you 150 faces !
That's great. :)

29-03-2003, 10:15 PM
I was reading that one article about r_speeds vs detail. I can easally say it's not very good;

W_Poly around 400, and E_Poly around 900. Can ANYONE honestly say in a large area this is an easy thing to do? Personally, I like to keep it betwen 600-1800, but that's just me.

The best advice is anything above 800 and 2000-3000 polys really needs to be redone.

30-03-2003, 03:31 AM
Yes, i go by these values, too. It's no fps difference whether there are 400 or 800 faces shown on most computers today.

(More interesting is how many entities your map has when it comes to nettraffic, but that's off topic here)

31-03-2003, 06:53 PM
A map can handle a lot more than 400 polys. A year or two ago, when people still had shitting computers that were choking up on HL, 400 polys might have been a decent limit. However, as this is the 21st Century, I think it's time people moved on with the rest of the mapping community and started making maps that actually have some detail in them. I mean come on people, I have a Geforce2MX and I have never choked up on a HL map.

While it's true that you can get some decent looking areas without the huge poly count (I can too) you shouldn't freak out if you go over 400. Just keep it below 1000.

10-04-2003, 08:00 PM
yea, really, lol, if your computer cant handle half-life, get a new life, cuz your wasting your years. i had a GeForce 2 MX, too, until recently, now i have a geforce 4 MX AGP 8x, and my computer handled every map perfectly.
thanks for the texture scaling tip, it's perfect for helping me lower my r_speeds in my map.:)
valve hammer editor's archive has lots of great tutorials and tips for reducing your r_speeds too. check it out

23-11-2003, 09:04 AM
are HIGH e-polys something bad? Cause I dont have any problems running my own-made maps FPS wise, and w-poys dont go haywire, but e-polys, they seem to reach levels like 15k and such when I run them! But that's about it, since I never see any flaws FPS wise or visuals wise :confused:

edit: lol, just forget what I said about 15k, those damn epolys reaches over 100k now due to some changes I did...

23-11-2003, 05:23 PM
epollys are model triangles, gargs have about 80k each

if u play ns u might know what i mean here

the final battle aginst the xeno, in a marine spawn, with a massive tf, lots of labs, and heaps of players = over 1m epolly

with that, you get lag

but a normal game epollys are something to consider, but not as inpornat as the wpollys - that you look at for r_speeds


23-11-2003, 05:51 PM
To keep Epolys down you can use Squad makers or Monstermakers which only spawn at execution time and not run time, this should limit the epoly range

The theory is:-

Wpoly > Should not exceed 8000

Epoly > Should not exceed 30000 or less than 25fps

Also vis blocking in high poly areas is good for optimising epolys. But generally a high speed graphics card can handle about 60 entities with a medocre slow down and a slow card offers 20-30 entities with a slow down. I say keep a balance in your maps, remember to split you map into segmented areas and block the VIS compiler from seeing into different portals.

24-11-2003, 11:55 AM
Thx to both of you for that information, its just that I already make use of both squadmakers and monstermakers, and the real problem was actually that I had used lots of 'trigger_once' entities using AAA_trigger pic (they were tiled up in rows because I didnt think of that I could simply name every squadmaker in each area the same... lol)

Well, at least I dont run into any problems FPS wise as of now, and r_speeds usually dont go very high either.

Thx for the info once again, both of ya.

24-11-2003, 12:07 PM
Originally posted by Tinman

Wpoly > Should not exceed 8000

You mean 800 right?
I've never seen a map exceed 4500 w_poly, and you would need an uber computer to run a map with 8000 w_poly :wtf:

24-11-2003, 12:26 PM
Hmm, regarding wpolys, try playing Minotaurs_maze, thats shows alot of wpolys, r_speeds are around 6500 in certain places and the map has about 27000 epolys, so 8000 is the absolute max the engine can actually handle without comming up with errors, it isnt a score mark for a specific map content or system spec.

Anyhow my current system with a Radeon 9600 pro could handle about 7000 wpolys at about 25fps, any more then that, then it would be unbearable to play.

A good graphics card can improve framerate amazingly.

I keep my polys optimized on all my maps,

I never exceed 750 wpolys and i try to keep epolys down to around 15000 > 8000 on large maps.

24-11-2003, 12:41 PM
My comp has 1200 mhz and my graphics card is also a Radeon 9600 pro, and i get 4 fps at 4500 w_poly.

14-02-2004, 12:50 PM
What does this tutorial exactly help?

16-07-2004, 12:46 PM
Another good way to reduce w_poly is to make ALL NON VISIBLE TEXTURES use null texture!