Hi!

I'm new to Dod mapping so I would like to know what number of polys I can have in my maps without degradation of performance. I looked at some oficial maps but the numbers vary a lot, depending on what map I play.

My current work has the following polys:
epolys: 1300 to 9000
wpolys: 400 to 900
Are those ok or should I try to lower them? Of course, the smaller the better...

e_poly you should try to keep it under 7,000, optimal is 5000
w_poly you should try to keep it under 1,000, optimal is 800
when i say keep it under i mean keep it under. rework your area to try get as clsoe to them as you can. if you have to sacrifcie too much detail give it some playtests to see wheter you actually need to. and area with 8,000 e_poly and 300 W-poly won't be that much of an issue but one with 6,500 e_poly and 950 w_poly is.

Thanks, you helped a lot.
The last part of your post is the most important!

to tell u the truth, it depends on what pc its on, a 2 Ghz pc can easily take 1000 w polys, but a 500 mghz pc would die.

but try to keep it below 900 to be safe.

Anyone knows in what way brush entities are "included" in wpolies ? How their polies are translated to overall w_poly value ?

every single last face you make in Hammer goes int w_poly.
nulled faces and brushes with addative and 255 wont be added to w_poly but genrally, if u make it in Hammer it'll add to w_poly.

to see each w_poly ingame turn on gl_wrieframe 1 or 2

e_poly is anything from models.

Originally posted by Craftos
Anyone knows in what way brush entities are "included" in wpolies ? How their polies are translated to overall w_poly value ? Good question. Basically each visible face will add wpolies: for example a rectangle. It will be cut into 2 triangles and, according to the texture scale, the subdivide will add more or less world polies. All is calculated during the compile.
You can make tests in an empty test map, just add simple blocs or stairs, with r_speeds 1 you will see the influence of the texture scale and the null texture. If you add only 1 brush or only 1 brush-entity, you will see the exact amount when you look at the sky only and then 1 brush only. developer 1 and r_speeds 1, always.

The main part of your question, brush-based entities. Each visible face adds wpolies. The good point of brush entities is that they don't cut the brushes they are touching. The bad part is that entities are not affected by vis blocking and don't block vis: you will see them more often trough walls and the engine will "see" through them. Check by yourself the difference with gl_wireframe 2 and 1 (what is drawn - what the player can see. each line is a subdivide cut). It takes time but if you understand how the engine works you will make maps with more details and lower r_speeds ;)

The best reference covering this complex subject:
http://www.slackiller.com/tommy14/rspeeds.htm

Before that I was thinking that func_walls, etc. are "poor-man" models and they are renderend the same way as func_models. Now I'm not sure what they real purpose is in Quake engine if they doesn't block vis but affect r_speeds - except transparent ones.
All this 'x cuts other brushes, y not' strategy is not quite true. Problem is you don't have any real tool which would display most important datas from BSP file. gl_wireframe isn't it. Im not sure what it really displays, but at least it's not all mapper should know. Mapper would need leafs and portals displayed, esp. PVS data of every portal. func_walls should be drawed as models, and no impact r_speeds (w_polies).

entitys by defualt "float" in the world. They are entirely part of the world and entirely affectable by it good and bad. The only speciality that sperates them from the world is the fact they are "floating" in it. this fact lets them be moved shoved altered and otherwise screwed with dynamically. 90% of the entitys contain some certain or special aspect. but basically every brush entity is world through and through. The reason the entitys have a tendancy not to cut the world is the fact they are floating. but the key fact is "have a tendancy not to" instead of "dont". the engine isn't perfect, but Q2 used that few enetiys for other purposes than doors and windows that no one really gave a flying monkey if it didn't work perfectly.

HL2 will be the engine we need and want. The more you know about the HL1 engine the more impressed you become that it runs in the first damn place.


When the brushes hide absolutely nothing i personally would be more inclined to make them a func_wall just so you can avoid excessive bsp cutting.