VTK issueshttps://gitlab.kitware.com/vtk/vtk/-/issues2022-04-21T11:27:04-04:00https://gitlab.kitware.com/vtk/vtk/-/issues/18529improve openfoam reader so that it reads 64bit floats2022-04-21T11:27:04-04:00umutkaya-ugentimprove openfoam reader so that it reads 64bit floatsvtkOpenFOAMReader uses vtkFloatArray to store field values which can store 32 bit floating numbers. It is common to use 64bit floating numbers during OpenFOAM simulations. Adding an option to store 64 bit floats would increase usability ...vtkOpenFOAMReader uses vtkFloatArray to store field values which can store 32 bit floating numbers. It is common to use 64bit floating numbers during OpenFOAM simulations. Adding an option to store 64 bit floats would increase usability of VTK beyond visualization.
`https://github.com/Kitware/VTK/blob/master/IO/Geometry/vtkOpenFOAMReader.cxx`https://gitlab.kitware.com/vtk/vtk/-/issues/18528Touch (and multi-touch) not working in Linux systems with qt62022-04-28T06:05:47-04:00Iker Salmón San MillánTouch (and multi-touch) not working in Linux systems with qt6VTK code asumes QEventPoint ids in a QEvent start at zero or that they are sequential. Such an assumption is often false due to the way the underlying drivers work.
This makes some systems with some drivers unable to make touch events w...VTK code asumes QEventPoint ids in a QEvent start at zero or that they are sequential. Such an assumption is often false due to the way the underlying drivers work.
This makes some systems with some drivers unable to make touch events work.https://gitlab.kitware.com/vtk/vtk/-/issues/18526TEST_DEPENDS can be silently ignored2022-04-18T14:09:16-04:00Mathieu Westphal (Kitware)TEST_DEPENDS can be silently ignoredA VTK module with a TEST_DEPENDS that is not provided by VTK will just see the tests being disabled silently. eg:
eg:
```
find_package(VTK 9.0 REQUIRED
COMPONENTS
FiltersGeneral
FiltersGeometry)
```
```
NAME
myModule
PRIVAT...A VTK module with a TEST_DEPENDS that is not provided by VTK will just see the tests being disabled silently. eg:
eg:
```
find_package(VTK 9.0 REQUIRED
COMPONENTS
FiltersGeneral
FiltersGeometry)
```
```
NAME
myModule
PRIVATE_DEPENDS
VTK::FiltersGeneral
TEST_DEPENDS
VTK::TestingCore
```
The module will build fine but the tests will not be, without any explanation.
@ben.boeckel @francois.mazenhttps://gitlab.kitware.com/vtk/vtk/-/issues/18524TestOggTheoraWriter test fails2022-05-16T22:34:19-04:00Sean McBrideTestOggTheoraWriter test failsThe TestOggTheoraWriter fails on some of my bots.
The fix is a one character change, but I figured I should apply it upstream first. But I'm confused by where upstream is...
Here: https://gitlab.kitware.com/third-party/theora says ups...The TestOggTheoraWriter fails on some of my bots.
The fix is a one character change, but I figured I should apply it upstream first. But I'm confused by where upstream is...
Here: https://gitlab.kitware.com/third-party/theora says upstream is https://git.xiph.org/theora.git , but that's 404 now.
Seems it moved here? https://gitlab.xiph.org/xiph/theora
But also confusing is that there the file that needs changing hasn't changed in 11 years, yet vtk's version of that file does not match. So I guess VTK is using some branch?
@ben.boeckel do you know who knows?https://gitlab.kitware.com/vtk/vtk/-/issues/18520Hyper tree grid rescale to visible data range does not work2022-04-15T08:12:47-04:00Evgenii SharaborinHyper tree grid rescale to visible data range does not work"Rescale to visible data range" button does not work. I tried in Paraview 5.9.0, 5.10.1. May I kindly ask you improve the "Hyper Tree Grid". I think that there are small problems that stuck the work. "Hyper Tree Grid" is really new and v..."Rescale to visible data range" button does not work. I tried in Paraview 5.9.0, 5.10.1. May I kindly ask you improve the "Hyper Tree Grid". I think that there are small problems that stuck the work. "Hyper Tree Grid" is really new and valuable feature. Thank you in advance!
Steps to reproduce:
- Sources -> HyperTreeGrid Random, Apply
- Zoom to a zone with only a single color
- Press Rescale to visible data range
- Nothing happenshttps://gitlab.kitware.com/vtk/vtk/-/issues/18519QML/VTK : QQuickRenderWindow with ui elements on top of that create undesired...2022-04-14T11:02:03-04:00Lucas GivordQML/VTK : QQuickRenderWindow with ui elements on top of that create undesired rendering callWith vtk 9.1 or newer and QML based on QT 6 (tested with QT 6.2.1), we have some limitation when UI elements are superimposed on the vtk render window. When user moves his cursor on theses UI elements, a vtk rendring was call.
It seems ...With vtk 9.1 or newer and QML based on QT 6 (tested with QT 6.2.1), we have some limitation when UI elements are superimposed on the vtk render window. When user moves his cursor on theses UI elements, a vtk rendring was call.
It seems to be related to a current limitation in `QQuickVTKRenderWindow` explain [here](https://gitlab.kitware.com/vtk/vtk/-/blob/master/GUISupport/QtQuick/QQuickVTKRenderWindow.h#L227-230).
related discussion in the discourse could be find here : [QML Rendering Problem](https://discourse.vtk.org/t/qml-rendering-problem/7820)https://gitlab.kitware.com/vtk/vtk/-/issues/18516VTK failed to cmake with MSVC on windows arm642022-04-14T08:47:58-04:00LinGaoVTK failed to cmake with MSVC on windows arm64Environment: Windows Server 2016 + VS2019 VTK master branch c87efc1 commit.
VTK failed to cmake with MSVC on windows arm64. Does VTK support windows arm64? Could you please help look at this issue?
Steps to reproduce the behavior:
1. g...Environment: Windows Server 2016 + VS2019 VTK master branch c87efc1 commit.
VTK failed to cmake with MSVC on windows arm64. Does VTK support windows arm64? Could you please help look at this issue?
Steps to reproduce the behavior:
1. git clone https://gitlab.kitware.com/vtk/vtk F:\gitP\vtk\vtk
2. cd F:\gitP\vtk\vtk && git submodule update --init --recursive
3. mkdir build_arm64 && cd build_arm64
4. cmake -G "Visual Studio 16 2019" -A arm64 -DCMAKE_SYSTEM_VERSION=10.0.18362.0 -DBUILD_SHARED_LIBS=OFF -DVTK_BUILD_TESTING=OFF -DVTK_BUILD_EXAMPLES=OFF ..
Error message:
CMake Error at ThirdParty/hdf5/vtkhdf5/config/cmake/ConfigureChecks.cmake:367 (list):
list index: 1 out of range (-1, 0)
Call Stack (most recent call first):
ThirdParty/hdf5/vtkhdf5/CMakeLists.txt:503 (include)https://gitlab.kitware.com/vtk/vtk/-/issues/18510ShallowCopy inconsistency with GlobalIds2022-04-06T11:35:39-04:00Nicolas VuailleShallowCopy inconsistency with GlobalIdsIn the `vtkProgrammableFilter`, we [initialize](https://gitlab.kitware.com/vtk/vtk/-/blob/41ab85a4c125b69f1eaf33a8328a863c22052014/Filters/Programmable/vtkProgrammableFilter.cxx#L180) the output with a `ShallowCopy` of the input (when `C...In the `vtkProgrammableFilter`, we [initialize](https://gitlab.kitware.com/vtk/vtk/-/blob/41ab85a4c125b69f1eaf33a8328a863c22052014/Filters/Programmable/vtkProgrammableFilter.cxx#L180) the output with a `ShallowCopy` of the input (when `CopyArrays` is `true`).
For `vtkCompositeDataSet`, we have a special code path where we use an iterator and call the `ShallowCopy` on each `vtkDataObject` we find. For other class, we call `ShallowCopy` directly.
**Question:** why is this iteration needed ? Is it not done in the Composite implementation ?
Also, in the linked version of the code, due to a missing `else`, composite input was also ShallowCopied to output after the iteration, leading to a different result in copied arrays: whereas the "iterator" version copy all arrays, some are missing in the second (Global Ids ?). Any idea why ?
tested with disk_out_ref (vtkPartionedDataSetCollection), through ParaView Python Calculator.https://gitlab.kitware.com/vtk/vtk/-/issues/18509vtkCellTreeLocator access to vtkCellTree/vtkCellTreeNode2022-04-07T11:01:56-04:00PetervtkCellTreeLocator access to vtkCellTree/vtkCellTreeNodeHello,
I hope this is the right location to ask for this. I'm using the JAVA binding of VTK and it works really great!
The vtkCellTreeLocator provides a great data structures for efficient algorithms, but it seems it is supposed to be ...Hello,
I hope this is the right location to ask for this. I'm using the JAVA binding of VTK and it works really great!
The vtkCellTreeLocator provides a great data structures for efficient algorithms, but it seems it is supposed to be not accessible from outside the class to implement an own algorithm based on it.
Would it be possible to change this so the cellTree and cellTreeNodes are accessible from outside the class?
Thanks Peterhttps://gitlab.kitware.com/vtk/vtk/-/issues/18504lsan report a leak when using vtkRenderWindow with mesa without a vtkRenderWi...2022-04-03T04:54:30-04:00Mathieu Westphal (Kitware)lsan report a leak when using vtkRenderWindow with mesa without a vtkRenderWindowInteractorlsan reports a leak when calling vtkRenderWindow::Render() without using a vtkRenderWindowInteractor, only on mesa.
Excerpt code to reproduce (full code below):
```
vtkNew<vtkRenderWindow> renderWindow;
renderWindow.Render();
```
Stes...lsan reports a leak when calling vtkRenderWindow::Render() without using a vtkRenderWindowInteractor, only on mesa.
Excerpt code to reproduce (full code below):
```
vtkNew<vtkRenderWindow> renderWindow;
renderWindow.Render();
```
Stesp to reproduce:
- Build VTK
- Build this slightly modified [CylinderExample](/uploads/cdec0f111dab7cdb8053d558e094354c/CylinderExample.tgz) with `-fsanitize=address` cxx flag.
- run with mesa: `__GLX_VENDOR_LIBRARY_NAME=mesa LIBGL_ALWAYS_SOFTWARE=1 ./CylinderExample`
```
[glow@arch ~/tmp/CylinderExample/build]$ __GLX_VENDOR_LIBRARY_NAME=mesa LIBGL_ALWAYS_SOFTWARE=1 ./CylinderExample
=================================================================
==518583==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 128 byte(s) in 1 object(s) allocated from:
#0 0x7f277a22a1b2 in __interceptor_realloc /usr/src/debug/gcc/libsanitizer/asan/asan_malloc_linux.cpp:164
#1 0x7f276973a5ea (<unknown module>)
Direct leak of 64 byte(s) in 1 object(s) allocated from:
#0 0x7f277a22b811 in operator new(unsigned long) /usr/src/debug/gcc/libsanitizer/asan/asan_new_delete.cpp:99
#1 0x7f27697194bd (<unknown module>)
Indirect leak of 56 byte(s) in 1 object(s) allocated from:
#0 0x7f277a229fb9 in __interceptor_calloc /usr/src/debug/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x7f276a7d11e8 (/usr/lib/libasan.so.6.0.0+0x3eb1e8)
Indirect leak of 56 byte(s) in 1 object(s) allocated from:
#0 0x7f277a229fb9 in __interceptor_calloc /usr/src/debug/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x7f276a7d11d0 (/usr/lib/libasan.so.6.0.0+0x3eb1d0)
SUMMARY: AddressSanitizer: 304 byte(s) leaked in 4 allocation(s).
```
Notes:
- Using a vtkRenderWindowInteractor prevents/hide the leak. See the relevant part in CylinderExample.
- Comenting out the whole vtkRenderWindow::Render() method also prevents the leak, so it is not in the X initialization stack but in the actual rendering code that the leak occurs.
- For some reason, LSAN does not provide the callstack. Using `fast_unwind_on_malloc=0` is supposed to work around that but this LSAN flags hangs when using mesa.
- The allocation probably occurs in mesa stack, as leaks in VTK are correctly reported by LSAN in my tests. This means that building mesa in debug may be a way forward to isolate the issue.
- Switching to nvidia prevents/hides the leak
I spent multiples hours trying to figure this one out but am on my wits ends. In any case, this is probably either a leak in mesa or a false positive, but the fact that using a vtkRenderWindorInteractor hides it shows that maybe there is something that VTK can do.
I will just hide the leak in my own CI. This issue is for information and if someone else is impacted.
FYI @dgobbi @ken-martin @michael.migliorehttps://gitlab.kitware.com/vtk/vtk/-/issues/18499export_gltf generates invalid gltf2022-03-31T04:22:47-04:00Egil Möllerexport_gltf generates invalid gltfI was instructed [in a pyvista github issue](https://github.com/pyvista/pyvista/issues/2371#issuecomment-1081792744) to open this issue. Linking both issues together.
TL;DR:
When exporting meshes as gltf, the generated gltf ends up bei...I was instructed [in a pyvista github issue](https://github.com/pyvista/pyvista/issues/2371#issuecomment-1081792744) to open this issue. Linking both issues together.
TL;DR:
When exporting meshes as gltf, the generated gltf ends up being invalid, with bad vertice indexing.
Data files:
* [Single cell](/uploads/66e38f041bf57aef98390b41b82d41f6/boreholes-test-small.zip)
* [5 cells](/uploads/2c6c168c94eba15f3e00ab87f87a720f/boreholes-test-larger.zip)
Code to reproduce:
```
import pyvista as pv
b = pv.read("boreholes-test-small.vtk")
c = b.extract_surface()
pl = pv.Plotter()
pl.add_mesh(c)
pl.export_gltf("boreholes-test-small.gltf", save_normals=True, inline_data=True)
```
Errors as reported by the validator built into https://sandbox.babylonjs.com/ for the single cell file:
```
{
"code": "MESH_PRIMITIVE_UNEQUAL_ACCESSOR_COUNT",
"message": "All accessors of the same primitive must have the same count.",
"severity": 0,
"pointer": "/meshes/0/primitives/0/attributes/POSITION"
},
{
"code": "ACCESSOR_INDEX_OOB",
"message": "Indices accessor element at index 1 has value 1 that is greater than the maximum vertex index available (0).",
"severity": 0,
"pointer": "/meshes/0/primitives/0/indices"
}
```
and for the 5 cell file:
```
{
"code": "MESH_PRIMITIVE_UNEQUAL_ACCESSOR_COUNT",
"message": "All accessors of the same primitive must have the same count.",
"severity": 0,
"pointer": "/meshes/0/primitives/0/attributes/POSITION"
},
{
"code": "ACCESSOR_INDEX_OOB",
"message": "Indices accessor element at index 5 has value 5 that is greater than the maximum vertex index available (4).",
"severity": 0,
"pointer": "/meshes/0/primitives/0/indices"
},
{
"code": "ACCESSOR_INDEX_OOB",
"message": "Indices accessor element at index 6 has value 6 that is greater than the maximum vertex index available (4).",
"severity": 0,
"pointer": "/meshes/0/primitives/0/indices"
},
{
"code": "ACCESSOR_INDEX_OOB",
"message": "Indices accessor element at index 7 has value 7 that is greater than the maximum vertex index available (4).",
"severity": 0,
"pointer": "/meshes/0/primitives/0/indices"
},
{
"code": "ACCESSOR_INDEX_OOB",
"message": "Indices accessor element at index 8 has value 8 that is greater than the maximum vertex index available (4).",
"severity": 0,
"pointer": "/meshes/0/primitives/0/indices"
},
{
"code": "ACCESSOR_INDEX_OOB",
"message": "Indices accessor element at index 9 has value 9 that is greater than the maximum vertex index available (4).",
"severity": 0,
"pointer": "/meshes/0/primitives/0/indices"
}
```
System information as per `pyvista.Report()`:
```
--------------------------------------------------------------------------------
Date: Wed Mar 23 10:56:32 2022 CET
OS : Linux
CPU(s) : 8
Machine : x86_64
Architecture : 64bit
RAM : 38.9 GiB
Environment : Jupyter
GPU Vendor : Intel Open Source Technology Center
GPU Renderer : Mesa DRI Intel(R) UHD Graphics (CML GT2)
GPU Version : 4.6 (Core Profile) Mesa 20.0.8
Python 3.8.0 (default, Feb 25 2021, 22:10:10) [GCC 8.4.0]
pyvista : 0.33.3
vtk : 9.0.1
numpy : 1.22.1
imageio : 2.9.0
appdirs : 1.4.4
scooby : 0.5.7
matplotlib : 3.4.1
PyQt5 : 5.15.6
IPython : 7.22.0
scipy : 1.6.3
tqdm : 4.60.0
meshio : 4.4.0
--------------------------------------------------------------------------------
```https://gitlab.kitware.com/vtk/vtk/-/issues/18498vtkPLYReader crashes for some files due to infinite loop in vtkIncrementalOct...2023-10-16T22:29:24-04:00Andras LassovtkPLYReader crashes for some files due to infinite loop in vtkIncrementalOctreeNodeWhen loading certain PLY files that contain texture coordinates (such as this [example PLY file](https://github.com/lassoan/PublicTestingData/releases/download/data/20220329-LocatorCrash.ply), exported by MeshLab) then the application cr...When loading certain PLY files that contain texture coordinates (such as this [example PLY file](https://github.com/lassoan/PublicTestingData/releases/download/data/20220329-LocatorCrash.ply), exported by MeshLab) then the application crashes with stack overflow.
Stack (most recently called on top):
```
...this same line is repeated hundreds of times
vtkCommon-9.1d.dll!vtkIncrementalOctreeNode::CreateChildNodes(vtkPoints * points, vtkIdList * pntIds, const double * newPnt, __int64 * pntIdx, int maxPts, int ptMode, int & numberOfNodes) Line 426 C++
vtkCommon-9.1d.dll!vtkIncrementalOctreeNode::CreateChildNodes(vtkPoints * points, vtkIdList * pntIds, const double * newPnt, __int64 * pntIdx, int maxPts, int ptMode, int & numberOfNodes) Line 426 C++
vtkCommon-9.1d.dll!vtkIncrementalOctreeNode::CreateChildNodes(vtkPoints * points, vtkIdList * pntIds, const double * newPnt, __int64 * pntIdx, int maxPts, int ptMode, int & numberOfNodes) Line 426 C++
vtkCommon-9.1d.dll!vtkIncrementalOctreeNode::CreateChildNodes(vtkPoints * points, vtkIdList * pntIds, const double * newPnt, __int64 * pntIdx, int maxPts, int ptMode, int & numberOfNodes) Line 426 C++
vtkCommon-9.1d.dll!vtkIncrementalOctreeNode::CreateChildNodes(vtkPoints * points, vtkIdList * pntIds, const double * newPnt, __int64 * pntIdx, int maxPts, int ptMode, int & numberOfNodes) Line 426 C++
vtkCommon-9.1d.dll!vtkIncrementalOctreeNode::CreateChildNodes(vtkPoints * points, vtkIdList * pntIds, const double * newPnt, __int64 * pntIdx, int maxPts, int ptMode, int & numberOfNodes) Line 426 C++
vtkCommon-9.1d.dll!vtkIncrementalOctreeNode::CreateChildNodes(vtkPoints * points, vtkIdList * pntIds, const double * newPnt, __int64 * pntIdx, int maxPts, int ptMode, int & numberOfNodes) Line 426 C++
vtkCommon-9.1d.dll!vtkIncrementalOctreeNode::CreateChildNodes(vtkPoints * points, vtkIdList * pntIds, const double * newPnt, __int64 * pntIdx, int maxPts, int ptMode, int & numberOfNodes) Line 426 C++
vtkCommon-9.1d.dll!vtkIncrementalOctreeNode::CreateChildNodes(vtkPoints * points, vtkIdList * pntIds, const double * newPnt, __int64 * pntIdx, int maxPts, int ptMode, int & numberOfNodes) Line 426 C++
vtkCommon-9.1d.dll!vtkIncrementalOctreeNode::InsertPoint(vtkPoints * points, const double * newPnt, int maxPts, __int64 * pntId, int ptMode, int & numberOfNodes) Line 494 C++
vtkCommon-9.1d.dll!vtkIncrementalOctreePointLocator::InsertUniquePoint(const double * point, __int64 & pntId) Line 1281 C++
vtkIO-9.1d.dll!vtkPLYReader::RequestData(vtkInformation * __formal, vtkInformationVector * * __formal, vtkInformationVector * outputVector) Line 536 C++
vtkCommon-9.1d.dll!vtkPolyDataAlgorithm::ProcessRequest(vtkInformation * request, vtkInformationVector * * inputVector, vtkInformationVector * outputVector) Line 87 C++
vtkCommon-9.1d.dll!vtkExecutive::CallAlgorithm(vtkInformation * request, int direction, vtkInformationVector * * inInfo, vtkInformationVector * outInfo) Line 734 C++
vtkCommon-9.1d.dll!vtkDemandDrivenPipeline::ExecuteData(vtkInformation * request, vtkInformationVector * * inInfo, vtkInformationVector * outInfo) Line 462 C++
vtkCommon-9.1d.dll!vtkCompositeDataPipeline::ExecuteData(vtkInformation * request, vtkInformationVector * * inInfoVec, vtkInformationVector * outInfoVec) Line 162 C++
vtkCommon-9.1d.dll!vtkDemandDrivenPipeline::ProcessRequest(vtkInformation * request, vtkInformationVector * * inInfoVec, vtkInformationVector * outInfoVec) Line 261 C++
vtkCommon-9.1d.dll!vtkStreamingDemandDrivenPipeline::ProcessRequest(vtkInformation * request, vtkInformationVector * * inInfoVec, vtkInformationVector * outInfoVec) Line 343 C++
vtkCommon-9.1d.dll!vtkDemandDrivenPipeline::UpdateData(int outputPort) Line 421 C++
vtkCommon-9.1d.dll!vtkStreamingDemandDrivenPipeline::Update(int port, vtkInformationVector * requests) Line 417 C++
vtkCommon-9.1d.dll!vtkStreamingDemandDrivenPipeline::Update(int port) Line 381 C++
vtkCommon-9.1d.dll!vtkAlgorithm::Update(int port) Line 1409 C++
vtkCommon-9.1d.dll!vtkAlgorithm::Update() Line 1403 C++
MRMLCore.dll!vtkMRMLModelStorageNode::ReadDataInternal(vtkMRMLNode * refNode) Line 301 C++
```
The error is that vtkIncrementalOctreePointLocator gets into an infinite loop when [vtkPLYReader calls `InsertUniquePoint`](https://gitlab.kitware.com/vtk/vtk/-/blob/master/IO/PLY/vtkPLYReader.cxx#L535) with the coordinates `{-1.8040610551834106, -0.060864001512527466, 0.0000000000000000}`. It is outside the bounds that the locator was initialized with `{0.0, 1.0, 0.0, 1.0, 0.0, 1.0}` but hundreds of similar points were added to the locator before.https://gitlab.kitware.com/vtk/vtk/-/issues/18497vtkSetGet macros are not available in doxygen2022-03-23T21:57:22-04:00Jean-Christophe Fillion-RobinvtkSetGet macros are not available in doxygenMacros implemented in [Common/Core/vtkSetGet.h](https://github.com/Kitware/VTK/blob/master/Common/Core/vtkSetGet.h) are not listed on the doxygen website: https://vtk.org/doc/nightly/html/annotated.html
In prior version, they used to be...Macros implemented in [Common/Core/vtkSetGet.h](https://github.com/Kitware/VTK/blob/master/Common/Core/vtkSetGet.h) are not listed on the doxygen website: https://vtk.org/doc/nightly/html/annotated.html
In prior version, they used to be available as https://vtk.org/doc/release/4.0/html/vtkSetGet_8h.htmlhttps://gitlab.kitware.com/vtk/vtk/-/issues/18496vtk writer truncates precision of large magnitude ORIGIN values in Structured...2022-03-22T05:25:41-04:00madala70vtk writer truncates precision of large magnitude ORIGIN values in Structured Points, Rectilinear GridsWith large magnitude ORIGIN values vtk writer reverts to scientific notation & looses precision
![Test_code](/uploads/ef1a4b7963a03ae43bde8c1befa580ee/Test_code.PNG)
Comparison of source and output files using WinMerge (No issue with d...With large magnitude ORIGIN values vtk writer reverts to scientific notation & looses precision
![Test_code](/uploads/ef1a4b7963a03ae43bde8c1befa580ee/Test_code.PNG)
Comparison of source and output files using WinMerge (No issue with differences in first two lines)
![WinMerge](/uploads/5d1f156df8ba00355e4435abed3bb1ea/WinMerge.PNG)https://gitlab.kitware.com/vtk/vtk/-/issues/18493Fix all clang -Wstrict-prototypes warnings2022-04-13T20:11:42-04:00Sean McBrideFix all clang -Wstrict-prototypes warningsClang is considering making the -Wstrict-prototypes warning an error by default, see: https://discourse.llvm.org/t/rfc-enabling-wstrict-prototypes-by-default-in-c/60521
vtk has several such warnings, but they are *all* from third party ...Clang is considering making the -Wstrict-prototypes warning an error by default, see: https://discourse.llvm.org/t/rfc-enabling-wstrict-prototypes-by-default-in-c/60521
vtk has several such warnings, but they are *all* from third party libs.
I have fixed most upstream:
https://github.com/CGNS/CGNS/pull/332
https://github.com/Unidata/netcdf-c/pull/2239
https://gitlab.onelab.info/seanm/gl2ps/-/merge_requests/1
and created a ticket for another:
https://github.com/gsjaardema/seacas/issues/290
VTK just needs to update its copy of these third party libs...https://gitlab.kitware.com/vtk/vtk/-/issues/18491Move all Java related targets to VTKJava-targets-*.cmake2022-08-22T20:04:04-04:00StefanBruensMove all Java related targets to VTKJava-targets-*.cmakeCurrently, the executable VTK::ParseJava, VTK::WrapJava targets and the VTK::Java library target are part of VTK-targets-<configuration>.cmake
As far as I can see, none of these targets is usable without the remaining java parts.
(The ...Currently, the executable VTK::ParseJava, VTK::WrapJava targets and the VTK::Java library target are part of VTK-targets-<configuration>.cmake
As far as I can see, none of these targets is usable without the remaining java parts.
(The same probably applies to VTKPython-targets-*.cmake)https://gitlab.kitware.com/vtk/vtk/-/issues/18484Break reference cycle in vtk pipeline2022-03-08T13:50:43-05:00Jaswant Panchumarti (Kitware)Break reference cycle in vtk pipelineThe goal is to empower asynchronous VTK applications by removing the necessity of VTK garbage collector. That GC has a severe limitation: can collect garbage only on the main thread.
This issue documents the current design of VTK pipel...The goal is to empower asynchronous VTK applications by removing the necessity of VTK garbage collector. That GC has a severe limitation: can collect garbage only on the main thread.
This issue documents the current design of VTK pipeline and elaborates on the requirement of a GC. It dives right into the guts of `vtkAlgorithm` and `vtkExecutive`. I find this helps me recap the problem from time to time.
## Understand the requirement for GC:
VTK GC was required to deal with complex reference loops in the current design of VTK pipeline and elsewhere. A producer keeps a hard reference to itself within it's output information objects per port (say `info_op0`) via the `vtkExecutive::PRODUCER` key. This is the most complex issue here. A consumer hard references it's producer's output information object per port in one of its input information objects. This is how a consumer keeps a strong reference to its producer.
#### Example
Observe evolution of `info_op0` in a simple pipeline setup with `snk->SetInputConnection(0, src->GetOutputPort())`:
```
------- -------
| | | |
| src |-[op0]--------->[inp0]-| snk |
| | | |
------- -------
```
`src->GetOutputInformation(port)` is called somewhere in the beginning of `::SetInputConnection`.
The producer (`src`) adds a hard reference to itself in its output information object for that port. `info_op0` now looks like
```
info_op0 (vtkInformation 0xabcde):
PRODUCER: <src (vtkExecutive 0x12345), 0>
CONSUMERS: []
```
Towards the end of `::SetInputConnection` the consumer goes on to add a hard reference to itself in the very same `info_op0` object.
```
info_op0 (vtkInformation 0xabcde):
PRODUCER: <src (vtkExecutive 0x12345), 0>
CONSUMERS: [<snk (vtkExecutive 0x6789a, 0>]
```
The consumer then sets `info_op0` object as its input information object (say `info_ip0`) for the specified input port. There's a similar setup in `::AddInputConnection`. Whatever is set or appended in either of these functions is removed in `::RemoveInputConnection`
Assuming `vtkExecutive` and `vtkAlgorithm` did not use a GC. If one were to
1. delete `snk` by decref'ing, it is still kept alive by `src`'s `info_op0`.
2. delete `src` by decref'ing, it is still kept alive by `snk`'s `info_ip0`.
When the application exits, both `src` and `snk` keep each other alive and leak memory very nicely. Whereas with a GC, this strongly connected component is identified and freed.
Here's a real example of that leak when you build VTK with garbage collection disabled for `vtkExecutive` and `vtkAlgorithm`.
```python
>>> from vtkmodules.vtkCommonExecutionModel import *
>>> from vtkmodules.vtkFiltersSources import *
>>> src = vtkPlaneSource()
>>> snk = vtkTrivialConsumer()
>>> src.UsesGarbageCollector()
False
>>> snk.UsesGarbageCollector()
False
>>> src.GetExecutive().UsesGarbageCollector()
False
>>> snk.GetExecutive().UsesGarbageCollector()
False
>>> snk.SetInputConnection(0, src.GetOutputPort())
>>> snk.Update()
>>> exit()
vtkDebugLeaks has detected LEAKS!
..
Class "vtkPlaneSource" has 1 instance still around.
..
Class "vtkTrivialConsumer" has 1 instance still around.
..
```
## Secondary problem
The `CONSUMERS: []` key-value pair is really unnecessary. Its only use case is a very strange application where an algorithm modifies its number of output ports after the construction of a pipeline. See `vtkAlgorithm::SetNumberOfOutputPorts()`. Here, the algorithm visits each previously connected consumer and removes itself from the consumer's inputs. I don't know of a use case where a derived algorithm would call `::SetNumberOfOutputPorts()` outside the constructor. We could remove all occurrences of `vtkExecutive::CONSUMERS` and ideally nothing would change.
Possible solutions have been moved to !8975
## Test scripts:
1. This should not leak upon exit.
```python
from vtkmodules.vtkCommonExecutionModel import *
from vtkmodules.vtkFiltersSources import *
src = vtkPlaneSource()
snk = vtkTrivialConsumer()
snk.SetInputConnection(0, src.GetOutputPort())
```
2. This should not leak upon exit and must print the expected output.
```python
from vtkmodules.vtkCommonExecutionModel import *
snk = vtkTrivialConsumer()
print(snk.GetReferenceCount())
1
print(snk.GetExecutive().GetReferenceCount())
2
print(snk.GetReferenceCount())
1
```Jaswant Panchumarti (Kitware)Jaswant Panchumarti (Kitware)https://gitlab.kitware.com/vtk/vtk/-/issues/18482VTK testing macros are not external module friendly2023-04-24T08:36:13-04:00Mathieu Westphal (Kitware)VTK testing macros are not external module friendlyAdding tests to VTK modules outside of VTK is not friendly at all.
Here is how it currently works in VTK.
- VTK rely on ExternalData to recover data. This is fine and generally not used outside of VTK and optional generally, nothing to...Adding tests to VTK modules outside of VTK is not friendly at all.
Here is how it currently works in VTK.
- VTK rely on ExternalData to recover data. This is fine and generally not used outside of VTK and optional generally, nothing to fix here
- vtkTesting.cxx rely on the -V/-B/-D/-T to find out where is located the baselines, data and such, this is fine and could be used outside of VTK
- vtkModuleTesting.cmake is where the fix should happens
in **vtk_add_test_cxx** macro we should be able to:
- set if external data should be used or not
- set if only baseline dir should be used or full baseline name
- set the baseline dir
- set the data dir
- set the temporary dir
in **vtk_add_test_python** we should be able to:
- set the baseline dir
- set the data dir
- set the temporary dir
Currently, these dirs are hardcoded which is not practical at all. They can be specified with env vars but this is not the right way to go.
FYI @ben.boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/18481vtkDelaunay2D produces inverted triangles2022-03-08T03:41:42-05:00Tiffany ChhimvtkDelaunay2D produces inverted trianglesThe `vtkDelaunay2D` algorithm sometimes creates a triangulation where some triangles are inverted, as illustrated below.
![BackfaceIssue](/uploads/35346567d226ab326ae48b0118dfb2b3/BackfaceIssue.png)
(These points were taken from the sc...The `vtkDelaunay2D` algorithm sometimes creates a triangulation where some triangles are inverted, as illustrated below.
![BackfaceIssue](/uploads/35346567d226ab326ae48b0118dfb2b3/BackfaceIssue.png)
(These points were taken from the script `Filters/Core/Testing/Python/constrainedDelaunay.py`.
No constraints on the triangulation.)
One of the consequences is that the ensuing algorithm for adding edge constraints becomes invalid.https://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;
}
```