Although the contour filter was recently divided into 2 filters, flying
edges and marching cubes, the marching cubes version still had many
conditions and was the file that took the longest to compile on Frontier.
To help speed up parallel compiles and prevent a single run of a
compiler from being overwhelmed, the compilation of all the marching
cubes conditions has been split up using instantiations.
8f4d5fdf8 Remove some unneeded test comments and debug code
7bea5413c Revert from VOIIsGlobal to IncludeOffset. Add comment about deprecation reasoning.
523c8f3f2 Add test whether GlobalPointDimensions are preserved
84e719ae1 Set GlobalPointIndexStart correctly, copy GlobalPointDimensions
e55b700f7 Deprecate SetIncludeOffset and rename to SetVOIIsGlobal
e013ad126 Add test for GlobalPointIndexStart to TestingExtractStructured
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Abdelilah Essiari <aessiari@lbl.gov>
Merge-request: !3086
This resolves a compiler ambiguity I hit during development.
In my case, I created an `ArrayHandleDecorator` with one of the arrays being
an `ArrayHandleTransform`. The ambiguity occurs in function
`DecoratorStorageTraits<...>::BuffersToArray`, here an `ArrayHandleTransform`
is constructed using buffers (`std::vector<vtkm::cont::internal::Buffer>`)
This constructor is not defined for `ArrayHandleTransform`, but it's defined for
its superclass (`vtkm::cont::ArrayHandle`). `ArrayHandleTransform` does have a
non-explicit constructor that takes the array to be transformed and the
transform-functor as parameters, where the later has a default value.
This produces the following ambiguous options for the compiler:
1. Create a "to-be-transformed" ArrayHandle instance using the buffers, call
the `ArrayHandleTransform` constructor with this array with the defaulted
functor parameter.
2. Create the superclass instance using the buffer and call the
`ArrayHandleTransform` constructor that takes the superclass.
In this situation, option 2 is the correct choice.
The ambiguity is resolved by marking the constructors that take
buffers as explicit. These constructors are also added for the
derived classess via the `VTK_M_ARRAY_HANDLE_SUBCLASS_IMPL` macro.
There are occasions when you need a worklet to opeate on 2D or 3D
indices. Most worklets operate on 1D indices, which requires recomputing
the 3D index in each worklet instance. A workaround is to use a worklet
that does a 3D scheduling and pull the working index from that.
The problem was that there was no easy way to get this 3D index. To
provide this option, a feature was added to the `BoundaryState` class
that can be provided by `WorkletPointNeighborhood`.
Thus, to get a 3D index in a worklet, use the
`WorkletPointNeighborhood`, add `Boundary` as an argument to the
`ExecutionSignature`, and then call `GetCenterIndex` on the
`BoundaryState` object passed to the worklet operator.
The file `ArrayRangeCompute.cxx` was taking a long time to compile with
some device compilers. This is because it precompiles the range computation
for many types of array structures. It thus compiled the same operation
many times over.
The new implementation compiles just as many cases. However, the
compilation is split into many different translation units using the
instantiations feature of VTK-m's configuration. Although this rarely
reduces the overall CPU time spent during compiling, it prevents parallel
compiles from waiting for this one build to complete. It also avoids
potential issues with compilers running out of resources as it tries to
build a monolithic file.
Previously, the `ComputeMoments` filter only operated on a finite set of
array types as its input field. This included a prescribed list of `Vec`
sizes for the input. The filter has been updated to use more generic
interfaces to the field's array (and float fallback) to enable the
computation of moments on any type of scalar field.
The structured connectivity classes are templated on two tags to
determine what 2 incident topological elements are being accessed. Back
in the day, these were called the "from" elements and "to" elements, as
taken from VTK filter names like `PointDataToCellData`. However, these
names were found to be very confusion, and after much debate they have
been renamed to the visit element type and the incident element type.
Meaning that a worklet is "visiting" elements of a particular type (such
as visiting each cell) and can access "incident" elements of a
particular type (such as the points incident on the cell).
I found a few methods converting flat and logical indices using the old,
confusing from/to convention. This changes them to the new convention.
62eb0e3f3 copying Actor into Scene
04b6d96aa enable copying for Actor and ConnectivityProxy
09c78eec4 use unique_ptr for PIMPL ConnectivityProxy
b2880566d move Actor
6b0d2e369 use unique_ptr for PIMPL Actor
fe211adfd Merge branch 'master' into rendering_cpp_cleanup
b4f17b851 use unique_ptr for PIMPL for View
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <morelandkd@ornl.gov>
Merge-request: !3074
6508d47cb Remove 3DPara
c39ff5f86 add include CanvasRayTracer.h
ca1fe424c cleanup Camera
d660a53b8 clean up Ray and RayOperator
9ed11540f cleanup Camera
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <morelandkd@ornl.gov>
Merge-request: !3072
2631e5561 Split up the particle advection/streamline test
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Dave Pugmire <dpugmire@gmail.com>
Merge-request: !3067
