Page MenuHomePhabricator

Point Set Interaction not working in 3d window (world point picking broken because depth buffer is empty)
Closed, ResolvedPublic


When a surface is loaded (e.g. book.stl from MITK-Data) and you want to set a point on the surface, the point is not shown on the surface, but somewhere else in the volume.

Event Timeline

mindrocf triaged this task as Normal priority.Feb 2 2018, 4:16 PM
mindrocf created this task.
kislinsk renamed this task from Point Set Interaction not working correctly to Point Set Interaction not working on surfaces.Mar 6 2018, 10:00 AM
kislinsk added a subscriber: kislinsk.

2d display coords are working fine. It's just the depth coord that's off.

All points are added on an imaginary plane parallel to the camera plane. For example, if I add points along an imaginary line on a curvy surface, and rotate the camera up afterwards, you see a straight line.

Adding points:

View from top:

The picking is done in So basically, it uses the z-buffer for the depth value.

I wrote the z-buffer of the 3d window into a PNG file and it is plain white. So I assume, the z-buffer currently is not used as intended and the depth value returned by the WorldPointPicker equals the camera focal point.

kislinsk raised the priority of this task from Normal to High.Mar 26 2018, 10:00 AM
kislinsk moved this task from Backlog to Blocking v2018.04 on the MITK (2018-04) board.

Works in 2016.11. I guess it has something to do with the VTK upgrade resp. the usage of the new OpenGL backend / render window.

I wrote a minimum plain VTK application similar to this one and the z-buffer was filled as expected.
I upgraded the application to use QVTKOpenGLWidget (like the MITK Workbench) and the z-buffer was empty again.
I then explicitly set the number of samples (multisampling) to zero and it worked!
I did the same in MITK (mitkRenderWindow and QmitkRenderWindow as well as BaseApplication initialization) and the z-buffer was still empty.
I can't figure out what still prevents the z-buffer from being written to in contrast to the minimum VTK application.
As next step I want to write a minimum MITK application like the MITK tutorial steps and see if I can narrow down the actual issue.

I stepped into the rendering of VTK's poly data mapper. The rendering uses shaders and there is a template for a depth pass. I noticed that this template is not replaced with a concrete implementation because glIsEnabled(GL_MULTISAMPLE) returns GL_TRUE. Otherwise the shader would include the line gl_FragDepth = gl_FragCoord.z;+. However, even in my minimum plain VTK application glIsEnabled(GL_MULTISAMPLE) returns GL_TRUE and the z-buffer is filled as expected. I called glDisable(GL_MULTISAMPLE) anyway, the shader included the line above, and the z-buffer looked the same as before. I gave it a try in MITK to see if that might be the solution but it wasn't. I noticed that I had to disable GL_MULTISAMPLE rather deep in the hot path as there is some component that enables it again. That is most probably Qt. So my best quess at the moment is still some quirk in the usage of Qt and VTK at the same time.

+ The [[|reference page of gl_fragDepth]] says that if depth buffering is enabled and no shader writes to gl_FragDepth, then the fixed function value for depth will be used (this value is contained in the z component of gl_FragCoord). That's why depth buffering works in my plain VTK application even though GL_MULTISAMPLE is GL_TRUE.

kislinsk moved this task from Blocking v2018.04 to Backlog on the MITK (2018-04) board.

Plain VTK application source code:

kislinsk renamed this task from Point Set Interaction not working on surfaces to Point Set Interaction not working in 3d window (world point picking broken because depth buffer is empty).Mar 28 2018, 1:28 PM

Seems like upgrading from VTK version 8.0 to version 8.1 will resolve this issue.

kislinsk claimed this task.