Game Asset Design and Performance.

Mr_Fulano used Ask the Experts™
I have a question regarding performance and how game engines handle mesh objects. – For the purpose of this question, let’s assume we have a wall asset within a game. If we make our wall 10 feet tall and 100 feet long, we have a rectangle, which can be made up of two large triangles.

So, our first example is a wall that is 10 feet tall X 100 feet long and is made up of 2 triangles.

Let’s now assume we broke up that same wall into smaller 10 foot sections (i.e. 10 feet tall X 10 feet long each).

So, in our second example we have our 100 foot long wall made up of 10 individual sections, which are each 10' x 10' made up or 2 triangles each, so our 100 foot wall now contains 20 triangles.

In recap:
Example 1 = A wall, 10 feet tall X 100 feet long and is made up of 2 triangles.

Example 2 = A wall made up of 10 sections, each at 10 feet tall x10 feet long and each section is made up or 2 triangles, so our wall has a total of 20 triangles.

My question is which of these designs approaches to our wall is more memory intensive for the game engine to deliver to the scene?

Is it more expensive (in terms of memory resources) to draw 2 very large triangles. Or, is it more expensive to draw 20 much smaller triangles?

Or are they equivalent…after all, we’re producing the same asset which is 10 feet tall and 100 feet long? The only difference is that in one instance we're drawing 2 huge triangles and in the other we're drawing 20 much smaller triangles. Can we assume each triangle is 1 "draw-call"? Or is that something totally different?

Although this may seem somewhat academic in terms of "one wall", it can add up when you're producing "modular" assets for a city scene or for a large office building scene or modular asset.

Thank you,
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Fulano I'm not much of an expert on 3D rendering, but I think you're confusing two concepts.

For memory usage, you want to think in terms of "textures" - which basically means a bitmap image.  Those are loaded into the GPU and will consume memory.  The more detail in the image (the more pixels) the more memory required.

Once you have the texture loaded, then you can issue draw calls to render that texture somewhere on the screen - e.g. onto your wall made up of 2 triangles.

If you take the texture and render it 20 times or 2 times, it's the same memory usage.  But rendering 20 smaller images may require more CPU/GPU time because there's more draw calls.

Also you can take one texture and stretch it during the drawing.  Let's imagine your wall is flat - so we'll ignore any 3D rotations etc.  If the wall was 1000 pixels x 1000 pixels on the user's screen and your texture was 100 pixels x 100 pixels, then you could:
a) Stretch the texture 10x10 to cover the entire wall (1 draw call, no extra memory)
b) Render the texture at 1:1 and draw it 100 times to cover the entire wall (100 draw calls, no extra memory)

(b) will take more time, but also look a lot better (a lot higher res) than (a) which is a stretched texture (so it'll look blurry on screen).

If you want approach (a) to look as good as (b) - you could also load a texture that's 100 times as big (1000 pixels x 1000 pixels) and render that directly without stretching it (1 draw call, 100 times the memory).

At least that's my take on how this works.

Hope that helps a bit,



Hi Doug, thank you for the very detailed explanation. Perhaps I am a bit confused, because I always thought that poly count had a huge impact on performance. I understand that painting the different textures have an impact, but I was always under the impression that drawing the geometry over and over, frame by frame, taxied the system's resources tremendously, so that's the origin of my question. I do recognize that this is a difficult question to answer, because a lot of developers don't get too deeply interested about the dynamics of how the game engine does what it does, but rather simply work with a set of industry supported rules of thumb.

Thanks for the very good info.
I think lots of polygons tends to mean lots of separate draw calls - so definitely taxes the system resources, but not really the system memory (there would be some for storing the mesh but that should be just 3 points per triangle rather than a lot of image data).

It's sort of the old CPU vs RAM tradeoff that we're used to in many other parts of computing.  And also in this case quality vs speed.  (Higher polygons -> higher quality, but lower speed).

So definitely important to consider, but I think it's more about CPU cycles (or GPU cycles) rather than memory in this case.  Both are of course a limited resource and their use should be considered carefully.

OWASP Proactive Controls

Learn the most important control and control categories that every architect and developer should include in their projects.


Thanks Doug, you have very valid points, but let's put aside the concepts of poly count and draw calls and go back to my basic question. Would it be "better" to have a wall with 2 large triangles or 20 smaller ones if the wall is made up of a modular composition?
From a purely technical standpoint, the larger wall is more efficient. Its hard to describe why with your example because neither scenario present a situation that would stress the engine or hardware.

So lets say you have your game running on a mobile device thats a few generations old and pretty slow. A scene where it loads a giant wall, there is only only three faces it has to draw with large single wall with two triangles (assuming the angle of the camera sees top, and two sides, if you figure out how to see more sides than that let me know). However the wall made up of many objects will have more faces to render, and therefore tax it more. Alternatively, there would be almost no difference in the large single wall with 2 triangles or 20, but of course, at a certain point increasing the mesh polly count to a drastic degree would eventually make a performance hit.


Hi Ben, I think you're correct. I agree with your analysis. In the end, there are going to be more draw calls and more performance impacts on the 20 smaller segments than the larger 2 segments.

Both you and Doug presented a very good analysis and I think both addressed my concerns. I think the only other thing I could do is create two very simple scenes in my game and fill one with the 20X version of the wall and the other with the larger version of the wall and see if it would have any impact whatsoever, but my machine is so powerful in terms of hardware, that I may not see anything at all. Trying it on a much weaker machine would probably be the only way I can figure that out.

Thank you both for your great help.


Great job to you both!

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial