Visible cell selection - HardwareSelector.py example is not working reliably

I have been trying to use the hardwareselector example given at https://lorensen.github.io/VTKExamples/site/Python/Visualization/HardwareSelector/ and this only occasionally works. I am running the file exacly as it is given. I am using an anaconda environment with python 3.7.3 and vtk 8.2.0 installed using conda install vtk . I get the same behaviour when using Visual Studio Code to run the environment.

When I run the program from anaconda prompt, it will open a small window which remains black until I interact with it.
image

The sphere then becomes visible.

image

When I press the ‘u’ key to capture the visible cells, one of three things happens.

  1. The list of the cells are printed in anaconda prompt as expected
  2. One element is printed
  3. The window freezes and then closes.

Which of the behaviours is exibhited seems random, however the windows does not crash once behaviour (1) or (2) occurs. The results shown here are after trying the program 3 times before it stopped crashing and then many ‘u’ presses (about 30) before the visible cells were printed. After each, I changed the orientation, position of zoom of the sphere.

I have no prior experienced with vtk and only very limited experience with python so am unlikely to be able to make any progress with this on my own. I am happy to provide more information if needed.

Do you use an Intel video card? Could you please test if you can reproduce the issue with an nVidia GPU?

Just an FYI, my comments in Opacity issue with point picking on surface about random section issues were stemming from some problems I’ve been having with implementing this PyVista PR for this original feature request from @S0Phon

I’m also having trouble using the hardware selector - My GPU is a Radeon Pro Vega 20 4 GB

com-video-to-gif-6

We had the issue of starting up with black window until interaction when used Intel graphics card on Windows with OpenGL core profile instead of OpenGL compatibility profile. It may or may not be the same issue as this. Try it on an nVidia graphics card or try to create the rendering context using compatibility profile to see if the problems look similar.

Yes, I have an intel integrated graphics card (UHD 620) on the computer I have been running this on. I have just tried on my other computer which has a nVidea GPU (GeForce GTX 650 Ti) and have had no issues so far. The window opens directly to the sphere and outputs the cell data as expected.
I will also try the openGL compatability profile (once I figure out how to do that) and try to get it working on my other computer too.

Thank you @lassoan, for pointing this out and for the links to the other topics. It is very appreciated!

1 Like

Enabling compatibility mode might be as simple as uncommenting this line and rebuild VTK.

1 Like

I think @S0Phon and I are both using the PyPI wheels or conda Pyhton package for VTK… I’m not sure if there’s an easy process for us to do that.

If I opened an issue with the conda build of VTK about uncommenting that line, could/would that have any negative implications?

Compatibility profile is needed for Windows, may or may not make a difference on Linux, and must not be enabled for macOSX (as it does not support compatibility profile). If local testing confirms that uncommenting that line fixes the issue then it would be a good idea to change that in VTK proper and it would eventually find its way into PyPI.

1 Like

I’ve no idea how to go about rebuilding a program. I will have a look and see if it’s something I think I can try.
In the meantime, are there any older intel gpu drivers which are known to work or an older version of vtk which works with the newer drivers?

I managed to build vtk with the line uncommented as suggested. This seemed to fix the issue of the initial black window but has not changed the behaviours I described which are the main problem for me as I cannot reliably extract the data I need.
Perhaps there are other files in which similar lines would need to be uncommented for it to work as expected although this seems like a very time consuming way to try to fix the issue with no guarantee of a it working. Perhaps there is a more global setting somewhere. Unfortunately, at the moment I don’t have the time to try to find it (if it exists) and will stick with using the computer on which it seems to work for now.
With regards to the black window fix though. Someone more competant should confirm this as it was the first time I have built a program and I barely had any idea what I was doing.

The crash/incorrect selection is a caused by a memory corruption bug in the example. vtkHardwareSelector.SetArea gets (x,y) as bottom-right pixel, which is outside of the valid range (x-1, y-1). To fix it, change

hsel.SetArea(0, 0, x, y)

to

hsel.SetArea(0, 0, x-1, y-1)
1 Like

@ken-martin and VTK core developers: It is a quite serious issue that VTK rendering is incorrect on Intel graphics cards on Windows. We discovered a while ago that core OpenGL profile does not work in VTK render windows in Qt-based applications, but now it seems that pure VTK render windows require compatibility profile, too. A quick workaround would be to enable compatibility profile on Windows (in both QVTK rendering widgets and basic VTK render windows), but the proper solution would be to debug what causes the rendering failure when core profile is used.

Changing x and y to x-1 and y-1 respectively as you described has fixed the behaviour for me. Thank you again @lassoan.
I am creating an issue on the lerensen/VTKExamples github to try to get the example updated.

Hopefully, the rendering issue will be fixed in a future build.

@lassoan I just ran a few examples on my intel windows system and they were fine. Is there something specific that shows the issue you are talking about?

The main issue is that the previous state of the render is displayed (black screen until the second rendering as explained by the user above; the entire Qt application GUI update lagging behind as described in the topic I linked above).

do you reslove this problem? i have the same problem? can you give me you solve?

Hello, I have some opinions about the wrong choice:
I read the source code of PyVista about Cell selection. The problem of cell selection disorder should be related to the use of HardwareSelector instead of graphics card. For example, in vtk8.2, when selecting a cell from a hexahedral UnstructuredGrid, you should get its id, construct vtkExtractGeometry by cell id, and finally create a vtkActor to represent the selection effect. In fact, the cell id selected by HardwareSelector is converted from UnstructuredGrid to PolyData At this time, a face of a hexahedron has an id, and the id does not correspond to the cell id in the original UnstructuredGrid. Finally, the vtkExtractGeometry is then used to construct the Actor, which will cause confusion. Now I haven’t solved this problem either, you can see this problem:

    def visible_pick_call_back(picker, event_id):
        x0,y0,x1,y1 = self.get_pick_position()
        selector = vtk.vtkOpenGLHardwareSelector()
        selector.SetFieldAssociation(vtk.vtkDataObject.FIELD_ASSOCIATION_CELLS)
        selector.SetRenderer(self.renderer)
        selector.SetArea(x0,y0,x1,y1)
        cellids = selector.Select().GetNode(0)   ######This cell id is wrong, it comes from polydata converted from unstructuredGrid
        if cellids is None:
            # No selection
            return
        selection = vtk.vtkSelection()
        selection.AddNode(cellids)
        extract = vtk.vtkExtractSelectedIds()
        extract.SetInputData(0, mesh)
        extract.SetInputData(1, selection)
        extract.Update()
        self.picked_cells = pyvista.wrap(extract.GetOutput())
        return end_pick_helper(picker, event_id)

How to select a hexahedral cell using HardwareSelector

FYI: I managed to fix this in PyVista. See https://github.com/pyvista/pyvista/pull/799

In summary: vtkSelectionNode was giving us the cell IDs after running a vtkDataSetSurfaceFilter and a vtkTriangleFilter (figured this out by guessing). So we have to mimic that pipeline to map the selected cells in the selection node back to the original mesh.

An important note… the representation style MUST be surface!!! Using wireframe or points styles on the property will break this pipeline.

2 Likes