No Cast Shadow Raster Bin performance

Development Rendering
, ,
1

I was wondering if raster bins for cast shadow and no cast shadow nanite sections have different performance in main render pass.

Repro/test:

Add a nanite enabled and shadow casting mesh with multiple sections to a scene. Look at Nanite’s Raster Bins debug view mode. Disable a Cast Shadow on a section and look at raster bins again. Now the sections have differente colors.

2

Steps to Reproduce
Add a nanite enabled and shadow casting mesh with multiple sections to a scene. Look at Nanite’s Raster Bins debug view mode. Disable a Cast Shadow on a section and look at raster bins again. Now the sections have differente colors.

3

Hi,

thanks for reporting this issue. I have started investigating and tried to reproduce it following the repro steps, however I did not manage to see a different color in the Raster Bins debug mode: all sections remain grey colored, regardless of disabling Cast Shadow on one of the sections. Would it be possible to provide a minimal repro scene?

Thank you,

Sam

4

I attached a vanilla 5.6 project. Here the rasterbin issue is a bit different.

Cast shadow doesn’t change raster bin on static meshes.

Spline deformation doesn’t change raster bin (this is a bit strange too).

Cast shadow does change raster bin on spline meshes.

5

From GetRasterMaterialName non cast shadow bin should be Bin 0 (that Visualization.ush and IntToColor convert to gray) and cast shadow bin should be bin 8 and be greenish.

6

Hi,

thanks for the repro scene, but I’m still unclear about a few things. Could you please clarify what you mean by “Cast shadow does change raster bin on spline meshes”? It seems that toggling the “Cast Shadow” flag on either of the mesh sections in the StaticMesh editor will sometimes flip the colors between the static and spline meshes (the orange mesh becomes purple and vice versa), but not always.

On a sidenote, since both the static and spline mesh use a material with WPO, Nanite cannot use the default fixed function rasterization path because the geometry is constantly deforming and it must use a more expensive programmable rasterization path (Nanite is designed for static, highly optimized geometry, and WPO introduces dynamic behavior that breaks).

Thanks,

Sam

7

With “Cast shadow does change raster bin on spline meshes” I mean that if you change the “cast shadow” flag on a section of a lod of a static mesh in the static mesh editor, the raster bin computed in code change properly and this is properly reflected in the debug view mode by a color change.

So the question now may be: why “sometimes flip the colors … but not always”? Is the debug mode and raster bin selection working properly?

8

Hi,

Thanks for clarifying that. I had a look with a colleague at how the raster bin colors are generated and it seems that the code block inside GetRasterMaterialName() starting with the if(bFixedFunctionBin) condition is not entered (none of the output colors match the raster bin debug colors on the WPO-enabled geometry seen in this particular scene), indicating that these mesh sections are not sorted into a fixed function raster bin but into a raster programmable raster bin instead (because of WPO). This can also be verified by looking at the GPU profiling stats (enter r.RHISetGPUCaptureOptions 1, then profilegpu in the console, and open RenderGraphExecute - ViewFamilies > Scene > Nanite::VisBuffer > Nanite::DrawGeometry > MainPass), where for this scene no time is spent in the “Fixed Function” paths, but only in the programmable paths:

[Image Removed]

I’m not sure why the colors are not consistently changing when the flags are toggled but I will raise a bug report for this and will post a link here when that becomes available on the public issue tracker. I could replicate the same behavior in a scene with two Nanite enabled sphere meshes (a static mesh and spline mesh) with a WPO material applied, so it does not seem to be related to having multi-sectioned meshes.

Please let me know if you have any more questions.

Thanks,

Sam

9

Hi again,

this issue is now public at this link, to track its progress.

Thanks again for reporting this,

Sam