Handle properties are not properly set up when starting vtkBoxwidget2

Change-Id: Ia1a5d73f7b32b3620843be852ccca9a6ad6975be
FindPythonModules: use a function

Prevent unnecessary scope pollution.

Change-Id: If268d5fcbcf4edd7b5dcac62fa567ca4cf634082
FindPythonModules: search if not found

It might have been installed to satisfy the module requirement since the
first check.

Change-Id: I1775c3d060cbf75bec383309fd026a4cf7b348a3
vtkmpi4py: empty out Py_{UN,}BLOCK_THREADS

Cython will put _save in a WITH_THREAD block, so it isn't available
without threads. Just having empty code works just as well.

Change-Id: Ia5c63824916a5f14b1d0cf6833e12ed40bf4f71b
Fix rotation handling in vtkTransformInterpolator.

Overhaul the handling of rotations in vtkTransformInterpolator, which
was being done in a completely wrong manner due to performing
interpolations on angle-axis rotation values rather than actual
quaternions.

Change-Id: I593a2a8baeeab4b3734cbaece99dbe5da497fe98
Fix operation order in vtkTransformInterpolator.

Modify vtkTransformInterpolator::InitializeInterpolation() to set the
interpolation type first, then initialize the interpolators, AND THEN
set the number of tuples. The quaternion interpolator may not care, but
for vtkTupleInterpolator, this ordering is CRITICAL, as either of the
first two steps may unset the number of tuples, resulting in a broken
interpolator.

Change-Id: Id4787bb304ca4b3e8a9501e5583b4caf59dd507f
Check if the selection array exists before dereferencing it.

Change-Id: I63a6952a0d4493d57096d6b544f03ed9a6f0b107
some fixes for macs

Change-Id: Iaa2a54bcfa67e52fd6ccd346d89d3a6a960b0d53
fix glyph memory leak and issue on intel

Change-Id: I68652c7397f806e544dd2bbef7a2c009755cf3f2
Fix vtkAbstractPolygonalHandleRepresentation3D visibility

When the default position of the camera is not looking at 0,0,0 (default
handle position) the handle representation was never displayed.
Its bounds were culled by the renderer which prevented the handle actor
from being rendered which prevented the representation from calling
BuildRepresentation() which prevented the actor to have its correct
position set.

Change-Id: I36bffca7fef86c1493ff6869522fb89824390d06
Rename local functions and embed in anonymous namespace

The templated function vtkMapperScalarToTextureCoordinate was defined
within the implementation file for vtkScalarsToColorsPainter. An
identical function with the same name was also defined in the
implementation file for vtkMapper. As is done with multiply-defined
templated functions, the linker was selecting only one of these
definitions for use by both vtkScalarsToColors and vtkMapper,
which is obviously not desirable behavior, but which turned out
no to cause any problems because the definitions were the same.

Solved this problem by placing both function definitions in anonymous
namespaces. Also, reduce the size of the names of these functions to
exclude the class name prefix.

Change-Id: I7cd8533c383b9388846c2f72c0873c2201a9b395
Change clamping range for texture coordinates

When InterpolateScalarsBeforeMapping is on, vtkMapper and
vtkScalarsToColorsPainter would clamp texture coordinates to the range
[0, 1]. This lead to incorrect results if the range of the scalar
values associated with points that define a primitive were not
completely contained within the range of the color lookup table used
to color that primitive, e.g., a quad with scalar range [0,3] colored
by a color map with range [1,2], and the option
InterpolateScalarsBeforeMapping is on. In this case, the texture
coordinates should be in the range [-1, 2], not clamped to [0, 1].

Unfortunately, removing the clamping completely leads to another
problem. It turns out that some implementations of OpenGL do not
handle arbitrary texture coordinates of about 1000 or higher
correctly. To handle this, clamping has been retained, but to the
range [-1000, 1000]. Hopefully this covers most use cases.

Change-Id: I597c4c1b5f18af645fd6f54e90103321b20b8fb9
Turn on edge clamping

This will ensure that texture coordinates outside the range [0,1] will
map to either the first or last texel, depending on which side of the
range the texture coordinate falls, rather than a texture border color
of some blended combination of the border color and texel value.

Change-Id: I2a9731c48d264d9bed63f1db67b5ea4bca257224
Fixed errors exposed by changes to clamping of texture coordinates

Told the mapper to use the lookup table's range. Without doing that,
the mapper was using the range [0, 1] for the color map range instead
of approximately [-250, 250]. The somewhat correct (but wrong)
appearance of the original baselines was a side-effect of the
incorrect clamping. Baselines have been updated to reflect the
corrected color mapping.

Change-Id: I639c026cd6b889ab7416eb48695529423ffa0a82
Merge remote-tracking branch 'pvvtk/pv-master' into HEAD

* pvvtk/pv-master:

Change-Id: I3c4f01e6ac9cdf732ce11ab0ce4aa9acd9426fc0
Merge topic 'support-future-use-of-crossbar-io' into master

12f6589c Properly override ApplicationSession c-tor, supports Crossbar.io.
Merge topic 'fix_colormap_texture_coords' into master

56b92366 Fixed errors exposed by changes to clamping of texture coordinates
95686b60 Turn on edge clamping
b807a6d6 Change clamping range for texture coordinates
8160c637 Rename local functions and embed in anonymous namespace
Merge topic 'fix-vtkabstractpolygonalhandlerepresentation3d' into master

f8fe12a6 Fix vtkAbstractPolygonalHandleRepresentation3D visibility
Merge topic 'control-points-selection' into master

81a76c77 Check if the selection array exists before dereferencing it.
Merge remote-tracking branch 'pvvtk/pv-master' into HEAD

* pvvtk/pv-master:

Change-Id: I9aab8d3babb04ae43215561456eb396dc6a0f325