Polygon count

expression refering to the number of polygons in a three-dimensional image, which effects how smooth the image appears to be, how quickly it can be rendered, and how long it will take the computer to redraw it, as part of a game or other interactive application. usually, the polygons are triangles, since this is the most flexible type (you can make a square out of two triangles, but it would take a lot of little squares to make a convincing triangle).

polygon count is generally lower for objects with flat surfaces than it is for objects with curved surfaces (see nurbs for more information about creating organic shapes). this is because a curve is approximated by subdividing triangles, creating a lot of small triangles for the application to keep track of. it's a pretty simple concept (illustrated in 2d because i don't have the patience to try and approximate 3d in ascii):

                                 /\                                          /\
                                /  \                                        /__\
                               /    \                                      /\  /\
                              /______\                                    /__\/__\
 
                              triangle..                                subdivided.

so in a 2d example, polygon count increases by a factor of 4. of course, it increases much more quickly in three dimensions.

whether the emphasis is on low polygon count or smoothness depends on the purpose of the graphics being created. it is a trade-off and finding a happy medium can be a complicated task. anyone who has used vrml or any virtual reality application has probably seen that objects tend to be more jagged than in a sophisticated 3d computer game, and anyone who has seen gerrie's game or other 3d film will have noticed how incomperable the graphics in games are to the graphics in a movie. obviously, how complex an object can be depends on how quickly graphics need to be rendered. in an interactive game where users can move objects around, the computer may be asked to redraw any object, from any angle, at any scale. in a game with fixed graphics, the user will approach objects, but other than the scale their appearance will remain more or less the same. for a movie, the only 'users' can take quite a bit of time waiting for objects to be rendered, making a low polygon count much less important.

Heh. I created this nodeshell, started to fill it, and then I was drawn elsewhere and stuck it on my to do list. I'm not sure exactly what I was going to write, but it went something like this...

Polygon Count: What some game companies are more concerned about than actually making a cool game that people will want to play. I keep hearing about how great some game engine is, and how anyone with a $300 graphics card featuring the GeForce chip is going to be wowed by the incredible realism brought to you by 12 million polygons, all with incredible anti-aliasing, bathed in 24-bit colored light, all on the screen at the same time.

What I never seem to hear nowadays is that the programmers of some hot new game have realized that polygonal-based 3D games do not look realistic at all, and they won't look realistic for a long time, so rather than spend more money on the game engine than it took to build the Petronas Towers, they've decided to focus on gameplay and storyline to make an exciting game with actual replay value.

Imagine that.