Performance issue with lots of simple actors, prob. related to FIndirectLightingCache

There’s a part of our game where we spawn about 1000 simple actors – basically just vertically stretched cubes with a simple material on them.

When we do this, our frame rate goes from 120 fps down to 27.

We used the Very Sleepy profiler to examine the performance, and it says the rendering thread is spending pretty much all of its time inside FTextureLayout3D::AddSurfaceInner.

Here’s what the profiler tells us, further confirming that the performance issue is coming from the indirect lighting cache.

What can we do about this? Clearly, 1000 super-simple actors shouldn’t be slowing the game down this much.

Is there a good way for us to somehow turn off the indirect lighting, given that these are basically just player feedback indicators?

Or should we be building and rendering a custom mesh for this?

EDIT: Here’s an example. Notice how with just this set of objects, we’re down to 8 frames per second.

What’s more worrisome is that after we spawn all these little indicator actors for our overlay modes, they incur what seems to be a permanent performance cost. Even though we hide them when you’re not in an overlay mode by setting their ‘Visible’ property to false, they still hurt the frame rate by the same amount.

I’m not sure as far as the indirect lighting is concerned, but each object will end up as a draw call which is why it’s slowing down with 1000 object even if they are simple.

… To 8 frames per second? Surely not. And that still wouldn’t explain the slowdown when the actors aren’t even visible, which seems like a rendering bug.

Those performance results are definitely bad but I need some better information. Do a ‘stat dumpframe -ms=.1’. Also ‘stat scenerendering’ will show where a lot of the time is.

The Indirect Lighting Cache is probably the culprit here and is totally unnecessary for what you are doing. It is doing a heavyweight interpolation of the precomputed GI for dynamic objects.

I think we need a property ‘bSupportsLighting’ or something like that and when you uncheck it, we can skip all that work. The problem is that right now, the renderer has no way of knowing whether a mesh is going to actually need lighting information or not, so it just computes it either way.

2 Likes

Nm about more stats, the screenshot you posted is enough.

Note that even with a flag that disables Indirect Lighting Cache work for your gameplay indicators, 1000+ draw calls is going to be a lot and probably not the way you want to implement that. Have a look at the instanced static mesh component and see if that works for your uses.

Hi! Sorry for bringing this thread up again but I have similar issues. I have been working pretty hard on a game where the player designs furniture/structure elements out of very basic shapes. Then, he can craft them and place it in the world. I can’t use instanced static meshes because there are a lot of different shapes and textures to choose from.

I placed about 200 of the shapes (all walls with 12 polygons each) in the empty world and watched the framerate go down from 60 to about 30 FPS (intel i5 3750k CPU, 16GB RAM and GTX 650 Ti). It didn’t change when I changed the mobility from movable to static and built the lighting. I can’t code so I’m using blueprints only.

Is there anything I can do or is that the death of another project? I wonder how the Fortnite developers managed to get a detailed world out of many components to work when it begins to stutter with 2400 polygons in my project …

Edit: I turned off the shadows and now I’m getting a smooth framerate (120 FPS). Now I ask myself how I can tweak the shadows. Using the scalability settings, there is almost no difference between medium and epic, only between on and off.

Could you please start a new thread or answerhub question, this one is specifically about the indirect lighting cache performance. You’re asking a much more general question.

Oh, ok. Will do after I learned more about shadows before spread misinformation again. Sorry about posting in the wrong thread.