7 Myths in Modeling for Games

#1 - Assets are measured in 'polycount'.

This is one of the most common inaccuracies in circulation. 'Polycount' is an ambiguous label associated with all types of ngons. However, GPU's only render triangles. Since game engines use the GPU to render most meshes, triangle count is the only quantity that game developers care about. Don't worry though! Your 30k quad mesh will be automatically triangulated by the game engine so you don't have to.

So, if you have a mesh that's made of 1 hexagon, it could have a polycount of 1, but will actually have a tri-count of 6. Here's an example:

From left to right our polygon counts are: 1, 32, and 64.

But our triangle counts are: 32, 32, and 128.

Important to remember, but less of an issue than you think. As you'll see in the next section...

#2 - There's a hard-limit to amount of geometry for models.

And this is the most common question that I hear, largely attributed to game development before the early 00's. Back then video RAM (VRAM) was very limited and tricks were created to help fake topology. These are widely used today (baking normals, retopologizing, decimation, etc...). But these days...

Yes, my 6GB GTX 1060 is real-time rendering 4.3 million triangles at 84 frames per second in-engine. We could triple that number and still run around the same speed. The number of draw calls is MUCH more of a limitation these days than the number of triangles. As long as you have clean purposeful topology and generate level-of-detail (LOD) meshes in-engine, you can be as hi-poly as you'd like.

#3 - All models need to be baked and uniquely textured.

This one is really dependent on your studio's asset pipeline. However it's quite inefficient to have per-asset textures for every model in a game. All that time you're spending in Substance Painter and Photoshop working on your models isn't as important as you think for game assets. Instead, efficient pipelines create a "Material Library" with high-fidelity maps for common types of materials (plastic, wood, chrome, rust, etc...). Your job as a modeler will be separating your mesh into different materials, while being as conservative as possible. Later on, optimizations can be made to use low-res masks to separate the materials.

This also does away with baked normal maps, since they're per-asset and typically the largest textures in a PBR workflow.

For indie studios, file size is close to as important as performance. This is because all of the textures will need to be stored somewhere and shared in source control (click here to learn about the best source control methods in game dev). Per-asset textures bloat file-size like nothing else.

Here is an example of a chair with 2 materials that each have tiled (infinite resolution) textures:

#4 - Modelers don't need to worry about lighting.

If you ever plan on getting into 3d games, there's one thing you should start mastering immediately...


Lightmaps tell a game engine how to bake in-engine static light onto a model. Your job as a modeler is unwrapping UVs to a Lightmap channel. This channel is usually the second UV channel for a mesh.

Before 2012 our modelers were baking light in their modeling software for static scenes and we were using those maps in-engine. Things have come a long way...

Most popular game engines today have a way to generate passable Lightmap UVs for you if your color UVs are compatible. But still as a modeler you probably don't want "passable" models, so start looking into creating your own Lightmaps asap. More on Lightmaps here.

#5 - Everything can be exported as-is.

Modeling is just one cog of the game development wheel. Assets need to be created uniformly to make changes easier later on. As such, there are some big things that need to happen after you think your model is finished.

It needs to be separated into any pieces that will move independently in-game, renamed to follow naming conventions, the origin needs to be set to the pivot point and centered on the grid, materials assigned as needed to the faces, color and lightmap UVs created, export settings customized for the game engine, and more.

Say you have an entire house you've put together in your modeling software.

First off, if the player will go inside, or even get close to it...it should probably be broken into smaller assets so that it can be LOD'd and occlusion/frustum culled more efficiently.

Next, each piece will need to be moved to center it's pivot point on the grid, so a door's pivot point will be on the ground centered inside the hinge.

Then you'll need to make sure the UV layouts will work and export with correct naming conventions and settings.

Here are some utensils ready to be exported individually:

#6 - Modelers only need to work in their modeling software.

At the AAA level, where job responsibilities are very compartmentalized...modelers still will need to know how to interact with source control, 3rd party plug-ins, project management software, and most importantly...know how to communicate. If you're working for a studio that adheres to agile development methodologies, you'll be communicating more than modeling since there's a heavy focus on iterations and testing.

But at the Indie level, it's commonplace to have modelers wear several hats on the team. Our studio has 2 fantastic modelers, divided by Organics and Hard Surfaces. The organic modeler also does skinning, rigging, texturing, and occasionally some animating. The hard surface modeler also does level design, game design, texturing, and occasionally some tech art. They both use our game engine.

Having knowledge in many different programs and disciplines facilitates effective work as a team member.

#7 - Modelers are a dime a dozen these days.

We've worked with around 6 different modelers here at Sonder since the studio was created, but we've probably looked through over a thousand modeling portfolios on ArtStation, DeviantArt, Behance, Instagram, College websites, Discord channels, and more.

You're right, there are a ton of people getting into modeling these days with a lower entry cost (free programs like Blender), and cheaper/better hardware becoming more commonplace. Still, great modelers are incredibly rare.

You don't need the best topology or renders to be a great modeler. You need a passion for 3d and games in general, the ability to communicate and take criticism, the curiosity to learn more, and the work ethic to take your assets to completion.

Featured Posts
Recent Posts
Search By Tags
No tags yet.
Follow Us
  • Facebook Basic Square
  • Twitter Basic Square
  • Google+ Basic Square