Nanite Tessellation performance considerations

Development Rendering
, ,
1

Hello,

Before digging into shader code I would like to ask a few questions regarding performance of Nanite Tessellation on static meshes. I’m aware that this feature is currently experimental.

  1. For regular high-poly nanite meshes it is recommended to avoid additional vertex data like vertex color and additional UVs to reduce memory cost. Does this still apply for low-poly meshes with nanite tessellation enabled?
  2. Does instancing (HISM) work with nanite tessellated meshes? Will it have negative performance or memory impact if the Displacement is different for each instance? For example depends on PerInstanceRandom.
  3. Should I expect worse performance if the Displacement changes every frame? For example heightmap offset is animated. (ignoring other factors like shadowmap invalidation)

I guess it all boils down if nanite tessellation generates the mesh on-the-fly each frame or uses some kind of cache. And if there is no cache, are you planning to introduce it in the future?

Regards,

Gabor

2

Steps to Reproduce

3

Hey there! To answer your questions:

  1. The cost scales with the number of vertexes, so this is ultimately a tradeoff you’ll have to decide on. For what it’s worth, Nanite only supports up to 4 UV channels, and you can opt into high precision (32-bit) UVs. I’d say this is fairly marginal compared with the total number of verts.
  2. Instancing shouldn’t have an impact on tessellation (except to ensure that everything is part of one raster bin). The perf impact will be determined by the fixed displacement magnitude value in your material itself. PerInstanceRandom is probably going to be scaling displacement between -Magnitude and +Magnitude.
    1. Nominally, you want to keep your magnitude under a value at which it becomes relevant to gameplay.
      1. For example, if a player has Nanite disabled and they can see around a corner whereas a Nanite-tessellated surface would obscure that sightline, then the magnitude is probably too great.
      2. As another example, if the displacement is so great that it would affect foot IK
  3. No, I wouldn’t expect the rasterization cost to change depending on the phrase of an animated texture.

Tessellation is all happening on the fly, nothing is cached. I don’t know of any plans to introduce one in the future (beyond the landscape Displacement RVT which effectively caches displacement by way of the heighmap)

The most important thing you need to do with your tessellated materials is enable Displacement Fade. This will disable tessellation on clusters whose size on screen falls below the set threshold. You don’t want, or need, every pixel to tessellate out to the horizon, and this is how you control that.

As with everything, make sure you’re profiling before and after in a consistent fashion so you can properly evaluate the impact on your project.

Hope that helps!

4

Hi Matt,

Thank you for the explanation, it helped. I think we can close this question now.

Gabor