Screen Coordinates Override

[etienne-p]

Purpose of this PR

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.
  • RenderTargetBufferSystem -> remove a method not needed anymore. (Was involved in the swap buffer issue.)
  • 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.

---

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.

[sandy-carter-unity]

Is _ScreenCoordScaleBias meant to be a drop-in replacement for _BlitScaleBias as it is used int the Blitter Api?

[etienne-p]

Is _ScreenCoordScaleBias meant to be a drop-in replacement for _BlitScaleBias as it is used int the Blitter Api?

No it is meant to provide a transformation for screen coordinates, to be performed before some screen space post processing shader computations are performed. You can look at the docs linked in the PR description for more explanations of the problem/solution. I'd also be available for a zoom call :) The only commonality with BlitScaleBias is that we describe our 2D transformation as a scale and translation

[sandy-carter-unity]

These changes look sensible and don't conflict with my dynamic scaling work which touch uv but on the vertex shader side.

[phi-lira]

LGTM overall. Mostly concerned about shader stripping.

[phi-lira]

is this one by chance only used in fragment shader? If so please do multi_compile_fragment

[phi-lira]

This needs to be stripped so we don't regress build times / shader memory. We usually add option so user can optin / optout of feature.

[sebastienlagarde]

please used multi_compile_local_fragment here

[etienne-p]

I need to use multi_compile_fragment here

[phi-lira]

LGTM, thank you for adding the stripping option.

Changes were addressed we need to land

[patrickp-unity3d]

@eturquin do you think that when using this feature users should also use #5953 (when using path tracing)? My guess is otherwise there would be 'noise' seams at the edges of the tiles, correct? Or will ray generation take this PR into account and already be correct?