Handling Raytracing Proxy Meshes

Development Rendering
, ,
1

Howdy!

We are looking to maximize HWRT performance initially through proper management of the acceleration structure. We are opting to use Ray Tracing Proxies as opposed to deriving the proxy through the fallback mesh. We do have a few questions on how to manage this pipeline before we begin developing our own solutions:

  1. The standard decimation of the source mesh to generate the proxy oftentimes is not an efficient use of triangles to define the topology that should be traced in the BLAS. Is there a way to define a specific proxy mesh for proxy LOD0 without dropping the the whole ray tracing proxy setup and just applying custom fallback meshes?
  2. We’d like to use different proxies for different skus (i.e. console v high-end PC) to accommodate the HWRT pipeline on all applicable skus. Do you guys have a recommended method for handling this?
  3. How do we define/offset when LOD1 is used?

Thank you in advance. I love your engine :slight_smile:

[Attachment Removed]

2

Hello!

Thanks for reaching out. Let me try to answer your questions as best as I can:

1. Is there a way to define a specific proxy mesh for proxy LOD0 without dropping the the whole ray tracing proxy setup and just applying custom fallback meshes?

Not out of the box. The proxy is built in PrepareRayTracingFallbackBuild / Build purely by reducing the Nanite source mesh description (NaniteBuildContext.SourceModel->GetCachedMeshDescription(), StaticMeshBuilder.cpp:808). LOD0 is added with MaxNumOfTriangles = MAX_uint32, so it’s the unreduced Nanite LOD0 mesh (StaticMeshBuilder.cpp:798-799), and LOD1 gets decimated afterward.

FMeshRayTracingProxySettings (EngineTypes.h:3562) only exposes FallbackTarget / FallbackPercentTriangles / FallbackRelativeError / FoliageOverOcclusionBias, so there is no method to reference a separate proxy mesh asset. To control the proxy-LOD0 topology without dropping the proxy path, you will need to provide your own meshes or extend the builder (which would require some code modifications).

2. We’d like to use different proxies for different skus (i.e. console v high-end PC) to accommodate the HWRT pipeline on all applicable skus. Do you guys have a recommended method for handling this?

Currently, we do not support built-in per-SKU mesh selection. The FMeshRayTracingProxySettings struct is a single, non-FPerPlatform struct and is folded into the DDC key. The proxy is rebuilt at cook for each platform where TargetPlatform->UsesRayTracing() is true, but with the same settings. That means you can’t carry two distinct proxy meshes in one asset.

What you can try to do instead is to drive the build with per-platform CVars set in your platform .ini files, so each cook produces a different BLAS topology:

- r.StaticMesh.RayTracingProxies (StaticMesh.cpp:180)

- r.StaticMesh.RayTracingProxies.LOD1MaxNumOfTriangles (default 64, StaticMesh.cpp:186)

Then at runtime you can tweak r.RayTracing.Geometry.NaniteProxies.LODBias per device profile to bias console SKUs down a LOD cheaply without recooking.

3. How do we define/offset when LOD1 is used?

Only two proxy LODs exist (LOD0 = full, LOD1 = LOD1MaxNumOfTriangles). For a dedicated proxy, selection is not screen-size driven, see GetRayTracingLODIndex:

RayTracingMinLOD = bUsingRenderingLODs ? GetCurrentFirstLODIdx(...) : 0;  // =0 for dedicated proxies
RayTracingLODBias = r.RayTracing.Geometry.NaniteProxies.LODBias;
RayTracingMinLOD = Clamp(RayTracingMinLOD + RayTracingLODBias, RayTracingMinLOD, NumLODs-1);

So LOD1 is reached only by setting r.RayTracing.Geometry.NaniteProxies.LODBias = 1, or streaming/residency fallback (skips an LOD0 BLAS that’s evicted/not-yet-built/streamed-out).

Let me know if you have any follow-up questions.

[Attachment Removed]

3

Hi Tim, thank you for the extremely detailed and clear responses! ​

[Attachment Removed]

4

You are welcome! I will close out this ticket then, but feel free to reach out again with any questions.

[Attachment Removed]