Zooming a Camera causes shadowdepths to increase beyond reason

The scope itself is just a UI overlay no PIP or anything fancy.
When switching to scope cam Im disabling the character cam.
Basic settings, I have already discounted it being anything in post processing or lighting.
Trees are inside a Procedural Foliage volume
RVT on landscape
Nothing seems to affect these invisible boundries of “frame suck” :{P

Im not sure how to go deeper with this bud, It shows its adding the overhead to the shadowdepths but there are no more shadows being drawn (to that extent) from one spot 1 step away…
I originally thought it was occlusion calls because they would spike a little, so Ive turned off trees as occluders, decrement of ~2ms evenly…

There are almost like grids around the map that you get the framerate expected (im going to wrie code to place a sphere at these boundries as i walk and confirm shape)

Sense this issue makes= 0

without twitch recording in background framerate is ~100-~110 and drops to ~85-90 in the good zone and ~95-100 and drops to 40-50 in the bad

Any Ideas on whats going on here?




“Good Spot” looking directly at ground, exactly what one would expect


“Bad Spot” I get the same looking at 60 actors at lod0…

Scene Heiarchy


Relevant major settings: Lumen GI and Reflections, VSM… Everything is pretty much default only other deviations is Mesh Streaming (switched this off and on no effect) Generate mesh distance fields on.

All foliage is culled at x distances, except the nanite hardwoods (had a similar issue before with a small sparse grass with no cull distance set…fun)
I have adjusted CSM and Distant Field Shadows, the affect on ms was even across both…

What else gets added to shadowdepths that is not shadow?

and one step right

And to eliminate the possibility of it being something with my camera actor on the scope, Increased the Char Cam FOV, not spawned the scope actor.


All optimization viewmodes look as expected
Confirmed multiple “spots” on the same landscape component
FOV of 10 and 20 on a camera component lose 5-5.5ms into shadowdepths from L1 to L2
Deleted the cams that were in scene hiearchy, just in case.

Upon further testing:
Created a new level, landscape no mat on it, another FT and put in a Procedual foliage volume and populated, dropped in my character, and in 2 min found a area

1 foot forward 30ish frames back? This was actually a few more steps forward, lost track but the line is absolute


another test removing scope actor

Remomved all the trees, planted some 256 tri cones in the procedural volume, resimulated. This is the same position as the previous test… Idk… im at a loss as to what can be causing this geopositional anomoly…


This is the real kicker for me though in the bad area (which makes up majority of area on the map) just looking straight at the ground, which normally reduces nearly all the overhead for rendering (as you are not rendering anything but the ground) Takes up a good percentage of frames… note this area may be receiving a small amount of indirect lighting but no shadow.

Yet a couple steps over in a area that is receiving more indirect and a shadow??

Standalone Test


1 step right…

A more visually dense test


couple steps forward

note this invisible line runs adjacent the procedural volume grid lines here.

Set engine scaleability back up to epic, more pronounced effect as I presumed, but strangely its hitting 125fps in the good spot

The next update is going to be from a new project entirely…
Update_ Cannot replicate in another project
Set all project settings under rendering to that projects… still have the same issue.
dont tell me Im going to have to rebuild this… again

Ok well after 15-20 hrs rebuilding in a new project… similar results, looking down a cam with a low FOV sucks the frames right up… It shows in shadowdepths but even looking at unshadowed grass and zooming in instant 5-6 ms added to shadowdepth… I dont EXPLATIVE get what the EXPLATIVE problem EXPATIVE is…!!!

Zoom 10fov

FOV 5

Dropped Normals, no change.
Same results but worse, no good areas…
Its now doing the same thing in editor as well not just durning simulation

Lighting only Viewmode


In editor, lit, just looking at the sky with a 5deg camera view

System Specs: R9 , RTX 2080s, 64G ram, Win 10

stat gpu

added. I have known its attributing it to shadowdepths but I have observed its not scaling with shadow as it normally would, there is no difference between location 1 and x + 1 meter to the tune of that much ms anyway… thats the conundrum. Ive dl renderdoc but no idea how to use it on a nonpackaged project… to see deeper in the shadowdepth thread

So at the moment it appears that with a camera with a FOV of (only tested with 90 and 10) current value 10 makes the frames (5ms) go bye bye into shadowdepths. I originally was like ok well its rendering CSM between my current actor and the view so that makes sense… until I found these spots…and started comparing, with a PIP scope I was seeing about the same frame drop as the frame suck areas, thats why I replaced that with the UI overlay. FOV of 20 Is also 5ms loss

Gotta be honest… I have no idea what the issue could be. You might try Intel’s Frame Analyzer if you can’t get the info out of RenderDoc

Thanks for the suggestion, and the brainpower toward the issue. Im trying to set up another level to see if it replicates, having problems with procedural foliage volume though… it may be related. Havent touched it since 5.0 release. (this problem was not related, had to clear inclusion layers, make new spawner)

Ok well I think I got this in the bag now, one cvar and its acting normally when I zoom the camera…
r.Shadow.Virtual.NonNanite.IncludeInCoarsePages 0
so apparently to my understanding when I zoomed the camera all the local vsm cache pages were being invalidated (each frame i beleive) Whew glad I got that solved… what do you have for me next UE?

Why it was doing it in diffent spots im unsure… but was def stange.

1 Like

Glad you got it resolved, I would recommend you report this as a bug; You’ll most likely need to include your project so they can reproduce it but it seems like an issue they should really know about.