VisGL depth buffer

[szellmann]

Testing the VisGL device with our example code, we found that the depth values wouldn't behave as expected (or, e.g., as the depths provided by the "visrtx" device do). According to @jeffamstutz the depth values returned by ANARI are supposed to be linear, and should originate at the camera position. For interop with OpenGL, our app therefore transforms these depth values to GL window coordinates (cf. this code).

So I'm wondering if the depth values that the "visgl" device generates are already in window coordinates (which to my understanding they're not supposed to be, according to the specs). Could you please clarify what the format is of the depth buffer obtained by VisGL? (for spheres and cylinders I found fragment shader code that I'm quite sure generates depth in WC, but have a bit of a hard time following what the triangle object shaders do.)

[progschj]

Yes, that's a hole in VisGL at the moment. It just maps whatever is in the depth buffer without attempting any conversion:

VisRTX/devices/gl/src/VisGLFrameObject.cpp

Line 225 in c760f26

void frame_map_depth(ObjectRef<Frame> frameObj, uint64_t size, void **ptr)

The triangle shaders don't explicitly do anything and you just get default depth behavior. The reason why the sphere/cylinder ones have explicit handling is that they have to adjust the depth from the bounding geometry to the "exact geometry" to be consistent with each other and triangles.

To get the correct behavior the code above should run an additional full screen pass or compute shader to linearize the gl depth values based on camera parameters. I just haven't gotten around to it yet and it wasn't higher priority until someone asked. So now it is. I'll get around to it this or next week.

Another approach would be to have a "raw" depth buffer channel and allow querying the gl projection parameters (near/far, or the entire matrix) as a property. But that would be in addition to the spec behavior I guess and be more an opengl interop feature.

[szellmann]

In fact, the current behavior would be useful to us as an extension, because we do the exact opposite of what you do (or, plan to do), i.e., project the linear depth buffers that come out a compliant ANARI implementation. So for us it would actually be helpful if the existing GL depth buffer would be exposed as an extension (e.g., "channel.depth.gl" or so). Then we could query that extension and avoid the back and forth conversion altogether in case the extension is available. I oof course understand that this is a very special use case.

Either way, I'm leaving this issue open for now if this is ok, to keep track of the fact that the depth buffer one currently gets is not linear and that this is a to-do.

[progschj]

Linear depth is now implemented in commit 40a7a4a a quirk of the rasterizer is that the background will have the depth of the far plane which is just slightly behind the actual geometry.