I'm surprised to find that each mesh takes at least 5-6 MB,

how can a 3D game be so fluent when there are hundreds of models?

I'm expecting it will simply go out of memory or something else that makes the game un-playable..

What's the trick employed here?

  • 1
    \$\begingroup\$ Can you link to the source of that "5-6 MB" number? Knowing the context of that would help explain things. \$\endgroup\$ Commented Jul 26, 2012 at 3:30
  • \$\begingroup\$ @Nathan Reed ,I downloaded several mesh myself online,each of them is at least 5-6 MB... \$\endgroup\$ Commented Jul 26, 2012 at 3:38

4 Answers 4


There are tons of tricks developers use to get the maximum out of their art assets.

Optimizing models

The first is to optimize for polycount. Here's a great example:


When you look at the texture model, it looks amazing detailed with probably like a million triangles. But the truth is, it only has the polygons shown on the right! In this case, an artist used the following process:

  • Build an amazingly detailed demon model in Maya, 3DS Max or Blender. We're talking a million or more polygons.
  • She reduces the amount of polygons in the model to a more reasonable size, like 400 or so, and saves it to a new file.
  • Finally, she uses a package to generate a normal map from the million-polygon model and puts it on the reduced detail model.
  • Alternatively, she uses ZBrush to "sculpt" the normals for the model.

There is also tons of detail being added using just the diffuse texture.

Batching and instancing

Others have touched upon this, but it's very true. If you're going to render the same tree model hundreds of times, it makes no sense to load it into memory a hundred times. It's better to load it into memory once and render it at different positions.

Here's a great article on that: http://blog.wolfire.com/2009/11/Fast-object-instancing

Reduced level-of-detail

For our space RTS, we actually had multiple representations for our ships:

  • Very far away - icons. No model or anything, just a small icon to show the position of a ship on the map.

  • Far away - small ship. These ships had about 100 triangles each. But even at that reduced scale, it doesn't matter. At that range, all you really care about is that the outline of the model stays the same.

  • Near - big ship. These are the base models. Each had about 2000 triangles, with a diffuse map, normal map, specular map and glow map. Shaders became more expensive (alpha pass, glow pass) and particles were turned on.

Occlusion culling

This is a topic of research that is increasingly becoming more important. The basic idea is: why render something that is drawn behind something else? However, the intricacies can become quite complicated.

The most common approach is to label certain objects as "occluders". The rendering then happens in stages:

  • First, the occluders are rendered into a depth buffer without textures or shaders.

  • Objects compare themselves to this buffer, if they're behind it they don't get drawn.

  • Objects that are still in view are rendered with textures and shaders.

A very simple approach to occlusion culling could be: "don't render anything that isn't in the camera's view frustum". Objects check if they're inside the camera's view frustum (the box that defines the camera's transformation of the world to the screen) and if they are, they're added to a list of objects to render.


Finally, the mother of all memory savings: chunking. If you're playing in a large open world, it makes no sense to load everything into memory at once. Especially on platforms like the Xbox 360 and the PS3, where memory is worth its weight in gold. So a solution could be to divide your level into chunks.

When you turn a corner in an FPS game, the next section is loaded while the old one is thrown away. However, this affects the level design greatly and basically ensures corridors everywhere. There's also no silver bullet: what works for a game like Just Cause 2 doesn't work at all for a game like Fable 3.


For any game, you should look at what's important to you. If you're on PC, you don't have to care about memory that much. Most gaming rigs these days will have at least 2 GB of memory and 1 GB of video memory. That's a lot of models and textures! Keep in mind that any optimization you make for memory will usually have a price for processing. If you compress your textures to PNG for example, your files will be smaller than BMP images, but they'll take longer to load.


If you downloaded a model from an online source, it is most likely not in an optimized format. It will be in a format designed for use in a 3D modeling program, which may be much larger than the optimized/compressed mesh data that will eventually be sent to the game engine (usually generated by the game's level builder or other workflow tools). If the downloaded package includes textures, those also might not be compressed as aggressively as they would be for the final game data.


This is just 5-6 MB of GPU memory (textures, vertices or indices, does not really matter). With an average 256mb you can load dozens of such models into GPURAM. When model is rendered for more than 1 time it's usually just instanced (e.g. 12 identical cars in a racing game you see at once are rendered from 1 model with just color/position changed). And usually only player objects are fine detailed, with the rest of the scene using less details per unit of rendered surface.

Now, GPUs are very good at what they are designed to do - rendering tons of textured/shaded/transformed polygons. No wonder typical scenes can have million of polygons and few hundreds of megabytes of textures.

Optimizations kick in as well - when you cant see full-resolution texture it is rendered in smaller resolution (mipmaping + anisotropic filtering make it almost unnoticeable). Every model that is too far away is rendered in lower details (LOD). When you play MMO games only things that are in reach are loaded/rendered, everything else gets streamed when you get closer to it. Thats how 20gb WoW works.

P.S. In my experience with circuit racing games typical car models were 0.5-16mb. 8 per race. Scenery being another 30mb. Scenery objects were 5-10mb. HUD - another 5mb. Sound and everything else another 5mb. All-n-all just some 60-120mb. And you could cut that size by half just by switching to lower res textures.


The trick employed in making a 3D game with hundreds of models run smoothly despite each mesh taking at least 5-6 MB is a combination of various optimization techniques.

i mean developers utilize strategies such as optimizing models by reducing polygon count and using normal maps, batching and instancing to render multiple instances of the same object efficiently, employing reduced level-of-detail representations for distant objects, implementing occlusion culling to avoid rendering objects that are not visible, and utilizing chunking to load and unload game sections dynamically.

These techniques help manage memory usage, reduce processing requirements, and ensure that the game maintains a high level of performance while still delivering visually appealing content. It's important to strike a balance between memory optimization and processing efficiency based on the target platform and specific game requirements.

If you want to research more about 3d modeling for games, remember to verify the credibility and expertise of the sources you come across and cross-reference information from multiple reputable sources to ensure accuracy and relevance to your specific needs.

Actually I recommend some game development forums (you can find it by yourself)

  • 2
    \$\begingroup\$ This answer seems to mostly just paraphrase and summarize content present in the existing answers. What new information do you want to share here? try to focus on just the new part. \$\endgroup\$
    – DMGregory
    Commented Jun 17, 2023 at 12:46

You must log in to answer this question.

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