Sporadic seam along boundary between 2 VSM clip levels?

Development Rendering
, ,
1

We see a bug a couple times a day across our team in Ultra quality mode with Nanite tessellated + displaced terrain where a sharp seam becomes visible between 2 VSM clip levels (we think) fairly close to the player. It looks like outside the ring we have something like a projective aliasing artifact making those areas darker. Still trying to repro to get more info. Any suggestions appreciated.

[Image Removed]

[Image Removed]

[Attachment Removed]

2

Hello,

This sounds like a similar issue to what was posted here: [Clipmap shadow line when using displacement [Content removed]

You should be able to check if you’re using displacement fade in this area to determine if it’s the same/similar issue.

[Attachment Removed]

3

Thanks Alex,

The project Art Director managed to repro a variant of the problem in the Editor this morning. Turning off Displacement Fade did seem to resolve the problem in the editor. We’re going to try it in our build next. Here’s a video showing some of the artifacts in motion. The curved transition areas don’t line up exactly with the VSM clip boundaries.

[Attachment Removed]

4

Hi,

Glad to hear that helped, here’s some more information about why the underlying issue was marked as a known issue - does this sound like it describes the displacement amounts being used in the problem location?

For the repro case we received, this is expected as shadows in the fade region get pushed to min displacement (it’s not feasibly to match pixel for pixel the shadow tessellation for the receivers in the fade region). Thus if the displacement is moving the geometry too much - there can be obvious differences between clipmap levels.

The resolution here is that more of the shape of the geometry/silhouette really has to be in the actual underlying geometry, not moved by dynamic displacement. Using the dynamic displacement just for the small up close details rather than larger changes that significantly push coarse sections of the terrain in/out should minimize issues.

[Attachment Removed]

5

Possibly. It isn’t 100% repro, so could it be more than just an expected artifact of displacement fade?

[Attachment Removed]

6

OK, a couple things we also recommend regarding Nanite tessellation on Landscapes while you’re looking at it:

  1. A dicing rate of 4 has been found to be the sweet spot for performance and anything higher typically has noticeably worse performance
  2. Ensure the Landscape’s displacement range uses as much of the 0..1 range as possible. The settings for that for landscape specifically are unusual because landscape internally adds a scale to the meshes it generates (64x). So the magnitude has to be much smaller than you think.
  3. Displacement should be as cheap as possible. If there’s more than sampling a Displacement RVT that’s probably too much work and can really hurt performance.
    [Attachment Removed]
7

that’s great info, thank you!

[Attachment Removed]

8

Thanks Chris, and Alex -

Alex, a few follow-up questions to 2 and 3

2 - So, I instinctively authored full-range displacement info on our textures, requiring more subtle adjustment on the numerical (Material Instance) Range

Does this mean that I have to reduce the range on the texture, to be able to use more of the numerical range in the MI_ ?

3 - While displacement pixel-information only comes from the RVT in our shader, its ranges are being remapped (min/max) on the MI_ for each individual displacement channel that contributes. I’m assuming from your 3rd point, that these should be hardcoded and not set via exposed params?

Thank you again!

[Attachment Removed]

9

Does this mean that I have to reduce the range on the texture, to be able to use more of the numerical range in the MI_ ?

If I understand correctly, your texture uses full 0..1 range, but it’s possible the MI_ parameters can affect this so it’s outside that range? It’s good to use the full range in the texture, but whatever manipulation happens to that in the Material or MI, shouldn’t exceed the range of 0..1 when it gets to the Displacement input.

I just realized our Nanite tessellation docs in 5.7 have some more info about this which is worth a read: https://dev.epicgames.com/documentation/unreal\-engine/working\-with\-naniteenabled\-content?application\_version\=5\.7\#nanitetessellation

Range remapping should be hardcoded and not set via exposed params?

I recommend testing how much of a perf benefit you get from hard coding the remapping math. It may not be worth it if you find you are changing those params often enough. The kind of slowness we look for often comes from complex terrain materials where there may be erosion, water features and sometimes gameplay features affecting displacement and slowing it down.

[Attachment Removed]

10

Thanks Alex -

I should have cited our MI_ params for adjusting the displacement ranges.

My displacement channels use as much of the texture’s range as possible, but the MI_ params are seldom exceeding 20% of that -

Example - Use the Displacement channel as a Lerp Alpha, then Inputs A-Min and B-Max would most frequently be set to Min: 0.0, Max ~0.2

How does that technique apply to that second point?

3 - So currently, nothing is affecting displacement at Runtime in our project, and I think generally our displacement amount is good, so I could hardcode the values and see if there’s a perf boost.

Thanks again, Alex!

[Attachment Removed]

11

The problem with not using the full 0..1 range of displacement is that you may be compensating for it with the Magnitude property and that leads to performance issues as mentioned in the doc:

  • Keep the Magnitude setting’s value as small as is necessary. Instead, try to use the entire 0-1 range of the Displacement output. Don’t set the Magnitude to 100 and then scale down the value you plug into the Displacement output to compensate. The reason for this is because the Magnitude value is used to bound patches for culling. If the Magnitude is large it can have serious impacts on performance, especially with virtual shadow maps.

Basically, the cost of the effect scales with the displacement magnitude amount for the material. So if you had a poorly scaled displacement mask or the way your MI params are configured means the displacement output never exceeds like <0.5, it isn’t taking up the full 0-1 range, and you might have the urge to raise the magnitude in the material properties. Don’t do that because it is increasing the overhead cost of it all(it messes with culling).

I hope that makes sense and I haven’t misunderstood how the MI params are used in your Material.

[Attachment Removed]