Difference between revisions of "Compute eye space from window space"
(Stub for unfinished.) |
(Not a stub.) |
||
(4 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
This page will explain how to recompute eye-space vertex positions given window-space vertex positions. This will be shown for two cases. Case 1 uses {{code|gl_FragCoord}} in its entirety. Case 2 uses only {{code|gl_FragCoord.xyz}}. Both require access to the projection matrix. | This page will explain how to recompute eye-space vertex positions given window-space vertex positions. This will be shown for two cases. Case 1 uses {{code|gl_FragCoord}} in its entirety. Case 2 uses only {{code|gl_FragCoord.xyz}}. Both require access to the projection matrix. | ||
− | |||
− | |||
== Definitions == | == Definitions == | ||
Line 39: | Line 37: | ||
== From gl_FragCoord == | == From gl_FragCoord == | ||
− | {{code|gl_FragCoord}} | + | {{code|gl_FragCoord.xyz}} is the window-space position W, a 3D vector quantity. {{code|gl_FragCoord.w}} contains the inverse of the clip-space W: <math>gl\_FragCoord_w = \tfrac{1}{C_w}</math>. |
Given these values, we have a fairly simple system of equations: | Given these values, we have a fairly simple system of equations: | ||
Line 80: | Line 78: | ||
What we are missing is the original window-space '''W''' coordinate. | What we are missing is the original window-space '''W''' coordinate. | ||
− | Therefore, we must find a way to compute it from the window-space XYZ coordinate and the perspective projection matrix. This discussion will assume | + | Therefore, we must find a way to compute it from the window-space XYZ coordinate and the perspective projection matrix. This discussion will assume your perspective projection matrix is of the following form: |
+ | |||
+ | [ xx xx xx xx ] | ||
+ | [ xx xx xx xx ] | ||
+ | [ 0 0 T1 T2 ] | ||
+ | [ 0 0 E1 0 ] | ||
+ | |||
+ | The {{code|xx}} mean "anything;" they can be any value you use in your projection. The 0's must be zeros in your projection matrix. {{code|T1}}, {{code|T2}}, and {{code|E1}} can be any arbitrary terms, depending on how your projection matrix works. | ||
+ | |||
+ | If your projection matrix does not fit this form, then the following code will get a lot more complicated. | ||
+ | |||
+ | === From window to ndc === | ||
+ | |||
+ | We have the XYZ of window space: | ||
+ | |||
+ | <math> | ||
+ | \vec W = | ||
+ | \begin{bmatrix} | ||
+ | gl\_FragCoord.x\\ | ||
+ | gl\_FragCoord.y\\ | ||
+ | fromDepthTexture | ||
+ | \end{bmatrix} | ||
+ | </math> | ||
+ | |||
+ | Computing the NDC space from window space is the same as the above: | ||
+ | |||
+ | <math> | ||
+ | \vec N = | ||
+ | \begin{bmatrix} | ||
+ | \tfrac{(2 * W_x) - (2 * V_x)}{V_w} - 1\\ | ||
+ | \tfrac{(2 * W_y) - (2 * V_y)}{V_h} - 1\\ | ||
+ | \tfrac{(2 * W_z) - D_f - D_n}{D_f - D_n} - 1 | ||
+ | \end{bmatrix} | ||
+ | </math> | ||
+ | |||
+ | Just remember: the viewport and depth range parameters are, in this case, the parameters that were used to render the ''original scene''. The viewport should not have changed of course, but the depth range certainly could (assuming you even have a depth range in the lighting pass of a deferred renderer). | ||
+ | |||
+ | === From NDC to clip === | ||
+ | |||
+ | For the sake of simplicity, here are the equations for going from NDC space to clip space: | ||
+ | |||
+ | <math> | ||
+ | \begin{align} | ||
+ | C_w & = \tfrac{T2}{N_z - \tfrac{T1}{E1}}\\ | ||
+ | \vec C_{xyz} & = \vec N * C_w | ||
+ | \end{align} | ||
+ | </math> | ||
+ | |||
+ | ==== Derivation ==== | ||
+ | |||
+ | Deriving those two equiations is very non-trivial; it's a pretty big stumbling block. Let's start with what we know. | ||
+ | |||
+ | We can convert from clip space to NDC space, so we can go back: | ||
+ | |||
+ | <math> | ||
+ | \begin{align} | ||
+ | \vec N & = \tfrac{\vec C}{C_w}\\ | ||
+ | \vec C & = \vec N * C_w | ||
+ | \end{align} | ||
+ | </math> | ||
+ | |||
+ | The problem is that we don't have C<sub>w</sub>. We were able to use {{code|gl_FragCoord.w}} to compute it before, but that's not available when we're doing this after the fact in a deferred lighting pass. | ||
+ | |||
+ | So how do we compute it? Well, we know that the clip space position was originally computed like this: | ||
+ | |||
+ | <math> | ||
+ | \vec C = M * \vec P | ||
+ | </math> | ||
+ | |||
+ | Therefore, we know that C<sub>w</sub> was computed by the dot-product of P with the fourth row of M. And given our above definition of the fourth row of M, we can conclude: | ||
+ | |||
+ | <math> | ||
+ | \begin{align} | ||
+ | C_w & = E1 * P_z\\ | ||
+ | \vec N & = \tfrac{\vec C}{E1 * P_z} | ||
+ | \end{align} | ||
+ | </math> | ||
+ | |||
+ | Of course, this just trades one unknown for another. But we can use this. It turns out that N<sub>z</sub> has something in common with this: | ||
+ | |||
+ | <math> | ||
+ | N_z = \tfrac{C_z}{E1 * P_z} | ||
+ | </math> | ||
+ | |||
+ | It's interesting to look at where C<sub>z</sub> comes from. As before, we know that it was computed by the dot-product of P with the ''third'' row of M. And again, given our above definition for M, we can conclude: | ||
+ | |||
+ | <math> | ||
+ | \begin{align} | ||
+ | C_z & = T1 * P_z + T2 * P_w\\ | ||
+ | N_z & = \tfrac{T1 * P_z + T2 * P_w}{E1 * P_z} | ||
+ | \end{align} | ||
+ | </math> | ||
+ | |||
+ | We still have two unknown values here, P<sub>z</sub> and P<sub>w</sub>. However, we can assume that P<sub>w</sub> is 1.0, as this is usually the case for eye space positions. Given that assumption, we only have one unknown, P<sub>z</sub>, which we can solve for: | ||
+ | |||
+ | <math> | ||
+ | \begin{align} | ||
+ | P_w & = 1.0\\ | ||
+ | N_z & = \tfrac{T1 * P_z + T2}{E1 * P_z}\\ | ||
+ | N_z & = \tfrac{T1}{E1} + \tfrac{T2}{E1 * P_z}\\ | ||
+ | N_z - \tfrac{T1}{E1} & = \tfrac{T2}{E1 * P_z}\\ | ||
+ | E1 * P_z & = \tfrac{T2}{N_z - \tfrac{T1}{E1}}\\ | ||
+ | P_z & = \tfrac{T2}{E1 * (N_z - \tfrac{T1}{E1})}\\ | ||
+ | P_z & = \tfrac{T2}{E1 * N_z - T1} | ||
+ | \end{align} | ||
+ | </math> | ||
+ | |||
+ | Now armed with P<sub>z</sub>, we can compute C<sub>w</sub>: | ||
+ | |||
+ | <math> | ||
+ | \begin{align} | ||
+ | C_w & = E1 * P_z\\ | ||
+ | C_w & = \tfrac{T2}{N_z - \tfrac{T1}{E1}} | ||
+ | \end{align} | ||
+ | </math> | ||
+ | |||
+ | And thus, we can compute the rest of C from this: | ||
+ | |||
+ | <math> | ||
+ | \begin{align} | ||
+ | \vec C_{xyz} & = \vec N * C_w\\ | ||
+ | \vec C_{xyz} & = \vec N * (\tfrac{T2}{N_z - \tfrac{T1}{E1}}) | ||
+ | \end{align} | ||
+ | </math> | ||
+ | |||
+ | === From clip to eye === | ||
+ | |||
+ | With the full 4D vector C computed, we can compute P just as before: | ||
+ | |||
+ | <math> | ||
+ | \vec P = M^{-1}\vec C | ||
+ | </math> | ||
+ | |||
+ | === GLSL example === | ||
+ | |||
+ | Here is some GLSL sample code for what this would look like: | ||
+ | |||
+ | <source lang="glsl"> | ||
+ | uniform mat4 persMatrix; | ||
+ | uniform mat4 invPersMatrix; | ||
+ | uniform vec4 viewport; | ||
+ | uniform vec2 depthrange; | ||
+ | |||
+ | vec4 CalcEyeFromWindow(vec3 windowSpace) | ||
+ | { | ||
+ | vec3 ndcPos; | ||
+ | ndcPos.xy = ((2.0 * windowSpace.xy) - (2.0 * viewport.xy)) / (viewport.zw) - 1; | ||
+ | ndcPos.z = (2.0 * windowSpace.z - depthrange.x - depthrange.y) / | ||
+ | (depthrange.y - depthrange.x); | ||
+ | |||
+ | vec4 clipPos; | ||
+ | clipPos.w = persMatrix[3][3] / (ndcPos.z - (persMatrix[4][3] / persMatrix[3][4])); | ||
+ | clipPos.xyz = ndcPos * clipPos.w; | ||
+ | |||
+ | vec4 eyePos = invPersMatrix * clipPos; | ||
+ | } | ||
+ | </source> | ||
+ | |||
+ | {{code|viewport}} is a vector containing the viewport parameters. {{code|depthrange}} is a 2D vector containing the {{apifunc|glDepthRange}} parameters. | ||
[[Category:Algorithm]] | [[Category:Algorithm]] |
Revision as of 19:14, 9 February 2013
This page will explain how to recompute eye-space vertex positions given window-space vertex positions. This will be shown for two cases. Case 1 uses gl_FragCoord in its entirety. Case 2 uses only gl_FragCoord.xyz. Both require access to the projection matrix.
Contents
Definitions
Before we begin, we need to define some symbols:
Symbol | Meaning |
---|---|
M | The projection matrix |
P | The eye-space position, 4D vector |
C | The clip-space position, 4D vector |
N | The normalized device coordinate space position, 3D vector |
W | The window-space position, 3D vector |
V_{x, y} | The X and Y values passed to glViewport |
V_{w, h} | The width and height values passed to glViewport |
D_{n, f} | The near and far values passed to glDepthRange |
From gl_FragCoord
gl_FragCoord.xyz is the window-space position W, a 3D vector quantity. gl_FragCoord.w contains the inverse of the clip-space W: .
Given these values, we have a fairly simple system of equations:
In a GLSL fragment shader, the code would be as follows:
vec4 ndcPos;
ndcPos.xy = ((2.0 * gl_FragCoord.xy) - (2.0 * viewport.xy)) / (viewport.zw) - 1;
ndcPos.z = (2.0 * gl_FragCoord.z - gl_DepthRange.near - gl_DepthRange.far) /
(gl_DepthRange.far - gl_DepthRange.near);
ndcPos.w = 1.0;
vec4 clipPos = ndcPos / gl_FragCoord.w;
vec4 eyePos = invPersMatrix * clipPos;
This assumes the presence of a uniform called viewport, which is a vec4, matching the parameters to glViewport, in the order passed to that function. Also, this assumes that invPersMatrix is the inverse of the perspective projection matrix (it is a really bad idea to compute this in the fragment shader). Note that gl_DepthRange is a built-in variable available to the fragment shader.
From XYZ of gl_FragCoord
This case is mostly useful for deferred rendering techniques. In deferred rendering, we render the material parameters of our objects to images. Then, we make several passes over these images, loading those material parameters and performing lighting computations on them.
In the light pass, we need to reconstruct the eye-space vertex position in order to do lighting. However, we do not actually have gl_FragCoord; not for the fragment that produced the material parameters. Instead, we have the window-space X and Y position, from gl_FragCoord.xy, and we have the window-space depth, sampled by accessing the depth buffer, which was also saved from the deferred pass.
What we are missing is the original window-space W coordinate.
Therefore, we must find a way to compute it from the window-space XYZ coordinate and the perspective projection matrix. This discussion will assume your perspective projection matrix is of the following form:
[ xx xx xx xx ] [ xx xx xx xx ] [ 0 0 T1 T2 ] [ 0 0 E1 0 ]
The xx mean "anything;" they can be any value you use in your projection. The 0's must be zeros in your projection matrix. T1, T2, and E1 can be any arbitrary terms, depending on how your projection matrix works.
If your projection matrix does not fit this form, then the following code will get a lot more complicated.
From window to ndc
We have the XYZ of window space:
Computing the NDC space from window space is the same as the above:
Just remember: the viewport and depth range parameters are, in this case, the parameters that were used to render the original scene. The viewport should not have changed of course, but the depth range certainly could (assuming you even have a depth range in the lighting pass of a deferred renderer).
From NDC to clip
For the sake of simplicity, here are the equations for going from NDC space to clip space:
Derivation
Deriving those two equiations is very non-trivial; it's a pretty big stumbling block. Let's start with what we know.
We can convert from clip space to NDC space, so we can go back:
The problem is that we don't have C_{w}. We were able to use gl_FragCoord.w to compute it before, but that's not available when we're doing this after the fact in a deferred lighting pass.
So how do we compute it? Well, we know that the clip space position was originally computed like this:
Therefore, we know that C_{w} was computed by the dot-product of P with the fourth row of M. And given our above definition of the fourth row of M, we can conclude:
Of course, this just trades one unknown for another. But we can use this. It turns out that N_{z} has something in common with this:
It's interesting to look at where C_{z} comes from. As before, we know that it was computed by the dot-product of P with the third row of M. And again, given our above definition for M, we can conclude:
We still have two unknown values here, P_{z} and P_{w}. However, we can assume that P_{w} is 1.0, as this is usually the case for eye space positions. Given that assumption, we only have one unknown, P_{z}, which we can solve for:
Now armed with P_{z}, we can compute C_{w}:
And thus, we can compute the rest of C from this:
From clip to eye
With the full 4D vector C computed, we can compute P just as before:
GLSL example
Here is some GLSL sample code for what this would look like:
uniform mat4 persMatrix;
uniform mat4 invPersMatrix;
uniform vec4 viewport;
uniform vec2 depthrange;
vec4 CalcEyeFromWindow(vec3 windowSpace)
{
vec3 ndcPos;
ndcPos.xy = ((2.0 * windowSpace.xy) - (2.0 * viewport.xy)) / (viewport.zw) - 1;
ndcPos.z = (2.0 * windowSpace.z - depthrange.x - depthrange.y) /
(depthrange.y - depthrange.x);
vec4 clipPos;
clipPos.w = persMatrix[3][3] / (ndcPos.z - (persMatrix[4][3] / persMatrix[3][4]));
clipPos.xyz = ndcPos * clipPos.w;
vec4 eyePos = invPersMatrix * clipPos;
}
viewport is a vector containing the viewport parameters. depthrange is a 2D vector containing the glDepthRange parameters.