VTK issueshttps://gitlab.kitware.com/vtk/vtk/-/issues2023-12-04T20:03:14-05:00https://gitlab.kitware.com/vtk/vtk/-/issues/19181Can't write vtkMultiBlockDataSet with empty poly data.2023-12-04T20:03:14-05:00Francois MazenCan't write vtkMultiBlockDataSet with empty poly data.When a multiblock contains an empty poly data (i.e. that it contains no points and no cells), then the vtkXMLCompositeDataWriter fails and the executive returns an error.
To reproduce with VTK python:
```python
from vtkmodules import vt...When a multiblock contains an empty poly data (i.e. that it contains no points and no cells), then the vtkXMLCompositeDataWriter fails and the executive returns an error.
To reproduce with VTK python:
```python
from vtkmodules import vtkIOXML
from vtkmodules.vtkCommonDataModel import (
vtkPolyData,
vtkMultiBlockDataSet,
vtkCompositeDataSet,
)
mbds = vtkMultiBlockDataSet()
mbds.SetNumberOfBlocks(2)
block_0 = vtkPolyData()
mbds.SetBlock(0, block_0)
mbds.GetMetaData(0).Set(vtkCompositeDataSet.NAME(), "foo")
block_1 = vtkPolyData()
mbds.SetBlock(1, block_1)
mbds.GetMetaData(1).Set(vtkCompositeDataSet.NAME(), "bar")
writer = vtkIOXML.vtkXMLMultiBlockDataWriter()
writer.SetFileName("vtk_test.vtm")
writer.SetInputData(mbds)
writer.Update(0)
writer.Write()
```
This case seems legit to me, and there is a trivial fix similar to the one for #19175: `vtkXMLCompositeDataWriter::WriteNonCompositeData` should return 1 when a writer is not available. I'll push a fix shortly.https://gitlab.kitware.com/vtk/vtk/-/issues/19188vtkXMLUnstructuredGridReader double update creates inconsistent dataset2023-12-04T10:17:10-05:00Louis GombertvtkXMLUnstructuredGridReader double update creates inconsistent datasetThe following script shows an inconsistency in the XML VTU reader
```cpp
#include <string>
#include "vtkNew.h"
#include "vtkXMLUnstructuredGridReader.h"
#include "vtkUnstructuredGrid.h"
int main() {
const std::string baseName = {"cube...The following script shows an inconsistency in the XML VTU reader
```cpp
#include <string>
#include "vtkNew.h"
#include "vtkXMLUnstructuredGridReader.h"
#include "vtkUnstructuredGrid.h"
int main() {
const std::string baseName = {"cube-with-time.vtu"};
vtkNew<vtkXMLUnstructuredGridReader> baselineReader;
baselineReader->SetFileName(baseName.c_str());
baselineReader->SetTimeStep(0);
baselineReader->Update();
vtkUnstructuredGrid *baseData =
vtkUnstructuredGrid::SafeDownCast(baselineReader->GetOutputAsDataSet());
std::cout << baseData->GetNumberOfCells() << std::endl; // 1
baselineReader->Update();
baseData =
vtkUnstructuredGrid::SafeDownCast(baselineReader->GetOutputAsDataSet());
std::cout << baseData->GetNumberOfCells() << std::endl; // 2
}
```
using the `cube-with-time.vtu` dataset from the VTK testing data. The dataset contains a single cube at each timestep, expected output would be 1 and 1 cells but it is not.https://gitlab.kitware.com/vtk/vtk/-/issues/19179Rendering/OpenGL2/vtkWin32OpenGLDXRenderWindow.h:113:8: error: ‘unique_ptr’ i...2023-12-01T20:03:14-05:00Julien SchuellerRendering/OpenGL2/vtkWin32OpenGLDXRenderWindow.h:113:8: error: ‘unique_ptr’ in namespace ‘std’ does not name a template typesince https://gitlab.kitware.com/vtk/vtk/-/merge_requests/10596 vtk cannot be compiled in c++17 mode anymore because of std::unique_ptr
I think vtk still defaults to c++11 (or is it paraview ?), but it should also retain compatibility w...since https://gitlab.kitware.com/vtk/vtk/-/merge_requests/10596 vtk cannot be compiled in c++17 mode anymore because of std::unique_ptr
I think vtk still defaults to c++11 (or is it paraview ?), but it should also retain compatibility with c++17 on windows like it does on linux
/cc @LucasGandelKitware @alexy.pellegrinihttps://gitlab.kitware.com/vtk/vtk/-/issues/19187`vtkPolyDataNormals` hangs with problematic data and `SplittingOn` or `Consis...2023-12-01T14:24:59-05:00Aron Helser`vtkPolyDataNormals` hangs with problematic data and `SplittingOn` or `ConsistencyOn`The attached dataset causes an infinite loop and therefore a program hang in `vtkPolyDataNormals` with the default options `Splitting` or `Consistency` enabled. Disabling both these options removes the hang.
It seems to be stuck in a l...The attached dataset causes an infinite loop and therefore a program hang in `vtkPolyDataNormals` with the default options `Splitting` or `Consistency` enabled. Disabling both these options removes the hang.
It seems to be stuck in a loop inside `vtkPolyData::GetCellEdgeNeighbors()` .
In ParaView this can be replicated in the `Generate Surface Normals` filter.
[normals_bug_polydata.vtp](/uploads/7544c9c2cc8c14b6c17e520a3b4e2bd0/normals_bug_polydata.vtp)Spiros TsalikisSpiros Tsalikishttps://gitlab.kitware.com/vtk/vtk/-/issues/19182vtkMath::Random assertion and abort - lack of thread safety2023-12-01T12:55:33-05:00Francois MazenvtkMath::Random assertion and abort - lack of thread safetyWhen running `vtkMath::Random(-1, 1)` simultaneous in several threads, then an assertion is raised and the program aborts.
It's likely due to lack of thread safety in `vtkMath` and/or in `vtkMinimalStandardRandomSequence`. `vtkMath::Int...When running `vtkMath::Random(-1, 1)` simultaneous in several threads, then an assertion is raised and the program aborts.
It's likely due to lack of thread safety in `vtkMath` and/or in `vtkMinimalStandardRandomSequence`. `vtkMath::Internal` is `static` and that means that `vtkMinimalStandardRandomSequence::Seed` could be modified concurrently.
To reproduce with assertion activated in VTK and TBB SMP backend:
```cpp
#include <vtkMath.h>
#include <vtkSMPTools.h>
#include <array>
int main(int, char*[])
{
std::cout << "backend: " << vtkSMPTools::GetBackend() << std::endl;
std::cout << "estimated number of threads: " << vtkSMPTools::GetEstimatedNumberOfThreads() << std::endl;
const size_t size = 10000;
std::array<double, size> results;
vtkSMPTools::For(0,size, [&](vtkIdType start, vtkIdType stop){
for(vtkIdType i = start; i < stop; ++i)
{
results[i] = vtkMath::Random(-1,1);
}
});
return EXIT_SUCCESS;
}
```
It outputs:
```
backend: TBB
estimated number of threads: 12
vtk_test: /home/francois/dev/vtk/VTK/Common/Core/vtkMinimalStandardRandomSequence.cxx:79: virtual double vtkMinimalStandardRandomSequence::GetValue(): Assertion `"post: unit_range" && result >= 0.0 && result <= 1.0' failed.
```
For the context, I discovered it from a random crash in ParaView when applying the "Resample to Image" filter.https://gitlab.kitware.com/vtk/vtk/-/issues/19183VTK::RenderingCellGridPython-TestCellGridRendering is flaky and is excluded f...2023-12-01T08:17:02-05:00Mathieu Westphal (Kitware)VTK::RenderingCellGridPython-TestCellGridRendering is flaky and is excluded from CI on WindowsVTK::RenderingCellGridPython-TestCellGridRendering is flaky and is excluded from CI on Windows
![a](/uploads/62aa397b633ffacd0e7c020c1c9cabc5/a.png)
Excluded here: https://gitlab.kitware.com/vtk/vtk/-/merge_requests/10736VTK::RenderingCellGridPython-TestCellGridRendering is flaky and is excluded from CI on Windows
![a](/uploads/62aa397b633ffacd0e7c020c1c9cabc5/a.png)
Excluded here: https://gitlab.kitware.com/vtk/vtk/-/merge_requests/10736https://gitlab.kitware.com/vtk/vtk/-/issues/19173anari: Visibility changes are not propogated to the anari scenegraph2023-11-30T16:55:06-05:00Sankhesh Jhaverianari: Visibility changes are not propogated to the anari scenegraph## Steps to reproduce
- Fetch and build VTK branch [anari-visibility-bug](https://gitlab.kitware.com/sankhesh/vtk/commits/anari-visibility-bug)
- Run `ctest -V -R AnariPassVisibility`
The test renders the bunny dataset via ANARI and ...## Steps to reproduce
- Fetch and build VTK branch [anari-visibility-bug](https://gitlab.kitware.com/sankhesh/vtk/commits/anari-visibility-bug)
- Run `ctest -V -R AnariPassVisibility`
The test renders the bunny dataset via ANARI and then toggles the prop visibility.
| Expected Result | Test Result |
|:---:|:---:|
|![](https://vtk.org/files/ExternalData/SHA512/bdcb122fb7afdfc29e17e8d4cc487629352f320ef70616baa3f13af5047f4ad15d6dc03562cdc1cbb5d48f01c079ccf605af1a56ed526391ce7ab98bb4c92b17)|![TestAnariPassVisibility](/uploads/a44b3df578658a0baa0eb2c50fdbcf89/TestAnariPassVisibility.png)|https://gitlab.kitware.com/vtk/vtk/-/issues/19152the android VolumeRender disable to display2023-11-28T03:21:19-05:00DavidMcthe android VolumeRender disable to display vtk:8.2.0
https://github.com/Kitware/VTK/tree/master/Examples/Android/VolumeRender I download the demo code from the url,but it could not rightly run,don'nt know why?
```
vtkRenderWindow* renWin = vtkRenderWindow::New();
char jniS[4]... vtk:8.2.0
https://github.com/Kitware/VTK/tree/master/Examples/Android/VolumeRender I download the demo code from the url,but it could not rightly run,don'nt know why?
```
vtkRenderWindow* renWin = vtkRenderWindow::New();
char jniS[4] = { 'j', 'n', 'i', 0 };
renWin->SetWindowInfo(jniS); // tell the system that jni owns the window not us
renWin->SetSize(width, height);
vtkNew<vtkRenderer> renderer;
renWin->AddRenderer(renderer.Get());
vtkNew<vtkAndroidRenderWindowInteractor> iren;
iren->SetRenderWindow(renWin);
vtkNew<vtkOpenGLGPUVolumeRayCastMapper> volumeMapper;
vtkNew<vtkPiecewiseFunction> pwf;
#ifdef SYNTHETIC
vtkNew<vtkRTAnalyticSource> wavelet;
wavelet->SetWholeExtent(-63, 64, -63, 64, -63, 64);
wavelet->SetCenter(0.0, 0.0, 0.0);
vtkNew<vtkImageCast> ic;
ic->SetInputConnection(wavelet->GetOutputPort());
ic->SetOutputScalarTypeToUnsignedChar();
volumeMapper->SetInputConnection(ic->GetOutputPort());
pwf->AddPoint(0, 0);
pwf->AddPoint(255, 0.1);
#else
vtkNew<vtkNrrdReader> mi;
mi->SetFileName(jstringToChar(path));
mi->Update();
double range[2];
vtkPointData* pd = mi->GetOutput()->GetPointData();
pd->GetRange(pd->GetScalars()->GetName(), range);
LOGI("Min %f Max %f type %s", range[0], range[1], mi->GetOutput()->GetScalarTypeAsString());
volumeMapper->SetInputConnection(mi->GetOutputPort());
double tweak = 80.0;
pwf->AddPoint(0, 0);
pwf->AddPoint(255 * (67.0106 + tweak) / 3150.0, 0);
pwf->AddPoint(255 * (251.105 + tweak) / 3150.0, 0.3);
pwf->AddPoint(255 * (439.291 + tweak) / 3150.0, 0.5);
pwf->AddPoint(255 * 3071 / 3150.0, 0.616071);
#endif
volumeMapper->SetAutoAdjustSampleDistances(1);
volumeMapper->SetSampleDistance(0.5);
vtkNew<vtkVolumeProperty> volumeProperty;
volumeProperty->SetShade(1);
volumeProperty->SetInterpolationTypeToLinear();
vtkNew<vtkColorTransferFunction> ctf;
ctf->AddRGBPoint(0, 0, 0, 0);
ctf->AddRGBPoint(255 * 67.0106 / 3150.0, 0.54902, 0.25098, 0.14902);
ctf->AddRGBPoint(255 * 251.105 / 3150.0, 0.882353, 0.603922, 0.290196);
ctf->AddRGBPoint(255 * 439.291 / 3150.0, 1, 0.937033, 0.954531);
ctf->AddRGBPoint(255 * 3071 / 3150.0, 0.827451, 0.658824, 1);
volumeProperty->SetColor(ctf.GetPointer());
volumeProperty->SetScalarOpacity(pwf.GetPointer());
vtkNew<vtkVolume> volume;
volume->SetMapper(volumeMapper.GetPointer());
volume->SetProperty(volumeProperty.GetPointer());
renderer->SetBackground2(0.2, 0.3, 0.4);
renderer->SetBackground(0.1, 0.1, 0.1);
renderer->GradientBackgroundOn();
renderer->AddVolume(volume.GetPointer());
renderer->ResetCamera();
// renderer->GetActiveCamera()->Zoom(1.4);
renderer->GetActiveCamera()->Zoom(0.7);
struct userData* foo = new struct userData();
foo->RenderWindow = renWin;
foo->Renderer = renderer.Get();
foo->Interactor = iren.Get();
renWin->Render();
return (jlong)foo;`
```
![截屏2023-11-03_17.28.11](/uploads/4b4d7762e3e5c3ec1593c0156b855c4f/截屏2023-11-03_17.28.11.png)https://gitlab.kitware.com/vtk/vtk/-/issues/19175Can't write multiblock with empty leaf2023-11-28T02:58:56-05:00Francois MazenCan't write multiblock with empty leafIf a multiblock contains an empty leaf, the `vtkXMLMultiBlockDataWriter` trigger an exception when calling the `Write()` method.
Sample code to reproduce with vtkpython:
```python
from vtkmodules.vtkCommonDataModel import vtkMultiBlock...If a multiblock contains an empty leaf, the `vtkXMLMultiBlockDataWriter` trigger an exception when calling the `Write()` method.
Sample code to reproduce with vtkpython:
```python
from vtkmodules.vtkCommonDataModel import vtkMultiBlockDataSet
from vtkmodules.vtkIOXML import vtkXMLMultiBlockDataWriter
mbds = vtkMultiBlockDataSet()
mbds.SetBlock(0, vtkMultiBlockDataSet())
writer = vtkXMLMultiBlockDataWriter()
writer.SetInputData(mbds)
writer.SetFileName("test.vtm")
writer.SetInputData(mbds)
writer.Write()
```
Then it triggers this output:
```
( 91.595s) [main thread ] vtkExecutive.cxx:729 ERR| vtkCompositeDataPipeline (0x555555649a10): Algorithm vtkXMLMultiBlockDataWriter (0x555555754f80) returned failure for request: vtkInformation (0x5555557571c0)
Debug: Off
Modified Time: 163
Reference Count: 1
Registered Events: (none)
Request: REQUEST_DATA
FROM_OUTPUT_PORT: -1
ALGORITHM_AFTER_FORWARD: 1
FORWARD_DIRECTION: 0
```
The issue seem to be in `vtkXMLMultiBlockDataWriter::WriteComposite` which returns 0 (the error code) when there is nothing to write.
Having an empty leaf in a multiblock seems a valid case (VTK multiblock reader handles it nicely), so returning a valid return code would makes sense. A MR should follow shortly.https://gitlab.kitware.com/vtk/vtk/-/issues/19180Xdmf3: 64bit data array support broken on Windows2023-11-27T22:18:04-05:00Ben BoeckelXdmf3: 64bit data array support broken on WindowsDiscovered in !10726, Xdmf3 assumes that `long` is 64bits and doesn't provide for `long long` support. This means that on Windows, arrays are mangled via a 32bit-sized `long` type instead of going through a proper 64bit type. See [this c...Discovered in !10726, Xdmf3 assumes that `long` is 64bits and doesn't provide for `long long` support. This means that on Windows, arrays are mangled via a 32bit-sized `long` type instead of going through a proper 64bit type. See [this code in Xdmf3](https://gitlab.kitware.com/vtk/vtk/-/blob/aedf544f5a3160d592488cef57e69b6e94341cd3/ThirdParty/xdmf3/vtkxdmf3/core/XdmfArray.cpp#L146-150).
I'm of a partial mind to disable the module Windows, but maybe 64bit data types aren't that common anyways. In any case, we should probably consider a runtime warning at least.
Cc: @demarlehttps://gitlab.kitware.com/vtk/vtk/-/issues/19174The MapScalars() methods leak in Python2023-11-26T15:21:38-05:00David GobbiThe MapScalars() methods leak in PythonWhen called from Python, the `MapScalars()` methods leak the `vtkUnsignedCharArray` that they return. To avoid the leak, they need the `VTK_NEWINSTANCE` hint.
These methods appear in `vtkScalarsToColors` and `vtkMapper`. In addition t...When called from Python, the `MapScalars()` methods leak the `vtkUnsignedCharArray` that they return. To avoid the leak, they need the `VTK_NEWINSTANCE` hint.
These methods appear in `vtkScalarsToColors` and `vtkMapper`. In addition to adding the hint, the wrappers can be made to warn if they encounter an unhinted `MapScalars()` method that returns a VTK array.
In fact, any VTK method that returns a VTK object but isn't a getter (i.e. doesn't start with Get) has a fair probability of needing a hint.
Ref: [https://discourse.vtk.org/t/retrieve-the-mapped-colors-from-vtkopenglpolydatamapper/12760](https://discourse.vtk.org/t/retrieve-the-mapped-colors-from-vtkopenglpolydatamapper/12760)9.3David GobbiDavid Gobbihttps://gitlab.kitware.com/vtk/vtk/-/issues/19155vtkOCCTReader fails to compile2023-11-26T15:20:15-05:00Orion PoplawskivtkOCCTReader fails to compileTrying to build vtk 9.3.0.rc2 on Fedora rawhide I'm getting:
```
[ 28%] Building Java object Wrapping/Java/CMakeFiles/vtkjava.dir/vtk/vtkOCCTReader.class
cd /builddir/build/BUILD/VTK-9.3.0.rc2/redhat-linux-build-serial/Wrapping/Java && /...Trying to build vtk 9.3.0.rc2 on Fedora rawhide I'm getting:
```
[ 28%] Building Java object Wrapping/Java/CMakeFiles/vtkjava.dir/vtk/vtkOCCTReader.class
cd /builddir/build/BUILD/VTK-9.3.0.rc2/redhat-linux-build-serial/Wrapping/Java && /usr/bin/javac -classpath /builddir/build/BUILD/VTK-9.3.0.rc2/redhat-linux-build-serial/Wrapping/Java -source 1.7 -target 1.7 /builddir/build/BUILD/VTK-9.3.0.rc2/redhat-linux-build-serial/Wrapping/Java/vtk/vtkOCCTReader.java -d CMakeFiles/vtkjava.dir
warning: [options] bootstrap class path not set in conjunction with -source 7
warning: [options] source value 7 is obsolete and will be removed in a future release
warning: [options] target value 7 is obsolete and will be removed in a future release
warning: [options] To suppress warnings about obsolete options, use -Xlint:-options.
/builddir/build/BUILD/VTK-9.3.0.rc2/redhat-linux-build-serial/Wrapping/Java/vtk/vtkOCCTReader.java:47: error: method SetFileFormat(int) is already defined in class vtkOCCTReader
public void SetFileFormat(int id0)
^
1 error
4 warnings
```9.3https://gitlab.kitware.com/vtk/vtk/-/issues/19176Is it possible to updrade ThirdParty/fmt to the latest version?2023-11-25T10:13:58-05:00Andrew MacleanIs it possible to updrade ThirdParty/fmt to the latest version?This is not an error, just a warning and relates to fmt.
Building with Microsoft Visual Studio Community 2022 (64-bit) - Current Version 17.8.1 generates this warning if the C++17 standard is enabled:
``` cmd
stdext::checked_array_itera...This is not an error, just a warning and relates to fmt.
Building with Microsoft Visual Studio Community 2022 (64-bit) - Current Version 17.8.1 generates this warning if the C++17 standard is enabled:
``` cmd
stdext::checked_array_iterator<T *>::iterator_category': warning STL4043: stdext::checked_array_iterator, stdext::unchecked_array_iterator, and related factory functions are non-Standard extensions and will be removed in the future. std::span (since C++20) and gsl::span can be used instead. You can define _SILENCE_STDEXT_ARR_ITERS_DEPRECATION_WARNING or _SILENCE_ALL_MS_EXT_DEPRECATION_WARNINGS to suppress this warning.
```
If you search on STL4043 you will find this [MSVC is deprecating stdext::checked_array_iterator #3540](https://github.com/fmtlib/fmt/issues/3540) the fix seems to be to just upgrade fmt to 10.1 or later. This seems to confirm that upgrading fmt will silence this: [Update fmt version to 10.1.0 #12411](https://github.com/microsoft/react-native-windows/pull/12411)9.3Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/19177vtkInteractorEventRecorder in record mode causes vtkObject.cxx:556 WARN| Pa...2023-11-24T12:10:41-05:00Dimitar PashovvtkInteractorEventRecorder in record mode causes vtkObject.cxx:556 WARN| Passive observer should not call AddObserver or RemoveObserver in callback.Hello,
Don't know if this is a bug or merely undesirable behaviour, but it does issue the warning in the title.
There is indeed the following sequence:
```
vtkInteractorEventRecorder::vtkInteractorEventRecorder():
...
this->Ev...Hello,
Don't know if this is a bug or merely undesirable behaviour, but it does issue the warning in the title.
There is indeed the following sequence:
```
vtkInteractorEventRecorder::vtkInteractorEventRecorder():
...
this->EventCallbackCommand->SetCallback(vtkInteractorEventRecorder::ProcessEvents);
this->EventCallbackCommand->SetPassiveObserver(1);
void vtkInteractorEventRecorder::ProcessEvents(...):
self->Off();
void vtkInteractorEventRecorder::SetEnabled(...):
...
this->Interactor->AddObserver(vtkCommand::AnyEvent, this->EventCallbackCommand, this->Priority);
...
this->Interactor->RemoveObserver(this->EventCallbackCommand);
```
Similar scenario occurs with `ProcessCharEvent`.https://gitlab.kitware.com/vtk/vtk/-/issues/18220Regression in object factory autoinit registration in VTK 9.0.1 (works fine i...2023-11-24T09:56:06-05:00Aleksei NikiforovRegression in object factory autoinit registration in VTK 9.0.1 (works fine in VTK 8.2.0)I'm trying to run itk-snap 3.8.0 (http://www.itksnap.org/pmwiki/pmwiki.php) with VTK 9.0.1, and it crashes. It looks like it vtkPolyDataMapper2D::New() returns nullptr even while libvtkRenderingOpenGL2-9.0.so is linked. It's regrettion: ...I'm trying to run itk-snap 3.8.0 (http://www.itksnap.org/pmwiki/pmwiki.php) with VTK 9.0.1, and it crashes. It looks like it vtkPolyDataMapper2D::New() returns nullptr even while libvtkRenderingOpenGL2-9.0.so is linked. It's regrettion: with VTK 8.2.0 it worked fine.
On further inspection, it looks like function vtkRenderingOpenGL2_AutoInit_Construct() is never called, never registering corresponding classes in factory.
Here's corresponding part of build log:
> cd /usr/src/RPM/BUILD/vtk-9.0.1/BUILD/Rendering/OpenGL2 && /usr/bin/c++ -DRenderingOpenGL2_EXPORTS -DVTK_IN_VTK -DvtkRenderingCore_AUTOINIT_INCLUDE=\"/usr/src/RPM/BUILD/vtk-9.0.1/BUILD/CMakeFiles/vtkModuleAutoInit_4e7408e0d020c0bc0cc5c2b2e46c90a4.h\" -I/usr/src/RPM/BUILD/vtk-9.0.1/BUILD/Rendering/OpenGL2 -I/usr/src/RPM/BUILD/vtk-9.0.1/Rendering/OpenGL2 -I/usr/src/RPM/BUILD/vtk-9.0.1/BUILD/Common/Core -I/usr/src/RPM/BUILD/vtk-9.0.1/Common/Core -I/usr/src/RPM/BUILD/vtk-9.0.1/BUILD/Common/DataModel -I/usr/src/RPM/BUILD/vtk-9.0.1/Common/DataModel -I/usr/src/RPM/BUILD/vtk-9.0.1/BUILD/Common/Math -I/usr/src/RPM/BUILD/vtk-9.0.1/Common/Math -I/usr/src/RPM/BUILD/vtk-9.0.1/BUILD/Common/Transforms -I/usr/src/RPM/BUILD/vtk-9.0.1/Common/Transforms -I/usr/src/RPM/BUILD/vtk-9.0.1/BUILD/Rendering/Core -I/usr/src/RPM/BUILD/vtk-9.0.1/Rendering/Core -I/usr/src/RPM/BUILD/vtk-9.0.1/BUILD/Common/ExecutionModel -I/usr/src/RPM/BUILD/vtk-9.0.1/Common/ExecutionModel -I/usr/src/RPM/BUILD/vtk-9.0.1/BUILD/Filters/Core -I/usr/src/RPM/BUILD/vtk-9.0.1/Filters/Core -I/usr/src/RPM/BUILD/vtk-9.0.1/BUILD/Common/Misc -I/usr/src/RPM/BUILD/vtk-9.0.1/Common/Misc -I/usr/src/RPM/BUILD/vtk-9.0.1/BUILD/Rendering/UI -I/usr/src/RPM/BUILD/vtk-9.0.1/Rendering/UI -I/usr/src/RPM/BUILD/vtk-9.0.1/BUILD/Common/System -I/usr/src/RPM/BUILD/vtk-9.0.1/Common/System -isystem /usr/src/RPM/BUILD/vtk-9.0.1/BUILD/Utilities/KWIML -isystem /usr/src/RPM/BUILD/vtk-9.0.1/Utilities/KWIML -isystem /usr/src/RPM/BUILD/vtk-9.0.1/BUILD/Utilities/KWSys -isystem /usr/src/RPM/BUILD/vtk-9.0.1/Utilities/KWSys -isystem /usr/src/RPM/BUILD/vtk-9.0.1/BUILD/ThirdParty/glew -isystem /usr/src/RPM/BUILD/vtk-9.0.1/ThirdParty/glew -pipe -frecord-gcc-switches -Wall -g -O2 -I/usr/include/gsl -DHAVE_SYS_TIME_H -DHAVE_SYS_TYPES_H -DHAVE_SYS_SOCKET_H -D__USE_LARGEFILE64 -DH5_HAVE_SIGSETJMP -D__USE_POSIX -DH5_HAVE_SETJMP_H -g -Wnon-virtual-dtor -Wno-long-long -ansi -Wcast-align -Wchar-subscripts -Wall -Wextra -Wpointer-arith -Wformat-security -Woverloaded-virtual -Wshadow -Wunused-parameter -fno-check-new -fno-common -Werror=undef -Werror=return-type -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -std=c++11 -o CMakeFiles/RenderingOpenGL2.dir/vtkRenderingOpenGL2ObjectFactory.cxx.o -c /usr/src/RPM/BUILD/vtk-9.0.1/BUILD/Rendering/OpenGL2/vtkRenderingOpenGL2ObjectFactory.cxx
And here are files:
```
$ cat /usr/src/RPM/BUILD/vtk-9.0.1/BUILD/Rendering/OpenGL2/vtkRenderingOpenGL2Module.h
#ifndef VTKRENDERINGOPENGL2_EXPORT_H
#define VTKRENDERINGOPENGL2_EXPORT_H
#ifdef VTKRENDERINGOPENGL2_STATIC_DEFINE
# define VTKRENDERINGOPENGL2_EXPORT
# define VTKRENDERINGOPENGL2_NO_EXPORT
#else
# ifndef VTKRENDERINGOPENGL2_EXPORT
# ifdef RenderingOpenGL2_EXPORTS
/* We are building this library */
# define VTKRENDERINGOPENGL2_EXPORT __attribute__((visibility("default")))
# else
/* We are using this library */
# define VTKRENDERINGOPENGL2_EXPORT __attribute__((visibility("default")))
# endif
# endif
# ifndef VTKRENDERINGOPENGL2_NO_EXPORT
# define VTKRENDERINGOPENGL2_NO_EXPORT __attribute__((visibility("hidden")))
# endif
#endif
#ifndef VTKRENDERINGOPENGL2_DEPRECATED
# define VTKRENDERINGOPENGL2_DEPRECATED __attribute__ ((__deprecated__))
#endif
#ifndef VTKRENDERINGOPENGL2_DEPRECATED_EXPORT
# define VTKRENDERINGOPENGL2_DEPRECATED_EXPORT VTKRENDERINGOPENGL2_EXPORT VTKRENDERINGOPENGL2_DEPRECATED
#endif
#ifndef VTKRENDERINGOPENGL2_DEPRECATED_NO_EXPORT
# define VTKRENDERINGOPENGL2_DEPRECATED_NO_EXPORT VTKRENDERINGOPENGL2_NO_EXPORT VTKRENDERINGOPENGL2_DEPRECATED
#endif
#if 0 /* DEFINE_NO_DEPRECATED */
# ifndef VTKRENDERINGOPENGL2_NO_DEPRECATED
# define VTKRENDERINGOPENGL2_NO_DEPRECATED
# endif
#endif
/* AutoInit dependencies. */
#include "vtkRenderingCoreModule.h"
#include "vtkRenderingUIModule.h"
/* AutoInit implementations. */
#ifdef vtkRenderingOpenGL2_AUTOINIT_INCLUDE
#include vtkRenderingOpenGL2_AUTOINIT_INCLUDE
#endif
#ifdef vtkRenderingOpenGL2_AUTOINIT
#include "vtkAutoInit.h"
VTK_MODULE_AUTOINIT(vtkRenderingOpenGL2)
#endif
#endif /* VTKRENDERINGOPENGL2_EXPORT_H */
$ cat /usr/src/RPM/BUILD/vtk-9.0.1/BUILD/CMakeFiles/vtkModuleAutoInit_4e7408e0d020c0bc0cc5c2b2e46c90a4.h
#define vtkRenderingCore_AUTOINIT 1(vtkRenderingUI)
```
It looks like file vtkRenderingOpenGL2Module.h expects to have **vtkRenderingOpenGL2_AUTOINIT_INCLUDE** and **vtkRenderingOpenGL2_AUTOINIT** defined, but during build **vtkRenderingCore_AUTOINIT_INCLUDE** is defined, and it points to file defining **vtkRenderingCore_AUTOINIT**.https://gitlab.kitware.com/vtk/vtk/-/issues/18993Indexed vtkLookupTable performance regression2023-11-23T11:14:00-05:00Seun OdutolaIndexed vtkLookupTable performance regressionHello Ken, @ken-martin
I am currently working on a task involving the use of an Indexed vtkLookupTable and realised that it was rather slow, on doing a bit of digging I discovered that there was a change internally to vtkScalarsToCo...Hello Ken, @ken-martin
I am currently working on a task involving the use of an Indexed vtkLookupTable and realised that it was rather slow, on doing a bit of digging I discovered that there was a change internally to vtkScalarsToColor's InternalAnnotated structure see:[map -> list](https://gitlab.kitware.com/ken-martin/vtk/-/commit/38ced6d550fd03eb61b90c379b72eda5dea48a46) which vtkLookupTable uses for annotation purposes.
Could you kindly shed some light on why this change was necessary as I've also noticed quite a lot of VTK code uses maps for quick lookup and was wondering why this isn't the case for the Indexed LookupTable.
@seanmhttps://gitlab.kitware.com/vtk/vtk/-/issues/17779UTF-8 filename support for Windows via vtksys2023-11-20T11:59:25-05:00David GobbiUTF-8 filename support for Windows via vtksysIn !6122 the default KWSys encoding for VTK on Windows was changed to UTF-8 in `Utilities/KWSys/CMakeLists.txt`:
set(KWSYS_ENCODING_DEFAULT_CODEPAGE CP_UTF8)
This causes `vtksys::Encoding::ToWide()` and `vtksys::Encoding::ToWin...In !6122 the default KWSys encoding for VTK on Windows was changed to UTF-8 in `Utilities/KWSys/CMakeLists.txt`:
set(KWSYS_ENCODING_DEFAULT_CODEPAGE CP_UTF8)
This causes `vtksys::Encoding::ToWide()` and `vtksys::Encoding::ToWindowsExtendedPath()` to decode their arguments as UTF-8 instead of using the Windows system locale. The benefit is that it allows VTK users to access filenames that contain Unicode characters that aren't within their locale's character set. The goal is, for example, to allow a VTK user in the USA to easily access a filename that contains Chinese characters.
Of course, in order for this to work, VTK must access the filesystem via `vtksys`, or if this isn't possible, then VTK must at least use `vtksys::Encoding::ToWindowsExtendedPath()` to convert UTF-8 strings to the wide strings that Windows uses to natively support Unicode on its filesystems.
Stuff that has been done: !6122 !6291 !6301 !6422 !6426
- change `fopen()` to `vtksys::SystemTools::Fopen()`
- change `ifstream/ofstream` to `vtksys::ifstream/ofstream`
- use `vtksys::Encoding::ToWindowsExtendedPath()` where the above is impossible/inconvenient
**Stuff that hasn't been done:**
The changes above covered VTK classes that access files via fopen() and C++ streams. However, they didn't touch VTK classes that use third-party libraries such as hdf5, netcdf, or libz to access files.
VTKs third-party IO libraries fit into three categories:
1. libraries that require the files to already be open: jpeg, png, ...
2. libraries that provide 'wide string' APIs for use on Windows: hdf5, zlib, tiff, ...
3. libraries that only allow narrow strings encoded in the current locale: netcdf, ...
For (1), nothing need be done, as these are covered by the previous batch of changes.
For (2), it will be necessary to change the VTK classes that use these libraries so that they apply `vtksys::Encoding::ToWindowsExtendedPath()` and call the 'wide' variant of the library APIs. Examples are the vtkNIFTIImageReader/Writer (for zlib), and all VTK classes that use hdf5.
For (3), there is no good solution at this time. If a library accepts neither UTF-8 nor wide strings, the options are:
- accept only narrow strings in the locale encoding, instead of accepting UTF-8, or
- accept UTF-8 and attempt to convert it to a narrow string in the locale encoding (generate an error on failure)
The first option really isn't acceptable, because VTK users shouldn't be expected to consult the documentation for individual VTK classes to see whether they expect UTF-8 vs. the locale encoding. And this is assuming that the documentation actually provides this information and is kept up-to-date.
The second option is better, because it at least allows users to work with UTF-8 filenames that only use characters from their local language. Also, if illegal characters are encountered, they can be informed via an error message that this is the reason they are unable to open the file.
**Addendum: vtkDirectory**
The vtkDirectory class currently uses the Windows C library functions '\_findfirst()' and '\_findnext()' and narrow strings.https://gitlab.kitware.com/vtk/vtk/-/issues/19171vtkSurfaceNets3D crashes when DataCaching is OFF2023-11-20T07:25:45-05:00Bryn LloydvtkSurfaceNets3D crashes when DataCaching is OFFvtkSurfaceNets3D is crashing when I disable DataCaching.
My pipeline/settings are as follows:
```cpp
auto contour_filter = vtkSmartPointer<vtkSurfaceNets3D2>::New();
contour_filter->SetInputData(label_field);
con...vtkSurfaceNets3D is crashing when I disable DataCaching.
My pipeline/settings are as follows:
```cpp
auto contour_filter = vtkSmartPointer<vtkSurfaceNets3D2>::New();
contour_filter->SetInputData(label_field);
contour_filter->SetBackgroundLabel(BG);
for (int i = min_label, count = 0; i <= max_label; ++i)
{
if (i != BG)
contour_filter->SetValue(count++, i);
}
contour_filter->SetSmoothing(true);
contour_filter->SetNumberOfIterations(30);
contour_filter->SetConstraintStrategyToConstraintDistance();
contour_filter->SetAutomaticSmoothingConstraints(true);
contour_filter->SetConstraintScale(1.0);
contour_filter->SetOutputMeshTypeToTriangles();
contour_filter->SetTriangulationStrategyToMinArea();
contour_filter->SetDataCaching(false);
```
The crash is occurring here https://gitlab.kitware.com/vtk/vtk/-/blob/master/Filters/Core/vtkSurfaceNets3D.cxx?ref_type=heads#L2042
> Exception thrown: read access violation.
> **vtkPointSet::GetPoints[virtual]**(...) returned nullptr.
I guess this happens because [here](https://gitlab.kitware.com/vtk/vtk/-/blob/master/Filters/Core/vtkSurfaceNets3D.cxx?ref_type=heads#L2433) we copy from an invalid `this->GeometryCache`.https://gitlab.kitware.com/vtk/vtk/-/issues/19170vtkSurfaceNets3D produces open surfaces2023-11-20T07:24:31-05:00Bryn LloydvtkSurfaceNets3D produces open surfacesvtkSurfaceNets3D produces open surfaces when the non-background voxels reach the boundary.
I guess a special case would be needed to add the quads at the boundary (i.e., if first/last voxel value != BackgroundLabel, add quad). The Bound...vtkSurfaceNets3D produces open surfaces when the non-background voxels reach the boundary.
I guess a special case would be needed to add the quads at the boundary (i.e., if first/last voxel value != BackgroundLabel, add quad). The BoundaryLabels would could store the BackgroundLabel for the "voxel that is outside the image".
A workaround would be to document that vtkSurfaceNets can produce open surfaces and that the image should be padded with the BackgroundLabel before running the filter.
what I get:
![image](/uploads/50da33ed7da3bc17a97616d8a32339ff/image.png)
what I get if I pad the image first (`vtkImageConstantPad`):
![image](/uploads/bf499fe598301f90d3bcbf7e53b1348e/image.png)https://gitlab.kitware.com/vtk/vtk/-/issues/17235Header depends for Python wrapper targets aren't updated2023-11-19T11:36:05-05:00David GobbiHeader depends for Python wrapper targets aren't updatedWhen header files are removed from VTK, they sometimes still appear in the "make" dependencies of the Python wrapper library/module targets. The result is that removing a header file might cause the build to fail, with "make" complainin...When header files are removed from VTK, they sometimes still appear in the "make" dependencies of the Python wrapper library/module targets. The result is that removing a header file might cause the build to fail, with "make" complaining that the header file is needed and is missing.
This occurs because the dependency is generated by the add\_custom\_command() call in vtkWrapPython.cmake, which uses IMPLICIT\_DEPENDS to scan the wrapped header for \#include directives. The list of header dependencies is updated only when the custom command is updated, and removing a header file does not trigger such an update.
A discussion, and a possible fix, is provided in cmake/cmake#16830.David GobbiDavid Gobbi