Arnold Z pass vs Ray Length in Houdini

[seanmyersWYKWA]

We've had some issues with Arnold's built in Z pass. It writes large values in dead space areas where there are no objects. I'm assuming it's just returning the depth value of the end of the clipping zone.

In the past we've solved this by creating giant spheres surrounding our scenes and set them to force matte the render so we get a value of 0 in the dead space. It isn't a great solution so I've been exploring an alternate approach.

In an AOV shader network, I know that creating a state float and setting it to Ray Length measures the distance between the camera and the objects rendered. In theory this should be the same value as the built in Z pass but I've noticed that it's off by some variable percentage. Something like 2-3 percent. The advantage to using the Ray Length is that I have access to it in the shader network and I can multiply it by another attribute to zero out the dead space.

I decided set up a test to compare the two. I created an attribute in Houdini to measure the distance between the origin of the camera and the geo rendered. It turns out that the Ray Length matches the distance attribute almost exactly, but the built in Z pass seems to be off.

So I suppose I have a multi part question.

1. Is there a way to zero out dead space in the built in Z pass (I'm assuming the answer is no)
2. Is there a way to bring in the Z pass into a shader network to fix it there. I tried a AOV read node but that didn't work, maybe that isn't its intended purpose.
3. If we use ray length instead of the Z pass, is there a way to make it mathematically consistent with the Z pass? Is it possible that the built in Z pass is less accurate than the Ray Length?

[Stephen.Blair]

1. No

2. No

3. Are you using the same filter for your custom depth AOV? I'm seeing 0.1 to 0.2 percent difference

[seanmyersWYKWA]

Thank you for your response! I am using the same filter for the custom AOV. For objects close the camera the difference is quite small, but it does look like it starts increasing in disparity over long distances, like in the range of 500 plus meters. And I mean the percentage of disparity increases as well, not just difference between the two numbers.

I did some research and decided to try and use an OSL shader to generate the Z pass.

https://render.otoy.com/forum/viewtopic.php?f=9&t=68040

I stumbled upon this thread, and I've been using the OSL code from the final entry and it matches Arnold's Z pass pretty much identically with no increase in discrepancy over super long distances. There is some discussion about how there are multiple ways to calculate Z pass here and I suspect that the distance from the film plane along the view vector is the way Arnold does it, as opposed to just measuring the ray distance?

Anyway this is working as intended and I can interact with the depth pass in the AOV shader net now. I'll be running this by our compositors to confirm everything is good but I'm optimistic.

[madsd]

Just a small convenience note.
The Otoy OSL code lacks a vital part IMO.

You are bound to the position of the spherical static position of P in 0,0,0 with it.
P does not sit on the view ray nor does it move with the perspective/camera if you move around, this is a problem if you animate a camera through a shot and want a fixed stream of distance from camera to hit point distance sitting on a constant distance from the camera.

I wrote something a year or so back that can also take any other form of ray lookup shape, a square, concave, convex, and things like displacement maps, instead of the classic spherical P.


You can see I ping the ray I first to establish a dynamic rig.

1/clamp(distance(I,P-point("camera", 0, 0, 0))/1000,0,1);

This camera moves in the Nvidia Cafe scene, and the Z pass follows it automatically.

If you want something like this I can look at sending over a small utility shader, Note Im not using constant values, my shader is meant and designed to be graded for artistic purposes, so it will not match any of the versions you have tried so far only, you can do more with it on the other hand.