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
Originally `MakeTestDataSet.h` was header-only code. This was changed to
put its functionality into a library. The obvious library to put it in
was `vtkm_cont_testing`.
The problem is that there is some external code that is (unadvisably)
adding this header to their own code. This code ends up breaking because
it needed to include `vtkm_cont_testing`, which was not needed before.
As a workaround, there was a CMake interface link that caused external
code linking in `vtkm_cont` to also link in `vtkm_cont_testing`. This
works OK, but creates something of a circular dependency. CMake itself
has no problem with this, because `vtkm_cont` did not itself depend on
`vtkm_cont_testing`; only things that linked to `vtkm_cont` also had to
link to `vtkm_cont_testing`.
Unfortunately, some Ascent CMake script was trying to trace down
dependencies and ran into an infinite loop. So this solution was not so
great for them.
Get around the problem by just adding the `MakeTestDataSet` code
directly to `vtkm_cont` (for now).
The scalar field difference along x, y, and z should be divided by the
spacing not multiplied. This was causing some test failures in VTK and
ParaView when overriding the default contour filter with `vtkmContour`.
When `PointTransform` was converted to the new filter structure, some of
the methods that were moved from .hxx to .cxx (and therefore compiled in
a library) were still marked as `inline`. This caused the compiler to
not compile the function into the library if it was not used. Fix the
problem by removing the `inline` modifier to the method implementations.
The deprecated class `vtkm::filter::MeshQuality` contained a private
method that was referenced in its inlined constructor. The problem was
that this private method was compiled in the `vtkm_filter_mesh_info`
library but not properly exported. Fix this by adding an export to the
class.
e6b37f7a4 Remove deprecated use of old unscoped enums in FieldToColors
f37cc7657 Use scoped enum for FieldToColors modes
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Dave Pugmire <dpugmire@gmail.com>
Merge-request: !2734
The current implementation of the AMD HIP compiler adds default compiler
flags to attempt to inline everything possible. This is wrecking havoc
with the `Variant::CastAndCall` function, whose implementation has one
or more large switch statements with each case calling a different
potentially inline function. In some parts of the VTK-m code, this is
dragging the compilation on for days as it tries to resolve a
`Variant::CastAndCall` within a `Variant::CastAndCall`. This will
probably need to be addressed in the compiler, but meanwhile we will
force the inlining to be turned off for the function called by
`Variant::CastAndCall`. It is unclear if this will result in some extra
runtime overhead, but the change is worth it to get reasonable compile
times.
Thanks to Nick Curtis for tracking this down and providing the solution.
The previous implementation of `Variant`'s `CastAndCall` generated a
switch statement with 20 cases (plus a default) regardless of how many
types were handled by the `Variant` (with the excess doing nothing
useful). This reduced the amount of code, but caused the compiler to
have to build many more instructions (and optimize for them). This in
turn lead to large compile times and unnecessary large libraries/
executables.
This change makes a different function to use for `CastAndCall` so that
the number of cases in the switch matches exactly the number of types in
the `Variant`'s union.
Because the size of VariantImplDetail.h was getting large, I also
reduced the maximum expansions for the code. This does not seem to
negatively affect compile time, and I doubt it will have an noticible
difference in running time (when in release mode).
I also modified some other parts of this code to match the expansion
without making unnecessary defaults.
For the templated methods that we are precompiling instances for, do not
put their implementation inside of the class declaration. The problem is
that if you define a method inside of a class, it is implicitly inline.
If it is inline, a compiler might choose to compile it even if an
external symbol exists.
It appears that some compilers treat template instances different than
calling a template. For example, if you have
```cpp
template <typename T, typename U>
void Foo(T t, U u);
template <typename T>
void Foo(T t, int u);
template void Foo(int t, int u);
```
that some compilers will complain that the instance is ambiguous because
it matches both versions of Foo even though the second one is the one
that is called (unless you specifically declare template parameters).
This is what happend with the gradient instances. Fix the problem by
wrapping the "ambiguous" cases to be called by a simple, single
templated function.
When the gradient filter was moved over to the new filter structure, it
lost its instantiations. This is a problem because the gradient filter,
which compresses a lot of the code into single worklet calls for
efficiency, is one of the longest to compile filters.
This commit restores the instantiations with the updated instantiation
functionality. This breaks up the code into many translation units that
can be compiled simultaneously and thus not hold up the entire compile
on one process.
Recently, an instantiation method was added to the VTK-m configuration
files to set up a set of source files that compile instances of a template.
This allows the template instances to be compiled exactly once in separate
build files.
However, the implementation made the assumption that the instantiations
were happening for VTK-m filters. Now that the VTK-m filters are being
redesigned, this assumption is broken.
Thus, the instantiation code has been redesigned to be more general. It can
now be applied to code within the new filter structure. It can also be
applied anywhere else in the VTK-m source code.
When the Marching Cubes algorithm merges points together for multiple
isosurfaces, it uses an ArrayHandleZip to combine the isosurface id and
the edge identification. This is to prevent merging points from
different isosurfaces. However, internally this has to do an array copy.
It was doing this copy with `ArrayCopy`. A recent change to that method
made the copy fail for `ArrayHandleZip`. The fix is to change to
`ArrayCopyDevice`.
The reason why this bug was introduced was because there was no test
case for this specific use. A regression test has been updated to test
for this case.
08e682601 Remove deprecated use of old unscoped enums in FieldSelection
28aa9b570 Use scoped enum for FieldSelection mode
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Sujin Philip <sujin.philip@kitware.com>
Merge-request: !2735
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
97f5ed640 Remove testing include from ZFP worklet headers
8d5e636ac Enable ci that compiles without testing
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Vicente Bolea <vicente.bolea@kitware.com>
Merge-request: !2738
The gradient filter has the ability to compute divergence, vorticity,
and q criterion. However, none of the gradient tests were actually
testing the result of these computations. At best, one of the tests was
checking that the arrays were created, but never actually looking at the
values.
For one of the gradient tests, this change computes these 3 values and
checks the results, which look reasonable compared to ParaView.
f8f41e0ef Update use of field association enumerations
56670dbba Rename field associations
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Sujin Philip <sujin.philip@kitware.com>
Merge-request: !2733
Several of the ZFP worklet headers included `vtkm/cont/testing/
MakeTestDataSet.h`. This is a problem because if testing is turned off,
then `MakeTestDataSet.h` attempts to include a file that is not
generated, so the compile just fails if testing is off (and the testing
library is not on). This include must be a remanent of some old testing
code during development. It can be safely removed.
The cell classifications were using an unscoped enum to define them. The
problem was that the symbols of the enum littered the `vtkm` namespace
without qualification. For example, it defined `vtkm::NORMAL`, which
could easily collide with some other meaning of normal.
Change the cell classification flags to be scoped within
`vtkm::CellClassification`. This thing behaves mostly like a scoped
enum. You can use the values declared within and reference
`vtkm::CellClassification` as a type itself. However, unlike a scoped
enum, `vtkm::CellClassification` items can automatically be cast to and
from `vtkm::UInt8`.
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.
The symbols in `vtkm::cont::Field::Association` have been changed from
`ANY`, `WHOLE_MESH`, `POINTS`, and `CELL_SET` to `Any`, `WholeMesh`,
`Points`, and `Cells`, respectively. The reason for this change is twofold:
* The general standard that VTK-m follows for `enum struct` enumerators
is to use camel case (with the first character capitalized), not all
upper case.
* The use of `CELL_SET` for fields associated with cells is obsolete. A
`DataSet` used to support having more than one `CellSet`, and so a
field association on cells was actually bound to a particular
`CellSet`. However, that is no longer the case. A `DataSet` has exactly
one `CellSet`, so a cell field no longer has to point to a `CellSet`.
Thus the enumeration symbol for `Cells` should match the one for
`Points`.
For backward compatibility, the old enumerations still exist. They are
aliases for the new names, and they are marked as deprecated, so using them
will result in a compiler warning (on some systems).
In the transition of the `Histogram` filter to the new filter types, a
bug was introduced. The `Histogram` filter has an option to set the
range for which to compute the histogram. (The range of the data will be
used instead if none is specified.) This range was properly used when
computing the histogram on a `PartitionedDataSet`. However, when running
on a single `DataSet`, the new filter structure skipped over the
partition code that checked to see if the range was specified. (It also
skipped over the code that properly computed the range in MPI.)
This change properly checks to see if `Execute` was called with a single
`DataSet` and updates the `ComputedRange` appropriately.
Recent changes to VTK-m include changes to MakeDataSet.h that require
the vtkm_cont_testing library to be loaded. This is problematic for
software using an earlier minor revision as they do not expect to need
to include this library.
For now, include vtkm_cont_testing in the interface of vtkm_cont so that
downstream code will load it. This should be a temporary solution. As we
move to new versions of VTK-m, we should break this link and require
downstream components to include it themselves.
This is mostly to support external code that expects deprecated
behavior. UnknownCellSet/UncertainCellSet replace DynamicCellSet. In the
deprecated class, you could use `ResetCellSetList` without having to
include a secondary file. It would be better to support that now so the
minor change does not break things.
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.
In pretty much any practical circumstance, whenusing `ListAll` or
`ListAny`, you have a list of types on which you run some sort of
predicate on each item in the list to determine whether any or all of
the items match the predicate. To make this easier, add a second
argument to `ListAll` and `ListAny` to provide a predicate that will
automatically be added.
If no predicate is given, then the operation is run directly on the
list. This is implemented by just using an identity operation.
GCC 11 is having trouble compiling brigand.hpp at all, even before we
instantiate any templates. Since we no longer need it, let's get rid of
it. It was always placed in an internal namespace.
Add deprecation warnings to the code whenever someone uses brigand.hpp.
We are no longer supporting this header file, but we'll give code a
chance to transition off of it.
Also added some other deprecation warnings to other header files that
are themselves deprecated but only issued warnings if you used something
in it.
