r.Shadow.LODDistanceFactor not correctly accounted for when CSM shadowing foliage with WPO

Development Rendering
, ,
1

This question was created in reference to: [r.Shadow.LODDistanceFactor [Content removed]

Hi, our issue isn’t directly related to the referenced issue, but was discovered as a result. It still happens with an unmodified 5.5.4 and 5.6.0 engine (see repro project). We flagged r.Shadow.LODDistanceFactor as ECVF_Scalability so we could increase it for our lower scalability settings, revealing that our foliage meshes go through a different code path for CSM shadows that doesn’t seem to correctly account for that cvar when the mesh has WPO in one of it’s materials. This manifests as the shadows for that mesh getting culled much closer to the camera than intended. See the attached video.

My best guess is that this is an issue in the bounds calculation for culling the shadows (due to the fact that decreasing r.Shadow.RadiusThreshold to a very small value, artificially expanding the static mesh bounds to a very large value, and removing WPO are all attributes that mitigate the issue). I can confirm they’re following the code path in NaniteCullingCommon.ush (despite having nanite disabled) where it passes the following condition (when it shouldn’t succeed at that distance):

if (RadiusSq < NaniteView.CullingViewMinRadiusTestFactorSq * InstanceDrawDistSq)
{
    bIsVisible = false;
    return bIsVisible;
}

That said, I’m not able to pin down what aspect of that flow needs to be changed specifically in order to account for that cvar correctly. Any suggestions would be appreciated.

2

Steps to Reproduce

  • Make a non-nanite static mesh (like a tree with leaves) that uses a material with World Position Offset hooked up
  • Add the static mesh as foliage and add an instance to a landscape
  • Set r.Shadow.LODDistanceFactor to a high value (like 16) and set r.Shadow.RadiusThreshold to roughly 0.03-0.06 (exact value not important)
    • Lowering scalability makes it more obvious, but isn’t strictly required
  • Observe how the the shadows on the foliage are culled closer than expected
    • Compared to removing the WPO from the material
    • Compared to a non-foliage static mesh
3

Hello,

Thank you for reaching out.

I’ve been assigned this issue, and we will be looking into the behavior of “r.Shadow.LODDistanceFactor” being applied to foliage with WPO for you.

4

Hello,

There are known bugs with GPU LOD selection for ISMs and their subclasses, including Instanced Foliage which lead to a discrepancy between ISMs and SMs.

For more information and potential workarounds, please see this ticket:

[Content removed]

Please let us know if this helps.

5

Thanks for getting back to me. That is unfortunate both issues are backlogged. In the meantime we’ve hacked around the issue by forcing the same cvar value across all scalability levels for the one map that contains foliage, but a real fix would be more ideal.

6

Hello,

Thank you for the reply.

Can we now close your case? You can always re-open it if you need additional assistance with the same issue.

7

It can be closed.