I recently noticed a deterioration in the mesh quality of the filter vtkClipPolyData. I was able to reproduce the exact same poor quality clip with PyVista and ParaView (clip_scalar in PyVista and Clip>Clip Type=Scalar in ParaView). I am mostly making this post because I am not sure how well-tracked this behaviour is.
When I try to make a Minimal Working Example, because my dataset is 8M cells + I can’t share it, the clips work as expected in all the listed versions of VTK which baffles me.
Steps
isolating with a box clip only this problematic section in ParaView,
saving it as a VTM
load to PyVista or ParaView and then perform a scalar clip e.g.
import pyvista as pv
reader = pv.get_reader("mwe.vtm")
case = reader.read()
data = case["internal"]
clip = data.clip_scalar(scalars="field", value=0.5, invert=False)
clip = clip.extract_surface()
clip.save("clip_clean.stl")
For my case I am happy to drop down to VTK 9.2.6 and wait for a release that contains a fix, but I would still like to understand what’s going on under the hood. Any help or ideas about what’s going on would be appreciated.
From VTK 9.3 until recently (20240624), vtkPolygon was using single-precision to compute normals for single-precision points. Before and after, it used/uses double precision to compute normals regardless of precision of the points.
However, this fix doesn’t match your version dates. How did you come up with 20240617 as the VTK version date for ParaView 5.13.1? It seems that it should be 20240925.
No, that wasn’t the problem. I thought it was the solution, according to my first glance at the dates given by the OP (note that he says the issue is gone the latest ParaView and in 9.4.0rc2). But now I think that it’s unrelated.
My data should be 64bit (everything), as for the ParaView that’s interesting for me on Linux it shows 9.3.20240617.
Full ParaView 5.13.1 details
Client Information:
Version: 5.13.1
VTK Version: 9.3.20240617
Qt Version: 5.15.10
vtkIdType size: 64bits
Embedded Python: On
Python Library Path: /home/gn/Programs/ParaView-5.13.1/lib/python3.10
Python Library Version: 3.10.13 (main, Sep 27 2024, 19:33:16) [GCC 10.2.1 20210130 (Red Hat 10.2.1-11)]
Python Numpy Support: On
Python Numpy Path: /home/gn/.local/lib/python3.10/site-packages/numpy
Python Numpy Version: 1.26.4
Python Matplotlib Support: On
Python Matplotlib Path: /home/gn/.local/lib/python3.10/site-packages/matplotlib
Python Matplotlib Version: 3.9.0
Python Testing: Off
MPI Enabled: On
ParaView Build ID: superbuild abdf9aa5f109ffa3558a63d86365a0203aaab773 (!1224)
Disable Registry: Off
Test Directory:
Data Directory:
SMP Backend: TBB
SMP Max Number of Threads: 32
OpenGL Vendor: NVIDIA Corporation
OpenGL Version: 3.2.0 NVIDIA 535.183.01
OpenGL Renderer: NVIDIA RTX A2000 12GB/PCIe/SSE2
Accelerated filters overrides available: No
Connection Information:
Remote Connection: No
From academic curiosity point of view I would like to know what caused it, that is, if that’s not a pain for you to locate the source of this behaviour. From a product point of view I am happy to pin to v9.4.0 when it comes out, I am just slightly worried that this behaviour is unintentional and untracked in VTK, which is why I thought I should reach out to your Discourse.
As a side note, doing the clip and extract surface on both paraview and pyvista with all the newer VTK versions 9.3+ (didn’t test the older versions), seemed to be resulting in inconsistent normal orientations when exported as an STL, OBJ, etc. The fix I found was calling Clean, but I am not sure if that should be a requirement. Recomputing normals and exporting to a surface mesh didn’t work, and visualising in ParaView/trame showed the normals correctly oriented. I am not sure if the 2 issues are connected
The VTK version in the ParaView “About” box needs to be taken with a grain of salt. The ParaView releases have their own VTK branch, and the “About” box reports the branch point (between that branch and VTK’s master branch). Individual patches are constantly pulled from the VTK master branch to the ParaView release branch.
I’m also interested in tracking regressions in VTK, so are lots of people. Unwanted changes in VTK behavior from version to version can be a real burr in the saddle. Studying how they occur can help us to avoid them.
Regarding the clipping, the images that you posted look like 3D cells rather than polygons. Can you provide additional details about your input data?
They are indeed 3D cells. The mesh is hexa-dominant, simulation results are cell data, interpolated in VTK to point data. The values of the field where I am doing the scalar clip, follow a bimodal distribution where the majority of the values are either 0 or 1. There are a few intermediate values at the interface between between 0 and 1 cells, in this specific case more than I am used to get, which is why the clips are of poor quality. Usually I get very well triangulated surfaces after the clip.
Thanks, good to know. I’ll take it into account next time I’m debugging VTK issues
