Some of the data sets that are included from VTK-m are derived from the
VisIt Tutorial Data (https://www.visitusers.org/index.php?title=Tutorial_Data).
These are covered by the VisIt license, as communicated by Eric Brugger.
Although the license for these data is compatible with VTK-m's license,
we should still attribute the source of the data and make clear the
copyrights. The data are moved into the third_party directory, and
readmes are added to document everything.
The noise.vtk and noise.bov files have been renamed example.vtk and
example_temp.bov to match the name of the file in the VisIt tutorial
data archive. The ucd3d.vtk file, which is similar to the curv3d.silo
data but altered, has been removed. It was not used for any tests. It
was referenced in a couple of example programs, but the reference is
easily changed.
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.
Previously, `DataSet` managed `CoordinateSystem`s separately from `Field`s.
However, a `CoordinateSystem` is really just a `Field` with some special
attributes. Thus, coordiante systems are now just listed along with the
rest of the fields, and the coordinate systems are simply strings that
point back to the appropriate field. (This was actually the original
concept for `DataSet`, but the coordinate systems were separated from
fields for some now obsolete reasons.)
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.
This mechanism sets up CMake variables that allow a user to select which
modules/libraries to create. Dependencies will be tracked down to ensure
that all of a module's dependencies are also enabled.
The modules are also arranged into groups.
Groups allow you to set the enable flag for a group of modules at once.
Thus, if you have several modules that are likely to be used together,
you can create a group for them.
This can be handy in converting user-friendly CMake options (such as
`VTKm_ENABLE_RENDERING`) to the modules that enable that by pointing to
the appropriate group.
The `vtkm_unit_tests` function in the CMake build now allows you to specify
which files need to be compiled with a device compiler using the
`DEVICE_SOURCES` argument. Previously, the only way to specify that unit
tests needed to be compiled with a device compiler was to use the
`ALL_BACKENDS` argument, which would automatically compile everything with
the device compiler as well as test the code on all backends.
`ALL_BACKENDS` is still supported, but it no longer changes the sources to
be compiled with the device compiler.
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.
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.
`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.
The `test_equal_images` function has been expanded to supply the
generated image in a `Canvas` or a `DataSet` in addition to a `View`.
Much of the templating code has been removed from `test_equal_images`
and most of the code has moved into the `vtkm_rendering_testing`
library.
The previous functions that enabled the render regression tests were
heavily templated, which required every test using rendering to
recompile the entire rendering system being used. Changed the interface
to not rely on templating so that the RenderTest method can be moved
into a library.
Also moved the options into a struct where they can be better managed.
The render testing functions tended to have lots of arguments that were
difficult to manage. Instead, created a single `struct` that holds all
the potential options. That way when someone specifies on option, it is
clear what option is being set.
1dce468ff Post test render images to dashboard
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Nickolas Davis <nadavi@sandia.gov>
Merge-request: !2652
By adding some XML tags to the test output, you can push the images used
and generated for tests to the dashboard where they will appear
alongside the test output.
Also made it more automatic to find alternate versions of test images.
Although it is generally wrong to try to call `ResetToBounds` with a
`Bounds` object that does not have a valid range, there are cases where
the range might not be valid. (For example, if `ResetToBounds` was
called in a routine that is rendering an empty scene, it would be best
not to crash.)
