Normalized z-depth shader (based on the cycles camera data node)

Question

I'm trying to create a shader that displays the normalized (0 to 1) camera Z-dpeth on top of the viewed object.

Yeah, I know I can easily do this in post with the normalize node if I render out the z depth pass, but I prefer to have this in a shader.

I tried to do this with an OSL script using the clamp function but it didn't really do what I wanted. See image below for clarification:

You can see the desired result on the right (achieved with compositor nodes), and the existing result on the left (with shader nodes).

This is the OSL script that didn't quite get me where I wanted, but might be a good start (I intended to use it between the camera data and emission nodes, the same way I use the normalize node in the compositor):

shader normalize_value(
    float inputValue = 0.0,
    output float normalizedValue = 0.0
){
    normalizedValue = clamp(inputValue, 0, 1);
}

I'm of course open to any other method, for instance involving other shader nodes (I couldn't find a way to get the same result but hey who knows!).

Answer 1

(Limitiations: Normalize is done per-object. I believe there is no way in native shader nodes to fix this.)

---

By using the generated coordinates, we can access the bounding box for the object.

Using this, we could estimate the depth the object occupies, and set min and max for the clamping operation.

---

However a much more elegant solution arises:

By dot-producting with the camera vector, we can sample the texel's position within its own space, along the camera's (local Z) vector. Using a bit of additionnal math, we ajust the generated to operate on [1:-1], then bring the result back to [0:1]

---

Note: because the "incoming" vector describes not the camera's Z vector, but the vector from the texel to thec camera origin. It's not ''flat'' raster distance that is calculated but the arguably more correct stereographic distance, of camera X + camera Y + camera Z local distances. This can be if needed, by deriving the camera vector from a different source or correcting it before the dot-product operation

Answer 2

If it's ok to put in some values manually, you can use a Cycles shader like this. You have to know the distance of your scene from the camera and the scene size along camera z. In this example the object starts 3 units away from the camera and has a size along camera z of 2 units.

Input the values into the two red value nodes.

Answer 3

Try to scale (multiply) the values first followed by other math operations.

(original - min)/(max - min)

I am investigating clamping numbers to the same type ... float values clamp(inputValue, 0.0, 1.0);

---

Guessing example. For example ... (original * (.5)) + offset ..... Then clamp.

Answer 4

If you don't want to hardcode the near/far planes distances, you can use two empties for that.

Both are aligned to the camera axis and rotated as the camera is (looking at minus Z). They are also parented to the camera.

From that, you can take the object coordinates of the three objects (the camera, the near empty called 'min' below and the far empty called 'max').

Now, we keep only the Z part of their coordinates and map range the view Z depth from a min value that is the Z distance between the camera and "min" empty and a max value that is the Z distance between the camera and "max" empty.

Once done, invert the resulting color.

(unlinked below, Z of the camera that can be used in place of the "min" empty if you want to get ride of it).

Note: inverting the color is useless, as you can also map range to min = 1 and max = 0.

To move the empties, use GZZ to grab them along their own Z axis.