Low-Polygon Levels That Look Amazing: A Primer in Model-Building Efficiency

Google+ Pinterest LinkedIn Tumblr +

Yes, today’s high-end PCs can handle upwards of a million polygons in realtime 3d.  However, there are some very compelling reasons not to make game levels with huge polygon counts.

-Framerate and playability.  The more lean and efficient your models, the more smooth your framerate, the more playable your game, and the faster levels load.

-Production expense and economics.  Aiming for the next-gen PCs and having photoreal graphics may seem cool, but the more complex the level, the more work it’ll take to complete it, and the higher the production cost per level.  Not only will costs increase, but potential audiences will be diminished.  A lot of people still have old computers, and it’s worth noting that console games are a huge market – and that the console platforms around now (Xbox 360, Wii, PS3) are aging badly; they’re half a decade old now… which means that geometry is still at a premium there.

-The portable gaming market.  PSP, DS, iPhone, Android… there are now a lot of people playing games on little handheld devices which, typically, can’t handle more than 10-25,000 polygons in a level.  This is comparable processing cability to desktop PCs in the year 2000 – and if you’re going for the booming handheld market, efficient geometry becomes even more critical than it is for console gaming.

-Bigger levels, better levels.  The more efficient your models, the more models and the more “Stuff” you can run in a single level.

So, if you’re in agreement with me that there are reasons why polygon count may need to be minimized, how do you go about doing that in practice?

Here are some tips:

-Delete any bit of geometry that players will not see.  There is no reason to model the bottom surfaces of an object that is attached to the floor, nor is there cause to make double-sided polygons when only one side will be seen.

-Textures need only be high enough resolution to look good.  If there’s an object which is far away, or small, it does not need a high-resolution texture.  Textures should be efficient, just like the models they’re mapped onto.

-Textures can be used to fake geometric detail where there isn’t any.  Transparency maps, bump maps, and normal maps are wonderful things.  Learn how to use them to suggest complex surfaces where there aren’t any.  A classic example is foliage; a few simple planes with an opacity map are all the geometry needed to create a bush or tree or patch of grass…

-Bake lighting.  If the light doesn’t need to move, bake the lighting into the texture itself, rather than having a dynamic light in the scene.  This saves a ton of real-time processing.

-Invisible collision meshes.  Physics simulation, when done on highly complex level geometry, can slow computers to a crawl.  Instead of using the level geometry as your collision mesh, try blocking out a very simplified separate invisible mesh of the level and using that as your collision mesh.  This alone can improve framerate greatly.

-Keep polygons triangular, and texture resolutions in multiples of 2.  (i.e. 256×512, 128×128, etc) This is a convention in realtime level design because it is more efficient, and – aside from that – some game engines actually require you to do this.

-Occlusion culling is useful.  If you use it, any piece of geometry which is blocked by other geometry, is not rendered.  This improves framerate greatly, especially in twisty levels where you can’t see the whole area of the level from any one position.

All of these are, I hope, good pieces of advice which you can use in your own mods and levels.  Creative and clever use of geometry and textures can be combined to form models which appear enormously detailed but which run very smoothly.


About Author

Leave A Reply