Use of vtkGeometryFilter in vtkDataSetMapper

Development
1

I’m displaying cell data on an unstructured grid and noticed a slowdown in rendering as the field changes (geometry is unchanged). Profiling a bit I noticed most of the time is taken in the vtkDataSetMapper to extract the surface of the tetrahedral mesh with vtkDataSetSurfaceFilter.

In my local build I swapped in a vtkGeometryFilter in the vtkDataSetMapper and it is about an order of magnitude faster for this use case. Is there any reason not to make this change in VTK itself? From what I can tell it should be basically a drop in replacement and will delegate back to vtkDataSetSurfaceFilter for any cases it can’t handle. If nobody knows of a reason not to do this I can make a merge request (just a few lines to change). Or if there’s some reason not to make it the default maybe we could add an option to use vtkGeometryFilter.

And a small follow up question: since only the cell data is changing why is the surface being extracted every update? (this happens with either filter). Does anyone know if there’s a faster path for rendering in this situation?

2

Steve, are you building multithreaded? What threading backend? Version of VTK?

We had significantly sped up vtkGeometryFilter (with threading), but more recently Spires has worked over the vtkDataSetSurfaceFilter (also with threading) and I was under the impression that vtkDataSetSurfaceFilter ended up being faster. So I am confused by the significant difference in your case. Hence why the VTK version number question…

3

Hi Will - Yes, both should be using TBB (this VTK was built with the Slicer superbuild defaults). All I did was change the filter and rebuild.

The render pipeline is in the MRML displayable manager code, but it’s really just setting up a vtkDataSetMapper and rendering.

Maybe threading got turned off somehow for vtkDataSetSurface?

CMakeCache says: VTK_SMP_IMPLEMENTATION_TYPE:STRING=TBB

>>> vtk.vtkVersion().GetVTKVersionFull()
'9.4.2-9-g454bb391df'

Here’s the mesh I was testing

I was able to replicate the behavior with this code. If you run the two updates you should see the same difference in performance.

r = vtk.vtkUnstructuredGridReader()
r.SetFileName("/opt/data/SlicerTMS/mesh.vtk")
r.Update()
meshGrid = r.GetOutput()

dss = vtk.vtkDataSetSurfaceFilter()
dss.SetInputData(meshGrid)
dss.Update()

gf = vtk.vtkGeometryFilter()
gf.SetInputData(meshGrid)
gf.Update()
4

Yes, I have replicated the problem with your data. This in on my AMD 48 thread desktop:

~/Develop/Voronoi/build/bin/vtkpython GeometryFilter.py
Time to vtkDataSetSurfaceFilter: 6.067303895950317
Num output points: 64161
Num output cells: 128450
Time to vtkGeometryFilter: 0.09132719039916992
Num output points: 64161

Num output cells: 128450

Even when I set the maximum number of threads to 1, there is an appreciable difference, although notice that vtkDataSetSurfaceFilter is running in about the same time (so it looks like threading is not functioning). Is it possible that you are running a modified/older version of vtkDataSetSurfaceFilter? I’ll check with Spiros and see what he thinks, I feel I am missing something obvious :slight_smile:

~/Develop/Voronoi/build/bin/vtkpython GeometryFilter.py
Time to vtkDataSetSurfaceFilter: 5.950025796890259
Num output points: 64161
Num output cells: 128450
Time to vtkGeometryFilter: 1.6691839694976807
Num output points: 64161
Num output cells: 128450

5

@pieper feel free to post an MR in which you replace it.

I wanted to get to it at some point, but it did not have the budget to fix an tests that might fail which we did not anticipate. vtkGeometryFilter is faster because it’s multithreaded plus more memory efficient and smarter wherever it can be.

6

Steve, I spoke with Spiros and he straightened me out. The fancy hashing and threading we did is in vtkGeometryFilter and, yes, is much faster. The original (serial) hashing concept was originated by Charles Law in vtkDataSetSurfaceFilter but has been mostly left relatively unchanged because it has the ability to handle non-linear VTK cell types. vtkGeometryFilter will actually delegate to vtkDataSetSurfaceFilter if it detects non-linear cells. So yes, please create a MR to swap the filters as vtkGeometryFilter should be a drop in replacement. Obviously in the future we should consolidate the classes, but it seems we’re all busy :slight_smile:

FYI as a workaround, I explicitly use a vtkGeometryFilter + vtkPolyDataMapper in the pipeline.

7

Thanks @will.schroeder and @spyridon97, for the feedback.

Fortunately this looks like an easy fix : )

I’ll build testing here and see if anything pops up.

8

Here’s an MR. Not sure what to do about the failing tests on my machine. Ignore them?

https://gitlab.kitware.com/vtk/vtk/-/merge_requests/12224

9

Please fix your CI: The ultimate "How to make CI work with my fork" guide

1 Like
10

you can ignore them