Here: https://gitlab.kitware.com/vtk/vtk/-/merge_requests/9125 . Thanks.
Thanks. True. Well, a fast code that doesn’t yield the correct result is of no use and shouldn’t be left broken if a working version is known, even if it is apparently slower. The z-buffer is somehow reset before that call. I modified the code to reset the depth buffer to 0.424242 instead of 1.0 and I was starting to get 0.424242 for every GetZ() call. Anyway, I did picking on a large vtkUnstructuredGrid with millions of cells and I couldn’t notice any performance worsening. Picking that large model was as slow as before. But now we are back getting the correct pick world coordinates.
Of course, if someone can improve that answer, she/he will be quite welcome.
It appears that depth testing gets disabled in the OpenGL state as @Paulo_Carvalho discovered. Couldn’t tell based on a cursory look where that happens but will try to dig into it a little unless @ken-martin already has idea where this could be coming from.
Hi, recently I upgrade my vtk to 9.1, So I am interested in this topic, but is there any official solution ?
Well, the merge request is still open. So, as far as I know, there is no solution avaliable downstream yet. If you can’t wait, you can patch the vtkRenderer::GetZ(int,int) in the VTK code (vtkrenderer.cxx source file) yourself.
@Paulo_Carvalho
It looks like this problem is still present in vtk 9.2.6, OSX (here to reproduce it). Most widgets are broken.
Is there a workaround in python?
Hello,
Unfortunatelly, the merge request is still open. If you build VTK from sources, you can use my VTK fork containing the branch with the fix: https://gitlab.kitware.com/PauloCarvalhoRJ/vtk/-/tree/Bugfix_vtkRenderer_GetZ . I just updated my VTK fork with the latest commits from upstream.
best,
PC
1 Like
Update:
After more than a year attempting to make the fix into downstream, I closed the merge request as I can’t afford the time to tender it undefinitely. Anyone in need can still use my fork to compile VTK with the fix: https://gitlab.kitware.com/PauloCarvalhoRJ/vtk/-/tree/Bugfix_vtkRenderer_GetZ or simply patch the source file as instructed further above.
all the best,
PC
Thanks for merging this. I updated the solution answer.
1 Like
Hi Paulo, I meet the same problem as you reported!
In my situation, I added an extra renderer to the render window to do overlay drawing for annotation stuffs. After that, “vtkRenderer::GetZ” almost returns value 1.0 at every time. Then I digged into the issue by exporting z buffer as an image file, guess what? It’s the depth buffer of the annotation render layer! I found that multiple renderers are invoked one by one in the RendererCollections, so the second annotation renderer clear the depth buffer immediately which made vtkWorldPointPicker to catch the second layer depth buffer.
The way I handle this problem is by observing the vtkCommand::EndEvent to the main renderer, and invoke vtkWorldPointPicker in the callback when it is needed with the current mouse position as input, then cache the correct result. After this, an extra rendering invocation is need before fetching the cache.
By the way, I don’t think it’s an issue caused by VTK9.1 upgrade since I was using the older VTK8.2.0.
Hopes to help every one whom has being struggling in the same issue!
It is up to you to decide if you want your annotation layer to clear the Z buffer or not (see vtkRenderer::SetPreserveDepthBuffer).
Grabbing the depth buffer after rendering certain layers may be a good solution, too.
Hello,
That never occured to me. Funny, I too use two renderers in my project. Maybe I should try @lassoan 's suggestion and review the solution as well as the fixing commit in VTK code. Thanks for the heads up.
best,
PC
I just need some time to setup my development environment since my previous computer failed.
Lassoan’s idea sounds better, which avoids an extra rendering invocation. And eliminates mouse position prediction, that means every screen position can be computed to output a world position based on depth buffer. Then, how to cache the depth buffer in an efficient way should be considered.
Thanks!
Depending on what you need, you may find vtkSelectVisiblePoints useful for getting and caching the Z buffer.
Unfortunately VTK 9.3 is not compilable in debug mode with MinGW64 (the compiler I use in Windows). I have somehow to recover my patched version of VTK 9.1 (to allow compiling with MinGW64).
VTK 9.1 is also not compilable (at least without extensive patching) in debug mode with the version 13.2.0 of MinGW64’s gcc…
Your solution solves the Z issue, but makes the foreground renderer pointless to display always-on-top labels:
In the example above, I did a SetPreserveDepthBuffer( true ) on the foreground renderer, now the labels are occluded by the geomertry.
I’ll experiment a bit with it in the mouse events to try to get it right.
thanks,
PC
So, inspired by your solution, I came up with a little dirty trick in my mouse-up event:
m_ParentView3DWidget->getForegroundRenderer()->SetPreserveDepthBuffer( true );
m_ParentView3DWidget->getRenderer()->Render();
[PICKING CODE]
m_ParentView3DWidget->getForegroundRenderer()->SetPreserveDepthBuffer( false );
m_ParentView3DWidget->getRenderer()->Render();
So, I believe the change to the GetZ method proposed by me can be reverted to restore it’s previous performance.
1 Like