Options for edge/face data

Subclassing vtkGenericDataSet

One option for supporting edge/face data in VTK proper is to derive from vtkGenericDataSet. A tutorial for doing so was presented at VisWeek '08, by ParaView. I'll attempt to summarize here.

vtkGenericDataSet is part of VTK's Adaptor Framework and was designed to allow new cell and attribute types to be created. Other classes in the framework include:

  • vtkGenericAdaptorCell
  • vtkGenericAttribute -- access and interpolate field data
  • vtkGenericDataSetAlgorithm
  • vtkGenericPointIterator/vtkGenericCellIterator

Many vis operations may need to be provided by our implementation (depends on our use-cases)

  • Iterators for ordered access to point/cells
  • Contouring
  • Clipping
  • Tesselation
  • Line intersection

Handling things through avtDataObject

I (Mark Miller) am not the expert here but wanted to summarize a portion of the discussion I heard regarding how to affect support for edge/face centered data within the current (5.0) VTK we are using.

The problem of course is that VTK understands cell and point data. This means there is a slew of software already designed to 'do the right thing' when it encounters cell/point data. If one has a 3D mesh with face and/or edge centered data, then faces and/or edges need to exists (as cells) in the VTK mesh object. But, those cells wind up living in the same 'address space' as the 3D mesh elements themselves. So, having an edge-centered variable, for example, in that context means we wind up having to define bogus values for 3D and face cells in order to have something defined for the edge cells.

A solution is to instantiate different VTK mesh objects for face/edge centered data such that the mesh object consists only of the kinds of cells necessary to represent the associated centering of the variable. In theory, this could be handled in AVT because an AVT data object is nothing more than a 'tree' of VTK datasets. Operators and pick/query may have to be 'smartened' to deal with different instantiations of the same mesh for different centerings. I think Jeremy pointed out that it may not even be possible for the different instantiations to share the underlying geometry (coordinate array(s)) and that would represent a memory bloat problem.

avtTransformManager could, based on a variable's centering, generate new 'equivalent' VTK mesh objects to define the variable(s) on so that the interaction with databases could be pretty much transparent.

Use Cases

Visualizing Fluxes between Zones (EM Codes)