Using Max Edge Length Factor to Influence Nanite Rasterization Paths

Development Rendering
, ,
1

We’ve noticed that Nanite static meshes often end up in hardware rasterization in scenarios where we would have expected them to remain in software rasterization. For example, meshes with flat or nearly flat surfaces tend to be decimated heavily, producing large triangles, even if the source mesh has a dense and evenly distributed topology.

In a scene such as a suburban street, this can cause issues. Many meshes like houses and roads have broad, flat surfaces where variation comes primarily from materials rather than geometry. As a result, much of the scene ends up in hardware rasterization, when our expectation is that more of it would stay in the software rasterization path, particularly for performance reasons.

We experimented with using Max Edge Length Factor on source meshes with suitable topology to prevent triangles from becoming too large. For example, a value of 25 on some meshes produced rasterization results closer to what we expected: the meshes stayed in the software path until they were reasonably close to the screen.

The tooltip for Max Edge Length Factor states:

“Controls the maximum distance allowed between each vertex of the mesh on screen. Can be used to prevent oversimplification of meshes that are intended to be deformed (e.g. animation using World Position Offset, Spline Mesh Component, etc.). Should be left at default of 0 unless explicitly needed to fix oversimplification issues.”

It makes sense that Nanite decimates aggressively to reduce disk and memory footprint, and that it’s often tuned for meshes with lots of high frequency, small scale detail. From our testing, though, Max Edge Length Factor can also influence the rasterization path by limiting decimation. While it seems intended for deformation cases, it appears useful for this purpose as well.

This leads to a couple of questions:

  • If we use Max Edge Length Factor to mitigate simplification so that meshes stay in software rasterization longer, are there consequences or gotchas we should be aware of?
  • Is this an incorrect use of the feature, or are there alternative approaches that would be preferable?
2

Hello there,

There is a console variable r.Nanite.MinPixelsPerEdgeHW that controls the switch over point, but increasing this beyond the default 32 to push more triangles through the software rasteriser can lead to visual artefacts. The console variables r.Nanite.ViewMeshLODBias.Offset and r.Nanite.ViewMeshLODBias.Min should also affect the cluster behaviour.

As I understand this, this inflection point should be a good default, so I am interested by how much of a performance gain max edge length factor is providing and whether the CitySample would work as a repro for this behaviour.

In terms of consequences, disk and memory use are probably going to be the biggest ones. The thing to pay attention to would be the streaming pool for Nanite, which is limited to 2GiB after subtracting the root page pool on most hardware (AMD hardware being the notable exception that allows 4GiB less the root pool). Increasing the amount of geometry can eat into that, but that isn’t say that using Max Edge Length Factor will cause an issue on this front.

One other potential issue could be the Nanite root pool. Max Edge Length Factor may affect the size of the root pages, and these are more limited, so it would be easier to hit that limit.

Best regards,

Chris