使用Python计算表面单元区域时产生奇怪的VTK结果

Question

I have a question regarding the use of DeepCopy and Filters/Algorithms in VTK using the vtk python interface. I get incorrect and strange results doing the following:

1. Create a cone object cone from a ConeSource algorithm
2. Deep copy cone into cone2
3. Compute the area of the first cell (a polygon) of both cones cone and cone2 .

The code also has some opt -lines ( opt1 , opt2 , opt3 ). They alter the output of the script.

• opt1 is imply an import of vtk_to_numpy but is never used in the script.
• opt2 changes the way cone is created. Either via a DeepCopy command applied on a newly created vtkPolyData object (like in the code below) or no deep copy simply referencing the object returned vom GetOutput .
• opt3 Changes the number of times the area of the first cell is computed and printed.

Here is the minimum working example:

import vtk
# from vtk.util.numpy_support import vtk_to_numpy  # opt1

coneSource = vtk.vtkConeSource()
coneSource.Update()

cone = vtk.vtkPolyData()
cone.DeepCopy(coneSource.GetOutput())
# cone = coneSource.GetOutput()  # opt2

cone2 = vtk.vtkPolyData()
cone2.DeepCopy(cone)

N = 80  # opt3
for _ in range(N):
    print cone.GetCell(0).ComputeArea(), cone2.GetCell(0).ComputeArea()

The results of that script are depicted in the table below. The entries in the cells are tuples representing the output of the computed are of cone and cone2 respectivly with ok being the correct result and (ok) meaning that the first line was printed correctly but all subsequent computations are incorrect.

+--------------------+-----------+-----------+----------+-----------+------------+-----------+
|                    |             DeepCopy             |              GetOutput             |
+--------------------+-----------+-----------+----------+-----------+------------+-----------+
|                    |     1     |    10     |    80    |     1     |     10     |     80    |
+--------------------+-----------+-----------+----------+-----------+------------+-----------+
| w/ numpy_support   |  nan, ok  |  inf, ok  |  ok, ok  |  ok, ok   |  (ok), ok  |  (ok), ok |
| w/o numpy_support  |  inf, ok  |  inf, ok  |  ok, ok  |  ok, inf  |  ok, ok    |  inf, ok  |
+--------------------+-----------+-----------+----------+-----------+------------+-----------+

The results are reproducable in subsequent calls of the script but differ after a reboot or after some longer period of time. So you might get different results (altough I would hope that you too experiance some results being nan or inf).

I suspect that I am doing something wrong memory wise with the VTK objects. I am interested in feedback if you can reproduce my problem and what I am doing wrong during the deep copy of a vtk object or the creation of one from a source. Also, is there a better way to compute the cell areas of a vtkPolyData instead of looping over all cells?

I am using VTK-8.0.1, Python2.7 and running this example on CentOS7. Both VTK and Python are built by myself so they are not the versions from the repostory.

Answer 1

I think there is actually a bug/unexpected behaviour of the vtkPolygon::ComputeArea() method. The problem I see is that the implementation of ComputeArea() looks like this:

double vtkPolygon::ComputeArea()
{
    double normal[3]; //not used, but required for the
                      //following ComputeArea call
    return vtkPolygon::ComputeArea(this->GetPoints(),
                             this->GetNumberOfPoints(),
                             this->GetPointIds()->GetPointer(0),
                             normal);

}

However, I think this is "wrong". this->GetPoints() returns array with just the points of the given polygon, so a 0-indexed array with just 3 points for a triangle cell. this->GetPointIds() is an array with indices, but in case the cell is part of a large polyData, those are not indices into the this->GetPoints() array, but rather into the global array with all the points of the polydata, not just the one of the cell. Even for the first cell of the mesh produced by vtkConeSource, this is wrong as I found, because even though the first cell uses the first points in the global array (so accesing either one should be fine), they are actually in different order (don't know why, but they are).

To sum up, if the array obtained by GetPointIds() is used, it should be used to index the "global" array. If the "local" vtkPoints of the cell are used, it should be indexed iteratively from 0 to N, where N is the number of points in the cell. vtkPolygon::ComputeArea() mangles these two things together so I would advise not to use it at this point.

Can you please verify that it is computed correctly if you replace the the line inside the loop to use the vtkPolygon::ComputeArea(vtkPoints * p, vtkIdType numPts, vtkIdType * pts, double normal 3 ) ) with the right parameters? So something like this (not sure about the python syntax, sorry, normal is a not-used vector for storing the normal):

print cone.GetCell(0).ComputeArea(cone.GetPoints(), cone.GetCell(0).GetNumberOfPoints(), cone.GetCell(0).GetPointIds().GetPointer(0), normal), cone2.GetCell(0).ComputeArea(cone2.GetPoints(), cone2.GetCell(0).GetNumberOfPoints(), cone2.GetCell(0).GetPointIds().GetPointer(0), normal)

If this is indeed the case for you, I will post the problem on the vtk bugtracker and hopefully it will get fixed in new versions.

EDIT : You can use vtkMeshQuality filter to compute the areas (and other quality metrics as well). Here is an example, it's in c++, but it should be straightforward to modify it for python, the key lines are just the filter set-up (my attempt for pseudo-python):

qualityFilter = vtk.vtkMeshQuality
qualityFilter.SetInputData(mesh) // mesh in your case is cone/cone2
qualityFilter.SetTriangleQualityMeasureToArea()
qualityFilter.SetQuadQualityMeasureToArea()
qualityFilter.Update()

...and retrieval of the computed values - they are stored in a celldata array of the output of the filter:

qualityArray = qualityFilter.GetOutput().GetCellData().GetArray("Quality"))

for i in range(qualityArray->GetNumberOfTuples()):
    print "area of  {0}. element is {1}".format(i, qualityArray->GetValue(i))

It's not really "better" in terms of algorithmic complexity (you can't get sublinear complexity if you want the result to be exact), but perhaps it's more convenient to use.