Proper Depth Channel

[Patryk Kizny]

I am calculating Z-Depth the following way

Code:

depth = 1.0 - 1.0 / Ray.Pos;

That's all based on standard 3D bundled with Fragmentarium.
This gives me image as attached.
I'm not sure if it's a proper way.

It looks like the depth was calculated as a distance from the center point, not necessarily as a distance from the imaging plane. Or it's just an illussion?

Anybody stumbled upon a proper implementation of Z-Depth as a distance from the imaging plane towards the scene in Z-Direction?

Thanks!

[zebastian]

Imho there is no need for an individual camera lense plane. The camera in itself can be scaled down infinitely small into one camera point, indepently From its field of view and the used Projection. Then the depth is simply the distance from camera to target for each z-pixel. This value should already be present as a side product of the Ray marching process and will have a value From 0 to infinity.
Please correct me, if im wrong.
Precision is an issue Here: in mandelbulber we use this value AS is for openexr. For PNG we clamp it to min max, remap it to log and then scale it to full range (buddhis idea )
See also Here for image saving: https://github.com/buddhi1980/mandelbulber2/blob/master/mandelbulber2/src/file_image.cpp

[hobold]

I'm not sure if it's a proper way.

I am no expert on GPU rasterization of 3d scenes. But I dimly recall that depth buffers usually store 1/z per pixel, where z comes from a coordinate system where all triangles have been transformed to a standard screen space. So z is an orthogonal distance from the display plane, possibly scaled according to the interval between near clipping plane and far clipping plane.

Depth buffers usually do not store ray lengths from eye point to the surface that was hit.

[3dickulus]

this thread describes (mostly) the current state of depth buffer saving in Fragmentarium http://www.fractalforums.com/fragmentarium/exporting-z-buffer-and-transparency/50/
afaik it is "proper"

[Patryk Kizny]

this thread describes (mostly) the current state of depth buffer saving in Fragmentarium http://www.fractalforums.com/fragmentarium/exporting-z-buffer-and-transparency/50/
afaik it is "proper"

I wasn't sure, mostly because of the fact that on the visual I posted you clearly see that the depth is somewhat radial from the center.

[3dickulus]

...from Fragmentarium v1.0.25 Examples/Include/DE-kn2.frag

Code:

        if(depthFlag) {
                // do depth on the first hit not on reflections
                depthFlag=false;
                // for rendering depth to alpha channel in EXR images
                // see http://www.fractalforums.com/index.php?topic=21759.msg87160#msg87160
                if(DepthToAlpha==true) gl_FragDepth = 1.0/Ray.Pos;
                else
                // sets depth for spline path occlusion
                // see http://www.fractalforums.com/index.php?topic=16405.0
                gl_FragDepth = ((1000.0 / (1000.0 - 0.00001)) +
                (1000.0 * 0.00001 / (0.00001 - 1000.0)) /
                clamp(Ray.Pos, 0.00001, 1000.0));
        }

the scene is calculated with 3D projection outside of the GL as an entirely mathematical representation, the derived color values are stored to a texture, the texture is applied to a quad, the quad is rendered by the GL with an (essentially) ortho projection to our screen view, that is : the flat quad fills the flat screen, after the last part of the rendering process the GL has only the quad object to work with so it will fill the depth buffer with the values of the quad surface, a flat plane that does not represent the depth values that correspond to the image. So the above GLSL code allows a choice of what is written to the depth buffer at image calculation time (the intermediate stage). In the case of spline path occlusion, the depth buffer needs values that make sense to the GL so that proper occlusion is done by the hardware wrt path splines vs scene objects, the splines are drawn into the scene before the buffershader (texture to quad) pass and after the mathematical scene calculation, in the case of sending the depth value to the EXR image alpha buffer, the value is : dark = far, light = close, and this is done by reading the depth buffer, C++, from the intermediate buffer before the next GL render cycle trashes it.

this method allows:
1. spline path occlusion (GL depth) http://www.fractalforums.com/fragmentarium/cat-mull-rom-spline-paths-cameraparameter-keyframes/
2. XYZ pos feedback (MBenesi spray gun) http://www.fractalforums.com/fragmentarium/fractal-gun-paintbrushspraypaint-style-modification-of-fractals/30/
3. depth to alpha channel (RGBZ EXR files) http://www.fractalforums.com/fragmentarium/openexr-output-in-fragmentarium-1-0-10/msg86928/

on the visual I posted you clearly see that the depth is somewhat radial from the center.

yes, depth values are a sphere with the camera as origin, in order to minimize the radial distortion you need to move the camera back and decrease the FOV to "flatten" the scene, a pretty standard thing commonly used by film and video directors/producers

Anybody stumbled upon a proper implementation of Z-Depth as a distance from the imaging plane towards the scene in Z-Direction?

to get this kind of Z-Depth the scene would have to be rendered with orthogonal projection and that depth would not match a video unless you have a camera that records video orthogonally.

a bit more info on exactly what you are trying to do might be helpful, I'm going to guess you are looking for a flat boolean clipping plane