Foliage performance with FOV changes

I’m getting strange performance decreases when decreasing camera FOV around foliage. I set up a test level using the landscape mountains project. I used the foliage tool to place ~200 trees on one side, and a single tree on the other. (Disclaimer: my video card died recently, so I’m using an old one to run these tests… not the best performance, but I think it still illustrates the effect)

  1. Zooming in on the single tree progressively drops performance (0:10-0:25 in the video)
  2. Moving closer and further away from the tree doesn’t affect performance (0:25-0:35)
  3. Zooming in on a blank part of the level progressively drops performance (0:38-0:50)

This level without foliage instances gives about 90fps, and zooming doesn’t affect that performance. Putting 1 tree in the level and zooming will drop the FPS from 90->70. Having 200 trees behind the player reduces that even further, starting at 45fps and dropping to 20fps as shown in the video. So changing FOV around any foliage at all causes an extreme performance hit. I originally had a level with 1000 trees, and zooming killed the framerate. Then I noticed it still occurred with only 1 or 0 trees in view. Is there any way to work around this, as zooming is a big part of my project.

I’ve only just started playing around with foliage, and I’m not really sure how the LOD or instance grouping is working under the hood. But I’m pretty sure the FOV thing is a problem regardless, since it occurs without any foliage in view at all.

Hello Kristiamo,

After viewing your youtube I believe there a few things affecting your FPS. In order to better understand this issue I would like a little more information from you.

You mentioned that your graphics card recently died and you are using an old one.

1.) Can you link me your DxDiag?
2.) How many Tris/Polygons is each Tree?

What is occurring is the calculation of pixels and bounds whenever your object is off of the screen.
I will link you to documentation that will elaborate further:

There are several work arounds

1.) Disable all occlusion culling for your screen by going to Project settings > Rendering > Occlusion culling and checking the box off.a.) Since you are wanting this utilized on static meshes this may not be the best option.

2.) In the viewport under Show > Visualize > Out of bounds pixels. Check this on and then enter the command r.VisualizeOccludedPrimitives 1 to see, in your scene what is being occluded behind what your looking at.

3.) The last option, is there is a console command r.hzbocclusion 1. This defines which occlusion is being used. This will allow for a more accurate calculation of your bounds.

After I have this information and you try some of these troubleshoots I will be able to assist you further.


Hi , thanks for the help, I’ve attached my dxdiag just in case (and I tried all your suggestions but none of them seemed to make a difference). However, after a bit of investigating I think I’ve found what’s causing the performance problem. It’s the LOD for hierarchical instanced static meshes.

In order to illustrate the effect, I changed the texture for the lowest LOD to pink. My test level has an actor with 900 static mesh components. They can either be spawned as normal static mesh components, or hierarchical instanced static meshes. When they are normal components, they have the behaviour I’d expect: the LOD changes when I zoom in, the FPS doesn’t drop too much (except for what you’d expect because of the extra geometry on the high LOD). However, with the hierarchical instances, it seems EVERY instance’s LOD is changing at the same time, regardless of what’s on screen. This causes huge performance decreases. Even when zooming in away from the trees, every instance changes it’s LOD.

0:00-0:18 normal static mesh components

0:19-0:50 hierarchical instances

0:55 changing FOV away from trees

link text

I set up a test in 4.9.2. What I did was create an actor. I then created an instanced static mesh. Then I added a good bit of trees to that mesh. I set up the culling distance to min around 10 and max 5000. I then added that to my level. I then changed the LOD0 of that tree to a brighter pink in order to see the transition. Then I changed the FOV. I saw a small drop in frame rate due to the increase in poly count but not too bad.

I then went back into the same blueprint and created a HInstanceStaticMesh. Then I added the foliage to that. I then enabled HLOD in World Settings as well as add the HLOD volume to my level. I then built and made sure I built the LOD system. I then changed the FOV. Again I saw a small drop in frame rate but not to the extreme that you are seeing.

If any of these steps differ from yours please let me know. Also if they do if you would provide some repro steps for how you have set up.

Just to clarify you have a GTX 275 graphics card. That, unfortunately, falls well below our recommended hardware specs for running and developing in UE4.

This is a screenshot from our documentation on what we recommend for graphics cards.

I don’t want to say this is the issue per say without making sure that I am replicating exactly what you have. Let me know if what I have recreated differs from your workflow.

Well half the problem is fixed. I didn’t realise my light’s “dynamic shadow distance” was set to 0, which for the regular static meshes had the shadows fading out fairly close. But for the hierarchical instances, this same setting had shadows being rendered far into the distance. I’m not sure why a value of 0 caused them to behave differently. But setting this to 20000 fixed a lot of the performance trouble when zooming in. So now it’s as good as I’d expect for this old card, even using thousands of instances.

However, there’s still an issue with the way instances respond to FOV change. From what I can tell, the hierarchical instance component doesn’t do any frustum calculations for its LOD. The LOD is calculated in a radius around the camera, and all the instances outside of the field of view are being changed too. So when you zoom in, the LOD increases for every instance in every direction. This means when I zoom out, I get a second of extreme lag as the culled instances appear at LOD1, then transition to LOD2. This might just be a limitation of the way instances work, but it’s pretty inefficient having 10,000 trees shift to LOD1, then back to LOD2 because you zoomed in on a small section of them. I’ve attached a picture to show what I mean.

(pic 3 seems a bit inefficient. Shouldn’t those sections reappear using LOD2, never really needing to change? It causes quite a performance hit).

Interesting. I will be investigating this further and see if I can come to a an answer of whether this is intended or not.

I am testing this with another member of our team and I’m trying to collect more data. The goal is to see if the popping of the entire LOD across the HLOD system is intended or if a more gradual change is what you should see. If it is expected the general consensus is that due to your video card having less than 1GB of video memory is causing the FPS drop.

This behavior is expected and we do see a slight drop in FPS on our machines while trying to test this issue. However, the drop we see is not comparable to the one you see. We believe this is due to the hardware on your machine.

Thanks for investigating . I got back to using a decent video card a few days ago, and like you said, the drop is still there but it’s definitely playable with sensible amounts of foliage. I mainly just wanted to make sure the behaviour was an intended part of the instancing system, and that no FOV specific stuff was being missed out. So that’s all good.

For anyone else reading: using more intermediate LODs can lessen the impact of zooming out. Also, the smaller the jump between FOV the less of a fps drop you’ll get (e.g. instantly going from FOV1->90 will have a huge radius of high detail meshes suddenly appearing)