Building lighting slow with foliage

Hi all,

I am working on a level that has a bunch of static meshes and so far lighitng build time was reasonable, 2-3 minutes. Today I added some foliage. Nothing earth shattering, just about 300 or so bushes, trees etc. but the lighting build time is in the basement. over half an hour so far and build is only 13% complete.

Is this normal with foliage, and what can be done to avoid this or speed it up?

Thanks

PS. Now that the build is complete I get warnings about “Instanced_Foliage_Actor_0”, that the “total lightmap for this InstancedStaticMeshComponent is large” and I should reduce it. What is this actor, is this the totality of all foliage in the level? Can I place multiple such “instanced actors” instead? But the foliage palette is always the same in the level, I haven’t found a way to have multiple such foliage painting setups

Hi Wallenstein,

This should help you out: A new, community-hosted Unreal Engine Wiki - Announcements - Epic Developer Community Forums

The foliage tool clusters actors together into chunks that get populated and when lighting is built these instances that are clustered are put into a texture atlas. Using a lower lightmap resolution or no static lighting for the foliage actors is often the best fit for them anyway.

I hope this helps.

Tim

Thanks alot, that helped already.
Could you perhaps explain or direct me to a link with explanation about the effectiveness of movable vs stationary lights with regards to large foliage areas?

I have levels of 1*1Km some of which will be mostly forest or other plants. I was under the impression there would be a significant penalty when dynamic lighting is used in such a large area? What can I expect in such a situation?

Thanks

Could you perhaps explain or direct me to a link with explanation about the effectiveness of movable vs stationary lights with regards to large foliage areas?

I’m not sure if there is a “direct” link that covers that specifically, but the documentation with lighting (and there’s lots of it!) covers this in more broad terms to cover how lighting works and why this is otherwise the documentation would have a lot of pages that are just mentioning very specific problems. These are things that I try and cover on my multiple wiki pages out there for things like, Lighting, Destructibles, Asset Creation, Swarm Agent, etc.

Dynamic Lighting is expensive because the Cascaded Shadow Maps for Directional Lights and the shadowmaps for point/spot lights take into account all vertices on the screen no matter their size if they are within range of calculation. This is where the biggest hit in performance comes with dynamic lighting. LODs help and controlling the CSM distance or point/spot light radius help reduce the performance impact.

Static Lighting for large areas can be just as bad, but instead of it being a GPU cost at runtime for light calculation you now have a ton of lightmap textures that have to be loaded taking up precious runtime texture memory. So it’s typically better to use dynamic lighting for large levels and reduce the draw distance for the CSM shadows to a range that is acceptable. This was done with the Kite Demo and by also using Distance Field Shadows, which, is another form of dynamic light shadowing by using a generated mesh distance field for shadowing. Kite Demo used CSM shadowing for 1600 cm (16 meters) draw distance since it’s more accurate and distance fields for shadowing farther out.

Tips continued in next post…ran out of space. :slight_smile:

Oh one other things before just going into lighting tips. Another performance factor to consider is the number of drawcalls happening on screen with the number of visible meshes.

Dynamic occlusion (hardware occlusion queries) are the most expensive form of occlusion, so reducing the number of queries that need to be sent to the GPU by using cull distance volumes can definitely help reduce this impact. So it may not just be lighting that is causing the performance hit, but also the number of meshes on screen that have to be calculated as well. You can use the command Stat Initviews to help you take a look and keep this in check.

Even though this is from UDK/UE3 it’s still relevant with how visibility/occlusion culling works in UE4.
https://udn.epicgames.com/Three/VisibilityCulling.html

General Tips for large levels:

  • Keep Directional Light CSM distance within a reasonable range that fits your needs.
  • Disable shadow casting on grass where you can. It will still receive shadowing but will not cast. If it’s low cut grass this can help. Taller grass or higher may need it, but that’s really just up to testing what works and doesn’t work for you.
  • Cull Distance Volumes, culling for foliage (set up through the material and controlled through the foliage panel), Min/Max Distance settings in the details panel when Cull Distance Volumes don’t work best.
  • Use aggressive LODs to reduce the vertex count that has to be considered for CSM shadowing.
  • Use ProfileGPU to check performance because you may be bound by more than just dynamic lighting. Also, Stat Initviews, Stat SceneRendering are good to help.
  • If you’re not using any static lighting in the given level, use Force No Precomputed Lighting in the World Settings panel. (This is level specific. If you’re not using for the project, change it in the Project Settings > Rendering > Allow Static Lighting)

I think that’s all I really have for the moment. Hopefully you’ll find some/all of this helpful.

Thanks a lot, I will see what I can do this info. Lighting is one of the most complicated features of the engine it seems and for beginners it’s really mostly poking around in the “dark” :slight_smile:

I think you summed it up fairly concisely. I’m here to shed a little light on the subject if needed and my Wiki Lighting Troubleshooting guide can be helpful for some of the common issues that I’ve seen people run into.