Pixel Bender depth map shader

Since I’m still in my honeymoon-phase with Pixel Bender, I decided to try to make a basic depth-map shader with it.
Just to quickly summarize, depth maps are images which can be used – among other things – to define complex multiple depth-level occlusion/masking situations in a scene.
This can come handy in games for example, and can work very nicely especially with pre-rendered scenes, where very precise procedural depth-maps can be generated.

Alright, let’s take a look at it: the single greyscale depth-map to the right was used to define levels of depth in the example below. If you play around with it and push the red tag in/out along the z axis, you can observe how it’s possible to dynamically position it between any two of the little clone-troopers, and still retain correct masking.

Neat, huh? Now, the Pixel Bender code to achieve this is literally about this much:

<languageversion : 1.0;>
 
kernel DepthMapShader
< namespace : "com.etoth";
    vendor : "edvardtoth.com";
    version : 1;
    description : "Depth Map Shader";
>
{
    parameter float zDepth
    < minValue:0.0;
        maxValue:1.0;
        defaultValue:1.0;
    >;
 
    // this is the depth-map image providing the alpha-values
    input image4 dmap; 
    // this is the bitmapdata the red tag is drawn into
    input image4 canvas;
 
    output pixel4 dst;
 
    void evaluatePixel()
    {
       float fadeRatio = 15.0;
       pixel4 dm = sampleNearest (dmap, outCoord());
 
       if (dm.a < = zDepth)
       {
            dst = sampleNearest (canvas, outCoord());
       }
        else
        {
            float difference = (dm.a - zDepth) * fadeRatio;
 
            dst = sampleNearest (canvas, outCoord()) - difference;
        }
    }
}

I’d like you to imagine how much more painful and clunky would it be to get the same effect and behavior by more “traditional” means. Yeah, exactly.

While the main effect came together fairly quickly, I learned quite a bit of new – and largely unrelated – stuff during the course of this experiment. Perhaps most notably I ran into a pretty mind-boggling issue involving the Matrix and Matrix3D classes, which Mike Chambers describes very thoroughly in this post.
This made me run a few rather annoying circles around the whole concept of how the z-axis movement was done, but I guess all’s well that ends well.

By the way, to give proper credit, the funny clone-trooper photo is from here.