this post is just a quick recap about the possible ways to reconstruct position from the depth buffer that I found around: almost all the credits goes to http://mynameismjp.wordpress.com/.
Let's define (again) the problem:
Reconstruct pixel position from the depth buffer.
Applying a personal way of seeing code, let's put in evidence Data and Transformations.
In my experience, I came up with a simplicistic idea about coding:
Coding is a sequence of Data transformed into other Data.
I know it is very simplicistic, and low level (we're not taking in account any architecture) but this is a low-level view of the problem.
And more views of the same problem can shed more light on the true nature of the problem itself (as in life in general).
In this problem we have two data: Pixel Position and Depth buffer.
The transformation is reconstruction.
To understand further, we can define the Domains of the datas.
- Pixel position can be either in World Space or in View Space
- Depth buffer can be encoded either in linear or in post-perpsective z (raw depth buffer)
So either the transformations will be from Depth buffer to Pixel position and can be:
- Linear depth buffer to View Space position
- Linear depth buffer to World Space position
- Post-Perspective depth buffer to View Space position
- Post-Perspective depth buffer to World Space position
To finish, we have two other transformations:
- Encode to Linear depth buffer
- Encode to Post-Perspective depth buffer
the post-perspective is hidden by the hardware, and it is what it's inside the real depth buffer.
The linear one maps the eye/camera/view space z to the domain 0..1.
To really finish this introduction to the problem, we must know a little bit about our coordinate system. Moving data from world to view to projection spaces, we must define those domains.
We can just skip World space and concentrate on the other.
If we follow OpenGL or DirectX APIs, we know that they are different in both spaces:
- OpenGL uses a right-handed system for the view space
- DirectX uses a left-handed one
- OpenGL uses a cube between (-1, 1) on x,y,z as projection cube
- DirectX uses a cube between (-1,1) on x,y and (0, 1) on z
Using a right-hand system ends up looking at negative z. Keep this in mind.
ENCODING AND DECODING TRANSFORMATIONS
In this section we'll talk about encoding: what we want to encode?
The raw-depth-buffer contains a depth transformed from the view-space depth, and they are encoded in a simple way, depending on your projection matrix.
Let's take only the relevant part of the matrix (the last 2x2 corner), that is:
( A B ( zView
-1 0 ) 1 )
and multiply it with the point in viewspace Pview(zView, 1).
Doing the multiplication has the result:
Pndc = (A * zView + B, -zView )
to became a 3d point (1d here) we apply the division by W:
Pndc = ( A * zView + B / -zView, 1 ) that further simplified became
Pndc = ( -A - (B / zView), 1).
Zndc so is -A - (B /zView).
This is the way in which the depth is encoded in the depth buffer, and the value is between -1 and 1.
Note: if you try to do some maths and put zView = n and zView = f, you'll notice that the values are not mapped correctly between -1 and 1. This is because we're using negative values, so the correct ones are zView = -n and zView = -f.
To find zView, just solve by zView and we'll obtain:
zView = -B / (zNdc + A )
So now we have defined the two transformations:
Projection-Space Encoding: -A - (B / zView )
Projection-Space Decoding: -B / (zNdc + A)
Ok then, it's finished.
Wait...what are thos A and B???
Those values depends again on the choice of your projection matrix.
In OpenGL they are defined as (n is near plane, f is far plane):
A = - (f + n) / (f - n)
B = -2 * n * f / (f - n)
those values can be easly calculated and passed to the shaders (don't bother doing it inside a shader, those are perfect values to be set once in a frame with other frame-constants) to reconstruct depth.
Different is the linear depth encoding. We're still encoding view-space depth, but that became easier. The values in camera/eye/view space are like world-space, but just centered around the camera. For the right-handed systems, we will encode all the negative z, because the camera is looking into the negative z semi-space.
The z values will be in the range 0, -infinite: the projection will take care of getting rid of values that are smaller than the near plane and greater than the far.
Linear depth encoding: -zView / f
Linear depth decoding: zLin * f
Those values are between 0 and 1.
Finally...some CODE!!!
This is POST-PROJECTION DEPTH:
// Calculate A and B
float rangeInv = 1 / (gFar - gNear);
float A = -(gFar + gNear) * rangeInv;
float B = -2 * gFar * gNear * rangeInv;
// Write -1,1 post-projection z
float encodePostProjectionDepth( float depthViewSpace )
{
float depthCS = -projParams.x - (projParams.y / depthViewSpace);
return depthCS;
}
// Read -1,1 post-projection z
float decodePostProjectionDepth( float2 uv )
{
float depthPPS = tex2D( depthMap, uv ).r;
return depthPPS;
}
// Reconstruct view-space depth (0..far)
float decodeViewSpaceDepth( float2 uv )
{
float depthPPS = decodePostProjectionDepth( uv );
float depthVS = -B / (A + depthPPS);
return depthVS;
}
This is Linear depth
// Encode 0..1 view-space depth
float encodeLinearDepth( float depthViewSpace )
{
return -depthViewSpace / far;
}
// Decode 0..1 view-space depth
float decodeLinearDepth( float2 uv )
{
float linearDepth = tex2D( depthMap, uv ).r;
return linearDepth;
}
// Reconstruct view-space depth (0..far)
float decodeViewSpaceDepth( float2 uv )
{
float linearDepth = decodeLinearDepth( uv );
return linearDepth * f;
}
As you can see using a linear depth is easier to encode and decode, but it's more expensive from a memory point of view (you'll need an additional render target), and you're already using a depth buffer so you already have those informations.
No comments:
Post a Comment