Screen Coordinates Override (Re-Submission)

[etienne-p]

Purpose of this PR

Re-submission of #6597 which got reverted due to test failures

This PR introduces Screen Coordinates Override (SCO for the remainder of this document) for both URP and HDRP. SCO
provides a transformation of screen space coordinates when evaluating screen space effects.

We have found it useful in virtual production scenarios.

The first use case for this is Cluster Display (formerly known as Cluster Rendering), that is, distributed rendering. It allows for post effects such as vignette to be properly rendered at the scale of a grid of displays.

Another use case is the implementation of Lens Distortion when replicating the distortion incurred by a physical lens. Since pixels near the edges may be pushed inwards of the viewport by the distortion, we need to render the scene with overscan. (By overscan, we mean rendering to an expanded pixel surface, later cropped out to its original size before being
presented.) To preserve the distortion's aspect in the cropped image, we need to apply a transform to screen space coordinates when the lens distortion is being computed.

The first implementation of this technique was part of the first Cluster Display effort, and was then called Cluster
Display Space or Global Screen Space. A high level description of the technique can be found in
this document and this one.

The switch to the Screen Coordinates Override terminology is justified by the fact that the technique is relevant outside of
Cluster Display. As illustrated above by our Lens Distortion example.

In the changes we regularly see the introduction of 2 fields:

• screenCoordScaleBias holds the scale and bias used to transform screen space coordinates.
• screenSizeOverride holds the screen size (and its reciprocal) to be used in conjunction with transformed screen
  space coordinates.

---

Changes Overview

• SRP Core

  • ScreenCoordOverrideUtils -> basic utilities to manage the shader keyword. Main point is to avoid the duplication of
    the shader keyword.
  • ScreenCoordOverride.hlsl -> shader code and macros to perform the screen space coordinates conversion.

• HDRP

  • FrameSettings -> add ScreenCoordOverride and AsymmetricProjection settings. AsymmetricProjection allows the
    activation of the asymmetric projection code path even when XR is not enabled. This is useful for Cluster Display.
  • HDAdditionalCameraData -> add the ScreenSizeOverride and ScreenCoordScaleBias fields.
  • ShaderVariablesGlobal -> add the ScreenSizeOverride and ScreenCoordScaleBias fields.
  • HDCamera -> update global shader variables.
  • HDRenderPipeline -> activates the shader keyword.
  • HDRenderPipeline.PostProcess -> activates the shader keyword based on frame settings.
  • UberPost.compute -> add SCO support.

• URP

  • ScriptableRenderer -> fix a swap buffer issue (first
    fixed here)
  • PostProcessUtils -> init random generation using frame count so that it's consistent across machines in a Cluster
    Display scenario.
  • UniversalAdditionalCameraData -> add the ScreenSizeOverride and ScreenCoordScaleBias fields and feature
    activation.
  • UniversalRenderPipeline -> populate additional camera data.
  • UniversalRenderPipelineCore -> add fields and associated shader properties.
  • UniversalRenderer -> related to swap buffer fix.
  • Input.hlsl -> add the ScreenSizeOverride and ScreenCoordScaleBias fields.
  • FinalPost.shader -> add SCO support.
  • UberPost.shader -> add SCO support.
  • CapturePass -> fixed color buffer access (before, post effects would not be captured)
  • UniversalRenderPipelineGlobalSettings -> add shader stripping option (SerializedUniversalRenderPipelineGlobalSettings, UniversalRenderPipelineGlobalSettingsUI.Drawers and UniversalRenderPipelineGlobalSettingsUI.Skin were modified to reflect this change)
  • ShaderPreprocessor -> implement shader stripping option

---

Testing status

We added the following graphics tests. We test custom post processes and passes since we want to enable users to use the
feature.

• HDRP_Tests

  • 9930-ScreenCoordOverride -> test with a built-in vignette effect.
  • 9931-ScreenCoordOverrideCustomPostProcess -> test with a custom post process.
  • 9932-ScreenCoordOverrideCustomPass -> test with a custom pass.

• UniversalGraphicsTest_PostPro

  • 250_ScreenCoordOverrideRenderPass -> test with a scriptable render pass.
  • 250_ScreenCoordOverridePostProcess -> test with a built-in vignette post process.

We are also in the process of developing Cluster Display and test this feature as part of our work. We are also adding
graphics test to that package as well.

---

Comments to reviewers

@sandy-carter-unity regarding the swap buffer bug we discussed in late december.
@phi-lira feel free to assign relevant members from your team.
@sebastienlagarde feel free to assign relevant members from your team.
Let me know how CHANGELOG update works, I assume I shouldn't add entries below past releases.

[github-actions]

Hi! This comment will help you figure out which jobs to run before merging your PR. The suggestions are dynamic based on what files you have changed.
Link to Yamato: https://unity-ci.cds.internal.unity3d.com/project/902/
Search for your PR branch using the search bar at the top, then add the following segment(s) to the end of the URL (you may need multiple tabs depending on how many packages you change)

HDRP
/jobDefinition/.yamato%2Fall-hdrp.yml%23PR_HDRP_trunk
With changes to HDRP packages, you should also run
/jobDefinition/.yamato%2Fall-lightmapping.yml%23PR_Lightmapping_trunk

URP
/jobDefinition/.yamato%252Fall-urp.yml%2523PR_URP_trunk
With changes to URP packages, you should also run
/jobDefinition/.yamato%2Fall-lightmapping.yml%23PR_Lightmapping_trunk

SRP Core
You could run ABV on your branch before merging your PR, but it will start A LOT of jobs. Please be responsible about it and run it only when you feel the PR is ready:
/jobDefinition/.yamato%252F_abv.yml%2523all_project_ci_trunk
Be aware that any modifications to the Core package impacts everyone in the Graphics repo so please discuss the PR with your lead.

Depending on the scope of your PR, you may need to run more jobs than what has been suggested. Please speak to your lead or a Graphics SDET (#devs-graphics-automation) if you are unsure.

[github-actions]

It appears that you made a non-draft PR!
Please convert your PR to draft (button on the right side of the page).
See the PR template for more information.
Thank you!

[sebastienlagarde]

submitted on private github