|
|
| (7 intermediate revisions by 3 users not shown) |
| Line 1: |
Line 1: |
| − | <!-- ## page was renamed from Polygon Count -->
| + | #REDIRECT [[Polygon Count]] |
| − | = Polygon Count =
| + | |
| − | | + | |
| − | | + | |
| − | <span id="PVT"></span><<Anchor([[PolygonsVsTriangles]])>>
| + | |
| − | == Polygons Vs. Triangles ==
| + | |
| − | When a game artist talks about the poly count of a model, they really mean the triangle count. Games almost always use triangles not polygons because most modern graphic hardware is built to accelerate the rendering of triangles.
| + | |
| − | | + | |
| − | The polygon count that's reported in a modeling app is always misleading, because a model's triangle count is higher. It's usually best therefore to switch the polygon counter to a triangle counter in your modeling app, so you're using the same counting method everyone else is using.
| + | |
| − | | + | |
| − | Polygons however do have a useful purpose in game development. A model made of mostly four-sided polygons (quads) will work well with edge-loop selection & transform methods that speed up modeling, make it easier to judge the "flow" of a model, and make it easier to weight a skinned model to its bones. Artists usually preserve these polygons in their models as long as possible.
| + | |
| − | | + | |
| − | {| border="1" cellpadding="2" cellspacing="0"
| + | |
| − | |-
| + | |
| − | |}
| + | |
| − | | + | |
| − | When a model is exported to a game engine, the polygons are all converted into triangles automatically. However different tools will create different triangle layouts within those polygons. A quad can end up either as a "ridge" or as a "valley" depending on how it's triangulated. Artists need to carefully examine a new model in the game engine to see if the triangle edges are turned the way they wish. If not, specific polygons can then be triangulated manually.
| + | |
| − | | + | |
| − | When using a [[NormalMap]] some tools may require an artist to convert the model into all triangles before baking. If the triangles are flipped differently when the model is exported than they were when the normal map was baked, this can cause the final normal-mapped lighting to zig-zag across the model. Triangulating before baking will solve this.
| + | |
| − | | + | |
| − | <span id="TCVVC"></span><<Anchor([[TriangleCountVsVertexCount]])>>
| + | |
| − | == Triangle Count vs. Vertex Count ==
| + | |
| − | Vertex count is ultimately more important for performance and memory than the triangle count, but for historical reasons artists more commonly use triangle count as a performance measurement.
| + | |
| − | | + | |
| − | On the most basic level, the triangle count and the vertex count can be similar if the all the triangles are connected to one another. 1 triangle uses 3 vertices, 2 triangles use 4 vertices, 3 triangles use 5 vertices, 4 triangles use 6 vertices and so on.
| + | |
| − | | + | |
| − | However, seams in UVs, changes to shading/smoothing groups, and material changes from triangle to triangle... are all treated as a physical break in the model's surface, when the model is rendered by the game. The vertices must be duplicated at these breaks, so the model can be sent in renderable chunks to the graphics card.
| + | |
| − | | + | |
| − | Overuse of smoothing groups, over-splittage of UVs, too many material assignments (and too much misalignment of these three properties), all of these lead to a much larger vertex count. This can stress the transform stages for the model, slowing performance. It can also increase the memory cost for the mesh because there are more vertices to send and store.
| + | |
| − | | + | |
| − | <span id="TFCV"></span><<Anchor([[ToolsForCountingVertices]])>>
| + | |
| − | === Tools for Counting Vertices ===
| + | |
| − | Because vertices are duplicated for in-game rendering, most 3D modeling tools don't give you the correct vertex count. They only count mesh vertices.
| + | |
| − | | + | |
| − | However, artists shouldn't worry too much about calculating exact vertex counts, simply go for common sense and don't be wasteful.
| + | |
| − | | + | |
| − | * [http://www.jhaywood.com/ James "FatAssasin" Haywood] wrote a [http://www.ericchadwick.com/examples/files/HaywoodTools-UberVertCount.mcr MAXScript for 3ds Max] that calculates the eventual in-game vertex count.
| + | |
| − | * [http://www.ldaustinart.com/paul/ Paul "MoP" Greveson] wrote a [http://boards.polycount.net/showthread.php?p=934301#post934301 mel script for Maya] that calculates the eventual in-game vertex count. Perhaps he'll be able to share it at some point. :)
| + | |
| − | | + | |
| − | <span id="TTC"></span><<Anchor([[TypicalTriangleCounts]])>>
| + | |
| − | == Typical Triangle Counts ==
| + | |
| − | The typical triangle count for a game mesh depends on many factors, see "[http://www.rsart.co.uk/2006/11/20/how-many-polygons-in-a-piece-of-string/ How many polygons in a piece of string?]" by [http://www.rsart.co.uk Rick Stirling]. Here are some examples, but the best bet is to ask your Lead Artist or Lead Programmer what should be used for each asset:
| + | |
| − | | + | |
| − | * [http://www.rsart.co.uk/2007/08/27/yes-but-how-many-polygons/ Yes, but how many polygons?] by [http://www.rsart.co.uk Rick Stirling]<<BR>>Triangle counts & texture sizes used in some of the popular console and PC games.
| + | |
| − | * [http://forum.beyond3d.com/showthread.php?t=43975 Yes, but how many polygons? (Beyond3D Forum)]<<BR>>Even more specifics for console and PC games.
| + | |
| − | * [http://boards.polycount.net/showthread.php?t=40563 Low Poly Hardware Specs] from the Polycount forum<<BR>>Maximum triangles, texture specs, and rendering features for popular handheld and mobile hardware.
| + | |
| − | | + | |
| − | <span id="AAP"></span><<Anchor([[ArticlesAboutPerformance]])>>
| + | |
| − | == Articles About Performance ==
| + | |
| − | * [http://boards.polycount.net/showthread.php?t=50588 Too much optimization (do polygon counts really matter?)] from the Polycount forum<<BR>>Discussion about the diminishing returns of optimizing meshes for most games.
| + | |
| − | * [http://boards.polycount.net/showthread.php?t=69183 # of sides on a barrel] from the Polycount forum<<BR>>Discussion about how many sides to add to rounded meshes in a game.
| + | |
| − | * [http://www.ericchadwick.com/examples/provost/byf1.html Beautiful, Yet Friendly Part 1: Stop Hitting the Bottleneck] article by Guillaume Provost<<BR>>Typical performance issues in game engines, and how the artwork affects them.
| + | |
| − | * [http://www.ericchadwick.com/examples/provost/byf2.html Beautiful, Yet Friendly Part 2: Maximizing Efficiency] article by Guillaume Provost<<BR>>The article continues with tips on how to create efficient meshes.
| + | |
| − | * [[Framerate Optimization Tips]] from [http://www.warbeast.de/ Soenke Christian 'warby' Seidel]<<BR>>A rundown of the best methods for improving the framerate for your game art.
| + | |
| − | | + | |
| − | ----
| + | |
| − | [[Category:CharacterModeling]] [[Category:EnvironmentModeling]] [[Category:Rendering]]
| + | |
