Question about URP coordinate space suffixes

DrummerB · October 2, 2024, 3:11pm

In URP shader code, Unity uses short suffixes to denote what coordinate system a position is in, which is super helpful:

github.com

Unity-Technologies/Graphics/blob/e42df452b62857a60944aed34f02efa1bda50018/Packages/com.unity.render-pipelines.core/ShaderLibrary/Common.hlsl#L16


      
          #endif
          
          // Convention:
          
          // Unity is Y up and left handed in world space
          // Caution: When going from world space to view space, unity is right handed in view space and the determinant of the matrix is negative
          // For cubemap capture (reflection probe) view space is still left handed (cubemap convention) and the determinant is positive.
          
          // The lighting code assume that 1 Unity unit (1uu) == 1 meters.  This is very important regarding physically based light unit and inverse square attenuation
          
          // space at the end of the variable name
          // WS: world space
          // RWS: Camera-Relative world space. A space where the translation of the camera have already been substract in order to improve precision
          // VS: view space
          // OS: object space
          // CS: Homogenous clip spaces
          // TS: tangent space
          // TXS: texture space
          // Example: NormalWS
          
          // normalized / unormalized vector

However, I am somewhat confused by the suffixes used in some built-in functions.

For example:

float2 GetNormalizedScreenSpaceUV(float2 positionCS)
{
    float2 normalizedScreenSpaceUV = positionCS.xy * rcp(GetScaledScreenParams().xy);
    TransformNormalizedScreenUV(normalizedScreenSpaceUV);
    return normalizedScreenSpaceUV;
}

This function seemingly expects a clip space position. But looking at the implementation, it treats it as screen space coordinates. It divides (rcp) the position by the screen resolution to get UV coordinates [0-1], e.g. for sampling a depth texture. Clip space coordinates are homogeneous and have a range of [-w, w] if I am not mistaken.

My assumption is that this is coming from the fact that SV_POSITION varyings/interpolators are a special case and even though a vertex shader is expected to output clip space coordinates, the fragment shader receives interpolated screen space coordinates.

Is this correct or am I confusing something? Are these suffixes incorrect?