[vtk-developers] vtkUnstructuredGridGeometryFilter

[Andreas Buykx]

Hi all,

vtkUnstructuredGridGeometryFilter (UGGF) does not handle vtkPolyhedron cells. I have written a new version of this filter that does handle polyhedrons.
When developing this filter I think I found some issues in the UGGF implementation:

*         VTK_BIQUADRATIC_TRIANGLE (line 531) and VTK_BIQUADRATIC_QUAD (line 559) discard the 'found' status of the corner points

*         VTK_POLYGON faces (line 457) will not be considered to match quadratic faces with the same number of points

*         VTK_POLYGON faces will compare inequal numbers of points

The new filter addresses these issues, and adds support for vtkPolyhedron cells.
Modifications wrt. UGGF are :

*         input data object must be vtkUnstructuredGrid, not vtkUnstructuredGridBase;

*         point, cell and extent clipping removed (mainly because I didn't need it, it probably can be re-installed easily);

*         re-implemented the vtkSurfel and removed vtkPoolManager logic to allow for arbitrarily sized vtkPolygon point lists, fix the issues found above, and use standard containers. I don't know yet what the performance penalty is...

I have just finished implementing it, and named vtkUnstructuredGridSurfaceFilter (UGSF) to illustrate that it offers (slightly) different functionality from UGGF, similar to vtkDataSetSurfaceFilter (DSSF).
The first results seem to be OK, I didn't do extensive functional or performance testing yet. Is there an interest in including it in VTK? If so I'll need to do some work to adapt it to VTK's coding style, etc. I could use some guidelines/help with finding appropriate test cases to adapt.

I used vtkCutter::GetCellTypeDimensions() to determine the dimension based on the cell type: it provides for a convenient way for determining the dimension of a cell which is useful in this algorithm.
I propose to move it to vtkCellTypes which seems to be the proper place for it.

My next topic is DSSF. The current implementation of DSSF::UnstructuredGridExecute creates a UGGF to extract the surface cells. This, as you can guess, does not work properly for vtkPolyhedron cells which is a nuisance if you want to visualize them using a vtkDataSetMapper. Moreover it is unnecessary to extract the surface if there are no 3D cells, which could easily be determined while determining handleSubDivision (lines 1323-1348). If UGSF is accepted for use with VTK, we could determine if polyhedrons are present and use UGSF instead of UGGF, and skip extracting surface if no 3D cells are present at all.

What are your opinions about this?

Thanks,
Andreas Buykx


____________________________________________________________
TNO DIANA BV is a limited liability company registered in the trade register of the Chamber of Commerce as TNO DIANA BV with registered number 27252655.
____________________________________________________________
This e-mail and its contents are subject to the DISCLAIMER at http://tnodiana.com/content/Disclaimer
____________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20141106/e7e00dac/attachment-0001.html>