- Use tao::tuple instead of FunctionInterface to hold array/portal
collections.
- Type signatures are simplified. Now just use:
- ArrayHandleCompositeVector<ArrayT1, ArrayT2, ...>
- make_ArrayHandleCompositeVector(array1, array2, ...)
instead of relying on helper structs to determine types.
- No longer support component selection from an input array. All
input arrays must have the same ValueType (See ArrayHandleSwizzle
and ArrayHandleExtractComponent as the replacements for these
usecases.
While making changes to how execution objects work, we had agreed to
name the base object ExecutionObjectBase instead of its original name of
ExecutionObjectFactoryBase. Somehow that change did not make it through.
0da55730 Fix scaling of x/y field of views
39b347db Fix raytrace using wrong fov with standard camera
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1185
Prevously, the x field of view was computed by scaling the y field of
view by the aspect ratio of the canvas. However, this is wrong because
the field of view angles do not scale linearly with the aspect ratio.
Fix this issue by using trig functions to convert the angle to distance,
scale the distance, and then convert back to angle.
The raytracing code has its own version of camera that maintains two
field of view (fov) parameters: one for the x direction and one for the
y. The standard vtkm::rendering::Camera contains only one fov. As is
consistent with OpenGL's gluPerspective and VTK's camera, the fov is
specified in the y direction. However, the raytracing code was
incorrectly using it in the x direction. That caused it to do a weird
rescaling when the aspect ratio was not 1.
Previously vtkm_find_gl was only usable when rendering was enabled.
This is problematic as examples would use vtkm_find_gl even if
they didn't use vtkm rendering library.
cleaned up a logic error texture2d and cleaned how the constructor for execution object was being called. Also, went and cleaned up how the execution object was being created for particle to align it with the same method for creating the execution object.
In order to make the change from the current way execution obejcts are utilized to the new proposed executionObjectFactory process type checks now has to look for the new execution object factory class to check against.
Previously, when a Worklet needed a scatter, the scatter object was
stored in the Worklet object. That was problematic because that means
the Scatter, which is a control object, was shoved into the execution
environment.
To prevent that, move the Scatter into the Dispatcher object. The
worklet still declares a ScatterType alias, but no longer has a
GetScatter method. Instead, the Dispatcher now takes a Scatter object in
its constructor. If using the default scatter (ScatterIdentity), the
default constructor is used. If using another type of Scatter that
requires data to set up its state, then the caller of the worklet needs
to provide that to the dispatcher. For convenience, worklets are
encouraged to have a MakeScatter method to help construct a proper
scatter object.
The problem is that there is no good "default" constructor for
ColorTable. The previous default constructor created an empty color
table, but that would be confusing if someone actually tried to use it.
We could set ot to the default preset, but the default preset uses the
diverging color map, which could foul people up if they actually want to
edit or create their own color map. Instead, force the declaration of
ColorTable to indicate what you plan to do with it.
The display of a color bar in an OpenGL canvas had an array overrun.
This method first used ColorTable to create an array of colors. It then
used the array to look up values for polygons that make up the color
bar. However, each polygon used indices i and i+1, and on the last value
the i+1 looked pass the end of the array. This fixes the problem by
adding one more value to the color array generated.
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.
Due to recent changes to remove static arrays that are not supported on
some devices, the function to return all the local point indices on a
face was removed. That left no way to get the structure of cell faces
short of pulling an internal data structure.
This change resurrects a function to get point indices for a face. The
interface for this method has necessarily changed, so I also changed the
corresponding function for getting edge indices.
This avoid accidental conversions from DataSet to Result in return
values. This exposed several issues with filters and their tests. Fixed
those as well.
cbadd3e6 Make CoordinateSystem not fail on CUDA
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Acked-by: Matt Larsen <mlarsen@cs.uoregon.edu>
Merge-request: !1108
These changes now allow VTK-m to compile on CUDA 7.5 by using const arrays,
when compiling with CUDA 8+ support we upgrade to static const arrays, and
lastly when CUDA is disabled we fully elevate to static constexpr.
c6565cde correcting compile error with CanvasGL
c57fad48 Depth no considered with annotations. Fix for volume renderer. Consistent color blending.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1068
b420a4b3 fixing typo
2bb64e65 fixing opacity for veritical bar
80081f2a adding finer grain control over color bar and scalar field label
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1063
