Struct vtkCellArray 

pub struct vtkCellArray(/* private fields */);

object to represent cell connectivity

vtkCellArray stores dataset topologies as an explicit connectivity table listing the point ids that make up each cell.

Internally, the connectivity table is represented as two arrays: Offsets and Connectivity.

Offsets is an array of [numCells+1] values indicating the index in the Connectivity array where each cell’s points start. The last value is always the length of the Connectivity array.

The Connectivity array stores the lists of point ids for each cell.

Thus, for a dataset consisting of 2 triangles, a quad, and a line, the internal arrays will appear as follows:

Topology:
---------
Cell 0: Triangle | point ids: {0, 1, 2}
Cell 1: Triangle | point ids: {5, 7, 2}
Cell 2: Quad     | point ids: {3, 4, 6, 7}
Cell 3: Line     | point ids: {5, 8}

vtkCellArray (current):
-----------------------
Offsets:      {0, 3, 6, 10, 12}
Connectivity: {0, 1, 2, 5, 7, 2, 3, 4, 6, 7, 5, 8}

While this class provides traversal methods (the legacy InitTraversal(), GetNextCell() methods, and the newer method GetCellAtId()) these are in general not thread-safe. Whenever possible it is preferable to use a local thread-safe, vtkCellArrayIterator object, which can be obtained via:

auto iter = vtk::TakeSmartPointer(cellArray->NewIterator());
for (iter->GoToFirstCell(); !iter->IsDoneWithTraversal(); iter->GoToNextCell())
{
// do work with iter
}

(Note however that depending on the type and structure of internal storage, a cell array iterator may be significantly slower than direct traversal over the cell array due to extra data copying. Factors of 3-4X are not uncommon. See vtkCellArrayIterator for more information. Also note that an iterator may become invalid if the internal vtkCellArray storage is modified.)

Other methods are also available for allocation and memory-related management; insertion of new cells into the vtkCellArray; and limited editing operations such as replacing one cell with a new cell of the same size.

The internal arrays may store either 32- or 64-bit values, though most of the API will prefer to use vtkIdType to refer to items in these arrays. This enables significant memory savings when vtkIdType is 64-bit, but 32 bits are sufficient to store all of the values in the connectivity table. Using 64-bit storage with a 32-bit vtkIdType is permitted, but values too large to fit in a 32-bit signed integer will be truncated when accessed through the API. (The particular internal storage type has implications on performance depending on vtkIdType. If the internal storage is equivalent to vtkIdType, then methods that return pointers to arrays of point ids can share the internal storage; otherwise a copy of internal memory must be performed.)

Methods for managing the storage type are:

• bool IsStorage64Bit()
• bool IsStorageShareable() // Can pointers to internal storage be shared
• void Use32BitStorage()
• void Use64BitStorage()
• void UseDefaultStorage() // Depends on vtkIdType
• bool CanConvertTo32BitStorage()
• bool CanConvertTo64BitStorage()
• bool CanConvertToDefaultStorage() // Depends on vtkIdType
• bool ConvertTo32BitStorage()
• bool ConvertTo64BitStorage()
• bool ConvertToDefaultStorage() // Depends on vtkIdType
• bool ConvertToSmallestStorage() // Depends on current values in arrays

Note that some legacy methods are still available that reflect the previous storage format of this data, which embedded the cell sizes into the Connectivity array:

vtkCellArray (legacy):
----------------------
Connectivity: {3, 0, 1, 2, 3, 5, 7, 2, 4, 3, 4, 6, 7, 2, 5, 8}
|--Cell 0--||--Cell 1--||----Cell 2---||--C3-|

The methods require an external lookup table to allow random access, which was historically stored in the vtkCellTypes object. The following methods in vtkCellArray still support this style of indexing for compatibility purposes, but these are slow as they must perform some complex computations to convert the old “location” into the new “offset” and should be avoided. These methods (and their modern equivalents) are:

• GetCell (Prefer GetCellAtId)
• GetInsertLocation (Prefer GetNumberOfCells)
• GetTraversalLocation (Prefer GetTraversalCellId, or better, NewIterator)
• SetTraversalLocation (Prefer SetTraversalLocation, or better, NewIterator)
• ReverseCell (Prefer ReverseCellAtId)
• ReplaceCell (Prefer ReplaceCellAtId)
• SetCells (Use ImportLegacyFormat, or SetData)
• GetData (Use ExportLegacyFormat, or Get[Offsets|Connectivity]Array[|32|64])

Some other legacy methods were completely removed, such as GetPointer() / WritePointer(), since they are cannot be effectively emulated under the current design. If external code needs to support both the old and new version of the vtkCellArray API, the VTK_CELL_ARRAY_V2 preprocessor definition may be used to detect which API is being compiled against.

@sa vtkAbstractCellArray vtkStructuredCellArray vtkCellTypes vtkCellLinks

Implementations

impl vtkCellArray

pub fn new() -> Self

Creates a new vtkCellArray wrapped inside vtkNew

Trait Implementations

impl Default for vtkCellArray

fn default() -> Self

Returns the “default value” for a type.

impl Drop for vtkCellArray

fn drop(&mut self)

Executes the destructor for this type.