wrong Zdepth data in Cycles
Closed, ArchivedPublic


In the attached file you can see that after rendering a couple of frames there's a flickering on the zdepth channel when it's rendering with cycles, if you switch to the blender internal render it's completely fine. The problem is only with the zdepth channel in cycles

More information:




To Do

It's a precision issue, where in one pixel a ray manages to slip through between two triangles. Usually you wouldn't notice this and the Z Depth channel itself does not flicker, but in this case the Normalize node is used, which is sensitive to changes in a single pixel. I'll see if I can fix this precision issue, but in general I'd suggest to not use the Normalize node for this kind of setup, in this simple scene it works but in general it can give issues even if tiny object move in/out of the camera view.

I also tried with a different setup for export the depth pass data into a bitmap file with the same results. What I did was to use a map value with a color ramp the problem is that all the data comming from the depth channel in cycles is corrupt or something so the values "dance" and produce this flickering thing. With Blender internal is fine. Do you suggest another way to export the depth pass?

I'm quite sure there is no flickering as long as you do not use the Normalize node, I tested it here and it works fine.

I'm checking this more in deep, doing some extra test, I'll provide additional information tomorrow or so, thanks Brecht.

Any news here? Otherwise I suggest to close and maybe mark as ToDo.

I did a few more tests and I think the only problem is with the depth values in cycles when using the normalize option. This is something that really confusse me a lot, the fact that some channels (vector channel, depth, normals...) looks completely different from Blender Internal to Cycles. IMO it should look exactly the same all the channels. So I think is more a ToDo list than something to just ignore.

Yes, will make this a todo. Improving raytracing precision is a nice thing to work on but we'll never get it 100% anyway, due to float precision.

I can confirm this problem. I did not know the normalize node was at fault, but it is my preferred way to render out a depth pass as a png.