Which "Shadow Update Mode" should I use on my lights?

[dgoyette]

I was looking into “Shadow Update Mode” for lights, and I’m confused on the significance of each of the options. Right now I believe I’m using the default of “Every Frame” on all of my lights. My belief was that I needed to do this so that dynamic objects would properly cast shadows. However, then I saw the setting “Always Draw Dynamic” as a separate shadowing option, which made me conclude I don’t understand “Shadow Update Mode” in the first place.

I find that with “Always Draw Dynamic” enabled, I can’t tell the difference in shadows regardless of which Shadow Update Mode I choose.

Does anyone have a simple answer for under what circumstances it’s necessary to set Shadow Update Mode to “Every Frame”? If I have a stationary light, should I just use “On Enable”? If the light can be turned on and off, should I set it to “On Demand”, and call RequestShadowMapRendering() when toggling the light?

[impheris]

I think the most common mode is “every frame” but i recommend you to read the docs, here is the link:
https://docs.unity3d.com/Packages/com.unity.render-pipelines.high-definition@10.0/manual/Shadows-in-HDRP.html

Read it Boy

[dgoyette]

The docs don’t really explain the significance of caching the shadow map or not. So, I could rephrase the question as, What is the impact of caching vs not caching a given light’s shadow map. I don’t believe the docs touch on that; it merely states whether caching occurs or not.

Per my original post, my assumption was that I needed to choose “Every Frame” since I have many dynamic objects in my scenes. However, I find that enabling “Always Draw Dynamic” produced correct shadows for Dynamic Objects even when I choose “On Enable” or “On Demand” for the Shadow Update Mode.

So in the case of a light that doesn’t ever move, I’m trying to understand whether its shadow map ever needs to be recomputed after its initially computed. My concern is that it seems like I can use “On Enable”, because I’m not immediately noticing any problems, but that I’ll find later there’s a good reason I actually need to keep it on “Every Frame”.

[dgoyette]

It turns out the features I was looking at are relatively new, and weren’t in the version whose documentation I was looking at. The docs for HDRP 12.1 does include the topic:

https://docs.unity3d.com/Packages/com.unity.render-pipelines.high-definition@12.1/manual/Shadows-in-HDRP.html

It also provides some good explanation of the significance, and situations, for enabling it:

With this set up, HDRP renders static shadow casters into the shadow map depending on the Light’s Update Mode, but it renders dynamic shadow casters into their respective shadow maps each frame. If you set the Update Mode to OnEnable, HDRP only renders static shadow casters when you enable the Light component. If the Update Mode is to OnDemand, HDRP only renders static shadow casters when you explicitly request an update.

This setup is particularly useful if your environment consists of mostly static GameObjects and the lights don’t move, but there are few dynamic GameObjects that you want the static lights to cast shadows for. In such scenarios, setting the light to have a mixed cached shadow map greatly improves performance both on the CPU and GPU.

So I’m going to try that out and see if it makes much of a difference in terms of performance.

[impheris]

yes i shared an doc from an old hdrp version because you did not specify which version you use, but ok you are now on a good path

[PutridEx]

For directional light, it should be every frame. Can’t be cached well as it depends on frustum view, so you’d need to update it very often, don’t think it’s worth the performance spikes.
Although I hear you can update cascades separately, so that could be worth looking into if you’re making a large world.

For all other lights with shadows, you should set them to on enabled or on demand.
I believe on enabled should work fine, it’ll cache shadows for static objects, and do every frame for dynamic objects with the right settings. (Dynamic part is a recent update)

on enabled basically does a single tick/shadow render when that light is enabled and that’s it, so if a static object was culled, or on a very low poly LOD when it was enabled, the shadows wouldn’t look right.

You can use on demand to manage shadow updates when using something that’s view dependent, like tessellation.
With tessellation cached shadows will look wrong if you only render it once, since it’s view dependent. You’ll have to update it more often with on demand.

You could also use on demand to update once every few seconds, but not just once like “on enable” or every single frame like “every frame”.

Possibly another use case for on demand is when LODs or culling causes issues with shadows, since on enable renders shadows once the light & shadows are enabled, if you enable it from far away it’ll react differently, and it won’t update once the player gets closer.

Fun fact: When using high quality shadow filtering, the entire cost of sampling higher quality soft shadows can’t be cached, and it’s extremely expensive for lights like point/spot (even more than directional light), all the cost will be added to deferred lighting on the GPU.
It’ll still cache the shadow render, but that’s nothing compared to the sampling cost.

[dgoyette]

@PutridEx

Possibly another use case for on demand is when LODs or culling causes issues with shadows, since on enable renders shadows once the light & shadows are enabled, if you enable it from far away it’ll react differently, and it won’t update once the player gets closer.

Thanks for mentioning that. That’s something I would have probably overlooked.

@PutridEx

Fun fact: When using high quality shadow filtering, the entire cost of sampling higher quality soft shadows can’t be cached, and it’s extremely expensive for lights like point/spot (even more than directional light), all the cost will be added to deferred lighting on the GPU.
It’ll still cache the shadow render, but that’s nothing compared to the sampling cost.

In a quick test, in a “Release” build of my game, I tested “Every Frame” vs “On Enable”, and unfortunately found that even in a scene with a lot of lighting, there wasn’t really any difference in performance that I could notice. However, that was with maxed out settings. I’ll test things again at lower graphics settings. I’d be happy if using “On Enable” instead of “Every Frame” was only a performance boost for lower-end hardware, so I’ll test things without high quality filtering, in case it makes a difference.

[PutridEx]

@dgoyette

In a quick test, in a “Release” build of my game, I tested “Every Frame” vs “On Enable”, and unfortunately found that even in a scene with a lot of lighting, there wasn’t really any difference in performance that I could notice. However, that was with maxed out settings. I’ll test things again at lower graphics settings. I’d be happy if using “On Enable” instead of “Every Frame” was only a performance boost for lower-end hardware, so I’ll test things without high quality filtering, in case it makes a difference.

On high filtering, all sampling cost is added to deferred lighting (seen in GPU unity profiler), the caching will remove the shadow.render (forgot the exact name) cost, found in the GPU profiler, which is small compared to sampling costs. the HDRP team should separate the directional light shadow filtering mode from other lights, that way you can enable high quality shadow filtering just for the directional light. Similar to what they already do with area light shadows.

In medium, the effect is much more noticeable. With unity profiler, enable GPU module and look into it’s performance, using the profiler’s hierarchy mode, search for “shadows”, you’ll see the cost of shadows. You can do a quick test with a bunch of point lights, when caching, most of the cost will be removed, it’s very helpful when using a lot of point lights with shadows. Other lights as well, but especially point lights. Of course, the bigger the range, the more objects effected by the shadows, increasing the cost

• also, my 1000th post! a thread about shadows and performance is a good place for it