Where is the overhead in very low poly static mesh components?

Development Platform & Builds Debugging, Optimization, & Profiling
, ,
1

I have one BP actor that is spawning off many, sometimes thousands, of static mesh components. They are not instances, because I eventually may want to modify materials individually, but they are all very low poly. Less than 200 polys per. So even a few thousand should be, on a tri count level, very easy to handle.

However, in one stress test I had 1200 of them and was noticing a rather large slowdown on my machine, which worried me because I have a rather powerful machine. I tried turning collision on the components off, but that made zero difference.

Other than the actual polygon count what would be the overhead in lots of components?

I7-4770k @ 3.5, 16GB RAM, GTX 980ti, Windows 10x64. In the editor without any components, I am capped at 120fps (not sure why but no worries right now). At 331 components I am at roughly 110fps. At 720 I am at 60fps. At 1,261 components I am down to 33fps

2

Draw calls are expensive. Each single non instanced mesh component requires its own draw call which causes CPU overhead.

What you’re experiencing is the reason why Mantle and DX 12 are developed to have less CPU overhead.

3

I’m hitting that limit already? That seems odd. Having a few thousand objects in a game doesn’t sound very high at all.

4

Two thousand draw calls is a shitton of them. DICE developed BF 3 so that they stayed below 1000.

5

Hmm… Well I need to render individual segments of a large game board, as well as movable pieces on top of said board. Due to user input each segment of the board can change color, so I can’t use an instance for that. I might be able to work out some clever method of using instances but swapping out to a non-instance when needed.

6

Have you considered using an instanced materials along with instanced mesh? Also with that many objects moving all at once using a texture atlas is worth considering.

Overall though materials is the big hit and more so if it has to react to environmental changes like reflections in real time.

Also something to consider is FPS running a benchmark inside the PIE is not the ideal if you are also running development applications in the background.

To get a better idea of what is actually causing the hit best practice would be to compile the environment as stand alone, shut down all back ground applications, and generate a profile. Or use the GPU profiler

You can then play back the profile and see in real time what’s causing the performance hit. Zak also did a tech video on how to load and performance test your map but I could not find it so something to search for.

7

Each mesh counts as a draw call, each material on the mesh counts as a draw call, so if the mesh has a single material then it’s 2 draw calls.

8

Thanks for the comments. I don’t know much about how instanced materials work, IE where they are better than normal materials, but I will take a look into them. As for profiling, yeah I have a couple pages bookmarked to read over this weekend. Definitely want to dig into that.

9

Yes instanced materials is the companion to instanced mesh in decreasing the performance hit. You can have as many variations as you wish as an instanced but because it’s a procedural material it’s still equal to a single draw call no matter how many variations you make.