VTK issueshttps://gitlab.kitware.com/vtk/vtk/-/issues2022-04-12T21:33:52-04:00https://gitlab.kitware.com/vtk/vtk/-/issues/18475Errors when using vtkAxesTransformWidget2022-04-12T21:33:52-04:00ZenErrors when using vtkAxesTransformWidgetI want to use the `vtkAxesTransformWidget` to translate/rotate a `vtkActor`, but there is always some errors, like:
```
2022-02-25 13:22:30.804 ( 0.224s) [ 6226DF40] vtkVectorText.cxx:63 ERR| vtkVectorText (0x24e2410): ...I want to use the `vtkAxesTransformWidget` to translate/rotate a `vtkActor`, but there is always some errors, like:
```
2022-02-25 13:22:30.804 ( 0.224s) [ 6226DF40] vtkVectorText.cxx:63 ERR| vtkVectorText (0x24e2410): Text is not set!
2022-02-25 13:22:30.804 ( 0.224s) [ 6226DF40] vtkExecutive.cxx:753 ERR| vtkCompositeDataPipeline (0x24e2990): Algorithm vtkVectorText(0x24e2410) returned failure for request: vtkInformation (0x24e3230)
Debug: Off
Modified Time: 28727
Reference Count: 1
Registered Events: (none)
Request: REQUEST_DATA
FROM_OUTPUT_PORT: 0
ALGORITHM_AFTER_FORWARD: 1
FORWARD_DIRECTION: 0
```
And there is no such thing like a axesTransformWidget in the renderer.
the source code is
```c++
#include <vtkActor.h>
#include <vtkCameraOrientationWidget.h>
#include <vtkNamedColors.h>
#include <vtkNew.h>
#include <vtkPolyDataMapper.h>
#include <vtkProperty.h>
#include <vtkRenderWindow.h>
#include <vtkRenderWindowInteractor.h>
#include <vtkInteractorStyleSwitch.h>
#include <vtkRenderer.h>
#include <vtkSTLReader.h>
#include <vtkAxesActor.h>
#include <vtkCubeSource.h>
#include <vtkAxesTransformRepresentation.h>
#include <vtkAxesTransformWidget.h>
#include <vtkCamera.h>
#include <filesystem>
namespace fs = std::filesystem;
int main(int argc, char *argv[])
{
vtkNew<vtkNamedColors> colors;
vtkNew<vtkRenderWindow> ren_win;
vtkNew<vtkRenderWindowInteractor> iren;
vtkNew<vtkRenderer> ren;
{
vtkNew<vtkCubeSource> src;
src->SetXLength(0.1);
src->SetYLength(0.2);
src->SetZLength(0.3);
vtkNew<vtkPolyDataMapper> mapper;
mapper->SetInputConnection(src->GetOutputPort());
vtkNew<vtkActor> cube;
cube->SetMapper(mapper);
cube->SetPosition(0.5, 1., 0);
ren->AddActor(cube);
}
{
vtkNew<vtkAxesActor> axes;
axes->SetTotalLength(1.0, 1.0, 1.0);
axes->SetAxisLabels(false);
ren->AddActor(axes);
}
ren->SetBackground(colors->GetColor3d("grey").GetData());
ren_win->AddRenderer(ren);
ren_win->SetSize(600, 600);
ren_win->SetWindowName("VtkApp");
// Important: The interactor must be set prior to enabling the widget.
iren->SetRenderWindow(ren_win);
vtkNew<vtkCamera> cam;
// cam->SetParallelProjection(true);
ren->SetActiveCamera(cam);
vtkNew<vtkCameraOrientationWidget> cam_orient_manipulator;
cam_orient_manipulator->SetParentRenderer(ren);
// Enable the widget.
cam_orient_manipulator->On();
vtkNew<vtkAxesTransformRepresentation> rep;
vtkNew<vtkAxesTransformWidget> trans_widget;
trans_widget->SetInteractor(iren);
trans_widget->SetRepresentation(rep);
vtkNew<vtkInteractorStyleSwitch> style;
style->SetCurrentStyleToTrackballCamera();
iren->SetInteractorStyle(style);
iren->Initialize();
ren_win->Render();
trans_widget->On();
iren->Start();
return EXIT_SUCCESS;
}
```https://gitlab.kitware.com/vtk/vtk/-/issues/18474Multi-texture OBJ texture blending issue2022-02-24T04:04:54-05:00Paul DickensMulti-texture OBJ texture blending issueAs reported [here](https://discourse.vtk.org/t/multi-texture-obj-texture-blending-issue/7898), there seems to be an issue in VTK 9.1.0 with blending multiple textures. Textures rendered earlier in the rendering cycle appear much brighter...As reported [here](https://discourse.vtk.org/t/multi-texture-obj-texture-blending-issue/7898), there seems to be an issue in VTK 9.1.0 with blending multiple textures. Textures rendered earlier in the rendering cycle appear much brighter than they should. Only the last texture to be applied appears at the correct brightness.
### Background
When `vtkOBJReader` encounters a `usemtl` command it creates a new `TCoords` array with name equal to the material name. This array is padded with `[-1, -1]` at every point that does not 'belong' to that material. The material names can be retrieved from the `vtkPolyData` object using `GetFieldData().GetAbstractArray('MaterialNames')`. Material names are associated with texture maps in the OBJ file's MTL file (linked with the command `mtllib`). Multiple textures are applied to an `actor`'s `vtkProperty` using the command `SetTexture(name, texture)` and linked to the correct `TCoords` array using `MapDataArrayToMultiTextureAttribute` in `vtkPolyDataMapper`.
If each texture's wrap mode is set to `vtkTexture.ClampToBorder` the entries `[-1, -1]` in the `TCoords` map to black, and if each texture after the first uses blending mode `vtkTexture.VTK_TEXTURE_BLENDING_MODE_ADD` the multiple textures should blend correctly.
### Issue description
- If the texture maps are in JPEG format and the number of textures is greater than two, textures applied earlier in the render cycle appear brighter than they should (washed out). Only the last-applied texture appears at the correct brightness.
- If the number of texture maps is two or less, each texture is rendered as expected.
- If the texture maps are converted to PNG format with alpha channel each texture is rendered as expected, no matter how many textures are applied.
### To reproduce
The attached zip file [cube.zip](/uploads/3cb3de237977bc791d9f0230d4c15e4c/cube.zip) contains three sample OBJ files of a cube and a python script `test.py`. To test use Python 3.7 or greater with VTK 9.1.0 installed.
1. A cube with a different material defined on each of the six faces. Each material is linked to the same JPEG texture map. Five of the six faces have a washed-out texture.
```
python test.py cube1.obj
```
![image](/uploads/5b569dcdb9e050347bf1c66377885e49/image.png)
2. A cube with three faces assigned to one material and three faces assigned to a different material. Each material is linked to the same JPEG texture map. All six faces are textured correctly.
```
python test.py cube2.obj
```
3. A cube with a different material defined on each of the six faces. Each material is linked to the same PNG texture map with alpha channel. All six faces are textured correctly.
```
python test.py cube3.obj
```https://gitlab.kitware.com/vtk/vtk/-/issues/18473vtkXMLPartitionedDataSetCollectionWriter fails if given a plain filename with...2022-02-21T11:29:49-05:00Aron HelservtkXMLPartitionedDataSetCollectionWriter fails if given a plain filename with no pathIf `vtkXMLPartitionedDataSetCollectionWriter` is provided with a filename with no path, it fails.
```
vtkNew<vtkXMLPartitionedDataSetCollectionWriter> writer;
writer->SetInputDataObject(source->GetOutput());
write...If `vtkXMLPartitionedDataSetCollectionWriter` is provided with a filename with no path, it fails.
```
vtkNew<vtkXMLPartitionedDataSetCollectionWriter> writer;
writer->SetInputDataObject(source->GetOutput());
writer->SetFileName("PDSCollection.vtpc");
writer->Write();
```
Result:
```
2022-02-21 10:59:01.244 ( 4.203s) [ F6E0A800]vtkXMLPartitionedDataSe:92 ERR| vtkXMLPartitionedDataSetCollectionWriter (0x55c8f4f21630): Failed to create directory ''.
```https://gitlab.kitware.com/vtk/vtk/-/issues/18472Python wrapping failures in Windows, Python 3.10, VTK master2022-05-16T11:14:09-04:00Andrew MacleanPython wrapping failures in Windows, Python 3.10, VTK masterFor some time I have been having trouble building VTK with Python wrapping in Windows. I have narrowed it down the three specific settings.
Setup: Python 3.10.2, venv, Visual Studio 2022, Qt 6.2.3, latest VTK master.
My usual CMake set...For some time I have been having trouble building VTK with Python wrapping in Windows. I have narrowed it down the three specific settings.
Setup: Python 3.10.2, venv, Visual Studio 2022, Qt 6.2.3, latest VTK master.
My usual CMake settings (which work perfectly in Linux), and used to work in Windows are:
### CMake Settings
These settings are in addition to the default settings.
``` txt
CMAKE_BUILD_TYPE Debug
VTK_ALL_NEW_OBJECT_FACTORY ON
VTK_BUILD_TESTING ON
VTK_GROUP_ENABLE_Imaging WANT
VTK_GROUP_ENABLE_Qt WANT
VTK_GROUP_ENABLE_Rendering WANT
VTK_GROUP_ENABLE_StandAlone WANT
VTK_GROUP_ENABLE_Views WANT
VTK_GROUP_ENABLE_Web WANT
VTK_LEGACY_REMOVE ON
VTK_SMP_IMPLEMENTATION_TYPE tbb
VTK_USE_LARGE_DATA ON
VTK_WRAP_PYTHON ON
```
With these settings wrapping fails in Windows.
If I set:
```txt
VTK_GROUP_ENABLE_Qt DEFAULT
VTK_LEGACY_REMOVE OFF
VTK_SMP_IMPLEMENTATION_TYPE sequential
```
Python wrapping works.
If I individually set the above three options, I get the following:
```txt
VTK_GROUP_ENABLE_Qt WANT
Causes this when "import vtk" is invoked in Python on the command line:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "D:<path>\Kitware\build\VTK\bin\Lib\site-packages\vtk.py", line 31, in <module>
all_m = importlib.import_module('vtkmodules.all')
File "C:\Users\amaclean\AppData\Local\Programs\Python\Python310\lib\importlib\__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "D:<path>\Kitware\build\VTK\bin\Lib\site-packages\vtkmodules\all.py", line 30, in <module>
from .vtkRenderingQt import *
ImportError: DLL load failed while importing vtkRenderingQt: The specified module could not be found.
```
```txt
VTK_SMP_IMPLEMENTATION_TYPE tbb
Causes this when "import vtk" is invoked in Python on the command line:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "D:<path>\Kitware\build\VTK\bin\Lib\site-packages\vtk.py", line 31, in <module>
all_m = importlib.import_module('vtkmodules.all')
File "C:\Users\amaclean\AppData\Local\Programs\Python\Python310\lib\importlib\__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "D:<path>\Kitware\build\VTK\bin\Lib\site-packages\vtkmodules\all.py", line 7, in <module>
from .vtkCommonCore import *
ImportError: DLL load failed while importing vtkCommonCore: The specified module could not be found.
```
```txt
VTK_LEGACY_REMOVE ON
Building CXX object CMakeFiles\vtkIOLSDynaPyth...CMakeFiles\vtkIOLSDynaPython\vtkLSDynaReaderPython.cxx.obj
FAILED: CMakeFiles/vtkIOLSDynaPython.dir/CMakeFiles/vtkIOLSDynaPython/vtkLSDynaReaderPython.cxx.obj
C:\PROGRA~1\MIB055~1\2022\COMMUN~1\VC\Tools\MSVC\1431~1.311\bin\Hostx64\x64\cl.exe /nologo /TP -DKISSFFT_DLL_IMPORT=1 -DPYTHON_PACKAGE=\"vtkmodules\" -DVTK_IN_VTK -D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS -D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS -Dkiss_fft_scalar=double -DvtkIOLSDynaPython_EXPORTS -ID:<path>\Kitware\build\VTK\IO\LSDyna -ID:<path>\Kitware\src\VTK\IO\LSDyna -ID:<path>\Kitware\build\VTK\Common\Core -ID:<path>\Kitware\src\VTK\Common\Core -ID:<path>\Kitware\build\VTK\Common\ExecutionModel -ID:<path>\Kitware\src\VTK\Common\ExecutionModel -ID:<path>\Kitware\build\VTK\Common\DataModel -ID:<path>\Kitware\src\VTK\Common\DataModel -ID:<path>\Kitware\build\VTK\Common\Math -ID:<path>\Kitware\src\VTK\Common\Math -ID:<path>\Kitware\build\VTK\ThirdParty\kissfft\vtkkissfft -ID:<path>\Kitware\src\VTK\ThirdParty\kissfft\vtkkissfft -ID:<path>\Kitware\build\VTK\Common\Transforms -ID:<path>\Kitware\src\VTK\Common\Transforms -ID:<path>\Kitware\build\VTK\IO\XMLParser -ID:<path>\Kitware\src\VTK\IO\XMLParser -ID:<path>\Kitware\build\VTK\Wrapping\PythonCore -ID:<path>\Kitware\src\VTK\Wrapping\PythonCore -ID:<path>\Kitware\build\VTK\Utilities\Python -ID:<path>\Kitware\src\VTK\Utilities\Python -external:ID:<path>\Kitware\build\VTK\Utilities\KWIML -external:ID:<path>\Kitware\src\VTK\Utilities\KWIML -external:ID:<path>\Kitware\build\VTK\Utilities\KWSys -external:ID:<path>\Kitware\src\VTK\Utilities\KWSys -external:ID:<path>\Kitware\build\VTK\ThirdParty\kissfft -external:ID:<path>\Kitware\src\VTK\ThirdParty\kissfft -external:IC:\Users\amaclean\AppData\Local\Programs\Python\Python310\include -external:W0 /DWIN32 /D_WINDOWS /GR /EHsc /W4 /bigobj /Zi /Ob0 /Od /RTC1 -MDd /showIncludes /FoCMakeFiles\vtkIOLSDynaPython.dir\CMakeFiles\vtkIOLSDynaPython\vtkLSDynaReaderPython.cxx.obj /FdCMakeFiles\vtkIOLSDynaPython.dir\ /FS -c D:<path>\Kitware\build\VTK\CMakeFiles\vtkIOLSDynaPython\vtkLSDynaReaderPython.cxx```https://gitlab.kitware.com/vtk/vtk/-/issues/18471Add tests to verify that third party libraries are mangled2022-02-16T15:14:04-05:00Ben BoeckelAdd tests to verify that third party libraries are mangledThere should be tests to ensure that all public symbols in third party libraries are properly mangled.
Cc: @seanmThere should be tests to ensure that all public symbols in third party libraries are properly mangled.
Cc: @seanmhttps://gitlab.kitware.com/vtk/vtk/-/issues/18469Configure error with build_dicom_examples=ON2022-02-24T19:26:21-05:00PeterConfigure error with build_dicom_examples=ONlatest vtk master,using cmake 3.22.0,win10 x64: build_dicom_examples=ON I get the following configure warning/error:
```
CMake Deprecation Warning at Remote/vtkDICOM/CMakeLists.txt:5 (cmake_minimum_required):
Compatibility with CMake ...latest vtk master,using cmake 3.22.0,win10 x64: build_dicom_examples=ON I get the following configure warning/error:
```
CMake Deprecation Warning at Remote/vtkDICOM/CMakeLists.txt:5 (cmake_minimum_required):
Compatibility with CMake < 2.8.12 will be removed from a future version of
CMake.
Update the VERSION argument <min> value or use a ...<max> suffix to tell
CMake that the project does not need compatibility with older versions.
```
```
vtkDICOM: Building vtkDICOM as a Remote VTK Module
CMake Error at CMake/vtkModule.cmake:3039 (get_property):
get_property could not find TARGET RenderingImage. Perhaps it has not yet
been created.
Call Stack (most recent call first):
Remote/vtkDICOM/Examples/CMakeLists.txt:50 (vtk_module_autoinit)
```
[cmakeoutput.txt](/uploads/b6541cf54e01bf3026be4b08d32ad089/cmakeoutput.txt)
If I disable build_dicom_examples I have no configure error.[CMakeCache.txt](/uploads/3a7b04e0b62308f0a84e85a711c0b029/CMakeCache.txt)https://gitlab.kitware.com/vtk/vtk/-/issues/18468multiple volumes in one vtkRenderer by using vtkGPUVolumeRayCastMapper,The di...2022-02-17T10:15:27-05:0018810186103multiple volumes in one vtkRenderer by using vtkGPUVolumeRayCastMapper,The display relationship is incorrectwhen multiple volumes in one vtkRenderer by using vtkGPUVolumeRayCastMapper,It shows who came first in the order they joined。![微信图片_20220215111823](/uploads/b55f392c2288ed9646cbee6c99588d2e/微信图片_20220215111823.png)![微信图片_20220215111815](...when multiple volumes in one vtkRenderer by using vtkGPUVolumeRayCastMapper,It shows who came first in the order they joined。![微信图片_20220215111823](/uploads/b55f392c2288ed9646cbee6c99588d2e/微信图片_20220215111823.png)![微信图片_20220215111815](/uploads/105be9536d33404aaf863b8da048943e/微信图片_20220215111815.png)https://gitlab.kitware.com/vtk/vtk/-/issues/18467Dataset with large-value coordinates renders black in VTK9.1, normal in VTK8.12022-02-15T09:40:05-05:00Kathleen BiagasDataset with large-value coordinates renders black in VTK9.1, normal in VTK8.1See this [entry in discourse](https://discourse.vtk.org/t/dataset-with-large-value-coordinates-renders-black-in-vtk9-1-normal-in-vtk8-1/7757)
I mention there that coordinates in the range 1e20 fail to render the correct color.
I tried o...See this [entry in discourse](https://discourse.vtk.org/t/dataset-with-large-value-coordinates-renders-black-in-vtk9-1-normal-in-vtk8-1/7757)
I mention there that coordinates in the range 1e20 fail to render the correct color.
I tried other ranges until 1e10 worked (so 1e11 renders black, too).https://gitlab.kitware.com/vtk/vtk/-/issues/18464vtkDelaunay3D generate VTK_TETRA no show inner tetra?2022-02-12T09:53:48-05:00youngylinvtkDelaunay3D generate VTK_TETRA no show inner tetra? vtkDelaunay3D generate tetrahedra
Input points: 12722
out points: 5655
out tetrahedra: 35225
but only show tetra surface,the inner tetra do not show? vtkDelaunay3D generate tetrahedra
Input points: 12722
out points: 5655
out tetrahedra: 35225
but only show tetra surface,the inner tetra do not show?https://gitlab.kitware.com/vtk/vtk/-/issues/18463Improve Abort Functionality2022-12-19T15:54:31-05:00Stephen CrowellImprove Abort Functionality**Summary: Our goal is to redesign how VTK algorithms are interrupted (aborted) in a way that is friendly to multi-threaded execution. Currently, the abort mechanism is designed to function only within a single thread when the abort flag...**Summary: Our goal is to redesign how VTK algorithms are interrupted (aborted) in a way that is friendly to multi-threaded execution. Currently, the abort mechanism is designed to function only within a single thread when the abort flag is set by an observer of the progress event. This severely limits the usefulness of the functionality as evidenced by the fact that it is rarely used (which must be the case as it has many bugs that no one reports on). Our design enables aborting algorithms from a separate thread.**
The changes described below were conceptualized by Berk Geveci and implemented by Stephen Crowell. Since this is a large change, we are looking for input on whether or not this change is well thought out and any possible issues that could come up.
# Requirements:
1. Aborting an algorithm should cause the currently executing algorithm and downstream to short circuit their execution.
2. When running an update after an abort, execution should restart at the filter that was executing when abort happened.
3. Setting abort from another thread is supported.
4. Pipelines that contain MPI enabled filters should not deadlock when aborted / restarted.
# High Level Design:
* The AbortExecute flag has been changed to atomic.
* Changing the flag to atomic allows for AbortExecute to be set from another thread without causing any issues.
* Algorithms call CheckAbort during execution. CheckAbort checks the current algorithm and upstream algorithms for a set AbortExecute flag.
* This is the first step for aborting an algorithm. In the previous method, if an upstream algorithm was aborted, the currently executing algorithm has no way of knowing and will continue to execute as normal. Checking upstream allows for the current algorithm to know that it needs to abort. This is necessary for multi-threaded execution as the filter that is set to abort may already be done by the time abort is set.
* Aborted algorithms exit early and return empty data.
* Returning early allows for a short circuit during execution. Returning empty data helps expedite future filter’s execution time. The reason the pipeline execution is not stopped is to avoid deadlock when pipelines contain parallel (MPI) algorithms that perform communication. All filters need to function properly with empty data.
* Pipeline continues executing with empty data and a new ABORTED flag is passed downstream.
* Passing the ABORTED flag downstream allows other filters to know they should abort as well.
* When an update is run, filters with an ABORTED flag will need to re-execute.
* Filters with the ABORTED flag exist in two cases: the filter was running when an AbortExecute flag or it is downstream of the filter mentioned in the previous case. As a result, these filters return empty data and will need to execute.
# Details:
* Modifications to existing filters:
* The only modifications to filters is to add the call to CheckAbort and adding the short circuit logic. Each filter will need to place the CheckAbort call in a place that will be executed frequently (but not too frequently). The short circuit logic varies from filter to filter, but the core concept is to stop any data processing loops from running when the AbortExecute flag is set. We choose not to return early from a filter since some filters deallocate memory or perform other cleanup steps before returning. The prototyping section has examples of changing a filter to call CheckAbort and short circuit.
* Optimization with MTime:
* Since we are calling CheckAbort often, it is a bad idea to have the function travel upstream during each call. As a result, we make use of two MTime timestamps: LastAbortTime and LastAbortCheckTime. LastAbortTime is a global timestamp updated when an AbortExecuteFlag is set and LastAbortCheckTime is a local timestamp updated when a filter travels upstream to check for a set AbortExecute flag. Before traveling upstream, CheckAbort will compare the two timestamps. If the LastAbortTime is more recent than LastAbortCheckTime, then traverse upstream.
* MPI algorithms:
* MPI algorithms are more complicated than most filters when it comes to aborting. We must be careful when adding the CheckAbort call since we want each process to perform the same number of calls and we cannot have one process block because of CheckAbort. As a result, CheckAbort should not be called when MPI communication is occurring and should not exit an algorithm early to prevent possible blocking. MPI algorithms will have to barrier at the beginning and the end of execution to make sure that the algorithm is aborted across all ranks and re-executes next time. If some of the ranks are not aborted and do not execute the next time, deadlocks can occur.
# Prototype:
An initial implementation of the design described above can be found [here](https://gitlab.kitware.com/stephen.crowell/vtk/-/merge_requests/3). This implementation modifies vtkAlgorithm to include CheckAbort and its associated helper functions. vtkAlgorithm also has a new function to set AbortExecute on and update LastAbortTime. vtkDemandDrivenPipeline has been modified to pass the ABORTED flag and tell the algorithm to re-execute based on the ABORTED flag. vtkRTAnalyticSource, vtkShrinkFilter, vtkContourGrid, and vtkClipDataSet filters have also been modified to include the CheckAbort call and the short circuit logic..
A testable example can be found [here](https://gitlab.kitware.com/stephen.crowell/vtk-abort). The example has two threads. ThreadA sets up a four filter pipeline with the filter mentioned previously and calls update twice. After each update, the AbortExecute flag and ABORTED flag are printed for each filter. ThreadB waits seven minutes and then tells the wavelet filter to abort. This results in the currently executing filter to check for an abort and then end execution early. Then when the second update is called, the next update will begin execution at the filter that was running when the abort occurred during the previous update.https://gitlab.kitware.com/vtk/vtk/-/issues/18462Error in shader when using surface representation and SetLinesAsTubes(true)2022-02-10T05:51:28-05:00casra-developersError in shader when using surface representation and SetLinesAsTubes(true)When using an actor and setting its representation to **surface** and at the same time use the method **SetLinesAsTubes(true)**, the render window shows an error ```error C1503: undefined variable "normalVCGSOutput"``` and the applicatio...When using an actor and setting its representation to **surface** and at the same time use the method **SetLinesAsTubes(true)**, the render window shows an error ```error C1503: undefined variable "normalVCGSOutput"``` and the application crashes.
This was discovered in the Activiz 9.1 library which wraps VTK.
Code to reproduce the error:
```cs
_renderWindow = RenderWindowControl.RenderWindow;
var renderer = _renderWindow.GetRenderers().GetFirstRenderer();
_interactorStyle = vtkInteractorStyleTrackballCamera.New();
_renderWindow.GetInteractor().SetInteractorStyle(_interactorStyle);
_interactorStyle.SetDefaultRenderer(renderer);
var boxSource = vtkCubeSource.New();
var boxMapper = vtkOpenGLPolyDataMapper.New();
boxMapper.SetInputConnection(boxSource.GetOutputPort());
_boxActor = vtkActor.New();
_boxActor.SetMapper(boxMapper);
_boxProperties = vtkProperty.New();
_boxProperties.SetEdgeVisibility(1);
_boxProperties.SetColor(1.0, 0.0, 0.0);
_boxProperties.LightingOff();
_boxProperties.SetRenderLinesAsTubes(true);
_boxProperties.SetLineWidth(3);
// if this line is commented out, the app will crash because one of the shaders is missing a definition of the variable "normalVCGSOutput"
//_boxProperties.SetRepresentationToWireframe();
boxSource.SetXLength(10);
boxSource.SetYLength(5);
boxSource.SetZLength(15);
_boxActor.SetProperty(_boxProperties);
renderer.AddActor(_boxActor);
```
[ShaderCrashDemo.zip](/uploads/501cd59df4ebe0b8cfa6c2358075ecd1/ShaderCrashDemo.zip)
This issue was also discussed with @LucasGandelKitwarehttps://gitlab.kitware.com/vtk/vtk/-/issues/18461mapper shallowcopy causes error2022-02-09T05:14:41-05:00Andreas Buykxmapper shallowcopy causes errorA mapper that has an input connection, but not a fully instantiated pipeline will cause an error on shallow-copy
```
import vtk
producer = vtk.vtkArrayCalculator()
mapper = vtk.vtkPolyDataMapper()
mapper.SetInputConnection(producer.Get...A mapper that has an input connection, but not a fully instantiated pipeline will cause an error on shallow-copy
```
import vtk
producer = vtk.vtkArrayCalculator()
mapper = vtk.vtkPolyDataMapper()
mapper.SetInputConnection(producer.GetOutputPort())
clone = vtk.vtkPolyDataMapper()
clone.ShallowCopy(mapper)
```
```
( 0.430s) [main thread ] vtkExecutive.cxx:741 ERR| vtkCompositeDataPipeline (0x1f0c930): Algorithm vtkArrayCalculator(0x1f07b80) returned failure for request: vtkInformation (0x1f0cdd0)
Debug: Off
Modified Time: 165
Reference Count: 1
Registered Events: (none)
Request: REQUEST_DATA_OBJECT
ALGORITHM_AFTER_FORWARD: 1
FORWARD_DIRECTION: 0
```
Without the input connection, the shallow copy executes without error.
The cause is that the copying of the lookup table will trigger vtkMapper::CreateDefaultLookupTable on the copied mapper. This will invoke an update of the pipeline because it uses GetInput to get the input data structure.
The part of CreateDefaultLookupTable that uses the input is actually only relevant for non-data-arrays. I propose to fix this by making that part a separate (protected or private) function that gets called when the mapper is actually going to do color mapping, e.g. in MapScalars and HasTranslucentPolygonalGeometry.https://gitlab.kitware.com/vtk/vtk/-/issues/18457Improve continuous integration to detect duplicated symbols2022-02-06T11:03:42-05:00Jean-Christophe Fillion-RobinImprove continuous integration to detect duplicated symbolsThis was discovered while working on https://gitlab.kitware.com/vtk/vtk/-/merge_requests/8885 addressing undefined behavior (aka Segfault) related to the use of generic class name like `vtkInteractionCallback`, I suggest we improve our c...This was discovered while working on https://gitlab.kitware.com/vtk/vtk/-/merge_requests/8885 addressing undefined behavior (aka Segfault) related to the use of generic class name like `vtkInteractionCallback`, I suggest we improve our continuous integration.
Few approaches:
1. Add a regex based approach like was used at https://discourse.slicer.org/t/transition-of-nightly-build-from-vtk-9-0-20201111-to-9-1-20220125/21669/3#further-analysis-of-the-vtk-toolkit-4
2. Identify linked flagshttps://gitlab.kitware.com/vtk/vtk/-/issues/18456Remove duplicated class vtkTextureArray2022-02-04T16:44:51-05:00Jean-Christophe Fillion-RobinRemove duplicated class vtkTextureArrayOccurrences:
* [Interaction/Widgets/vtkTexturedButtonRepresentation2D.cxx](https://github.com/Kitware/VTK/blob/67eaef6433e15644fd1b51d814b535dc66816464/Interaction/Widgets/vtkTexturedButtonRepresentation2D.cxx#L36-L39)
* [Interaction/Wid...Occurrences:
* [Interaction/Widgets/vtkTexturedButtonRepresentation2D.cxx](https://github.com/Kitware/VTK/blob/67eaef6433e15644fd1b51d814b535dc66816464/Interaction/Widgets/vtkTexturedButtonRepresentation2D.cxx#L36-L39)
* [Interaction/Widgets/vtkTexturedButtonRepresentation.cxx](https://github.com/Kitware/VTK/blob/67eaef6433e15644fd1b51d814b535dc66816464/Interaction/Widgets/vtkTexturedButtonRepresentation.cxx#L43-L46)
This was discovered while working on https://gitlab.kitware.com/vtk/vtk/-/merge_requests/8885.
It is important to avoid duplicated symbol names to avoid violating the ODR ([One Definition Rule](https://en.cppreference.com/w/cpp/language/definition)).
For some more context, see https://discourse.slicer.org/t/transition-of-nightly-build-from-vtk-9-0-20201111-to-9-1-20220125/21669/
Proposal approaches:
1. Move each `vtkTextureArray` to `vtkTexturedButtonRepresentation::vtkTextureArray` and `vtkTexturedButtonRepresentation2D::vtkTextureArray`
2. Rename `vtkTextureArray` respectively to `vtkTexturedButtonRepresentationTextureArray` and `vtkTexturedButtonRepresentation2DTextureArray`
3. Identify similar use of text array in the toolkit and create a dedicated `vtkTextureArray` class
I suggest to move forward with approach 1
cc: @ken-martinhttps://gitlab.kitware.com/vtk/vtk/-/issues/18454Difficulty in resizing/moving QDockWidgets in a PyQt5 app that contains a QVT...2022-02-09T09:39:13-05:00Paul SmithDifficulty in resizing/moving QDockWidgets in a PyQt5 app that contains a QVTKRenderWindowInteractor, on MacOS only.Hi,
I’m building an application using PyQt5 that contains a QVTKRenderWindowInteractor widget within a QDockWidget. On MacOS, adding the QVTKRenderWindowInteractor makes it very difficult to resize or move the docks.
Here’s an example ...Hi,
I’m building an application using PyQt5 that contains a QVTKRenderWindowInteractor widget within a QDockWidget. On MacOS, adding the QVTKRenderWindowInteractor makes it very difficult to resize or move the docks.
Here’s an example that displays this behaviour:
```py
from PyQt5 import QtWidgets
from PyQt5.QtCore import Qt
from vtkmodules.qt.QVTKRenderWindowInteractor import QVTKRenderWindowInteractor
if __name__ == "__main__":
app = QtWidgets.QApplication([])
main = QtWidgets.QMainWindow()
dock1 = QtWidgets.QDockWidget("One", main)
dock2 = QtWidgets.QDockWidget("Two", main)
dock3 = QtWidgets.QDockWidget("Three", main)
dock4 = QtWidgets.QDockWidget("Four", main)
label1 = QtWidgets.QLabel("Widget 1", dock1)
label2 = QtWidgets.QLabel("Widget 2", dock2)
label3 = QtWidgets.QLabel("Widget 3", dock3)
vtkWidget4 = QVTKRenderWindowInteractor(dock4)
label1.setStyleSheet("background-color:blue")
label2.setStyleSheet("background-color:red")
label3.setStyleSheet("background-color:green")
vtkWidget4.setStyleSheet("background-color:grey")
dock1.setWidget(label1)
dock2.setWidget(label2)
dock3.setWidget(label3)
dock4.setWidget(vtkWidget4)
main.addDockWidget(Qt.LeftDockWidgetArea, dock1)
main.splitDockWidget(dock1, dock2, Qt.Orientation.Vertical)
main.addDockWidget(Qt.RightDockWidgetArea, dock3)
main.splitDockWidget(dock3, dock4, Qt.Orientation.Vertical)
main.setTabPosition(Qt.AllDockWidgetAreas, QtWidgets.QTabWidget.North)
main.showMaximized()
app.exec_()
```
If in the above example, the QVTKRenderWindowInteractor is removed (or replaced by another QLabel), there is no issue moving or resizing the windows. However, the issue is there if the dock containing the QVTKRenderWindowInteractor is added and then removed from the main window.
I’m using:
```
macOS 11.6.2
pyqt5 5.15.6
vtk 9.0.3
```
I’ve also tried PyQt5 versions down to 5.12, as well as PySide2 and PySide6. There’s no issue with moving or resizing the docks on Ubuntu 18.04 and Windows 10, only on macOS.
The issue is also there if QVTKRenderWindowInteractor is set as the central widget of the main window, rather than put in a dock.
Any suggestions for what might be going on would be much appreciated!
P.S. sorry for the [cross-post from the forum](https://discourse.vtk.org/t/difficulty-in-resizing-moving-qdockwidgets-in-a-pyqt5-app-that-contains-a-qvtkrenderwindowinteractor-on-macos-only/7763), but as far as I can tell it seems like a bug rather than something I'm doing wrong - but I would be very happy to stand corrected!https://gitlab.kitware.com/vtk/vtk/-/issues/18453Wireframe black artefact (OSMesa, Intel chipset)2023-05-07T16:42:27-04:00Lucas GandelWireframe black artefact (OSMesa, Intel chipset)Black artefacts are visible when rendering a quad as wireframe on different hardware.
This has been reproduced with OSMesa and Intel UHD Graphics 630.
vtkResliceCursorWidget tests are impacted after forcing the representation of the wi...Black artefacts are visible when rendering a quad as wireframe on different hardware.
This has been reproduced with OSMesa and Intel UHD Graphics 630.
vtkResliceCursorWidget tests are impacted after forcing the representation of the widget to wireframe in order to workaround #18441. (See !8879) It only happens when the cursor is perfectly aligned with the camera view up. Moving the cursor a bit brings the color back.
<img src="/uploads/72c365864088c2c08eb1a5c7a3801638/ResliceCursorBlackLine.PNG" width="300" height="300">
<img src="/uploads/47f7df827ccbd0c49744486cfedfe3f0/ResliceCursorOK.PNG" width="300" height="300">
Similar issues can be reproduce with a simple quad rendered as wireframe.
<img src="/uploads/2e42bc2b6f0026fed99739a27766f203/PlaneSource1.PNG" width="500" height="300">
Please note:
- it only affect quads (vtkResliceCursorActor above is not using lines, but quads with a normal orthogonal to the camera direction).
- it seems to be caused by a wrong computation of `normalVCVSOutput` in [vtkOpenGLPolyDataMapper](https://gitlab.kitware.com/vtk/vtk/-/blob/master/Rendering/OpenGL2/vtkOpenGLPolyDataMapper.cxx#L2208).https://gitlab.kitware.com/vtk/vtk/-/issues/18452vtkGenericEnSightReader: Fix to bug #0007424 (automatic determination of endi...2022-02-09T05:52:24-05:00Thorsten RothvtkGenericEnSightReader: Fix to bug #0007424 (automatic determination of endian type) leads to issue with some EnSight6 casesRequestInformation() in vtkGenericEnSightReader.cxx contains the following comment:
```
// The following line, explicitly initializing this->ByteOrder to
// FILE_UNKNOWN_ENDIAN, MUST !!NOT!! be removed as it is used to
// force v...RequestInformation() in vtkGenericEnSightReader.cxx contains the following comment:
```
// The following line, explicitly initializing this->ByteOrder to
// FILE_UNKNOWN_ENDIAN, MUST !!NOT!! be removed as it is used to
// force vtkEnSightGoldBinaryReader::ReadPartId(...) to determine
// the actual endian type. Otherwise the endian type, the default
// value from combobox 'Byte Order' of the user interface -------
// FILE_BIG_ENDIAN unless the user manually toggles the combobox,
// would be forwarded to this->Reader->ByteOrder through the next
// line and therefore would prevent vtkEnSightGoldBinaryReader::
// ReadPartId(...) from automatically checking the endian type. As
// a consequence, little-endian files such as the one mentioned in
// bug #0008237 would not be loadable. The following line might be
// removed ONLY WHEN the combobox is removed through
// ParaViews\Servers\ServerManager\Resources\readers.xml.
// Thus it is highly suggested that the following line be retained
// to guarantee the fix to bug #0007424 -- automatic determination
// of the endian type.
this->ByteOrder = FILE_UNKNOWN_ENDIAN;
this->Reader->SetByteOrder(this->ByteOrder);
```
The byteorder is set to FILE_UNKNOWN_ENDIAN and forwarded to the specific reader object here. However, triggering automatic determination of byteorder again for each file leads to issues with at least some of our EnSight6 cases, where the byteorder is then interpreted as ambiguous in vtkEnSight6BinaryReader::ReadIntNumber() and the next call to this function fails at the initial read.
Setting the reader's byteorder manually is not possible without removing the fix mentioned in the comment, as it is always overwritten here.https://gitlab.kitware.com/vtk/vtk/-/issues/18451Add check for IO::HDF5 which requires HDF5 >= 1.10 as of VTK 9.1.02022-02-03T13:55:00-05:00Ryan Krattigerryan.krattiger@kitware.comAdd check for IO::HDF5 which requires HDF5 >= 1.10 as of VTK 9.1.0@danlipsa @chuck.atkins
HDF5 reader implemented in 9.1.0 implements duplicate API `vtkHDFReader::Implementation::NewArray` when HDF5 < 1.10.
`hid_t` in HDF5 < 1.10 is a typedef `int`,
`hid_t` in HDF5 >= 1.10 is a typedef `int64_t`@danlipsa @chuck.atkins
HDF5 reader implemented in 9.1.0 implements duplicate API `vtkHDFReader::Implementation::NewArray` when HDF5 < 1.10.
`hid_t` in HDF5 < 1.10 is a typedef `int`,
`hid_t` in HDF5 >= 1.10 is a typedef `int64_t`https://gitlab.kitware.com/vtk/vtk/-/issues/18450vtk3DLinearGridPlaneCutter changes data-type of Cell and Point Data2022-02-01T08:49:02-05:00Kathleen Biagasvtk3DLinearGridPlaneCutter changes data-type of Cell and Point DataI've attached a simple example and unstructured grid dataset for input.
[Cutter.cxx](/uploads/afef095712bb4bd3ef55ee4cafeba99f/Cutter.cxx)[ugrid.vtk](/uploads/47b7d44709b96883b7b9945c28216268/ugrid.vtk)
The input file has cell data of t...I've attached a simple example and unstructured grid dataset for input.
[Cutter.cxx](/uploads/afef095712bb4bd3ef55ee4cafeba99f/Cutter.cxx)[ugrid.vtk](/uploads/47b7d44709b96883b7b9945c28216268/ugrid.vtk)
The input file has cell data of type 'int' and point data of type 'unsigned int'.
Output from 3dLinearGridPlaneCutter, cell data and point data types are both 'float'.
I've tracked it down to the cutter's use of 'ArrayList::AddArray' which has a 'promote' option that defaults to true.
https://gitlab.kitware.com/vtk/vtk/-/blob/master/Filters/Core/vtk3DLinearGridPlaneCutter.cxx#L784
https://gitlab.kitware.com/vtk/vtk/-/blob/master/Common/DataModel/vtkArrayListTemplate.h#L262-L263
https://gitlab.kitware.com/vtk/vtk/-/blob/master/Common/DataModel/vtkArrayListTemplate.txx#L133-L141
For this simple example, it really doesn't matter much, but I ran across this in a more complex use-case involving vtkCutter(which uses vtk3DLinearGridPlanecutter under the covers) and passing results to vtkAppendPolyData with other data that hadn't been processed by the cutter. All of the Cell and Point data attributes were lost because the data types no longer matched.https://gitlab.kitware.com/vtk/vtk/-/issues/18448Python problems due to global vars in shared libs2022-02-03T14:20:41-05:00David GobbiPython problems due to global vars in shared libsProblems can arise when there are multiple copies of VTK on a system, and they are both loaded into Python at the same time. This was recently illustrated by !8853.
For example, let's say you have one copy of VTK that has been installe...Problems can arise when there are multiple copies of VTK on a system, and they are both loaded into Python at the same time. This was recently illustrated by !8853.
For example, let's say you have one copy of VTK that has been installed, and another copy in your build tree. And then, let's say you created your own custom VTK module called mymodules.vtkMyFirstModule.
```
import mymodules.vtkMyFirstModule
```
This will implicitly import `vtkmodules.vtkCommonCore` as well, via the dependency chain. But depending on which copy of `vtkmodules.vtkCommonCore` the Python module loader finds, we might end up with a situation like this:
mymodules.vtkMyFirstModule -> dynamically links to VTK shared libs in the build tree
vtkmodules.vtkCommonCore -> dynamically links to VTK shared libs in the installed VTK
The problem with this situation is that the VTK shared libs will be loaded twice, once from each location. And each copy of each shared lib will have its own data segment with its own globals.
One such global variable is located in `libvtkWrappingPythonCore`, in `vtkPythonUtil.cxx`:
```
static vtkPythonUtil* vtkPythonMap;
```
This variable holds mappings that are central to the VTK Python wrappers, and it must be unique and properly initialized or else the wrappers will behave very badly. It's not the only global variable, but it's the one most important for the wrappers.
----
Edit: The Python types (`PyVTKMethodDescriptor_Type` etc.) that are defined in `libvtkWrappingPythonCore` are also globals. They should be placed in a Python extension module (perhaps in `vtkCommonCore.so/.pyd`), not in a shared library that can be linked by several modules.