GitLab

This commit add support for 6 component symmetric tensor
array, by converting symmetric tensor to standard tensor.
Modifying Legacy reader/writer to support 6 Component tensor

Fixed clang warning about presence of doxygen deprecation comment with no corresponding compiler attribute (ie no VTK_LEGACY)

Issue was that a cell's celldata has a different ordering than
the ordering of the data set that the cell comes from. Most errors
were using the source data set cell id and the source cell
celldata.

Fixed clang warning about presence of doxygen deprecation
comment with no corresponding compiler attribute (ie no
VTK_LEGACY)

There is a singularity when v = 0. This patch checks for v = 0 and
replaces it with a small number, .05.

A new ivar DeltaV0 can change this value.

This bug was noticed when running the VTK wiki example:
Cxx/GeometricObjects/ParametricObjectsDemo2. While rotating the camera
for the Kuen surface, the center of rotation appeared off. The
z-coordinate was NAN for points when v == 0.

Also, the ordering of triangles was incorrect.

In the spirit of mesh subdivision filter, this filter operates on
a point cloud, generating new points in the local neighborhood of
existing points.

Bill Lorenson noticed that the front face of orientable surfaces was being
 displayed as a back face. This arose as a "hack" when these functions
 were
  first implemented because the cross-product used to create the normals
  was
   right-handed, thus the triangulation orientation was clockwise.
    Additionally there were weird triangulations in the
    ParametricSuperEllipsoid
     and ParametricSuperToroid.

     The following three fixes have been applied:

     1) The orientation of the normals is fixed in the case of
     anti-clockwise
        ordering by calculating cross(Dv,Du) instead of cross(Du,Dv).
	   When this is done the normals point in the expected direction
	   and the
	      front face is rendered correctly. See:
	      vtkParametricFunctionSource.cxx.
	      2) All the surfaces now implement anti-clockwise ordering
	      with respect to the
	         triangulation.
		 3) The ParametricSuperEllipsoid and ParametricSuperToroid
		 have been reworked,
		    now the surface is constructed as four pieces that are
		    abutted together,
		       this removes the triangulations resulting in weird
		       appearances.
		       4) In order to implement the anti-clockwise
		       ordering in the triangulation
		          the x, y points have had to be swapped in a few
			  cases.
			  5) TestParametricFunctions.png has had to be
			  replaced. The images for
			     ParametricTorus, ParametricSuperEllipsoid and
			     ParametricSuperToroid
			        changed as a result of the above changes

There is a singularity when v = 0. This patch checks for v = 0 and
replaces it with a small number, .05.

A new ivar DeltaV0 can change this value.

This bug was noticed when running the VTK wiki example:
Cxx/GeometricObjects/ParametricObjectsDemo2. While rotating the camera
for the Kuen surface, the center of rotation appeared off. The
z-coordinate was NAN for points when v == 0.

Also, the ordering of triangles was incorrect.

In the spirit of mesh subdivision filter, this filter operates on
a point cloud, generating new points in the local neighborhood of
existing points.

This avoids forcing every library that includes a vtk header file to
link to tbb if vtk was built with this backend.

CMake 3.7 adds support for cross-compiling to Android without a complex
toolchain file.  Port our main CMake build system to work without the
`android.toolchain.cmake` file:

```
$ cmake ../VTK \
    -DCMAKE_SYSTEM_NAME=Android \
    -DCMAKE_ANDROID_NDK=/path/to/ndk \
    -DVTKCompileTools_DIR=/path/to/vtk-compile-tools \
    -DOPENGL_ES_VERSION=3.0 \
    -DVTK_Group_StandAlone=OFF
```

Bill Lorenson noticed that the front face of orientable surfaces was being
 displayed as a back face. This arose as a "hack" when these functions
 were
  first implemented because the cross-product used to create the normals
  was
   right-handed, thus the triangulation orientation was clockwise.
    Additionally there were weird triangulations in the
    ParametricSuperEllipsoid
     and ParametricSuperToroid.

     The following three fixes have been applied:

     1) The orientation of the normals is fixed in the case of
     anti-clockwise
        ordering by calculating cross(Dv,Du) instead of cross(Du,Dv).
	   When this is done the normals point in the expected direction
	   and the
	      front face is rendered correctly. See:
	      vtkParametricFunctionSource.cxx.
	      2) All the surfaces now implement anti-clockwise ordering
	      with respect to the
	         triangulation.
		 3) The ParametricSuperEllipsoid and ParametricSuperToroid
		 have been reworked,
		    now the surface is constructed as four pieces that are
		    abutted together,
		       this removes the triangulations resulting in weird
		       appearances.
		       4) In order to implement the anti-clockwise
		       ordering in the triangulation
		          the x, y points have had to be swapped in a few
			  cases.
			  5) TestParametricFunctions.png has had to be
			  replaced. The images for
			     ParametricTorus, ParametricSuperEllipsoid and
			     ParametricSuperToroid
			        changed as a result of the above changes

Static builds of paraview were not freeing
vtkObjectFactory::RegisteredFactories or vtkOutputWindow::Instance. See:

https://open.cdash.org/viewTest.php?onlyfailed&buildid=4572721

This fixes the issue to ensure that they are always freed at process exit.

Removing this method in favor of using
vtkObjectBase::InitializeObjectBase, since it uses a user-supplied string.
This approach has proven fragile with templated classes.

Plus, the method is only a thin wrapper around
vtkDebugLeaks::ConstructClass and doesn't need to be.

vtkDebugLeaks registers instance by class name, which worked well for
many years. However, now that we have more templated code, this is
becoming difficult. For instance, "template <typename T> vtkBuffer<T>"
would be identified as "vtkBuffer<T>" when registering with
vtkDebugLeaks, but deregistered with the compiler dependent
typeid(vtkBuffer<T>).name() string returned from GetClassName().

This patch moves vtkDebugLeaks registrations to the method
vtkObjectBase::InitializeObjectBase(), which must be called after the
vtkObjectBase is instantiated. This ensures that objects are
registered using the same string as when they are destroyed. In
general, a call to "new vtkSomeClass" must be followed by a call to
InitializeObjectBase on the new instance. The common ::New()
implementation macros in vtkObjectFactory will ensure that
registration happens correctly.

Two notable exceptions are vtkCommand and vtkInformationKey
subclasses. These do not require any specific handling for
vtkDebugLeaks registration.

See discussion at:

http://vtk.1045678.n5.nabble.com/Proposal-Simplify-vtkDebugLeaks-registration-td5740222.html

I used perl regex to find any groups that spanned a protected: or
private: access specifier.

This commit reindents the code with the following utility:
Utilities/Maintenance/vtk-reindent-code.py

This utility changes the positions of the braces so that they are no
longer indented relative to the code block they reside in.

The bash command line used was the following:

for d in Charts Common Deprecated Domains Examples Filters GUISupport \
         Geovis IO Imaging Infovis Interaction Parallel Rendering \
         Testing Views Web Wrapping; do
  for e in cxx cxx.in txx txx.in hxx hxx.in h h.in c c.in; do
    find "${d}" -name "*.${e}" -exec \
      python Utilities/Maintenance/vtk_reindent_code.py {} +
  done
done

generated via:
cd $VTKSRC
perl Utilities/Doxygen/doc_header2doxygen.pl --to ~/tmp/vtkheaders .
cp -r ~/tmp/vtkheaders/* .

fix problematic ccomments that trip up doxygen generator. Mostly
c style comments in class description but a few cases of comments
not in expected location that leads to stripped out code and comp fails

fix trailing whitespaces that will fail style check when committed

Thanks Andrew Maclean for updating the url to VTK publications.

The NaN check was only done for the linear scale, the log scale missed
the check, and NaN would be displayed in the BelowRangeColor instead of
the NanColor.  For performance reasons, the NaN check is only performed
on floating-point values, not on integer values.

For accuracy the vtkDataSetCellIterator should have
the same floating point accuracy as the input data set. For
ImageData and HyperOctree it will be double since that is
their native data type for storing point locations. For
RectilinearGrid and HyperTreeGrid we do the best we can
but there are 3 arrays which store the point locations
for these grids so it's not always clear which one to use.
This was already done for the other data set cell iterators.

For accuracy the classes that derive from vtkCellIterator that
use data sets with vtkPoints for their point storage should have
the same floating point accuracy. This was already done for
vtkPointSetCellIterator but not the others.