[vtk-developers] Generic adaptor framework vs. custom vtkCell types

[Andreas Buykx]

Hi all,

We are studying the advantages and drawbacks of various options for visualizing our finite element data with VTK.  Our elements map for a large part to the existing VTK cells, but we have roughly 20-30 element types (higher order elements and elements that model an interface between two cells) that do not map to existing cell types. We expect that in the future our library of elements will grow, requiring an approach that minimizes the effort needed to implement new elements/cells. The two alternatives that we are currently considering are implementing the VTK generic framework vs. adding custom cells to VTK by deriving from vtkCell, vtkNonlinearCell, etc.

Regarding the generic adaptor framework I have the following questions:

1.       How mature is the framework, viz. how many projects/products have actually implemented the generic adaptor framework?

2.       From some experimentation it seems that walking over the cells of a grid does not scale to 1M cells or more, and applying the provided generic filtering algorithms also demonstrate a performance degradation by a factor 2-3. Is this observation correct? Is there any work going on to improve this?

3.       Are there example implementations other than the bridge example from the VTK code base?

Regarding extending the existing VTK cell collection I have investigated the current 5.9 VTK code. It seems to me that there are several locations where adding new cells requires significant patching of VTK code in the Graphics and Filtering areas:

·         vtkCellType - trivial - add cell type id

·         vtkGenericCell - trivial - add case statement for cell instantiation

·         vtkUnstructuredGrid - trivial - add case statement for GetCell()

·         vtkBoxClipDataSet - almost trivial - add fall-through case statement for appropriate shape

·         vtkCutter - trivial - add cellTypeDimensions entry.  Only for non 3D cell types

·         vtkDataSetSurfaceFilter - nontrivial extension to UnstructuredGridExecute, but probably not needed if the default case performs sufficiently fast

·         vtkGeometryFilter - almost trivial - add fall-through case statement for appropriate shape(?)

·         vtkUnstructuredGridGeometryFilter - nontrivial addition to RequestData, except if fall-through case is appropriate.

Regarding extending the existing VTK cell collection my questions are:

1.       Is the above analysis of impact to VTK code correct/complete?

2.       We are very reluctant to go into this much patching. Are there other approaches that have less impact to existing VTK code?

3.       What are the experiences with adding new cell types as outlined above? Has it been done before at all?

4.       It seems that there are several cell type ids that are entered in the VTKCellType enumeration that are not supported by the code, esp. the VTK_HIGHER_ORDER_... and VTK_PARAMETRIC_... entries. What is the intent of those entries?

Are there other aspects that I should take into account when deciding which direction to take?
Are there other options besides the two outlined above?

Thanks a lot for your help.

Andreas Buykx

Andreas Buykx
Senior Software Engineer

TNO DIANA BV
Software Developers and Analysis Consultants for Civil and Geotechnical Engineering

Delftechpark 19a, 2628 XJ, Delft, The Netherlands
Tel: +31 88 34262 15 (Direct) │ Tel: +31 88 34262 00 (Switchboard) │ +31 88 34262 99 (Fax)
http://tnodiana.com<http://tnodiana.com/>

...be green keep it on screen

____________________________________________________________
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/20110323/97c3437c/attachment.html>