`CoordinateSystem` differed from `Field` in that its `GetData`
method returned an `ArrayHandleVirtualCoordinates` instead of
a `VariantArrayHandle`. This is probably confusing since
`CoordianteSystem` inherits `Field` and has a pretty dramatic
difference in this behavior.
In preparation to deprecate `ArrayHandleVirtualCoordinates`, this
changes `CoordiantSystem` to be much more like `Field`. (In the
future, we may change the `CoordinateSystem` to point to a `Field`
rather than be a special `Field`.)
A method named `GetDataAsMultiplexer` has been added to
`CoordinateSystem`. This method allows you to get data from
`CoordinateSystem` as a single array type without worrying
about creating functors to handle different types and without
needing virtual methods.
The new and improved vtkm::cont::ColorTable provides a more feature complete
color table implementation that is modeled after
vtkDiscretizableColorTransferFunction. This class therefore supports different
color spaces ( rgb, lab, hsv, diverging ) and supports execution across all
device adapters.
Sandia National Laboratories recently changed management from the
Sandia Corporation to the National Technology & Engineering Solutions
of Sandia, LLC (NTESS). The copyright statements need to be updated
accordingly.
There was a case of bad casting where a Float32 that should be in the
range between 0 and 1 was cast to an Id and then multiplied by the size
of an array. The intention is to get a proportional index into the
array, but because the float was cast to an int first, you get either
the first or last index.
Instead, first cast the size of the array to a Float32, multiply it by
the fraction, and then cast back to an Id. That should give the desired
effect.
Change the VTKM_CONT_EXPORT to VTKM_CONT. (Likewise for EXEC and
EXEC_CONT.) Remove the inline from these macros so that they can be
applied to everything, including implementations in a library.
Because inline is not declared in these modifies, you have to add the
keyword to functions and methods where the implementation is not inlined
in the class.
One of the dashboard was complaining that the bottomLeft variable might
have been used uninitialized because it got set in a condition above it.
In fact, that condition is always true the first during the first
iteration, but it is not worth fighting the compiler over it. Instead,
just initialize the value of bottomLeft when it is constructed.
When VTKm_USE_DOUBLE_PRECISION is on (not the default), then
vtkm::FloatDefault is set to 64 bit values. There was some code that was
coded for 32 bit and never checked for 64 bit (on all compilers).
Generally we try not to expose the implementation details of how things
are stored in objects.
Also changed some arguments that should have been declared const to
actually be const.
The SamplerRect worklet had an error where it was possible that the
invSpacing stack-local values could be used uninitialized. On the first
iteration of the loop in the SamplerRect operation, it calls LocateCell,
which is supposed to set invSpacing. Under most conditions it does, but
if one of the ray directions is 0 (which can happen with axis-aligned
views), one of the invSpacing dimensions was skipped, leaving the value
to whatever garbage happened to be on the stack. Later, the invSpacing
value was used to interpolate a scalar, which under some circumstances
could cause an array index error when looking up a color in the color
map.
This fix changes the condition for when the ray direction is 0 to still
initialize invSpacing.
The word surface is more often used for something like a polygonal mesh,
so this name is quite confusing. Canvas is consistent with a
conventional name in GUI widget APIs.
There are a lot of VTK-m coding style issues I would also like to clean
up (such as variable names and using "this->" before member variables),
but it is late and I want to go home.
