Customise Consent Preferences

We use cookies to help you navigate efficiently and perform certain functions. You will find detailed information about all cookies under each consent category below.

The cookies that are categorised as "Necessary" are stored on your browser as they are essential for enabling the basic functionalities of the site. ... 

Always Active

Necessary cookies are required to enable the basic features of this site, such as providing secure log-in or adjusting your consent preferences. These cookies do not store any personally identifiable data.

No cookies to display.

Functional cookies help perform certain functionalities like sharing the content of the website on social media platforms, collecting feedback, and other third-party features.

No cookies to display.

Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics such as the number of visitors, bounce rate, traffic source, etc.

No cookies to display.

Performance cookies are used to understand and analyse the key performance indexes of the website which helps in delivering a better user experience for the visitors.

No cookies to display.

Advertisement cookies are used to provide visitors with customised advertisements based on the pages you visited previously and to analyse the effectiveness of the ad campaigns.

No cookies to display.

[ad_1]

There’s this Q&A: SV_POSITION in pixel shader, however the reply is incomplete so this query is asking for the entire reply.

What are SV_POSITION.z and SV_POSITION.w in a pixel shader and the way are they calculated?

Word: I am not on the lookout for generalities. I am on the lookout for the precise math. Given clip house coordinates p1, p2, p3 for a triangle, a viewport setting, a depth vary setting, then, given any fragment coordinate, what’s the math to compute SV_POSITION.z and SV_POSITION.w?

In OpenGL that is spelled out for gl_FragCoord which appears just like SV_POSITION however the values in DirectX 12 are completely different sufficient that it isn’t clear how z and w are calculated and I’ve had no luck discovering a spec.

The OpenGL math appears to be

  • clip => ndc

    which is simply ndc = clip.xyz/.clip.w

  • ndc => window

    which is successfully

    window.xy = (ndc.xy * 0.5 + 0.5) * viewport_range + viewport_x
    window.z = (ndc.z * 0.5 + 0.5) * depth_range + depth_near
    

Then, for every fragment:

  • compute a barycentric coordinate for fragcoord.xy relative to the second window triangle (so no z)

  • gl_FragCoord.z = the three window.z values * the barycentric coordinate (ie, linear iterpolation)

  • gl_FragCoord.w = 1 / (the clipspace.w values perspective-interpolated by the barycentric coordinates)

the place perspective-interpolation is outlined as

   f =  a(fa)/wa + b(fb)/wb + c(fc)/ wc
       ----------------------------------
             a/wa + b/wb + c/wc

the place a, b, c are the barycentric coordinates, wa, wb, wc are the clipspace.w coordinates, and fa, fb, fc are the three values being interpolated. On this case IIUC they’re the identical clipspace.w coords

Doing that math appears to compute the proper gl_FragCoord.zw values. What’s the equal math for SV_POSITION.zw?

Word: On DirectX window.z can be ndc.z * depth_range + depth_near I feel however simply making that adjustments does not match the SV_POSITION.zw values I get from rendering.

[ad_2]

Leave a Reply

Your email address will not be published. Required fields are marked *