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.
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.
View from top:
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.
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 [[https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/gl_FragDepth.xhtml|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.