Wpolly Count (rspeeds)
SnakeUb
Join Date: 2003-07-02 Member: 17871Members, Constellation
Join Date: 2003-07-02 Member: 17871Members, Constellation
Comments
my fps stil sux tho
its fast when i play it by using run function on hammer but slow when i preview it through ns using host langame menu ??
can i compile it so that it get beter fps?
in console in opengl mode and you see every single epoly thats cylculated.
when its 7500 I suggest running rad with "-full" first.
E_polys are the polys that make up Enitiy Brushes, i.e. the brush-based entities such as func_walls or func_doors.
E_polys are only the polys in model based entities, your gun in hands and armory command console etc...
Brush based entities (func_wall) rise only w_poly.
E_polys are only the polys in model based entities, your gun in hands and armory command console etc...
Brush based entities (func_wall) rise only w_poly. <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
No, brushes tagged to entities don't raise the w_poly count, they raise the e_poly, since they're entities.
Also, any idea what the recommended e_poly limit is, since Flayra only specifies the w_poly.
E_polys are only the polys in model based entities, your gun in hands and armory command console etc...
Brush based entities (func_wall) rise only w_poly. <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
No, brushes tagged to entities don't raise the w_poly count, they raise the e_poly, since they're entities.
Also, any idea what the recommended e_poly limit is, since Flayra only specifies the w_poly.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
<b>NO!</b> quazilin had it right. <!--emo&:D--><img src='http://www.natural-selection.org/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'><!--endemo-->
This is the correct, definitive answer from someone who knows the engine. Memorize it. <!--emo&:)--><img src='http://www.natural-selection.org/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
w_polys is short for "world polygons" and e_polys is short for "entity polygons", but that doesn't mean worldspawn vs. brush entity (the names can be misleading).
Anything that is specified using a BSP file is considered to be made up of "w_polys" by the engine -- these polygons contain lightmap data, are stored in a binary tree, and go through a specific path in the renderer. Every brush model uses four separate, miniature binary trees to store its data (1 per hull). Every brush model contributes to w_polys. Model (MDL) entities do not.
Anything that is specified in a MDL file is considered to be made up of "e_polys" by the engine -- these polygons do not have lightmaps (the entire model is scaled by a single light value), are stored as triangle strips to be rendered in groups, and use a different rendering path that is faster per triangle than the one used for world polygons. Entities that have art assets in MDL files (like your first-person view of your gun, building entities, and other players) contribute to e_polys. Brush entities do not.
The e_poly number can be much higher than the w_poly number because of the different rendering path used to render model information. The model rendering code is lacks the special effects of the world renderer and expects each component of the model to use a single texture map and light multiplier, allowing it to be faster on a per-triangle basis (the changes that DoD added to the engine for partially transparent models affect this, but those changes haven't been made available as a Half-Life update and can't be assumed to be on the machine of someone playing NS). Keep in mind that player models are supposed to be around 600 to 800 e_polys <i>apiece</i> depending on the project, potentially a number higher than the <i>total</i> w_polys that are supposed to be visible to regular players at any time.
The e_poly number is separate from the w_poly number because they count apples and oranges -- keeping both low is important for engine performance, but the e_poly count is the responsibility of the model designer and is on a completely different scale. Taking the sum of those numbers gives you garbage -- it'd be like saying, "I bought a total of 4 (suits + hamburgers) today," to an accountant trying to balance your budget. Burgers, like individual e_polys, have a low unit cost (dollars vs. performance). If you bought four burgers, you probably spent under twenty dollars. If you bought four suits, the cost might run into thousands of dollars. The sum of the two quantities doesn't tell you anything about the total impact they have--just like the *_poly amounts are only helpful to a knowledgeable level designer or modeler trying to optimize performance if they are kept separate.
I don't have a concrete number to give you regarding e_poly counts because they are directly affected by the number of players and buildings on the screen--the only way you're really going to add to the total would be to place hives, command chairs, and items like cyclers that let you place MDL based art into a map. Even in those cases, the MDL file is what actually controls the impact of those entities on the e_poly count. It's also impossible to cap e_poly counts as a mapper unless you are going to restrict the number of players that enter a room, what weapons they hold, what items they drop, etc. That said, lower is always better. I can tell you, however, that a 5000 e_poly count should have less impact on rendering performance than a 1000 w_poly count.
It is pointless to say: Keep w_poly under 600 but don't bother about e_polys. The mapping guidelines should be updated to show up good ways to hide buildings behind corners. The first res node for example could be placed behind a corner. It will still be taken into acount when it comes to rendering the scene, because of the way Flayra changed the entity vis. code, but of course they finally don't need to be rendered.
<snip>
The mapping guidelines should be updated to show up good ways to hide buildings behind corners. The first res node for example could be placed behind a corner. <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
Moving the node to a spot that isn't visible will save you 572 e_poly with the marine node structure in place--as you've said, NS can hit well over 10,000 e_poly in a marine spawn. While I agree that some sort of baseline e_poly guideline for map models is important, I don't think there's much point in reconfiguring a map for an optimization that amounts to under 6% of the problem as you've stated it.
I've tossed an email to Flayra to see what his input on the matter is regarding a specific number, but unless somebody's building rooms out of mdl files, they aren't going to have a significant impact on the e_poly count as a mapper (in comparason to the e_poly count that dynamic game entities will generate).
If you are adding mdl files to your map, you'll want to check e_poly counts minus the count any weapon you're holding when you're the only player and before a game as started. Trying to gauge e_poly counts during actual gameplay is self-defeating because as I noted above you have no control over what dynamic entities the game is going to generate in a given area of your maps.
EDIT: There may eventually be tutorials linked from the guidelines to provide information on how to map more effectively, but the guideline document's purpose is to provide NS specific information to experienced mappers.
I wasn't aware rad had a -full parameter.
God, I wish it did. That'd mean it'd have -fast, too.