Search Unity

  1. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

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

Discussion in 'High Definition Render Pipeline' started by SebLagarde, Apr 14, 2023.

  1. SebLagarde

    SebLagarde

    Unity Technologies

    Joined:
    Dec 30, 2015
    Posts:
    932
    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

    upload_2023-4-14_18-8-1.png

    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.

    upload_2023-4-14_18-13-45.png

    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.

    upload_2023-4-14_18-19-25.png

    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.

    upload_2023-4-14_18-24-37.png

    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.
     

    Attached Files:

  2. SebLagarde

    SebLagarde

    Unity Technologies

    Joined:
    Dec 30, 2015
    Posts:
    932
    The code in case mention above
     

    Attached Files:

    chap-unity, nehvaleem and Chris_Webb like this.
  3. Chris_Webb

    Chris_Webb

    Joined:
    Mar 18, 2014
    Posts:
    128
    Thanks so much, the ability to change these settings at runtime is exactly what we needed :)
     
  4. PutridEx

    PutridEx

    Joined:
    Feb 3, 2021
    Posts:
    1,133
    On this topic, it would also be great to split directional shadow filtering into two settings, one for directional light, second for point/spotlights. Similar to what's done with Area shadow filtering having its own setting.

    Point light shadows with high filtering are very expensive, and you can't cache the expensive sampling that comes with high quality shadow filtering
     
  5. chap-unity

    chap-unity

    Unity Technologies

    Joined:
    Nov 4, 2019
    Posts:
    750
    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)
     
    Chris_Webb likes this.
  6. slime73

    slime73

    Joined:
    May 14, 2017
    Posts:
    107
    Thank you! Having to change the whole pipeline just for shadow settings has been really annoying and it means there's a combinatorial explosion of pipeline assets when more setting changes are desired. I'm really happy you're addressing that. :)

    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.

    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.
     
    Chris_Webb likes this.
  7. Chris_Webb

    Chris_Webb

    Joined:
    Mar 18, 2014
    Posts:
    128
    I see this as the "correct" solution too. This will allow HDRP to move in line with builtin and URP, which both offer a setting per light.

    https://docs.unity3d.com/Packages/c...rsal@16.0/manual/whats-new/urp-whats-new.html
     
  8. Julien_Unity

    Julien_Unity

    Unity Technologies

    Joined:
    Nov 17, 2015
    Posts:
    72
    > 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.
     
    Chris_Webb likes this.
  9. slime73

    slime73

    Joined:
    May 14, 2017
    Posts:
    107
    That all makes sense to me. Thanks for the quick reply :)
     
  10. jjejj87

    jjejj87

    Joined:
    Feb 2, 2013
    Posts:
    1,113
  11. eggsamurai

    eggsamurai

    Joined:
    Oct 10, 2015
    Posts:
    103
    Deferred.compute: Kernel at index (xx) is invalid.. in build not work at all


    ...

    Compute shader (Deferred): Can't find kernel (2) variant with keywords: AREA_SHADOW_MEDIUM PROBE_VOLUMES_L2 SCREEN_SPACE_SHADOWS_OFF SHADOW_LOW
    ...
     
    Last edited: Jun 16, 2023
  12. Reanimate_L

    Reanimate_L

    Joined:
    Oct 10, 2009
    Posts:
    2,788
    Is there a plan to change this? Player usually doesn't like this kind of implementation where they have to going back to main menu or even restart the entire game just to change a graphic settings?