VTK issueshttps://gitlab.kitware.com/vtk/vtk/-/issues2017-04-11T08:00:55-04:00https://gitlab.kitware.com/vtk/vtk/-/issues/16874Missing debug libraries on install2017-04-11T08:00:55-04:00Boris BasicMissing debug libraries on installOn Windows, after building the INSTALL project of VTK 7.0 or 7.1 in debug mode, the following libraries are missing:
vtkGeovisCore
vtkgl2ps
vtkGUISupportQtSQL
vtkImagingMorphological
vtkImagingStatistics
vtkInfovisLayou...On Windows, after building the INSTALL project of VTK 7.0 or 7.1 in debug mode, the following libraries are missing:
vtkGeovisCore
vtkgl2ps
vtkGUISupportQtSQL
vtkImagingMorphological
vtkImagingStatistics
vtkInfovisLayout
vtkInteractionImage
vtkIOEnSight
vtkIOExport
vtkIOImport
vtkIOLSDyna
vtkIOMINC
vtkIOMovie
vtkIOParallelXML
vtkIOPLY
vtkIOSQL
vtkIOTecplotTable
vtkIOVideo
vtkLocalExample
vtkoggtheora
vtkproj4
vtkRenderingGL2PSOpenGL2
vtkRenderingImage
vtkRenderingLOD
vtkRenderingQt
vtkTestingIOSQL
vtkViewsInfovis
vtkViewsQt8.0https://gitlab.kitware.com/vtk/vtk/-/issues/16849Wrapping classes with deleted methods in Python2017-04-11T08:00:55-04:00David GobbiWrapping classes with deleted methods in PythonNow that VTK is moving towards C++11, people are more careful than ever about properly deleting unused destructors and copy constructors. The wrappers, likewise, need to know when these methods are or are not available.
Background: T...Now that VTK is moving towards C++11, people are more careful than ever about properly deleting unused destructors and copy constructors. The wrappers, likewise, need to know when these methods are or are not available.
Background: The Python wrappers can wrap an object "by reference" or "by value". All classes that derive from vtkObjectBase are wrapped "by reference", which means that these objects are always handled via a pointer. Conversely, all other classes are wrapped "by value", meaning that the Python wrappers make their own copy of these objects and use pass-by-value semantics. Obviously, pass-by-value requires a copy constructor, but the wrappers add additional restrictions on top of this.
Currently, for a non-vtkObjectBase object to be wrapped, it must have a public copy constructor and, furthermore, must have a public destructor and a public default constructor. I want to change this, because it is too restrictive. Here are some examples of classes I'd like to wrap:
class vtkFloatingPointExceptions
{
public:
static void Enable();
static void Disable();
private:
vtkFloatingPointExceptions() = delete;
vtkFloatingPointExceptions(const vtkFloatingPointExceptions&) = delete;
void operator=(const vtkFloatingPointExceptions&) = delete;
};
The above class is only used via its static methods, so the fact that it cannot be constructed is a non-issue. It should be wrapped so that its static methods can be used.
class vtkDICOMFile
{
public:
vtkDICOMFile(const char *filepath, int mode);
void Close();
~vtkDICOMFile();
private:
vtkDICOMFile() = delete;
vtkDICOMFile(const vtkDICOMFile&) = delete;
void operator=(const vtkDICOMFile&) = delete;
};
The above class has a deleted copy constructor, and therefore cannot be passed by value, but since we can construct and delete it and call its methods, there is no reason why we shouldn't wrap it. Also, since pass-by-value is impossible, we could allow pass-by-reference and assume that whoever constructed the object is responsible for deleting it.
The wrapper files that need to be fixed are vtkWrapPythonType.c and PyVTKSpecialObject.cxx.8.0David GobbiDavid Gobbihttps://gitlab.kitware.com/vtk/vtk/-/issues/15833Install of designer plugin fails in debug mode with custom postfix2017-04-11T08:00:55-04:00Kitware RobotInstall of designer plugin fails in debug mode with custom postfix**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=15833). Further discussion may take place here.**
---
If I compile VTK 6.3.0 with VTK_Group_Qt enabled and an additional flag
CMAKE_...**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=15833). Further discussion may take place here.**
---
If I compile VTK 6.3.0 with VTK_Group_Qt enabled and an additional flag
CMAKE_DEBUG_POSTFIX = d, then "nmake install" fails for designer plugin.
In the build directory I have to change GUISupport\Qt\PluginInstall.cmake
line 5 from
SET(VTK_INSTALL_QT_PLUGIN_FILE "QVTKWidgetPlugin.dll")
to
SET(VTK_INSTALL_QT_PLUGIN_FILE "QVTKWidgetPlugind.dll")8.0https://gitlab.kitware.com/vtk/vtk/-/issues/16928vtk 7.1.1 on Find HDF5 fails with cmake < 3.5.22017-04-05T13:34:02-04:00David E. DeMarlevtk 7.1.1 on Find HDF5 fails with cmake < 3.5.2Per Atri's report.
> I am a packager of vtk for openSUSE [1], and I find that vtk 7.1 fails
> to build, e.g.
> on openSUSE 13.2 (hd5 1.8.13, cmake 3.0.2), /*fails*/
> on openSUSE Leap 42.1 (hdf5 1.8.15, cmake 3.3.2), /* fails */
...Per Atri's report.
> I am a packager of vtk for openSUSE [1], and I find that vtk 7.1 fails
> to build, e.g.
> on openSUSE 13.2 (hd5 1.8.13, cmake 3.0.2), /*fails*/
> on openSUSE Leap 42.1 (hdf5 1.8.15, cmake 3.3.2), /* fails */
> but builds fine on openSUSE Leap 42.2 (hdf5 1.8.15, cmake 3.5.2) /* ok */
> and later. /*ok */
> The error I see on the older systems is along the lines of:
> ```
> [ 245s] -- [1;4;34mConfiguring proj library:[0m
> [ 245s] --
> [ 245s] -- PROJ_CORE_TARGET = vtkproj4
> [ 245s] -- PROJ_CORE_TARGET_OUTPUT_NAME = vtkproj4
> [ 245s] -- PROJ_LIBRARIES = vtkproj4
> [ 246s] CMake Error at CMake/NewCMake/FindHDF5.cmake:483
> (find_program):
> [ 246s] find_program does not support NAMES_PER_DIR
> [ 246s] Call Stack (most recent call first):
> [ 246s] CMake/FindHDF5.cmake:7 (include)
> [ 246s] CMake/vtkModuleMacros.cmake:858 (find_package)
> [ 246s] ThirdParty/hdf5/CMakeLists.txt:1 (vtk_module_third_party)
> ```
> Any way we could continue to provide vtk 7.1 for these older
> installations, or should we simply stop upgrading vtk for these? Thanks
> for any help, suggestions, etc.7.1.1Chuck AtkinsChuck Atkinshttps://gitlab.kitware.com/vtk/vtk/-/issues/16905TestGlyph3DMapperPicking silently failing since CPDM22017-04-24T04:25:08-04:00Allison Vacantialliepiper16@gmail.comTestGlyph3DMapperPicking silently failing since CPDM2I found this error after making a small change to how depth buffers are updated while multisampling:
https://open.cdash.org/testDetails.php?test=495715128&build=4620844
It's been failing for a while with an image error of 9, but my pat...I found this error after making a small change to how depth buffers are updated while multisampling:
https://open.cdash.org/testDetails.php?test=495715128&build=4620844
It's been failing for a while with an image error of 9, but my patch for some reason pushed it above the threshold to 12.
Bisecting the behavior points to the new `vtkCompositePolyDataMapper2` implementation (7912d3407f6ea6a1cbdd6f4f3d63d2b09e9393bb) as the culprit.
Test Image:
![image](/uploads/5e011d4db91fef1d7010b7362df88935/image.png)
Valid Image:
![image](/uploads/2471141fede2c28485c550f60ab02165/image.png)
Inspecting the selection buffer shows that the glyphs have varying values during the id pass, though each glyph instance is supposed to be uniform (image enlarged/brightened):
![image](/uploads/b0632133791de12ea0093b73cdbdd40d/image.png)
This is causing non-selected points to be incorrectly picked.
Other notes:
* Seems to be related to multisampling. This is one of the few tests that doesn't turn it off, and disabling MSAA in the test fixes the bug. Looks like this may be a general issue with picking + MSAA.
* I've verified that we are in fact disabling MSAA with `glDisable(GL_MULTISAMPLE)` while rendering the selection buffers.
* Inspecting the selection buffer produced by an apitrace replay oddly enough does NOT show the buggy selection buffer -- all pixels belonging to a glyph share the correct id.
* This doesn't seem to be platform / driver specific, it's happened on linux and windows (osx/ogl2 coverage is spotty, not sure if it happens there): https://open.cdash.org/index.php?compare1=63&filtercount=2&field1=buildname%2Fstring&project=VTK&field2=buildstarttime%2Fdate&showfilters=0&limit=100&compare2=83&value1=e102e48d&showfeed=0&value2=20161031T152056
* This is really weird.7.1https://gitlab.kitware.com/vtk/vtk/-/issues/16904v7.1.0 Can not display non ASCII text on TextActor2017-04-24T04:25:09-04:00Honghev7.1.0 Can not display non ASCII text on TextActorEnvironment:
* Ubuntu 14.04.5 64bit
* VTK 7.1.0
I try this code, but show nothing:
```
vtkSmartPointer<vtkTextActor> textActor =
vtkSmartPointer<vtkTextActor>::New();
textActor->SetInput("\u5728\u7ebf\u5de5\u5177");...Environment:
* Ubuntu 14.04.5 64bit
* VTK 7.1.0
I try this code, but show nothing:
```
vtkSmartPointer<vtkTextActor> textActor =
vtkSmartPointer<vtkTextActor>::New();
textActor->SetInput("\u5728\u7ebf\u5de5\u5177");
// or
textActor->SetInput("中文");
```7.1https://gitlab.kitware.com/vtk/vtk/-/issues/16901vtkOSPRayRendererNode.cxx: error: ‘isnan’ was not declared2017-04-24T04:25:09-04:00Jean M. FavrevtkOSPRayRendererNode.cxx: error: ‘isnan’ was not declared@demarle
I switched to a new machine with a newer compiler.
g++ (Ubuntu 5.4.0) does not like
vtkOSPRayRendererNode.cxx:124:36: error: ‘isnan’ was not declared in this scope
I corrected to the following line to make it compile cleanl...@demarle
I switched to a new machine with a newer compiler.
g++ (Ubuntu 5.4.0) does not like
vtkOSPRayRendererNode.cxx:124:36: error: ‘isnan’ was not declared in this scope
I corrected to the following line to make it compile cleanly:
if (std::isnan(ospDepthBuffer[i]))
This is both in ParaView master, and 5.2RC27.1Michael FoglemanMichael Foglemanhttps://gitlab.kitware.com/vtk/vtk/-/issues/16899Blurred edges problem in VTK 7.12017-04-24T04:25:09-04:00Boris BasicBlurred edges problem in VTK 7.1Edges in VTK 7.1 look blurred compared to the clean look they had in VTK 7.0 and before. The problem is particulary visible when displaying an unstructured grid with extract edges like the one I attached to the issue. The code used was c...Edges in VTK 7.1 look blurred compared to the clean look they had in VTK 7.0 and before. The problem is particulary visible when displaying an unstructured grid with extract edges like the one I attached to the issue. The code used was compiled with Visual Studio 2013 Update 5 and executed on Windows 7 64 bits. The graphics card is a nVidia GeForce Quadro 2000.
Here is a screenshot showing the differences between both versions of VTK:
![VTK71bug](/uploads/c64cceaa479057c1e4ff2c691d4a4322/VTK71bug.PNG)
Here is the code used:
```c++
#include <vtkXMLUnstructuredGridReader.h>
#include <vtkSmartPointer.h>
#include <vtkPolyDataMapper.h>
#include <vtkActor.h>
#include <vtkRenderWindow.h>
#include <vtkRenderer.h>
#include <vtkRenderWindowInteractor.h>
#include <vtkUnstructuredGridGeometryFilter.h>
#include <vtkDataSetSurfaceFilter.h>
#include <vtkPolyDataNormals.h>
#include <vtkExtractEdges.h>
#include <vtkProperty.h>
int main(int argc, char *argv[])
{
if (argc != 2)
{
cout << "Required parameters: Filename" << endl;
return EXIT_FAILURE;
}
std::string inputFilename = argv[1];
vtkSmartPointer<vtkXMLUnstructuredGridReader> reader = vtkSmartPointer<vtkXMLUnstructuredGridReader>::New();
reader->SetFileName(inputFilename.c_str());
reader->Update();
// Filter the geometry
vtkSmartPointer<vtkUnstructuredGridGeometryFilter> geometryFilter = vtkSmartPointer<vtkUnstructuredGridGeometryFilter>::New();
geometryFilter->SetInputConnection(reader->GetOutputPort());
// Convert to polydata using a surface filter
vtkSmartPointer<vtkDataSetSurfaceFilter> surfaceFilter = vtkSmartPointer<vtkDataSetSurfaceFilter>::New();
surfaceFilter->UseStripsOff();
surfaceFilter->SetNonlinearSubdivisionLevel(1);
surfaceFilter->SetInputConnection(geometryFilter->GetOutputPort());
// Compute the normals
vtkSmartPointer<vtkPolyDataNormals> normals = vtkSmartPointer<vtkPolyDataNormals>::New();
normals->SetInputConnection(surfaceFilter->GetOutputPort());
normals->ComputePointNormalsOn();
normals->ComputeCellNormalsOff();
normals->SetFeatureAngle(60.0);
vtkSmartPointer<vtkPolyDataMapper> geometryMapper = vtkSmartPointer<vtkPolyDataMapper>::New();
geometryMapper->SetInputConnection(normals->GetOutputPort());
geometryMapper->InterpolateScalarsBeforeMappingOn();
vtkSmartPointer<vtkActor> geometryActor = vtkSmartPointer<vtkActor>::New();
geometryActor->SetMapper(geometryMapper);
// Set the lighting parameters
geometryActor->GetProperty()->SetSpecularPower(0.0);
geometryActor->GetProperty()->SetAmbient(0.1);
geometryActor->GetProperty()->SetDiffuse(0.8);
// Extract edges
vtkSmartPointer<vtkExtractEdges> extractEdges = vtkSmartPointer<vtkExtractEdges>::New();
extractEdges->SetInputConnection(geometryFilter->GetOutputPort());
vtkSmartPointer<vtkPolyDataMapper> edgesMapper = vtkSmartPointer<vtkPolyDataMapper>::New();
edgesMapper->SetInputConnection(extractEdges->GetOutputPort());
vtkSmartPointer<vtkActor> edgesActor = vtkSmartPointer<vtkActor>::New();
edgesActor->SetMapper(edgesMapper);
edgesActor->PickableOff();
edgesActor->GetProperty()->SetOpacity(0.5);
// Create the renderer
vtkSmartPointer<vtkRenderer> renderer = vtkSmartPointer<vtkRenderer>::New();
vtkSmartPointer<vtkRenderWindow> renderWindow = vtkSmartPointer<vtkRenderWindow>::New();
renderWindow->AddRenderer(renderer);
vtkSmartPointer<vtkRenderWindowInteractor> renderWindowInteractor = vtkSmartPointer<vtkRenderWindowInteractor>::New();
renderWindowInteractor->SetRenderWindow(renderWindow);
// Add actors to the renderer
renderer->AddActor(geometryActor);
renderer->AddActor(edgesActor);
renderer->SetBackground(.3, .6, .3);
renderWindowInteractor->Initialize();
renderWindowInteractor->Start();
return EXIT_SUCCESS;
}
```
And the volume mesh used (sorry for not providing a smaller one there...)
[usg0.7z](/uploads/8a4c2b8de5848561e1c0672b3c463ee3/usg0.7z)7.1Allison Vacantialliepiper16@gmail.comAllison Vacantialliepiper16@gmail.comhttps://gitlab.kitware.com/vtk/vtk/-/issues/16876Switching offscreen rendering from off to on crashes on Windows2017-04-24T04:25:09-04:00Boris BasicSwitching offscreen rendering from off to on crashes on WindowsStarting VTK 7.0, a bug occurred when switching a render window to offscreen rendering and then back to on. This is caused by the window context being incorrectly destroyed.
Below is a small piece of code used to reproduce the bug. Thi...Starting VTK 7.0, a bug occurred when switching a render window to offscreen rendering and then back to on. This is caused by the window context being incorrectly destroyed.
Below is a small piece of code used to reproduce the bug. This creates a window with a sphere, clicking inside the window leads to a crash.
```c++
#include "vtkSphereSource.h"
#include "vtkPolyDataMapper.h"
#include "vtkRenderer.h"
#include "vtkRenderWindow.h"
#include "vtkRenderWindowInteractor.h"
int main()
{
vtkSmartPointer<vtkSphereSource> sphere = vtkSmartPointer<vtkSphereSource>::New();
sphere->SetRadius( 10.0 );
vtkSmartPointer<vtkPolyDataMapper> mapper = vtkSmartPointer<vtkPolyDataMapper>::New();
mapper->SetInputConnection( sphere->GetOutputPort() );
vtkSmartPointer<vtkActor> actor = vtkSmartPointer<vtkActor>::New();
actor->SetMapper( mapper );
vtkSmartPointer<vtkRenderer> renderer = vtkSmartPointer<vtkRenderer>::New();
renderer->AddActor( actor );
vtkSmartPointer<vtkRenderWindow> renderWindow = vtkSmartPointer<vtkRenderWindow>::New();
renderWindow->AddRenderer( renderer );
vtkSmartPointer<vtkRenderWindowInteractor> interactor = vtkSmartPointer<vtkRenderWindowInteractor>::New();
interactor->SetRenderWindow( renderWindow );
interactor->Initialize();
renderWindow->OffScreenRenderingOn();
renderWindow->OffScreenRenderingOff();
interactor->Start();
return 0;
}
```
This code worked perfectly in VTK 6.x. The bug is due to a change that occurred between 6.3 and 7.0 in **vtkWin32OpenGLRenderWindow::DestroyWindow()**:
VTK 6.3:
```c++
void vtkWin32OpenGLRenderWindow::DestroyWindow()
{
if(this->WindowIdReferenceCount > 0)
{
--this->WindowIdReferenceCount;
if(this->WindowIdReferenceCount == 0)
{
this->Clean();
if (this->WindowId)
{
ReleaseDC(this->WindowId, this->DeviceContext);
// can't set WindowId=NULL, needed for DestroyWindow
this->DeviceContext = NULL;
// clear the extra data before calling destroy
vtkSetWindowLong(this->WindowId,sizeof(vtkLONG),(vtkLONG)0);
if(this->OwnWindow)
{
::DestroyWindow(this->WindowId); // windows api
this->WindowId=0;
}
}
}
}
}
```
VTK 7.x:
```c++
void vtkWin32OpenGLRenderWindow::DestroyWindow()
{
this->Clean();
if (this->WindowIdReferenceCount > 0)
{
--this->WindowIdReferenceCount;
if (this->WindowIdReferenceCount == 0)
{
if (this->WindowId)
{
ReleaseDC(this->WindowId, this->DeviceContext);
// can't set WindowId=NULL, needed for DestroyWindow
this->DeviceContext = NULL;
// clear the extra data before calling destroy
vtkSetWindowLong(this->WindowId, sizeof(vtkLONG), (vtkLONG)0);
if (this->OwnWindow)
{
::DestroyWindow(this->WindowId); // windows api
this->WindowId = 0;
}
}
}
}
}
```
VTK 6.3 code was right there, because in VTK 7.x, call to ```Clean``` is done before checking that the window reference count is equal to 0, which leads to the OpenGL context being destroyed whil a window is still alive.7.1Ken MartinKen Martinhttps://gitlab.kitware.com/vtk/vtk/-/issues/16870TransformInputSamplingOff() for vtkImageReslice computes wrong origin2017-04-24T04:25:09-04:00David GobbiTransformInputSamplingOff() for vtkImageReslice computes wrong originThe TransformInputSamplingOff() method for vtkImageReslice is supposed to preserve the input spacing and origin of the image, but it doesn't. Instead, the output origin is shifted relative to the input origin.The TransformInputSamplingOff() method for vtkImageReslice is supposed to preserve the input spacing and origin of the image, but it doesn't. Instead, the output origin is shifted relative to the input origin.7.1David GobbiDavid Gobbihttps://gitlab.kitware.com/vtk/vtk/-/issues/16869recent valgrind defect2017-04-24T04:25:09-04:00David E. DeMarlerecent valgrind defecthttps://open.cdash.org/viewDynamicAnalysis.php?buildid=4585598
The tests that silently fail are most likely timeouts. Just disable them in the dashboard script.
The other two should be fixed by the responsible parties.https://open.cdash.org/viewDynamicAnalysis.php?buildid=4585598
The tests that silently fail are most likely timeouts. Just disable them in the dashboard script.
The other two should be fixed by the responsible parties.7.1Chuck AtkinsChuck Atkinshttps://gitlab.kitware.com/vtk/vtk/-/issues/16868vtkValuePass and OpenGL ES2017-04-24T04:25:09-04:00David E. DeMarlevtkValuePass and OpenGL EShttps://open.cdash.org/viewBuildError.php?buildid=4586175https://open.cdash.org/viewBuildError.php?buildid=45861757.1David E. DeMarleDavid E. DeMarlehttps://gitlab.kitware.com/vtk/vtk/-/issues/16867VTK_SMP_BACKEND=TBB enables implicit linking to TBB2018-12-04T16:32:27-05:00Shawn WaldonVTK_SMP_BACKEND=TBB enables implicit linking to TBBvtkAtomic is including tbb/atomich and tbb's headers on windows do #pragma based implicit linking unless the compile option __TBB_NO_IMPLICIT_LINKAGE is enabled. This means that any library that includes a vtk header file in any of it's...vtkAtomic is including tbb/atomich and tbb's headers on windows do #pragma based implicit linking unless the compile option __TBB_NO_IMPLICIT_LINKAGE is enabled. This means that any library that includes a vtk header file in any of it's source files must link against TBB even though tbb.lib is not in its link line. We should avoid using tbb headers in VTK's public headers or at least guard it with the option to disable implicit linkage.
@sujin.philip
@chuck.atkins @demarle Is this worth trying to get into 7.1?7.1https://gitlab.kitware.com/vtk/vtk/-/issues/16857vtkLookupTable does not handle NaN values with Log10 scale2017-04-24T04:25:09-04:00Federico MiorellivtkLookupTable does not handle NaN values with Log10 scaleIt seems like vtkLookupTable does not handle correclty NaN values when the Log10 scale is used.
In this case, all the NaNs in the input are not mapped to NanColor but to the minimum range color.
Unless there is a reason for this, I b...It seems like vtkLookupTable does not handle correclty NaN values when the Log10 scale is used.
In this case, all the NaNs in the input are not mapped to NanColor but to the minimum range color.
Unless there is a reason for this, I believe the bug is in vtkLookupTable::vtkApplyLogScale().
Here is a patch that might fix it (VTK 6.3.0)
```
--- old/vtkLookupTable.cxx Wed Jul 13 15:11:08 2016
+++ new/vtkLookupTable.cxx Wed Sep 21 10:54:24 2016
@@ -358,6 +358,11 @@
inline double vtkApplyLogScale(double v, const double range[2],
const double logRange[2])
{
+ if (vtkMath::IsNan(v))
+ {
+ return v;
+ }
+
// is the range set for negative numbers?
if (range[0] < 0)
{
```7.1David GobbiDavid Gobbihttps://gitlab.kitware.com/vtk/vtk/-/issues/16855Average intensity projection for volume mapper2017-04-24T04:25:09-04:00Sankhesh JhaveriAverage intensity projection for volume mapperAdd support for average IP in the OpenGL2 GPU volume mapperAdd support for average IP in the OpenGL2 GPU volume mapper7.1Sankhesh JhaveriSankhesh Jhaverihttps://gitlab.kitware.com/vtk/vtk/-/issues/16850False vtkDebugLeaks reports from template classes when VTK_ALL_NEW_OBJECT_FAC...2017-04-24T04:25:09-04:00Allison Vacantialliepiper16@gmail.comFalse vtkDebugLeaks reports from template classes when VTK_ALL_NEW_OBJECT_FACTORY enabled.The classes are being registered and un-registered using different class names. Two proposed solutions are discussed in this mailing list thread:
http://public.kitware.com/pipermail/vtk-developers/2016-September/034225.htmlThe classes are being registered and un-registered using different class names. Two proposed solutions are discussed in this mailing list thread:
http://public.kitware.com/pipermail/vtk-developers/2016-September/034225.html7.1Allison Vacantialliepiper16@gmail.comAllison Vacantialliepiper16@gmail.comhttps://gitlab.kitware.com/vtk/vtk/-/issues/16847vtkInteractorStyleDrawPolygon no longer works as "lasso tool" in 7.12017-04-24T04:25:09-04:00RickvtkInteractorStyleDrawPolygon no longer works as "lasso tool" in 7.1[TrackballCamera.cxx](/uploads/05034a1c83652e10256014b2ad750e09/TrackballCamera.cxx)[CMakeLists.txt](/uploads/be2fb9c048afb4d4acbd64b833beff3e/CMakeLists.txt)
This slightly modified example shows the the "Lasso" tool does not work with...[TrackballCamera.cxx](/uploads/05034a1c83652e10256014b2ad750e09/TrackballCamera.cxx)[CMakeLists.txt](/uploads/be2fb9c048afb4d4acbd64b833beff3e/CMakeLists.txt)
This slightly modified example shows the the "Lasso" tool does not work with VTK 7.1.7.1https://gitlab.kitware.com/vtk/vtk/-/issues/16007VTK 7.0 fails to build on Fedora 232017-04-24T04:25:09-04:00Kitware RobotVTK 7.0 fails to build on Fedora 23**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=16007). Further discussion may take place here.**
---
While building VTK 7.0 downloaded as a tar.gz archive from the official VTK web...**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=16007). Further discussion may take place here.**
---
While building VTK 7.0 downloaded as a tar.gz archive from the official VTK website, on Fedora 23, this error comes up:
/home/srsly111/Software_source_packages/VTK-7.0.0/Rendering/GL2PS/vtkGL2PSContextDevice2D.cxx:23:34: fatal error: vtkOpenGLGL2PSHelper.h: No such file or directory
compilation terminated.
Rendering/GL2PS/CMakeFiles/vtkRenderingGL2PS.dir/build.make:72: recipe for target 'Rendering/GL2PS/CMakeFiles/vtkRenderingGL2PS.dir/vtkGL2PSContextDevice2D.cxx.o' failed
make[2]: *** [Rendering/GL2PS/CMakeFiles/vtkRenderingGL2PS.dir/vtkGL2PSContextDevice2D.cxx.o] Error 1
make[2]: *** Waiting for unfinished jobs....
[ 66%] Tcl Wrapping - generating vtkQtInitializationTcl.cxx
/home/srsly111/Software_source_packages/VTK-7.0.0/Rendering/GL2PS/vtkGL2PSUtilities.cxx:24:34: fatal error: vtkOpenGLGL2PSHelper.h: No such file or directory
compilation terminated.
Rendering/GL2PS/CMakeFiles/vtkRenderingGL2PS.dir/build.make:96: recipe for target 'Rendering/GL2PS/CMakeFiles/vtkRenderingGL2PS.dir/vtkGL2PSUtilities.cxx.o' failed
make[2]: *** [Rendering/GL2PS/CMakeFiles/vtkRenderingGL2PS.dir/vtkGL2PSUtilities.cxx.o] Error 1
CMakeFiles/Makefile2:17459: recipe for target 'Rendering/GL2PS/CMakeFiles/vtkRenderingGL2PS.dir/all' failed
make[1]: *** [Rendering/GL2PS/CMakeFiles/vtkRenderingGL2PS.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
While the aforementioned file exists in the source tree:
$ locate vtkOpenGLGL2PSHelper.h
/home/srsly111/Software_source_packages/VTK-7.0.0/Rendering/OpenGL/vtkOpenGLGL2PSHelper.h7.1https://gitlab.kitware.com/vtk/vtk/-/issues/17835Follow-up from "Add rendering ui"2020-04-08T15:53:25-04:00Ben BoeckelFollow-up from "Add rendering ui"The following discussion from !6470 should be addressed:
- [ ] @michael.migliore started a [discussion](https://gitlab.kitware.com/vtk/vtk/-/merge_requests/6470#note_728214): (+1 comment)
> @ken-martin when configured the first ti...The following discussion from !6470 should be addressed:
- [ ] @michael.migliore started a [discussion](https://gitlab.kitware.com/vtk/vtk/-/merge_requests/6470#note_728214): (+1 comment)
> @ken-martin when configured the first time on linux, `VTK_USE_X` is not set yet and the factory do not create `vtkXRenderWindowInteractor` but `vtkGenericRenderWindowInteractor`.
> Two workarounds are possible:
> - Configuring VTK a second time fix the issue because `VTK_USE_X` is now set.
> - Use `-DVTK_USE_X=ON` explicitly when configuring VTK.
>
> The issue is similar on OSX with `VTK_USE_COCOA`.
> Imo, this should be fixed before 9.0 release.
> Quick fix: adding `VTK::opengl` in RenderingUI module dependencies where `VTK_USE_X` is defined but I'm not sure this is what we want.
>
> cc @mwestphal9.0Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/17832Regression: SimpleCocoaVTK window resizing is glitchy2020-05-22T17:52:52-04:00Sean McBrideRegression: SimpleCocoaVTK window resizing is glitchyRepro:
- in VTK master, build and launch the SimpleCocoaVTK example, in Examples/GUI/Cocoa/
- resize the window repeatedly
- you'll notice various glitches/artifacts, see: ![image](/uploads/4b99a5c0a3464f20c5b65960a697504b/image.png)
...Repro:
- in VTK master, build and launch the SimpleCocoaVTK example, in Examples/GUI/Cocoa/
- resize the window repeatedly
- you'll notice various glitches/artifacts, see: ![image](/uploads/4b99a5c0a3464f20c5b65960a697504b/image.png)
- this doesn't occur in VTK 8.1.1
Before b75bc715d32d2e0dd155bad1bfa54bd8855ea7ea all was well.
b75bc715d32d2e0dd155bad1bfa54bd8855ea7ea (2019-11-18) caused (the left two) SimpleCocoaVTK views to not draw at all. That was fixed in 75f6607214790c0fe087507c7d37aa13ec2f6799 (2020-02-12) with a one liner. At that point the views were drawing _something_ again, but the resizing glitches are then present. The sample app didn't actually support window resizing until the other day (a0774e0f655229a64439f6b3a194ad89b77dd7c2) so it was easy to miss. I just took the one line fix into b75bc715d32d2e0dd155bad1bfa54bd8855ea7ea and the resizing glitches reproed.
In other words, b75bc715d32d2e0dd155bad1bfa54bd8855ea7ea is the culprit.9.0Ken MartinKen Martin