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.
There was a bug with Flying Edges checking the boundary conditions in
the z-direction. It was comparing the z index to the size of the y
dimension, not the z dimension. This simple typo was probably missed
because most of the tests use square meshes. To catch the problem, you
need a mesh that has a different number of points in the y and z
directions and the contour has to go past the positive z boundary.
When this error was hit, the indices for the edges on that boundary were
not recorded, and later interpolation used garbage values for edge's
point ids.
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
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.
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.
It looks like there might be a precision problem that is causing some
rays to terminate before they start. However, I leave that to someone
else to diagnose.
I suspect that this test is not actually mapping colors correctly, and
the difference in images might be part of that problem. However, I leave
that to someone else to diagnose.
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.
