Entities/r_speeds And Blah

michaeltoe

<div class="IPBDescription">what does the limit imply?</div> The NS guidelines suggest under 400 entities, and average w_poly's under 500. So far my map meets that req, but only after I discovered the incredible boost of making func_walls out of all the oddly shape details on my map. I previously had crates, pipes, and light fixtures attached to the walls and floors and they really screwed with the r_speeds... but since I've now gone and converted practically all my details to func_wall or func_seethrough, I'm beginning to wonder exactly how the amount of entities affects game performance. I have a decent machine so I can't really tell if the game will lag on others'.

Do entities contribute to internet lag? Do they hog more resources than regular faces? Even if the limit is 400, what is the tradeoff of converting everything to entities to lower r_speeds? Do some entities cause more problems than others? Would 100 functional doors cause more lag than 100 static func_walls? Are ambient light entities even present after the compile when the light isn't variable?

My map is currently only about 1/3rd finished, and I have just over 100 entities. I don't think I'll need to go beyond 400, but it would be nice to know anyway... I could of asked this on another forum, but the limits relate specifically to NS.

Mouse

The 400 entity limit doesn't include static lights, info_player_starts, info_team_starts and info_locations.

Lt_Gravity

bad... really bad.
since I say tanith I was shure entities arent the way to success for one cause: the entities are calculated by the server. so many/too big/too complex entities would lower your map speeds.
like all beginner mappers I also made the mistake to simply cut the whole worldbrushes by other worldbrushes. it resulted in r-speeds that werent playable anymore. advanced mappers use func_walls instead <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo--> but semipro mapper go in the other direction again. they build there architecture so well that there are only few func walls needed. that of course will take longer to compile but the i-net speeds will be faster. and it looks much more realistic.

michaeltoe

When they say they want peak r_speeds of 700, how conservative was that value? Because I don't exceed it, but get pretty damn close in a lot of places.

Also, if entities cause lag, should I say to myself "400 is ok", or a lower value, like 200... ?

I want to know this because I've never made a map before and don't know what kind of numbers the other maps are running.

watch_me_die

Using architecture in a smart way to lower r_speeds is better than using entities, run around a couple of the maps with "r_drawentities 0" set and you can see how the NS mappers used them. Also by using "gl_wireframe 2" you can see which walls are split up by intersecting faces and can correct this (run both these commands with developer + sv_cheats on).

Lt_Gravity

hard to say. its all a matter of experience. today I simply "know" what is too much and what is right. as far as I know the point based entities (sound, sprites, trigger) arent so much "server laming" because their information data is pretty low. but the brushbased entities like func_walls, func_illusionary, doors, trains have a lot more of information to transfer. to specify a "good" amount of entities is not too easy.
to the r-speeds: some people may say "nah, r-speeds! I have a... *dunno* ... machine thats enough to draw 2000 faces per second." but keep in mind that some dont. If you going to have over 700 wpolies in sections with only few action, it will be ok. but in areas where possibly headed combat will take place the speeds should be around 500. try the r_speeds 1 command on official maps and look how they are build at some spots. so you will get a better idea how to achieve a playable map.

oOTOo

And, michaeltoe, remember that the rspeeds value from the ground (when you are a soldier or an alien) is different compared with the com's one, as the com will be able to see much more rooms at the same time. Rspeeds value allowed for com is 700-1000 but, in the way you describe your map, you should start a test with a CC (and a minimap) to check that point.

Shadowics

The w_ploys limit is somewhat loose, you should keep it low as much as possible, but a few high spots can be acceptable. For now of you want to be completely official you have to keep it under 700 at all times. I'm one of the low-end players who gets 10-12 fps when there are 700 wploys, but personally I would prefer a map that looks great and is a little over the limit rather than the other way around.

The entity limit isn't a major issue with lag and anything like that, it's a HL engine limitation. Now, the HL engine can only handle 1024 entities, some of which are reserved. So why 400 for NS? Well, for one thing entities aren't counted on a 1-1 ratio. For example a single func_breakable is considered 15 entities by the game engine because of the pieces it shatters into. NS also has a specific problem - all the entities that it creates. Every building placed, marine or alien, is an entity. Every health pack, ammo, weapon, jetpack dropped by the comm is an entity. Every tripmine placed is an entity - laser tripmines might be two entities because of the beam effect. Every web gorges lay is a entity. Not to mention every 'physical' weapon, like grenades, acid rockets, bilebombs, etc, may be entities. And I'm not even sure how much particles systems count for. So, a map that has the loose maximum of 400 entities, could come dangerously close to the hard limit of entities in play.

michaeltoe

Ironically, my commander r_speeds tend to be much lower than my player r_speeds... my comm r_speeds never exceeds 600

michaeltoe

I've found that when making func_walls and func_seethrough, you can reduce the amount of entities used by making them in groups IE; 5 light fixtures, per one entity. The downside being, if one is seen, they all count towards the w_poly count. Additionally, if the objects in the entity are connected, they will screw up the r_speeds just as when connected to the wall.

I'm curious, there are various situations where I use the {invisible texture because I only want one surface of an object to be seen. If I replaced these {invisible textures with the clip texture, will it work like {invisible, and does it reduce r_speeds? Or am I screwed either way?

moultano

use null texture instead.

michaeltoe

would using null reduce r_speeds?

moultano

yes

Shadowics

long answer - any faces textured with null are completely dropped from the visual plane during the compile, and therefore don't count towards w_polys or fps. However, the face is still counted for the clipping plane and is still solid. Using null can cause some visibility problems if it's in a place where players can see it though, so be careful using it, but it will reduce r_speeds wherever used.

michaeltoe

That's great to know... all the fixtures, pipes, crates (as well as a lot of see-through grates) are entities on my map, yet only some of the sides are showing. I set all the hidden sides to null and it cut my w_poly count down by 40-50 at some points. <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'><!--endemo-->

Hypergrip

If you are close to or a little above the w_poly limit, try using hint brushes.
I managed to get a place where I got 820 w_poly reduced to 699 (yepp exactly that value <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo-->) using hint brushes.
But remember that hint brushes are no replacement for good vis blocking architecture... but if you know how to use them right you can plan with them and use them to save a lot of polys.

-my2cent-

Hyper