1
\$\begingroup\$

I have the following problem: The levels in my game are made up of a Large Quantity of small Models and because of that I am experiencing frame rate problems. I already did some research and came to the conclusion that the amount of draw calls I am making must be the root of my problems.

I've looked around for a while now and couldn't quite find a satisfying solution. I can't cull any of those models, in a worst case scenario there could be 1000 of them visible at the same time.

I also looked at Hardware geometry Instancing, but I don't think that's quite what I'm looking for, because the level consists of a lot of different parts.

So, what I'd like to do is combining 100 or 200 of these Models into a single large one and draw it as a whole 'chunk'. The whole geometry is static so it wouldn't have to be changed after combining, but different parts of it would have to use different textures (I think I can accomplish that with a texture atlas). But I have no idea how to to that, so does anybody have any suggestions?

\$\endgroup\$

2 Answers 2

2
\$\begingroup\$

You basically answered the question for yourself.

Performance issues caused by too many draw calls can be solved by chunking together the different geometry sections. Also, you must chunk together your textures (atlasing) and modify the UV coordinates of each model to correctly index the smaller texture inside the atlas. Ideally this would happen inside your tool chain, but if it's just a hobby project, you might as well do it at load time.

Alternatively, an easier solution if your small models already share the same textures is to sort your draw calls by textures. Thus avoiding extraneous texture switches.

\$\endgroup\$
1
  • \$\begingroup\$ I solved it now. At first I tried the chunking approach, but then I quickly realized even tough I had a lot of different models, I'd be far better of if I just did a lot of instancing instead of baking everything into on large model. So now in level generation I have the game check which models will be used by the level, instance those and then go full rambo and just cram the whole level architecture into a few vertex buffers. While playing the whole level is now drawn at once. This might be a rather brute way of doing it, but for me it's working. Thanks for the answer :) \$\endgroup\$ Commented Nov 19, 2012 at 20:38
0
\$\begingroup\$

If you have so many models, they will be small - and if they are small and far away, maybe they can be replaced with billboards. Only two triangles for a model is much faster to draw..

\$\endgroup\$
2
  • \$\begingroup\$ While that may be true for some cases (like when the player is very high up and is watching the level from above), no I'm afraid most of the time the models won't be small enough to justify billboarding. Nonetheless, thanks for your answer :) \$\endgroup\$ Commented Nov 18, 2012 at 22:16
  • \$\begingroup\$ Also I'm 99% sure it's not the amount of triangles, but the amount of draw calls that is killing my performance. \$\endgroup\$ Commented Nov 18, 2012 at 22:36

You must log in to answer this question.

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