Performance Questions

Hello, I’ve been working with Unreal for a while but have some performance questions I can’t seem to find anywhere else.


  1. Collection Parameters
    Do these have a big impact on performance? I was planning on making a ‘Wet’ function+collection and plugging it into the metallic+roughness of nearly every material in my game.
    This way when it rains, all the objects will appear wet. What sort of performance impact will this have?

  2. Texture Samplers vs Lighting instructions
    I’ve created a function that parses a texture atlas but requires more lighting instructions. I can put a ton of extra stuff on the atlas but then I’ll have to call the function more often.
    So what type of performance will I get with 5 Texture samplers + 120 instructions vs 10 Texture samplers + 80 instructions?


  1. Static Vs Dynamic
    I’ve heard that fully dynamic can sometimes run better than baked static lighting but I’m not sure when/how. I want to have certain areas have different sun angles but the areas are streamed in. If the lighting is baked but at different angles, will it work properly if I move the sun/light to the proper spot when the levels are streamed in? Or will they need to stream in their own light source to keep the baked lighting working. Also, would it be better to just have pure dynamic lights here?


  1. Mesh baking
    Will there be a performance impact for using many small static meshes (such as individual walls, floors, etc) to form a larger object, vs creating the entire object as one static mesh?

  2. Spline Meshes
    We’re creating our organic areas (cliffs, hills, rock walls, etc) using tons of Spline Meshes, since they can be warped and skewed. Do static spline meshes have any performance impacts over regular static meshes?


  1. Building/Packaging
    Through both C++ compiling and Unreal Packaging, choosing ‘Shipping’ instead of Development seems to only remove the console without making any performance improvements. The game also minimizes and snaps to windowed/fullscreen instantly as if it were being stretched instead of properly adjusting my resolution to the game resolution like most games do. Am I missing something here?

Lower end PC’s
7. A very basic scene using spline meshes to create cliffs (basic materials) runs quite poorly on lower end PC’s. Is there anything else I can check to help improve it’s performance? I’ve already disabled the post processes from the Rendering tab in the settings.

That’s it!
Any info on these questions would be very much appreciated. :slight_smile:

1 - I don’t see a performance hit from using material collection parameters. You can only use a maximum of two MPCs per material, though. That seems a bit excessive, though. What exactly do you need to be wet?
2 - Draw calls. Draw calls depend on a number of factors: memory, GPU, CPU, but it’s much better to have more textures and less instructions. You can use shared samplers for assets that are going to be everywhere. There’s obviously a memory cost, but memory is cheap nowadays and saving on draw calls that way is fantastic!
3 - Uh, dynamic lighting is always more expensive. Direct lighting only is fine, but you need to supply the bounce lighting somehow, either as a skylight or in the material’s emissive (for a very cartoony game). You can’t bake lightmass from an object that needs to be moved, as far as I’m aware the light has to be marked as movable, and it renders all dynamic. You also need dynamic shadows on EVERYTHING, not just objects up front, because otherwise shadows will not appear anywhere in the level. Baking is always good for performance because of how much it groups multiple functions together. Unless you’re doing a really cheap mobile game, and I do mean extremely cheap mobile game (no shadows, no real shading, basic rendering), then baking is a lifesaver.
4 - More meshes means more draw calls. Easier to cull the meshes out that way, but a greater overhead. You can use the hierarchical LOD system to automatically build instances around the world and save on draw calls, but that would make the GPU draw more polygons than what it can possibly show onscreen.
5 - I have only basic experience with splines in UDK, none in UE4, so I won’t answer. However, they seemed to behave as static objects in UDK.
6 - Not too sure.
7 - Lots of stuff you can do. Lower the resolution, don’t use too many dynamic or stationary lights. I’m not sure what your project is doing and what hardware you’re targeting, though. That info is important. Some people modeled individual bricks and literally built a brick wall out of individual bricks and the performance tanked. Other people make 500+ instruction shaders and everything crashes.

This stream talked quite a bit about tracking performance issues in game, such as reading draw calls, seeing the things impacting the GPU and CPU. It’s a good stream to watch:

3- I believe dynamic is always more expensive. If you have more than one and they overlap, it’s a massive slow down.

7- if by lower end PC you mean a PC with integrated graphics, you are correct. UE4 runs like a dog on PC without a mild GPU. For those, I turn off AA, shadow quality, ambient occlusion and reduce the resolution scale…

Sorry for the late reply (been very sick with the flu), but thanks for the answers! They helped quite a bit. :slight_smile: