Improve DirectionalLight shadow rendering efficiency

[parasyte]

Godot version

3.4.2

System information

Windows 11, GLES3, NVIDIA RTX 3090 (511.23)

Issue description

A screenshot was posted to the discord memes channel a few days ago, and I got curious. The screenshot is below, along with the original comment.

Godot demo project. 12 cubes. 100k vertices. 20! drawcalls.
And people asking why Godot so slow when they run demos.

---

I created a test scene with a few objects and found that DirectionalLight with shadows enabled was the biggest issue. There is also some odd behavior with this combination that looks like false positives in the renderer culling, but I haven't found any reason for it while looking through the spatial partitioning code. At certain camera angles, objects that are no where near the camera frustum will contribute to the "Vertices Drawn", "Surface Changes", and "Draw Calls" metrics in the monitor.

Here are some screenshots from the test procedure described below. First, the scene is running, and I have the monitor shown in the editor:

Then I hide the SportsCar node, and "Vertices Drawn" is reduced by over 20,000! Surface Changes and Draw Calls also see some improvements:

Then I turn SportsCar back on and disable the shadow on DirectionalLight. Vertices Drawn has reduced by almost 60,000 (a massive 76% improvement)! and Surface Changes and Draw Calls see a 75% reduction; another huge improvement!

And finally, changing SportsCar visibility with the shadow off has no impact whatsoever, exactly what is expected for a node that cannot be seen by the camera at all.

This might be the cause of #35746.

Steps to reproduce

1. Open the example repro project and run the scene.
2. Open the Debugger/Monitors tab and enable everything under Raster.
3. Change the visibility of the "SportsCar" node, which is behind the camera and its shadow is being cast away from it.
   • Notice that this object is being drawn when it should not.
4. Do the same SportsCar visibility test with the DirectionalLight shadow disabled.
   • Notice that the monitor numbers no longer change with the SportsCar visibility! The numbers are also much lower with the shadow disabled.
5. Do the very same test, but hide the DirectionalLight, and use either of the other lights instead.
   • I found that any combination of the omni light and spotlight with their shadows does not change how many things are drawn, regardless of the SportsCar visibility. Shadows for these lights are free???
6. Do the same test but this time use DirectionalLight+Shadow and change the camera rotation along its local X axis while SportsCar visibility is enabled.
   • Even a slight adjustment upward from the camera's default rotation will reduce the number of things drawn. And yes, these are all from the SportsCar. Do the same rotation test with SportsCar hidden.

Minimal reproduction project

Render Culling Test.zip

[Zireael07]

The first pic is in editor. I can't find it right now, but I recall discussing it, and it turns out the editor also counts the gizmos and the grid, hence more draw calls than you expect.

Directional light basically renders the whole scene again when casting shadows, so careful tuning of directional light shadow distance and what meshes cast shadows is needed. You also have the option of using a simplified mesh for shadow casting, i.e. placing a second invisible mesh set to shadows only.

[parasyte]

Yes, but the gizmos and grid are not included in metrics while running the game.

Shadow map rendering is expected to be a little more expensive, but not 400% more expensive. Even if the camera encompasses the whole scene, I would expect the worst case for the shadow rendering pass to be 2x everything. Do that with the repro scene and you'll see it tops out around 127 draw calls with DirectionalLight shadows enabled. Disable those shadows and fake them with spot lights and you only have 49 draw calls.

[lawnjelly]

There are also splits for a directional light, and depth prepass. The culling of the shadow volume against the view frustum is not that good either, I did a PR for this many moons ago .. #33340 . Ah yes I'd like to resurrect that at some point.

Change your directional light to orthogonal and the verts rendered will drop a lot, it will be rendering shadow map once for every of the 4 splits you have it set to.

[mrjustaguy]

Shadows in Godot generally need some optimizing, albeit things are much worse in 3.x compared to 4.0
However Primitive count and Draw calls don't mean much, Frame time contribution matters, but that's available in Visual Profiler in 4.0

On the topic of Culling godotengine/godot-proposals#3890 proposes a method to Improve on Shadow rendering, with the occlusion culling part also being applicable to Directional Shadows if that is doable however I'm unsure if that would improve performance as they have to be rerendered every frame and the main benefit of it is to do a quick check to see if you need to render a new shadow or not.. But that is by using GPU's Shadow Maps, Using Occlusion culling available in 4.0 for Normal Rendering just used to help with Directional Shadows on the other hand might benefit performance.

Basically before rendering a given shadow in the shadowmap checks if there were any changes in the area that it's rendering (as in The radius around the Omni light, or Cone of the Spot Light, or less ideally their AABBs) and if there were changes there it pulls up the Last frame's Shadow to use as a Depth Buffer for Occlusion Culling, along with the Last frame's recorded object positions (to determine which objects were the casters in the last frame) and see if the Casters moved, or new Casters arrived in a possibly non shadowed area, in both cases requiring a new shadow rendering.

[parasyte]

Even though draw calls and primitive counts don't mean much on their own, this issue gets much worse in a real scene where several nodes have multiple materials and shaders. Even if they are hundreds of units behind the camera, we still end up paying for shader switches for these nodes that should be culled early on.

Although if it could avoid the shader switching for shadow passes, that might be nice. And of course, some other tricks like rendering shadows with lower LOD meshes.

[Calinou]

The culling of the shadow volume against the view frustum is not that good either, I did a PR for this many moons ago .. #33340 . Ah yes I'd like to resurrect that at some point.

See also godotengine/godot-proposals#3908, which would help improving the effective directional shadow map resolution (at the cost of slightly less effective object culling within each split). If we can combine both approaches together, we should be able to get back to the original efficiency level but with much greater effective shadow resolution.

And of course, some other tricks like rendering shadows with lower LOD meshes.

This is feasible to implement in Godot 4.0 with the automatic mesh LOD, see godotengine/godot-proposals#2600.

Godot 4.0 can also use dedicated shadow meshes that are automatically created on import. These shadow meshes weld vertices together to reduce memory bandwidth and vertex processing cost.

In Godot 3.x, you can use shadow meshes manually by setting a MeshInstance's Cast Shadow property to Off, duplicating the mesh, clearing its material so it uses the fallback opaque material and setting the duplicate's Cast Shadow property to Shadows Only. You can then load a lower-quality version of the mesh. See also the Level of Detail add-on.

Although if it could avoid the shader switching for shadow passes, that might be nice.

I'm not sure if this is always feasible, as shaders can influence where shadows are casted. Fully opaque materials are not affected by this, but this applies to any material that uses alpha scissor or opaque prepass. (Alpha blended materials can't cast shadows in Godot.)

It's definitely something to look into, but it may already be done in the master branch (which uses an entirely different renderer). Feel free to open a pull request for this on 3.x either way 🙂

PS: If you need help navigating the rendering code, feel free to ask questions in the Godot Contributors Chat's #rendering channel.