Huge bottleneck in Shadows.CreateUmbraShadowCuller

Hey guys, I'm using HDRP 12.1.0 + Hybrid Renderer 0.11.0 + Unity 2021.2 to render a rather large scene. Most dynamic objects are GameObjects, and most of the static level geometry is placed in subscenes. I'm also using the Umbra-based occlusion culling system, mostly for disabling certain GameObjects when they're not in view (CullingGroup API). The scene contains a single shadow casting directional light (sunlight).

Overall the performance is... managable, except for this giant spike in a single job worker that's making my life much more difficult. It appears to take more or less time depending on the camera angle and the number of objects in the subscene. Disabling occlusion culling in the camera settings makes it disappear, but this increases the rendering cost, so this isn't a viable solution. It also goes away when I disable scene lights or unload my subscenes.

7634578--950542--upload_2021-11-6_18-12-8.png

Edit: As I'm slowly rotating my camera, this is what the ~10ms spike looks like. I'm not sure if it's specific scene objects causing this, but I'll keep trying to narrow it down.
7634578--950932--upload_2021-11-7_12-12-22.png

A couple of questions:
- What is the engine doing exactly? (Shadows.CreateUmbraShadowCuller seems to be in the black box part of the engine, and there's no documentation available)
- What am I doing wrong here? How can I improve my setup to get rid of this bottleneck?
- Can I disable occlusion culling for shadows (or whatever is happening here) and keep the rest of my current rendering settings?

Umbra is not officially supported with the DOTS ecosystem. We are working on a new fully dynamic occlusion culling system that is heavily optimized with Burst that will be the default occlusion culling system for DOTS.

That being said, I do not see this issue to be specific to dots/hybrid, just that the pipline is significantly more optimized so the spike becomes more apparent. Can you submit an issue for this?
https://support.unity.com/hc/en-us/articles/206336985-How-do-I-submit-a-bug-report-

This logic is a part of how we cull directional shadow casters. I don't see a way to disable it just for shadow casting lights, as it is dependent on whether the tome data was created for umbra, which is dependent on the camera culling parameters so it is inherited from the camera. This limitation has already been addressed in the new occlusion culling system, which will give you fine grain control over enabling occlusion culling per camera and also per light.

3 Likes

[quote=“nigeljw_unity”, post:2, topic: 861185]
Umbra is not officially supported with the DOTS ecosystem. We are working on a new fully dynamic occlusion culling system that is heavily optimized with Burst that will be the default occlusion culling system for DOTS.
[/quote]

This will be usable with non DOTS renderers, right? Cause this sounds amazing, the umbra implementation is pretty rudimentary and limited

The only dependency for the new occlusion culling system is Burst. Game Object support is planned, but that will require full platform independence. Additional platform support is in progress.

5 Likes

[quote=“nigeljw_unity”, post:2, topic: 861185]
Umbra is not officially supported with the DOTS ecosystem. We are working on a new fully dynamic occlusion culling system that is heavily optimized with Burst that will be the default occlusion culling system for DOTS.

That being said, I do not see this issue to be specific to dots/hybrid, just that the pipline is significantly more optimized so the spike becomes more apparent. Can you submit an issue for this?
https://support.unity.com/hc/en-us/articles/206336985-How-do-I-submit-a-bug-report-

This logic is a part of how we cull directional shadow casters. I don’t see a way to disable it just for shadow casting lights, as it is dependent on whether the tome data was created for umbra, which is dependent on the camera culling parameters so it is inherited from the camera. This limitation has already been addressed in the new occlusion culling system, which will give you fine grain control over enabling occlusion culling per camera and also per light.
[/quote]

Thanks a lot for the timely response. I’ll try to put a bug report together, maybe even a repro project if possible.

[quote=“joshcamas”, post:3, topic: 861185]
This will be usable with non DOTS renderers, right? Cause this sounds amazing, the umbra implementation is pretty rudimentary and limited
[/quote]

I’m also interested in this. I don’t expect full support for GameObject renderer culling, but all I really need is an API to query or hook into the new culling system, and I should be able to retrofit it into my existing systems. Can you confirm whether that’s on the roadmap? (question was pretty much answered as I was typing it, but saving it for posterity)

This is extremely exciting news!! :smile: It also suggests that we'd be able to build our own cullers in c#, which could be very powerful

Hey, following up on the topic of the new occlusion culling system, do you know whether there's a chance that it will be released in some form together with the 0.50 or 1.0 ECS packages, or is it tied to some other schedule?


It seems to be working here, from looking at https://github.com/Unity-Technologies/EntityComponentSystemSamples

[quote=“apkdev”, post:7, topic: 861185]
Hey, following up on the topic of the new occlusion culling system, do you know whether there’s a chance that it will be released in some form together with the 0.50 or 1.0 ECS packages, or is it tied to some other schedule?
[/quote]

Sorry about the long delay in responding to this! It is tied together with the Dots 1.0. Initially, it will be considered experimental for that release. It is already production ready, but only for PC and consoles. It is planned to come out of experimental with support for game objects and also mobile support (using the relatively new Neon Burst intrinsics for acceleration) in a 2023 release.

[quote=“hippocoder”, post:8, topic: 861185]
It seems to be working here, from looking at https://github.com/Unity-Technologies/EntityComponentSystemSamples
[/quote]

Anything that is already released is very old, not properly fully conservative, and does not represent the final product that will be released with Dots 1.0. The official release will include extensive debug tooling, and as well a complete overhall of the SW rasterization job to be as lightweight as possible (though still relative to scene complexity). The burst occlusion culling release with 1.0 is fully conservative and fully dynamic, so no more pain from the lack of conservatism in the implicit voxel discretization in Umbra.

The initial workflow for Dots 1.0 will be slightly manual in that the creation and placement of proxy occluders is required. This will be the most common workflow, but we have a fully automatic system to generate and position the inscribed meshes well in progress, which is planned to release with game object and mobile support in 2023.

A workflow to properly support skinned/deformed meshes is being investigated. Initially, it is planned to support having skinned/deformed meshes as occludees using the overly conservative AABB for the skinned/deformed mesh. Using skinned/deforemd meshes as occluders will require much more investigation and integration into the different rendering workflows.

7 Likes

[quote=“nigeljw_unity”, post:9, topic: 861185]
Sorry about the long delay in responding to this! It is tied together with the Dots 1.0. Initially, it will be considered experimental for that release. It is already production ready, but only for PC and consoles. It is planned to come out of experimental with support for game objects and also mobile support (using the relatively new Neon Burst intrinsics for acceleration) in a 2023 release.

Anything that is already released is very old, not properly fully conservative, and does not represent the final product that will be released with Dots 1.0. The official release will include extensive debug tooling, and as well a complete overhall of the SW rasterization job to be as lightweight as possible (though still relative to scene complexity). The burst occlusion culling release with 1.0 is fully conservative and fully dynamic, so no more pain from the lack of conservatism in the implicit voxel discretization in Umbra.

The initial workflow for Dots 1.0 will be slightly manual in that the creation and placement of proxy occluders is required. This will be the most common workflow, but we have a fully automatic system to generate and position the inscribed meshes well in progress, which is planned to release with game object and mobile support in 2023.

A workflow to properly support skinned/deformed meshes is being investigated. Initially, it is planned to support having skinned/deformed meshes as occludees using the overly conservative AABB for the skinned/deformed mesh. Using skinned/deforemd meshes as occluders will require much more investigation and integration into the different rendering workflows.
[/quote]
COR! Love the sound of that! 1.0 is definitely a big deal for me. Thanks for the heads up, these posts really cheer me up. The occlusion work in progress is great news because I’d only exposed to what’s there so far on github. I was on Unity’s slack for DOTS but ran out of time / energy to keep popping in a while back.

Will there by HLOD / LOD improvements too? I’m betting… yes!

Although even 0.51 will be a bump in quality of life (I’m on URP 10 and it somewhat sucks compared to 12+) - any news on that front? :slight_smile: