Performance Art 3: Polygons don't matter.

As next gen technology came online, people started repeating this mantra:  "Polygons don't matter anymore."  For the longest time (okay, about a week) I was stuck thinking, "Awesome, we can throw any amount of geometry at the new cards and they'll just handle it.  Sweet!"  The part that the infamous "they" left off of that Mantra was: "...vertices do!"

So polygons don't matter anymore.  That is absolutely true.  However vertices do.  They matter absolutely.  Here's a handy little excercise to see what I mean by this.  Open up 3ds Max or Gmax (or follow along in your mind).  Create a box.  Convert it to an editable mesh and apply a UVW Unwrap modifier.  Collapse it back to a mesh and type in "getNumTverts $" in the Max Script listener window.  In the listener output window, you should see the number 8 appear.  That means it has 8 texture vertices.  That makes sense, 8 physical vertices and 8 texture vertices, right?  Now apply a UVW Map modifier to the box and choose "face" as the mapping type.  Collapse it back to a mesh and type in "getNumTverts $" in the Max Script listener. You should now see the number 36 appear in the listener output.  Huh?  36 texture vertices on a simple box?  This is because any texture vertex that is not welded gets duplicated.  That happens in the game as well.  It also happens for shading groups.  We do do some optimization and welding when we convert the geometry to a model, however any hard edge in the UVW Mapping will always cause a split in vertices.

So what this means is that even though your polygon count may be low, your vertex count may be sky high.  Like I said, we do optimize pretty heavily on export, but we can't catch every case and if the model is authored poorly from the start (completely unique texture vertices for all the faces for example) you can wind up with four times as many vertices as you intended.

So why does the vertex count matter?  Well, because all of the geometry is put onto the graphics card via vertex streams and vertex buffers.  A vertex buffer is basically 64k, which translates to ~64,000 vertices stored per buffer.  Every buffer is a single draw call.  Sometimes we fill the buffer up all the way, sometimes we don't (bad batching).  However, let's assume the best case scenario and imagine that we are batching everything perfectly.  We create a building that we wan't to appear in a scene 1,000 times.  That building has 1000 polygons.  Okay, that's a little high, but not bad for a high-detailed model.  But due to poor modeling, UVing and smoothing, the building actually has 2400 vertices in it.  64,000 / 2400 = 26 buildings per draw call.  1000 / 26 = 38.4 or 39 draw calls for those buildings.  Even though it's a perfect batch and a perfect scenario, we still require 39 draw calls for that single building 1000 times.  Let's imagine that the building was well authored and optimized and actually only had 1200 vertices in it (a more reasonable scenario).  64,000 / 1200 = 53 buildings per draw call.  1000 / 53 = 18.8 or 19 draw calls.  That's a pretty significant reduction. Especially if you have 200 variations of buildings you want to draw (200 * 39 = 7800 draw calls, 200 * 19 = 3800 draw calls).  These are all still excessive numbers, but you get the point (and also can see how creating high-polygon models with bad vertex optimization can kill the framerate quick).

So what can we do about this?  The first thing to do is author good models.  Yes we have our fair share of bad models.  As I said, we've got legacy that we just can't update every release, so we chip away at it release by release.  Make sure your smoothing groups are used wisely.  If it's a rounded object, 1 smoothing group may do.  If it's not, try to create as few smoothing groups as makes sense.  Also, weld your texture vertices and align and overlap things as much as possible.  If you have two faces overlapping in the UV space, make sure the common verts are welded.  Also, try to UV things as contiguously as possible.  If you are creating a building, create one seam on it and have all four faces lined consecutively on the texture sheet (like splitting a cylinder and flattening it out).  If the front and back and sides are identical, then make sure to weld all of the overlapping vertices.  Like I said, we do perform some automatic welding when threshholds are close, but if they aren't close in the first place, then we can't weld them.

The second thing to do is batch up parts of models when possible.  If you have several buildings with the same window type, batch up those windows with the same texture and the same material.  Since they're small in vertex count, they will all likely fit into a single draw call.  So rather than have 1200 vertex buildings that cause 19 draw calls, create smaller groups that can batch up smartly.  1 draw call for windows, 1 draw call for doors, 1 draw call for awnings and then 1 draw call for the simple building geometry that is left.  As the material batching comes online, this will be much easier to do.  But it's good practice to start thinking about this now.

Comments

• Anonymous
  January 01, 2003
  You are correct, the max specular power from a map is 256 (white) and the max specular power from the level spinner is 999.  We discovered this too late in the development cycle to change it and create havoc with all the content we had already made. Additionally, because the normal is calculated into the specular hotspot, you can only get it so small.  What starts happening beyond a certain power term (I used a hard-coded 1000.0 in the shader), is that the specular hotspot is so small it breaks into sub-pixel sparkling. Things to consider:

1.  The larger and flatter the surface normal, the bigger the hotspot.  Try breaking up the normal with normal maps or smaller, more rounded polygon subdivisions.
2.  The fresnel ramp is multiplicative, so it can only darken specular highlights.  We way overused this.  I wouldn't recommend using fresnel on specular unless you want to do a funky two-toned paint scheme or really tint the specular highlight.

• Anonymous
  January 01, 2003
  Of course every designer has read the excellent blog posts by Adrian Woods on how to optimize your performance

• Anonymous
  August 29, 2007
  Interesting stuff, Torgo. But using spec maps has one problem: You can't get a small enough highlight to get a glossy looking surface. Here's a test I did: In 3DS Max, I cranked up the Specular Color chip to full white, and Specular Level to 999 (the maximum). Then I turned up the Specular Map Power scale to the max - 256. I then gave the matl a specular map that had full white in the RGB channel, and full white in the alpha as well. With these settings, I presume I should be getting the smallest, brightest possible specular hilight - suitable for a glossy object. But the hilight is too big, and doesn't look convincing. If I then get rid of the specular map, the hilights become much smaller - and much more convincing (though they would look better if they were smaller and brighter still). So, two questions: 1.) Am I right in thinking that you can't get as small a highlight when using a spec map as you can without one, or am I missing a trick here? 2.) Why doesn't the exporter allow realistic highlights for glossy objects - that is, very small and very bright? Even in the tests I did without a spec map, the highlights aren't as small and bright as they would be in the real world. Is this just an oversight in the way the exporter is designed, or is it not technically possible to go smaller and brighter?

• Anonymous
  December 22, 2008
  Great stuff here, I'm getting into this performance issue. It would be nice if you have some pictures that being explained along with texts.  Some parts are quite hard to imagine.