The `FilterField` class provides convenience functions for subclasses to
determine the `ArrayHandle` type for scalar and vector fields. However, you
needed to know the specific size of vectors. For filters that support an
input field of any type, a new form, `CastAndCallVariableVecField` has been
added. This calls the underlying functor with an `ArrayHandleRecombineVec`
of the appropriate component type.
The `CastAndaCallVariableVecField` method also reduces the number of
instances created by having a float fallback for any component type that
does not satisfy the field types.
In addition to using uniform coordinates, the ContourFlyingEdges filter can now process any type of coordinate system, making the filter use Flying Edges in more cases
In order to compile the contour filter more efficiently, we split the contour filter into two separate translation units, corresponding to the new filters ContourFlyingEdges and ContourMarchingCells. The API for Contour filter is left totally unchanged, and tries to use flying edges if the dataset is structured and uniform.
All three contour filters inherit from the `AbstractContour` class, providing utility methods used in the implementations.
Fix compiler warnings......
Kick the dashboards..........
Kick the dashboards.....
use lambda instead of functor, remove unused code
ArrayHandle::StorageType should be public
StorageType is public in vtkm::cont::ArrayHandle, but some subclasses
re-declare it as private. Having it public provides a convenient way to
get the storage type of an ArrayHandle, otherwise it is quite verbose.
Addresses: #314
Tetrahedralize and Triangulate filters check if input is already triangulated
Previously, tetrahedralize/triangulate would blindly convert all the cells to tetrahedra/triangles, even when they were already. Now, the dataset is directly returned if the CellSet is a CellSetSingleType of tetras/triangles, and no further processing is done in the worklets for CellSetExplicit when all shapes are tetras or triangles.
ci,crusher: changed fs to orion
ci,osx,macos: fix value of GIT_CLONE_PATH
This new filtered designed for bi-variate analysis builds the continuous scatterplot of a 3D tetrahedralized mesh for two given scalar point fields. The continuous scatterplot is an extension of the discrete scatterplot for continuous bi-variate analysis.
The clip filter used to copy the input points and point fields as is,
regardless of if they were actually part of the output. With this change,
we track which input points are actually part of the output and copy
only those values.
Address: #112
014c429eb Make divide by volume in particle density estimate a little safer
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Li-Ta Lo <ollie@lanl.gov>
Merge-request: !3022
The `HierarchicalAugmenter` used in the distributed contour tree filter
attempts to save memory by releasing buffers used to send and receive
data after the DIY enqueues and dequeues are posted. This works as long
as the DIY serialization process copies the data in the arrays. However,
changes are coming where the data is sent directly from the buffers.
These changes cause a deadlock because the enqueue places a read lock
until the data is sent while the release tried to get a write lock.
The solution is simply to "forget" the array rather than explicitly
delete it. In this case, the array will automatically be deleted once
everyone is done with it.
While going through the VTK-m code to identify where a cast-and-call was
happening against VTKM_DEFAULT_TYPE_LIST, I ran into a subtle case in
`ParticleDensityBase` that was calling a worklet with an
`UnknownArrayHandle`. This works OK, but was probably compiling for
unnecessary types (for example, vectors). Changed the field resolution
to be more intentional.
MR !2969 was meant to update the clip filters such that their field
mapping works on any field type and preserves the value type. Although
this was done for `ClipWithField`, it was not fully implemented for
`ClipWithImplicitFunction`. These changes update
`ClipWithImplicitFunction` to match its sibling.
Some of the test data sets are derived from data sets that are commonly
distributed to test visualization algorithms and are featured in
numerous papers. However, I am unable to track down the original source
let alone identify what license, if any, they were released under. To
avoid any complications with data ownership, remove these data sets and
replace them with in house data sets that we explicitly own.
The precompiled `ArrayRangeCompute` function was not following proper fast
paths for special arrays. For example, when computing the range of an
`ArrayHandleUniformPointCoordinates`, the ranges should be taken from the
origin and spacing of the special array. However, the precompiled version
was calling the generic range computation, which was doing an unnecessary
reduction over the entire array. These fast paths have been fixed.
These mistakes in the code were caused by quirks in how templated method
overloading works. To prevent this mistake from happening again in the
precompiled `ArrayRangeCompute` function and elsewhere, all templated forms
of `ArrayRangeCompute` have been deprecated. Most will call
`ArrayRangeCompute` with no issues. For those that need the templated
version, `ArrayRangeComputeTemplate` replaces the old templated
`ArrayRangeCompute`. There is exactly one templated declaration of
`ArrayRangeComputeTemplate` that uses a class, `ArrayRangeComputeImpl`,
with partial specialization to ensure the correct form is used.
`vtkm::cont::DataSet` is a dynamic object that can hold cell sets and
fields of many different types, none of which are known until runtime. This
causes a problem with serialization, which has to know what type to compile
the serialization for, particularly when unserializing the type at the
receiving end. The original implementation "solved" the problem by creating
a secondary wrapper object that was templated on types of field arrays and
cell sets that might be serialized. This is not a great solution as it
punts the problem to algorithm developers.
This problem has been completely solved for fields, as it is possible to
serialize most types of arrays without knowing their type now. You still
need to iterate over every possible `CellSet` type, but there are not that
many `CellSet`s that are practically encountered. Thus, there is now a
direct implementation of `Serialization` for `DataSet` that covers all the
data types you are likely to encounter.
The old `SerializableDataSet` has been deprecated. In the unlikely event an
algorithm needs to transfer a non-standard type of `CellSet` (such as a
permuted cell set), it can use the replacement `DataSetWithCellSetTypes`,
which just specifies the cell set types.
