There are many occasions when the fragment position in world space needs to be reconstructed from a texture holding the scene depth (depth texture). One example of use is in deferred rendering when trying to decrease memory usage by not saving the position but instead only the depth. This will result in one channel of data, instead of three channels needed when saving the whole position.

There are different ways to save the depth. The most popular are view space depth and screen space depth. Saving depth in view space instead of screen space gives two advantages. It’s faster, and it gives better precision because it’s linear in view space.

This is how screen space depth can be rendered in HLSL:

struct VS_OUTPUT
{
   float4 Pos: POSITION;
   float4 posInProjectedSpace: TEXCOORD0;
};
 
// vertex shader
VS_OUTPUT vs_main( float4 Pos: POSITION )
{
   VS_OUTPUT Out = (VS_OUTPUT) 0;
   Out.Pos = mul(Pos,matWorldViewProjection);
   Out.posInProjectedSpace = Out.Pos;
   return Out;
}
 
// pixel shader
float4 ps_main( VS_OUTPUT Input ) : COLOR
{
   float depth = Input.posInProjectedSpace.z / Input.posInProjectedSpace.w;
   return depth;
}

The HLSL pixel shader below shows how the position can be reconstructed from the depth map stored with the code above. Although this is one of the slowest ways of doing position reconstruction since it requires a matrix multiplication.

float4 ps_main(float2 vPos : VPOS;) : COLOR0
{
   float depth = tex2D(depthTexture,vPos*fInverseViewportDimensions + fInverseViewportDimensions*0.5).r;
 
   // scale it to -1..1 (screen coordinates)
   float2 projectedXY = vPos*fInverseViewportDimensions*2-1;
   projectedXY.y = -projectedXY.y;
 
   // create the position in screen space
   float4 pos = float4(projectedXY,depth,1);
 
   // transform position into world space by multiplication with the inverse view projection matrix
   pos = mul(pos,matViewProjectionInverse); 
 
   // make it homogeneous
   pos /= pos.w; // result will be (x,y,z,1) in world space
 
   return pos; // for now, just render it out
}

To reconstruct depth from view space, a ray from the camera position to the frustum far plane is needed. For a full screen quad, this ray can be precalculated for the four corners and passed to the shader. This is how the computer game Crysis did it [1] . But for arbitrary geometry, as needed in deferred rendering, the ray must be calculated in the shaders [2] .

[1] “Finding next gen: CryEngine 2″
http://ati.amd.com/developer/gdc/2007/mittring-finding_nextgen_cryengine2(siggraph07).pdf

[2] “Reconstructing Position From Depth, Continued”
http://mynameismjp.wordpress.com/2009/05/05/reconstructing-position-from-depth-continued/

In [1] they describe a clever way of rendering the thickness of an object in a single pass. The method only correctly works for convex objects but this limitation isn’t that bad, the method can often be used to get the approximated thickness of concave objects as well. For example, [1] uses it to fake the light scattering in clouds rendered as billboards. The methods works like this:

The object is rendered and the distance from the near plane is saved in a color channel R. Also, the distance to the far plane is saved in channel G. By rendering with the blend color mode MIN, one will get the minimum distance from the near plane in R, and the minimum distance to the far plane in G. By using these two distances, one can easily calculate the thickness of the rendered object with the following formula (1-G) – R (if distance is scaled so one is the the distance between the clip planes). Alpha can be saved as well in the same render pass, by outputting it to the A channel. And selecting blend alpha mode ADD (color and alpha can have different modes). This will add up the alpha.

All this is done in only one pass. Just remember to clear to white before rendering.

The image below shows the thickness of the popular Hebe mesh rendered with this method. This model is not convex, and the problem areas are for example the arm holding the bowl. As one can see, the algorithm believes that the bowl and the shoulder are connected, and therefore believes that part of the object is the thickest.

[1] The Art and Technology of Whiteout
http://ati.amd.com/developer/gdc/2007/ArtAndTechnologyOfWhiteout(Siggraph07).pdf

In DirectX9, one can use instanced billboards to render lots of particles with good performance. Since we presume all particles to be billboards constructed from two triangles forming a quad, by using instancing, we can reuse this geometry data (only uv-coordinates needed) for each particle and therefore saving bandwidth. When rendering, two streams with different frequency should be used.  The quad-geometry data makes the first stream, the second stream consists of the per instance data that is unique for each particle. This instance data could be the position, rotation, color and more. The big drawback with this rendering approach is that it requires hardware instancing support, which means Shader Model 3.0. (or Shader Model 2.0 for ATI cards if using a trick described in the first source below).

This particle rendering approach described in details:
http://zeuxcg.blogspot.com/2007/09/particle-rendering-revisited.html

DirectX9 info about rendering multiple streams
http://msdn.microsoft.com/en-us/library/bb147299(VS.85).aspx

DirectX9 instancing info
http://msdn.microsoft.com/en-us/library/bb173349(VS.85).aspx

The aim with soft particles is to remove the ugly artifact that appears when the particle quad intersects the scene. There are a lot of different approaches to solve this, some more complicate than others. The simplest formula for soft particles is to just fade the particle if it’s getting to close to the scene. To do this, the scene without particles has to be rendered first and the depth saved in a texture. When drawing the particles, the depth of the particle will be compared to the scene depth. The alpha should be increased by a smooth fade by this depth difference. The formula below in HLSL is the simplest possible for soft particles, and works very well. Scene_depth is the sampled depth (in viewspace) of the scene in the direction of the current pixel. Particle_depth is the depth(in viewspace) of the current particle pixel. Scale is used to control the “softness” of the intersection between particles and scene:

fade = saturate((scene_depth – particle_depth) * scale);

NVIDIA [1] proposes a method that the following fade should be used instead of the linear one described above, to make the fade even smoother.

float Output = 0.5*pow(saturate(2*(( Input > 0.5) ? 1-Input : Input)), ContrastPower);
Output = ( Input > 0.5) ? 1-Output : Output;

Umenhoffer [2] proposes a method called spherical billboards to deal with these problems. In this method, the volume is approximated by a sphere. This method also deals with the near clipplane problem that particles will instantly disappear if they get to close to the camera.

There is also an idea [3] that the alpha channel can be used to represent the density of the particles. Although this method has the drawback that the textures might need to be redone by the artists.

The method by Microsoft [4] uses a combination of spherical billboards and a texture representation of the volume. But instead of using the alpha channel, they ray march the sphere and sample the density and volume from a 3D noise texture. The result can be seen in the image below.

The video below shows how soft shadows can increase realism in games using large particles. It’s originally an ad for Torque 3D engine.

[1] Soft Particles by NVIDIA
http://developer.download.nvidia.com/whitepapers/2007/SDK10/SoftParticles_hi.pdf

[2] Spherical Billboards and their Application to Rendering Explosions
http://www.iit.bme.hu/~szirmay/firesmoke.pdf

[3] A Gamasutra article about soft particles
http://www.gamasutra.com/view/feature/3680/a_more_accurate_volumetric_.php

[4] A DirectX 10 implementation of soft particles by Microsoft, called Volumetric Particles
http://msdn.microsoft.com/en-us/library/bb172449(VS.85).aspx

s683fcw9dj