mirror of
https://gitlab.kitware.com/vtk/vtk-m
synced 2024-09-08 13:23:51 +00:00
Merge topic 'update-changelogs'
569adda00 Update changelogs Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !2099
This commit is contained in:
commit
11a341ced5
13
docs/changelog/coordinate-transform-results.md
Normal file
13
docs/changelog/coordinate-transform-results.md
Normal file
@ -0,0 +1,13 @@
|
|||||||
|
# Result DataSet of coordinate transform has its CoordinateSystem changed
|
||||||
|
|
||||||
|
When you run one of the coordinate transform filters,
|
||||||
|
`CylindricalCoordinateTransform` or `SphericalCoordinateTransform`, the
|
||||||
|
transform coordiantes are placed as the first `CoordinateSystem` in the
|
||||||
|
returned `DataSet`. This means that after running this filter, the data
|
||||||
|
will be moved to this new coordinate space.
|
||||||
|
|
||||||
|
Previously, the result of these filters was just placed in a named `Field`
|
||||||
|
of the output. This caused some confusion because the filter did not seem
|
||||||
|
to have any effect (unless you knew to modify the output data). Not using
|
||||||
|
the result as the coordinate system seems like a dubious use case (and not
|
||||||
|
hard to work around), so this is much better behavior.
|
17
docs/changelog/dataset-unique-field-names.md
Normal file
17
docs/changelog/dataset-unique-field-names.md
Normal file
@ -0,0 +1,17 @@
|
|||||||
|
# DataSet now only allows unique field names
|
||||||
|
|
||||||
|
When you add a `vtkm::cont::Field` to a `vtkm::cont::DataSet`, it now
|
||||||
|
requires every `Field` to have a unique name. When you attempt to add a
|
||||||
|
`Field` to a `DataSet` that already has a `Field` of the same name and
|
||||||
|
association, the old `Field` is removed and replaced with the new `Field`.
|
||||||
|
|
||||||
|
You are allowed, however, to have two `Field`s with the same name but
|
||||||
|
different associations. For example, you could have a point `Field` named
|
||||||
|
"normals" and also have a cell `Field` named "normals" in the same
|
||||||
|
`DataSet`.
|
||||||
|
|
||||||
|
This new behavior matches how VTK's data sets manage fields.
|
||||||
|
|
||||||
|
The old behavior allowed you to add multiple `Field`s with the same name,
|
||||||
|
but it would be unclear which one you would get if you asked for a `Field`
|
||||||
|
by name.
|
8
docs/changelog/filter-specifies-own-field-types.md
Normal file
8
docs/changelog/filter-specifies-own-field-types.md
Normal file
@ -0,0 +1,8 @@
|
|||||||
|
# Filters specify their own field types
|
||||||
|
|
||||||
|
Previously, the policy specified which field types the filter should
|
||||||
|
operate on. The filter could remove some types, but it was not able to
|
||||||
|
add any types.
|
||||||
|
|
||||||
|
This is backward. Instead, the filter should specify what types its
|
||||||
|
supports and the policy may cull out some of those.
|
15
docs/changelog/flying-edges.md
Normal file
15
docs/changelog/flying-edges.md
Normal file
@ -0,0 +1,15 @@
|
|||||||
|
# Flying Edges
|
||||||
|
|
||||||
|
Added the flying edges contouring algorithm to VTK-m. This algorithm only
|
||||||
|
works on structured grids, but operates much faster than the traditional
|
||||||
|
Marching Cubes algorithm.
|
||||||
|
|
||||||
|
The speed of VTK-m's flying edges is comprable to VTK's running on the same
|
||||||
|
CPUs. VTK-m's implementation also works well on CUDA hardware.
|
||||||
|
|
||||||
|
The Flying Edges algorithm was introduced in this paper:
|
||||||
|
|
||||||
|
Schroeder, W.; Maynard, R. & Geveci, B.
|
||||||
|
"Flying edges: A high-performance scalable isocontouring algorithm."
|
||||||
|
Large Data Analysis and Visualization (LDAV), 2015.
|
||||||
|
DOI 10.1109/LDAV.2015.7348069
|
72
docs/changelog/no-cell-op-errors.md
Normal file
72
docs/changelog/no-cell-op-errors.md
Normal file
@ -0,0 +1,72 @@
|
|||||||
|
# Avoid raising errors when operating on cells
|
||||||
|
|
||||||
|
Cell operations like interpolate and finding parametric coordinates can
|
||||||
|
fail under certain conditions. The previous behavior was to call
|
||||||
|
`RaiseError` on the worklet. By design, this would cause the worklet
|
||||||
|
execution to fail. However, that makes the worklet unstable for a conditin
|
||||||
|
that might be relatively common in data. For example, you wouldn't want a
|
||||||
|
large streamline worklet to fail just because one cell was not found
|
||||||
|
correctly.
|
||||||
|
|
||||||
|
To work around this, many of the cell operations in the execution
|
||||||
|
environment have been changed to return an error code rather than raise an
|
||||||
|
error in the worklet.
|
||||||
|
|
||||||
|
## Error Codes
|
||||||
|
|
||||||
|
To support cell operations efficiently returning errors, a new enum named
|
||||||
|
`vtkm::ErrorCode` is available. This is the current implementation of
|
||||||
|
`ErrorCode`.
|
||||||
|
|
||||||
|
``` cpp
|
||||||
|
enum class ErrorCode
|
||||||
|
{
|
||||||
|
Success,
|
||||||
|
InvalidShapeId,
|
||||||
|
InvalidNumberOfPoints,
|
||||||
|
WrongShapeIdForTagType,
|
||||||
|
InvalidPointId,
|
||||||
|
InvalidEdgeId,
|
||||||
|
InvalidFaceId,
|
||||||
|
SolutionDidNotConverge,
|
||||||
|
MatrixFactorizationFailed,
|
||||||
|
DegenerateCellDetected,
|
||||||
|
MalformedCellDetected,
|
||||||
|
OperationOnEmptyCell,
|
||||||
|
CellNotFound,
|
||||||
|
|
||||||
|
UnknownError
|
||||||
|
};
|
||||||
|
```
|
||||||
|
|
||||||
|
A convenience function named `ErrorString` is provided to make it easy to
|
||||||
|
convert the `ErrorCode` to a descriptive string that can be placed in an
|
||||||
|
error.
|
||||||
|
|
||||||
|
## New Calling Specification
|
||||||
|
|
||||||
|
Previously, most execution environment functions took as an argument the
|
||||||
|
worklet calling the function. This made it possible to call `RaiseError` on
|
||||||
|
the worklet. The result of the operation was typically returned. For
|
||||||
|
example, here is how the _old_ version of interpolate was called.
|
||||||
|
|
||||||
|
``` cpp
|
||||||
|
FieldType interpolatedValue =
|
||||||
|
vtkm::exec::CellInterpolate(fieldValues, pcoord, shape, worklet);
|
||||||
|
```
|
||||||
|
|
||||||
|
The worklet is now no longer passed to the function. It is no longer needed
|
||||||
|
because an error is never directly raised. Instead, an `ErrorCode` is
|
||||||
|
returned from the function. Because the `ErrorCode` is returned, the
|
||||||
|
computed result of the function is returned by passing in a reference to a
|
||||||
|
variable. This is usually placed as the last argument (where the worklet
|
||||||
|
used to be). here is the _new_ version of how interpolate is called.
|
||||||
|
|
||||||
|
``` cpp
|
||||||
|
FieldType interpolatedValue;
|
||||||
|
vtkm::ErrorCode result =
|
||||||
|
vtkm::exec::CellInterpolate(fieldValues, pcoord, shape, interpolatedValue);
|
||||||
|
```
|
||||||
|
|
||||||
|
The success of the operation can be determined by checking that the
|
||||||
|
returned `ErrorCode` is equal to `vtkm::ErrorCode::Success`.
|
13
docs/changelog/remove-opengl-rendering-classes.md
Normal file
13
docs/changelog/remove-opengl-rendering-classes.md
Normal file
@ -0,0 +1,13 @@
|
|||||||
|
# Removed OpenGL Rendering Classes
|
||||||
|
|
||||||
|
When the rendering library was first built, OpenGL was used to implement
|
||||||
|
the components (windows, mappers, annotation, etc.). However, as the native
|
||||||
|
ray casting became viable, the majority of the work has focused on using
|
||||||
|
that. Since then, the original OpenGL classes have been largely ignored.
|
||||||
|
|
||||||
|
It has for many months been determined that it is not work attempting to
|
||||||
|
maintain two different versions of the rendering libraries as features are
|
||||||
|
added and changed. Thus, the OpenGL classes have fallen out of date and did
|
||||||
|
not actually work.
|
||||||
|
|
||||||
|
These classes have finally been officially removed.
|
Loading…
Reference in New Issue
Block a user