Problem with Z-Depth output

[juangea]

HI there.

We are using the Z-Depth for the support of Layama app in Blender/LuxCore.

But it seems the Z-Depth channel is acting werid, in this picture you can see an Eevee (Left) vs LuxCore (Right) output, I don't understand why is there such a big difference in the Z Depth output:

This leads a problem in the geometry calculation for the webapp, Left is LuxCore Z-Depth result, Right is Eevee Z_Depth result:

Some ideas on why may this be happening?

Some setting?

Thanks!

[Dade]

LuxCore Depth AOV is the distance from the film image plane, may be Eevee uses something different like distance from the camera position

[juangea]

Yes, I think Cycles/Eevee give the Z pass from the camera position, is there a way to counteract this?

Thanks!

[juangea]

And another qustion, trying to find an alternative option, the "Position" AOV inside the Geometry section, is World Position or Camera Position?

[Dade]

Yes, I think Cycles/Eevee give the Z pass from the camera position, is there a way to counteract this?

I can add a new AOV with this information (in v2.4). However I would further investigate the topic of Cycles/Eevee Z pass just to be sure how they work.

I don't think there is a viable work around at the moment aside form using the (first hit point) Position AOV and doing the math (<position> - <camera origin>)

[B.Y.O.B.]

And another qustion, trying to find an alternative option, the "Position" AOV inside the Geometry section, is World Position or Camera Position?

World position.

[juangea]

I think we will be able to use the POSITION AOV since it's World Position, instead of the Z-Depth, so we are fine

But could be a good idea to have a Z-Depth, in the future, that measures the things in the same way as Cycles/Eevee, just ot make easier the life of compositing people in mixed pipelines or with already defined pipelines and comps.

[CodeHD]

Hi,

I've been investigating the depth AOV a bit after yesterdays discussion in the radio-modelling thread.
After far too much unneccessary checking, I've noticed the following (blend-file attached for a test setup - camera at centre of a hollow sphere carved into a cube):

With LuxCore standalone, I get distance from the camera plane for ortho camera:

and distance from the camera point with perspective:

Rendering and saving from Blender, however, I get something quite different:

By my observations it is some factor times Dot(RayDirection, SurfaceNormal)^3
The World position AOV gives exactly the same output btw.

I tried following it through the code myself, but in blendluxcore i stalled at engine/final.py, _add_passes(), where I can't find the definition of eninge.add_pass(), also not in LuxCore. I assume it is part of pyluxcore? Or did Visual studios search just fail me?

Am I missing some switch in Blender here or does it really parse a wrong output?

[B.Y.O.B.]

in blendluxcore i stalled at engine/final.py, _add_passes(), where I can't find the definition of eninge.add_pass()

It is a Blender API method: https://docs.blender.org/api/current/bp ... e.add_pass
But it's not important to your problem.
You probably want to look at the LuxCore code where the depth AOV output is computed.

Or maybe this?
https://github.com/LuxCoreRender/LuxCor ... r.cpp#L166
It is used in the addon here: https://github.com/LuxCoreRender/BlendL ... nal.py#L25

[Dade]

Or maybe this?
https://github.com/LuxCoreRender/LuxCor ... r.cpp#L166

Depth value will be INF if nothing is hit and, in this case, the above code will obliterate all depth values

The above code should check for INF values and ignore them in order to compute the max value.

Anyway, I find it very strange, the scale will change according the farthest hit. It doesn't make sense to me, from the above code, I guess Blender expect depth values bet 0.0 and 1.0 ... but according what metric ?