Static-Path Raytracing Support

[connorjak]

This has been discussed a few times in the Discord but I'm making this issue for overall tracking.

Right now, the RMC doesn't support static-path Raytracing; instead using the same dynamic path as meshes that update or animate their vertices every frame. This means there is performance to be gained by changing this implementation for projects that use rarely- or never-updated meshes (like terrain).

Note: this is a different thing than the lighting Movability (Static, Stationary, Movable); it isn't related to lightmass / cooked lightmaps, only runtime lighting.

As my project is reliant on Runtime Mesh Component for runtime terrain, and uses raytracing shadows, I will probably eventually make this change myself and make a pull request. I would appreciate comments about where these changes would need to be, and pointing out other implementations of static-path raytracing in the engine.

[JohnAlcatraz]

Since I have been looking at doing this a while ago, there's a few things I can comment, if I remember correctly:

For RMCs with only one section that needs to have static raytracing support, the main thing that needs to happen is filling the RayTracingGeometries array in the FPrimitiveSceneInfo of the RMC, and doing so at the right moment, so that it fits with the threading model the RMC/UE4 uses for updating components, their scene proxy representation, and their FPrimitiveSceneInfo representation. The data that needs to be put into the RayTracingGeometries array is not any different from the data that is used for dynamic raytracing (which is already supported), so copying the data into the array is very simple. The only challenge is doing it at the right moment and in a way that is safe regarding the threading.

If the RayTracingGeometries array in the FPrimitiveSceneInfo array is filled, and virtual bool IsRayTracingStaticRelevant() in the FRuntimeMeshComponentSceneProxy is made to return true, then the engine automatically uses the static raytracing path. So quite simple.

For multi-section static raytracing support, additionally, it's required to combine all RMC sections into one section to fit the way the data needs to be put into the RayTracingGeometries array. So this requires a bit more copying-around of data than single-section static raytracing support and would be quite a bit more work to add.

It makes sense to first work on single-section static raytracing support and get that working nicely before trying to also get multi-section static raytracing support to work. For a lot of use-cases, single-section static raytracing support is all that is needed.

[Koderz]

This is something that's in progress, and was much of the reason behind the idea of SectionGroups as it allows batching multiple sections on the same set of buffers which is the prerequisite to allowing static ray tracing on multiple sections.

[Koderz]

This is complete at this point. There is the limitation of only a single SectionGroup an be static due to engine limitations, but you can have multiple sections in a group so if you set things up right it can work for all your sections.