Official How can he change the Shadow Filtering Quality at runtime? - Fix coming

Hi,

We have been inform recently that we can't change Shadow Filtering Quality at runtime in HDRP (or any other settings).
After investigation and discussion we have notice that the settings wasn't use as intented but also uncovered a kind of big oversight on the public API for HDRP asset customization. Shame on us!

Users can have multiple HDRP asset included in a build with different Shadow Filtering settings and swap them at runtime. This works but isn't very flexible since you need to swap the whole HDRP asset.
What isn't possible in current published released: Programmatically change the shadow filtering on the current HDRP asset itself. This is actually true for 99% of settings in the asset as they are read only.
This means you can't modify an HDRP asset from code and you can't even create a new "custom" one where you'd put all the users custom settings.

We are adding a missing public API in the pipeline settings to be able to change them at runtime (or in the editor). And will backport this all the way to 21.3. ASAP

This is the change if you want to patch locally



Note that this comes with two limitations:

• Any setting that is changed at runtime need to have the associated shader variants present in the build. This is done by having HDRP asset(s) with the relevant setting enabled in the build. This means it's the user's responsibility to ensure all relevant variants are included.
• A lot of the settings in the HDRP asset require reinit of the pipeline, so this means you can't change them on the fly during gameplay for example. Those should really only be considered as global settings for the game.

Overall the use case we want to support here with that is for PC games to be able to have a setup screen where users can customize the settings.

Here is a quick sample project that show how the settings was expected to work (TestShadowConfig).
(Note: long time ago I have written a post about how settings work in HDRP, it is still relevant today for the concept: https://forum.unity.com/threads/fin...-getting-started-settings-new-feature.833056/)

Shadow settings are define like this.
On the light, you have shadow resolution settings.
Here you can select "custom" to force a fixed size, or chose low, medium or high.
The intent of those low medium or high is to define the shadow quality for this light inside the game.
For example you could have a high quality shadow for light used in cinematic and low quality shadow for light use only in planar reflection or far away.



Then those Low, Medium and High settings map to numerical value in the HDRP asset.
Here you can define multiple quality settings with multiple HDRP asset, and change the mapping size for shadow resolution for your different quality settings / HDRP Assets.



You could decide for example that Quality Levels Low will be for PS4 and Quality Level Medium for PS5, and Low, Medium and High for PC

Shadow filtering can also be control from the HDRP asset. To be able to build configurable graphics option for a PC game, you need to ensure that all the variant for the graphics choice you offer will be compile. For this you could create a Low, Medium and High HDRP Asset to ensure it will compile all shader variants,
and then at runtime either generate a HDRP on the fly from an existing one and modifying shadow filtering (Custom Pipeline version in screenshot above which doesn't reference any HDRP Asset), or edit an existing one (Custom Filtering HDRP asset in above screenshots).

In the Project, open the TestScene scene, Run playmode. It allow you with the space bar to switch between the various quality settings, and for customazible asset, you can use return key to only edit the shadow quality filtering.



The script in TestShadowConfig\Assets\TestScene\QualitySettingControl.cs give a sample of how to manipulate settings.

The key part is here: (Required the patch provided at the beginning of the post)
asset.currentPlatformRenderPipelineSettings = settings;

where we setup the settings define before.

Note: We don't offer option to control shadow quality filtering from outside of HDRP asset because it required shader variants. If we were willing to offer dynamic way of changing shadow filtering it would be require to have a x4 on all build time all the time. Thus why we defer it to HDRP asset choice.

Hope this help.

 

The code in case mention above

 

To follow the progress of this change, here's the public bug link (to see in starting from which version it's going to be available)

 

> I think having something like a dropdown flags multi-select where I can choose one or many shadow quality settings to include as part of that HDRP Asset, alongside the existing enum dropdown for which of those is currently active would be a nice way to address that first point. Or maybe there are other approaches to avoid possible confusion there too.

We thought about having this but it but it comes with a few issues. First is that you currently can't change shadow filtering quality through frame settings. This means such an enum drop down would only be useful to add variants which could be confusing/detrimental if users aren't well aware of the shader variants issues. Second thing is that when you edit your settings on the camera in the editor, you are in the context of the currently assigned pipeline. This means that we can't do any validation because the pipeline may change depending on the platform/quality level and may not contain the requested filtering quality. This makes validating a build much harder and could also be confusing at edit time.
This is not out of the question but needs to be well thought if we want this to work.

> For the second point, should the setters for those properties be explicit functions which reinitialize the pipeline with some name (or maybe an optional parameter) indicating that they do that? Or some other Reinitialize API that'd you'd call afterward (I don't remember this existing yet but maybe it does already)? Overall I feel like there are some possible API design choices to avoid the confusion that might come with the new flexibility.

The PR exposing the setter for the settings currently reinitialize the pipeline all the time. This is the safest approach for now as it will work exactly like in the editor. We did this to be able to ship a solution quickly without risking many bugs. The reason is that the render loop was written in a way that assumes the pipeline is immutable after initialization so there aren't checks everywhere for value changes. This could be done but would be a massive amount of work and would delay this fix and risk a lot of issues down the line.