1
\$\begingroup\$

It is always said that the polygon amount of a single modell must be as little as possible when it comes to realtime simulations such as computer games. (Or at least lower than when rendering a movie) I am fully aware that this must be done in order to save performance. But aside from that information i cannot find why huge polygon amounts must be avoided.

(In Short: I know that polygons eat performance. I want to know why they eat performance)

So my question would be: What happens when a frame is rendered? The polygons are surely somehow processed in the graphicard. What happens there?. If possible i would like to have some links to sites containig this information.

\$\endgroup\$
1
  • 1
    \$\begingroup\$ related tangent: The importance of polycounts has changed drastically since I first started, and I still sometimes forget that. Graphics cards manufacturers have focused so much on optimizing polygon throughput that the polygons are rarely the bottleneck these days; more likely problems are texture fillrate or texture passes. I still remember when I first learned that the PS2 didn't do backface culling, because on that chip it was faster to simply render all the polygons than to calculate which ones to cull. \$\endgroup\$
    – jhocking
    Aug 27, 2014 at 14:47

3 Answers 3

5
\$\begingroup\$

Whenever a frame is rendered, your graphic card must translate the coordinate in 3-dimensional space of every polygon corner (aka vertex) to the two-dimensional space on the monitor. This is done by multiplying each vertex with a projection matrix which represents the current position, angle and field-of-view of the camera.

Only after this is done, the graphic card knows which polygons are actually on the screen and not behind the camera or hidden behind other polygons. It then processes with various other calculations for each on-screen polygon, like which texture it is showing and how it is lit.

That means your graphic card must perform a number of calculations for each polygon. The more polygons you have, the more does it have to calculate. Your graphic card can only perform a limited amount of calculations per second, so more polygons means a lower framerate.

\$\endgroup\$
6
  • \$\begingroup\$ Ahh thank you very much. Do you have by any chance a link to a source? I am currently writing a thesis... I dont think giving a stackExchange site as source is very brilliant :) \$\endgroup\$
    – zetain
    Aug 27, 2014 at 12:16
  • 5
    \$\begingroup\$ @zentain I would be honored to work as a research assistant for you. How much do you pay per hour? \$\endgroup\$
    – Philipp
    Aug 27, 2014 at 12:17
  • 1
    \$\begingroup\$ The honor is completly on my side. No, really i got the hint. :D \$\endgroup\$
    – zetain
    Aug 27, 2014 at 12:48
  • \$\begingroup\$ You might also consider adding that in lower poly scenarios, the mesh can be used for collision detection, which also becomes prohibitively expensive as the poly count increases. \$\endgroup\$
    – lase
    Aug 27, 2014 at 14:37
  • \$\begingroup\$ Good answer: just wanted to note that by using space partitioning techniques you can reject a lot of polygons/models early. However, you have to implement this yourself. \$\endgroup\$
    – Roy T.
    Aug 29, 2014 at 9:01
1
\$\begingroup\$

Like Phillip said one should always optimize your models for a specific goal. That said, i want to add some extra info on the creation of 3D models. Nowadays the polygons are not the bottleneck but texture space is. Since we bake so much into the texture for details (think: Diffuse, normal, occlusion, light, etc) and a top notch graphics card can only store 1GB of textures.

When an 3D object is close to the view it can takes up most of the screen which can be perhaps 1920x1280 pixels. If that single object has a 1024x1024 texture that texture is only partially seen since you only see a part of the object. So maybe 512x512 of that texture is actually seen, this gets translated to you screen resolution and thus blurred. 4 1024x1024 textures for a single object (different map types) can easily take up 10MB. Where someone rather uses a 2048x2048 texture space or larger for this object but that will take up about 40MB which would already be 4% from the GDDR memory of a graphics card with 1GB of memory. And that just for a smallish object in a scene of thousands. Besides this map and CG designers have plenty of tricks up there sleeves for reusing objects and textures.

Still, less polygons means better performance. And since we can do so much with texture space 3D artists focus on contour (the outline of the model). It's not possible to make the outline of a model more detailed without adding more polygons, within a model we can use textures to make just a couple of polygons look as detailed as thousands.

\$\endgroup\$
1
\$\begingroup\$

Increasing polygon count has performance impact in few key areas:

  1. There is a limit that GPU can issue new triangles (e.g. 4 per clock), normally 1 per Shader Engine (AMD) / Graphics Processing Cluster (NVIDIA). If your GPU runs at 1GHz and has 4 SE's/GPC's that puts absolute peak limit of 4 billion triangles per second on the GPU - normally not a bottleneck.
  2. GPU must run vertex shader for each vertex of each triangle, so heavier the shader more costly the geometry processing. There is post-transform LRU cache which remembers some number of previously processed vertices (GPU specific but it's somewhere around 32) that are shared between triangles to reduce processing cost (for indexed primitives) so it's important to optimize index buffer for this cache.
  3. The data for vertices that are processed by vertex shader must be fetched from GPU memory, and there is pre-transform cache helping to reduce the bandwidth usage. The data is fetched as cache lines (e.g. 64 byte chunks) thus it's good if the vertex data is aligned to cache lines to reduce bandwidth usage. E.g. vertex size 28 is worse than 32 because some vertices require 2 cachelines being fetched from memory. Also the pre-transform cache is motivation to reorganize vertex data to be accessed more locally, if your vertex size is smaller than cacheline (or unaligned).
  4. When you increase polygon count of a model you also reduce the triangle size. This has a negative impact on pixel processing performance because GPU's don't process individual pixels but pixel quads of 2x2 pixels. Now pixels in the quad that are outside the rasterized triangle are rejected which wastes processing power. This is a performance issue for objects with a lot of microtriangles and may result up to 75% waste in pixel processing.
\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .