The structured connectivity classes are templated on two tags to
determine what 2 incident topological elements are being accessed. Back
in the day, these were called the "from" elements and "to" elements, as
taken from VTK filter names like `PointDataToCellData`. However, these
names were found to be very confusion, and after much debate they have
been renamed to the visit element type and the incident element type.
Meaning that a worklet is "visiting" elements of a particular type (such
as visiting each cell) and can access "incident" elements of a
particular type (such as the points incident on the cell).
I found a few methods converting flat and logical indices using the old,
confusing from/to convention. This changes them to the new convention.
With the major revision 2.0 of VTK-m, many items previously marked as
deprecated were removed. If updating to a new version of VTK-m, it is
recommended to first update to VTK-m 1.9, which will include the deprecated
features but provide warnings (with the right compiler) that will point to
the replacement code. Once the deprecations have been fixed, updating to
2.0 should be smoother.
For several versions, VTK-m has had a `Variant` templated class. This acts
like a templated union where the object will store one of a list of types
specified as the template arguments. (There are actually 2 versions for the
control and execution environments, respectively.)
Because this is a complex class that required several iterations to work
through performance and compiler issues, `Variant` was placed in the
`internal` namespace to avoid complications with backward compatibility.
However, the class has been stable for a while, so let us expose this
helpful tool for wider use.
These mappers can be used to render cell sets as glyphs. The following
glyph types are available for scalar fields:
- Cube
- Sphere
- Axes
- Quads
For vector fields:
- Arrows
2fd8a9b9a Remove deprecated use of old unscoped enums in rendering
e051565d9 Use scoped enums in rendering classes
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2736
The enumerations in `vtkm::cont::Field::Association` were renamed in the
previous commit. The old names still exist, but are deprecated. Change
the rest of the code to use the new names.
This fix lerps the scalar field values at points of ray intersection,
ensuring rendering of quads pick the correct lerped color instead of
using the same color for the entire quad.
`RectilinearLocator::LocateCell` and `UniformLocator::LocateCell` assume
that the point in inside the bounds of the cell set, but may return a
cell location that does not exist, i.e., cell location that is outside
of the bounds of the cell set due to errors from floating point
operations.
This fix, given the assumption above, bounds the calculated cell
location to within the cellset by capping the indices to within the
limits.
The `DynamicCellSet` (and the related `DynamicCellSetBase`) are
deprecated and replaced with `UnknownCellSet` (and `UncertainCellSet`).
Thus, `UnknownCellSet` has some methods inherited from `DynamicCellSet`
but replaced with other functionality. These methods are now marked as
deprecated and their use is removed.
The `DynamicCellSet` class is now marked as deprecated (as is the header
that contains it), and all non-deprecated code is moved to its
`UnknownCellSet` replacement.
Also added a deprecation warning for the VariantArrayHandle.h header
file and deleted a couple inappropriate uses of it.
`UnknownCellSet` is an updated replacement for `DynamicCellSet`. The
next step in the replacement is to change `DataSet` to use the new
class.
Also replaced `DynamicCellSet` with `UnknownCellSet` in a few
places where `DynamicCellSet.h` was not directly included (and
therefore now no longer included at all). This change would have
to be made at some point anyway.
We have been doing a better job at hiding device code (and moving code
into libraries). Smoke out source that no longer needs to be compiled by
device compilers.
There were apparently some fields copy/pasted from the 3D version were
not used in the 2D version (probably because they had no meaning). In
one case, one was erroneously normalized, and could cause a floating
point exception.
Deprecate `VirtualObjectHandle` and all other classes that are used to
implement objects with virtual methods in the execution environment.
Additionally, the code is updated so that if the
`VTKm_NO_DEPRECATED_VIRTUAL` flag is set none of the code is compiled at
all. This opens us up to opportunities that do not work with virtual
methods such as backends that do not support virtual methods and dynamic
libraries for CUDA.
Virtual methods were used in the `MeshConnectivity` classes for the
internal ray casting system. However, using virtual methods in the
execution environment is being deprecated.
This change replaces the virtual object with an object containing a
`Variant`. The `Variant` holds one of the supported mesh connectivities
and selects the correct one at runtime rather than jumping into a
virtual method.
