Tips for Optimizing Level Design Performance in UE5?

Hi everyone,

I’m currently working on a mid-sized open-world environment using Unreal Engine 5, mainly focusing on third-person gameplay. I’ve been loving how powerful Nanite and Lumen are, but as my scene gets more detailed, I’ve started noticing performance drops—especially when moving quickly through different areas.

Here’s a quick summary of what I’ve done so far:

  • Using Nanite for most static meshes
  • Lumen is enabled (software ray tracing)
  • Landscape is broken into components + using HLODs
  • Using World Partition
  • Culled far-distance foliage using procedural volumes

Despite this, my frame rate still dips below 45fps on mid-range machines. I’m wondering:

  1. How do you usually balance high visual fidelity with performance?
  2. Are there any recommended practices for streaming assets efficiently in large open worlds?
  3. Does anyone have experience tweaking World Partition loading settings or LOD biasing that helped significantly?

Also, if anyone’s used Blueprints vs. C++ for optimizing actor behavior (especially AI or triggers in large maps), I’d love to hear your thoughts. I’m mostly Blueprint-focused but willing to dive deeper into C++ if it helps.

Would appreciate any insights or resources you could share!
Thanks in advance :raising_hands:

These things cannot be together :grinning_face_with_smiling_eyes:

Have you done profiling? It would be nice to pinpoint the bottleneck more precisely.

In any case, you will have to sacrifice the quality of the image, or resort to tricks that will take a lot of time to create them.

1 Like

A few loose things I’ve picked up.

1.) Always set max draw distance on meshes, and/or use a Cull Distance volume.

2.) Always set a max draw on your lights.

3.) Disable ‘cast shadows’ when possible. For example, if you have a light that’s shining on a flat wall, with nothing behind that wall, you can go ahead and disable shadows.

4.) To that point, keep attenuation radii to a minimum. For lights, if you’re unsatisfied with how far the light is reaching, consider increasing the brightness before increasing its attenuation. You can increase intensity past its ‘cap’ by manually entering values (I find 160 cd to be a bit dim imo)

5.) Sounds can add to performance overhead, make sure all sounds are managed by sound concurrencies, to ensure that you don’t have too many playing at once.

6.) Whenever possible, consider using a timer instead of Event tick. That said, if your timer has to be a very small interval, like 0.01, it may as well be on event tick. Event tick is also important for anything needing to do a lot of physics calculations, such as player movement and traces. If you do use timers, make sure to disable them by clearing their handlers, so you don’t have them tickin’ when not in use.

7.) Disable Collisions when possible. This one might just be cargo cult thinking but in other games most Out of Bounds stuff have their collisions disabled so I’m assuming that’s for a good reason. I also try to avoid complex collisions when simple collisions will do, for presumably the same reason.

8.) Minimize capsule traces when possible, ask yourself if a line trace or a box trace wouldn’t achieve the same result.

Now some of these you might not be able to make use of if you’re working with large open spaces lit only by the sun, but I think these are generally good practices to adopt. At least it’s what I’ve been practicing. Hopefully someone will correct me if I’m wrong.

9.) Look into using Instanced Static Meshes instead of Static Mesh Actors to save on draw calls when you’ve got lots of the same model and material being used (Such as windows on a building or books on a bookshelf) just don’t make your instance collections too large as this will make it harder to occlude them (For example, all of the windows on one face of a building can be instanced, but you shouldn’t make all your windows on all your buildings part of once instance, or else all of them will be rendered at once).

10.) Uncheck ‘use as occluder’ on meshes with transparent bits or on detail meshes such as this railings, windows (again), benches, small plants and such. Anything too small or see-through to reasonably occlude things. This will save your CPU a bit of trouble.

11.) Careful with models built with UE5’s modeling tools, these tend to have more tris than they need, especially on very simple/low poly models. Make sure to swap most of these out with cleaner meshes later. I tried to kitbash a building out of them and ended up with 300k tris which as you can imagine, tanked performance terribly.