VTK issueshttps://gitlab.kitware.com/vtk/vtk/-/issues2020-02-10T22:05:36-05:00https://gitlab.kitware.com/vtk/vtk/-/issues/17781PySide2 [linux]: polygons aren't shaded correctly when rendered in pyside22020-02-10T22:05:36-05:00simon klemencPySide2 [linux]: polygons aren't shaded correctly when rendered in pyside2## System
* Linux (Arch) Kernel 5.5.2
* VTK 8.2 (anaconda)
* PySide2 5.13.2 (anaconda)
## Problem:
Polygon faces aren't rendered correctly.
The issue came with vtk 8.1.2 -> 8.2.0
## Steps to reproduce:
* download [t...## System
* Linux (Arch) Kernel 5.5.2
* VTK 8.2 (anaconda)
* PySide2 5.13.2 (anaconda)
## Problem:
Polygon faces aren't rendered correctly.
The issue came with vtk 8.1.2 -> 8.2.0
## Steps to reproduce:
* download [test.py](/uploads/fa265f05ec8a8ba64b562762c620b467/test.py)
* install vtk with pyside 2 on linux
```
conda install vtk=8.2 pyside2
python test.py
```
i tried different combinations of inverted orientation / culling,..https://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/17778vtkIdFilter should (optionally) pass data arrays2020-02-03T19:16:06-05:00Joachim PouderouxvtkIdFilter should (optionally) pass data arrays`vtkIdFilter` can generate point & cell data ids but it has no option to pass the input data arrays to the output.
We should add an option to pass the existing data arrays into the output mesh.
How to reproduce with ParaView:
- Create...`vtkIdFilter` can generate point & cell data ids but it has no option to pass the input data arrays to the output.
We should add an option to pass the existing data arrays into the output mesh.
How to reproduce with ParaView:
- Create a Wavelet
- Apply the Generate Ids filter
=> Output does not contains the RTData point scalar array.https://gitlab.kitware.com/vtk/vtk/-/issues/17777vtkExtractSelection is not copying FieldData2020-01-30T00:26:31-05:00Mathieu Westphal (Kitware)vtkExtractSelection is not copying FieldDatavtkExtractSelection does not seem to copy field data associated with the selection.
Steps to reproduce (with ParaView)
* Open ParaView
* Open can.ex2, check all arrays, Apply
* Color by "Element Block Ids"
* Select a few cells
* Ex...vtkExtractSelection does not seem to copy field data associated with the selection.
Steps to reproduce (with ParaView)
* Open ParaView
* Open can.ex2, check all arrays, Apply
* Color by "Element Block Ids"
* Select a few cells
* Extract Selection, Apply
* "Element Block Ids" is not present in outputhttps://gitlab.kitware.com/vtk/vtk/-/issues/17773Should we migrate from jsoncpp?2020-01-24T10:59:30-05:00Ben BoeckelShould we migrate from jsoncpp?There are a number of JSON libraries out there. I'd like to keep VTK on just one. ADIS is using RapidJSON in !6402, but I'd like to know our future before merging/requiring a second one. There are 5 ParaView modules and 6 VTK modules usi...There are a number of JSON libraries out there. I'd like to keep VTK on just one. ADIS is using RapidJSON in !6402, but I'd like to know our future before merging/requiring a second one. There are 5 ParaView modules and 6 VTK modules using `VTK::jsoncpp` today for an idea of the porting burden.
I know SMTK has been happy with nlohmann_json. RapidJSON was apparently chosen originally for other projects because it supported JSON Schema validation, but there is [this project](https://github.com/pboettch/json-schema-validator) built on nlohmann for that (if VTK ever needs it).
Whatever we choose, I don't want to repeat our XML library explosion with JSON libraries as well. The third party packages are hard enough to wrangle without adding even more :) .
Cc: @chuck.atkins @robertmaynard @berkgeveci @utkarsh.ayachit @tjcorona @caitlin.rosshttps://gitlab.kitware.com/vtk/vtk/-/issues/17772QVTKOpenGLNativeWidget breaks painting of parent QWidget and all siblings2022-07-31T17:18:27-04:00Igor GribanovQVTKOpenGLNativeWidget breaks painting of parent QWidget and all siblingsWhen `QVTKOpenGLNativeWidget` is the central widget in `QMainWindow` it works fine, as shown in the sample RenderWindowNoUiFile. However, if sibling `QWidget`s are present in the same layout, then the siblings do not redraw upon window r...When `QVTKOpenGLNativeWidget` is the central widget in `QMainWindow` it works fine, as shown in the sample RenderWindowNoUiFile. However, if sibling `QWidget`s are present in the same layout, then the siblings do not redraw upon window resize or upon user interaction. The widgets do receive their `paintEvent`s. However, none of them redraw, unless the update was triggered by interaction with `QVTKOpenGLNativeWidget`.
To reproduce this effect, add a `QPushButton` to the main window as follows:
```
qtw = new QVTKOpenGLNativeWidget(ui->centralwidget);
qpb = new QPushButton("hello button", ui->centralwidget);
```
You will notice that the button does not redraw when clicked, and central widget does not redraw if the window is resized. The following versions of software are used: VTK 8.2, Qt 5.12.6, Ubuntu 18.04.3, GCC 7.4.0.
I found a quick fix, but not sure if it breaks anything else in VTK's rendering. When initializing `QSurfaceFormat`, I set alpha buffer size to zero:
```
QSurfaceFormat fmt = QVTKOpenGLNativeWidget::defaultFormat();
fmt.setAlphaBufferSize(0);
QSurfaceFormat::setDefaultFormat(fmt);
```
Also, in the current commit, `QVTKOpenGLNativeWidget` does not compile.
Thank you for your time.
![qtw](/uploads/dc553e4de3647c5621f79bd52056ab97/qtw.png)https://gitlab.kitware.com/vtk/vtk/-/issues/17764Hyper Tree Grid super cursor needs fixes2020-01-10T15:51:01-05:00Yohann Bearzi (Kitware)Hyper Tree Grid super cursor needs fixesThe super cursors that can be used to access data from neighboring trees are broken. In the current state, this feature is barely usable. I'll list a few bugs I've encountered:
* When accessing a neighbor from a border of the hyper tr...The super cursors that can be used to access data from neighboring trees are broken. In the current state, this feature is barely usable. I'll list a few bugs I've encountered:
* When accessing a neighbor from a border of the hyper tree grid, i.e. when accessing a non-existing node outside the extent, the index of this non existing node being returned is `0`, which refers to an existing cell. It should be something like `~0` for example, with `~0` being a `static constexpr` attribute of `vtkHyperTreeGrid`.
* When wanting to create a `vtkHyperTreeGridNonOrientedGeometryCursor` from a `vtkHyperTreeGridNonOrientedSuperCursor`, there is a `assert(false)` in the code, which will always fail. The issue here is that the created cursor, which should be able to access its parent since it is not oriented, cannot do so, unless we create the cursor by walking from the root of its `vtkHyperTree` to the node. This just needs to be implemented, with a warning in the documentation on the bad performance of such a procedure.
* The `vtkHyperTreeGridOrientedGeometryCursor` that one can create from `vtkHyperTreeGridNonOrientedSuperCursor` has non initialized pointers, such as `Scales`. This causes random crashes in methods needing this pointer.
There might be other issues. The idea of this issue would be to fix the known issues that I presented, and to do a sweep through the code related to supercursors, testing every method to see if there are other broken parts.Yohann Bearzi (Kitware)Yohann Bearzi (Kitware)https://gitlab.kitware.com/vtk/vtk/-/issues/17757Feature: make vtkOBJReader.cxx handle f// syntax gracefully2020-01-08T05:48:37-05:00Moritz MoellerFeature: make vtkOBJReader.cxx handle f// syntax gracefullyPlease see https://github.com/GollyGang/ready/issues/64 for a discussion. An example file exported from [Wings3D](http://www.wings3d.com/) is [attached](/uploads/1e4ba149aa658b189c3ad3727d0d6f55/knotty01.zip).
According to the discussio...Please see https://github.com/GollyGang/ready/issues/64 for a discussion. An example file exported from [Wings3D](http://www.wings3d.com/) is [attached](/uploads/1e4ba149aa658b189c3ad3727d0d6f55/knotty01.zip).
According to the discussion in above issue, vtkOBJReader does not handle `f//` syntax gracefully.
I made several points why it is good practice to do so [in this comment specifically](https://github.com/GollyGang/ready/issues/64#issuecomment-570571677).https://gitlab.kitware.com/vtk/vtk/-/issues/17755vtkCaptionActor2D does not respect Visibility flag during rendering2020-01-15T04:00:49-05:00Artem BodrinvtkCaptionActor2D does not respect Visibility flag during renderingvtkCaptionActor2D *actor = ...
actor->SetVisibility( false );
does not have any effect, actor is rendered
there is no check for this->Visibility in these methods:
```
int vtkCaptionActor2D::RenderOpaqueGeometry(vtkViewpor...vtkCaptionActor2D *actor = ...
actor->SetVisibility( false );
does not have any effect, actor is rendered
there is no check for this->Visibility in these methods:
```
int vtkCaptionActor2D::RenderOpaqueGeometry(vtkViewport *viewport)
int vtkCaptionActor2D::RenderOverlay(vtkViewport *viewport)
```
UPDATE:
I just checked some other actors, none of them respects that flag in rendering methods. I suppose that ok, but kind of confusing. Maybe it will be good solution to move setter/getter of visibility to protected section for them?https://gitlab.kitware.com/vtk/vtk/-/issues/17751vtkScalarBarActor::DrawTickLabelsOn() does not work.2022-04-02T10:36:24-04:00PauloCarvalhoRJvtkScalarBarActor::DrawTickLabelsOn() does not work.Setting that flag is ineffective.
Another user (Python) has also encountered this defect: https://discourse.vtk.org/t/tick-lines-with-vtkscalarbaractor/2268Setting that flag is ineffective.
Another user (Python) has also encountered this defect: https://discourse.vtk.org/t/tick-lines-with-vtkscalarbaractor/2268https://gitlab.kitware.com/vtk/vtk/-/issues/17749#undef _DEBUG in vtkPython.h2021-12-18T12:16:31-05:00Alexander Neumann#undef _DEBUG in vtkPython.hhttps://gitlab.kitware.com/vtk/vtk/blob/master/Utilities/Python/vtkPython.h#L53
is this intentionally or just a bug?
It fails my debug builds because python tries to link python37.lib instead of python37_d.lib on windowshttps://gitlab.kitware.com/vtk/vtk/blob/master/Utilities/Python/vtkPython.h#L53
is this intentionally or just a bug?
It fails my debug builds because python tries to link python37.lib instead of python37_d.lib on windowsBen BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/17748Java wrapping of external projects no longer works (VTK 8.90)2020-04-23T14:23:03-04:00David GobbiJava wrapping of external projects no longer works (VTK 8.90)In VTK 8.2 and earlier, vtkCommonCoreJava and the other Java targets were exported via `VTKTargets.cmake`. In VTK 8.90, the Java targets are no longer exported, which makes external Java wrapping impossible.
For this reason, I removed ...In VTK 8.2 and earlier, vtkCommonCoreJava and the other Java targets were exported via `VTKTargets.cmake`. In VTK 8.90, the Java targets are no longer exported, which makes external Java wrapping impossible.
For this reason, I removed the Java wrapping from the vtkMy example in !6247. The Java targets should be re-exported and the Java wrapping code should be re-inserted into vtkMy so that external wrapping can be tested.Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/17746Wrong node numbering for high-order Lagrange hexahedron and tetrahedron cells2023-10-19T13:01:29-04:00Florian MaurinWrong node numbering for high-order Lagrange hexahedron and tetrahedron cellsThe node numbering used in the code is not corresponding to the one provided by the documentation that can be found here:
https://blog.kitware.com/wp-content/uploads/2018/09/Source_Issue_43.pdf
Here is the high resolution pdf, to be ab...The node numbering used in the code is not corresponding to the one provided by the documentation that can be found here:
https://blog.kitware.com/wp-content/uploads/2018/09/Source_Issue_43.pdf
Here is the high resolution pdf, to be able to zoom on the node numbers!
[VtkLagrangeNodeNumbering.pdf](/uploads/d18be24480da192e4b70568f050d114f/VtkLagrangeNodeNumbering.pdf)
@dcthomp, @bob.obara, and @tjcorona
![image](/uploads/a0dc0173a41d3cf6b03a9266c0e23688/image.png)https://gitlab.kitware.com/vtk/vtk/-/issues/17745vtkWindowToImageFilter fails on vtkBillboardTextActor3D2019-12-10T09:42:48-05:00Michael JvtkWindowToImageFilter fails on vtkBillboardTextActor3DThere are some problems when using vtkWindowToImageFilter to save an image of a render window
which contains vtkBillboardTextActor3D objects.
- The text color is only visible in the image if the background opacity of the text is 1. Wit...There are some problems when using vtkWindowToImageFilter to save an image of a render window
which contains vtkBillboardTextActor3D objects.
- The text color is only visible in the image if the background opacity of the text is 1. Without background the text is always white.
- When using a scale > 1, the output of the vtkWindowToImageFilter does not contain any vtkBillboardTextActor3D objects.https://gitlab.kitware.com/vtk/vtk/-/issues/17739Remove exception throwing from VTK2019-11-27T16:12:39-05:00Ben BoeckelRemove exception throwing from VTKVTK is not, generally, very exception safe. There are apparently a number of places we end up throwing our own exceptions. We really probably shouldn't be doing this without using `vtkSmartPointer` or `vtkNew` to handle `vtkObject` lifet...VTK is not, generally, very exception safe. There are apparently a number of places we end up throwing our own exceptions. We really probably shouldn't be doing this without using `vtkSmartPointer` or `vtkNew` to handle `vtkObject` lifetimes ~everywhere.
Cc: @demarle @utkarsh.ayachit @allisonvacantihttps://gitlab.kitware.com/vtk/vtk/-/issues/17735vtkObjExporter uses transparency as opacity.2023-09-27T04:24:13-04:00Maximilian ReimervtkObjExporter uses transparency as opacity.The vtkObjExporter sets `Tr` in the mtl file to the opacity [see](https://gitlab.kitware.com/vtk/vtk/blob/master/IO%2FExport%2FvtkOBJExporter.cxx#L211). This means that meshes are not visible if you set the opacity to 1.
That should be...The vtkObjExporter sets `Tr` in the mtl file to the opacity [see](https://gitlab.kitware.com/vtk/vtk/blob/master/IO%2FExport%2FvtkOBJExporter.cxx#L211). This means that meshes are not visible if you set the opacity to 1.
That should be either `1-opacity` or one should set `d` to opacity. `Tr` means transparency whereas `d` is the opacity. [see](https://en.wikipedia.org/wiki/Wavefront_.obj_file).https://gitlab.kitware.com/vtk/vtk/-/issues/17734FindMPI in VTK fails if project that includes VTK specifies language to be ju...2021-05-15T15:10:05-04:00Keith BallardFindMPI in VTK fails if project that includes VTK specifies language to be just CXXFor context, this issue originally began in CMake: https://gitlab.kitware.com/cmake/cmake/issues/19996 but a second issue relevant to VTK in particular arose, so I opened this to address that part.
Cc: @ben.boeckel
I am trying to build...For context, this issue originally began in CMake: https://gitlab.kitware.com/cmake/cmake/issues/19996 but a second issue relevant to VTK in particular arose, so I opened this to address that part.
Cc: @ben.boeckel
I am trying to build a ParaView plugin against a build of ParaView 5.7 with MPI. My plugin project specifies the language to be CXX and then calls ```find_package(ParaView REQUIRED)```, which then fails in vtk/VTK-vtk-module-find-packages.cmake at
```cmake
find_package(MPI
${_vtk_module_find_package_quiet}
${_vtk_module_find_package_required}
COMPONENTS C
OPTIONAL_COMPONENTS )
```
It fails because ```CMAKE_C_COMPILER_LOADED``` is not set. The issue is:
1) Should ParaView plugins be required to include ```C``` language even if the plugin is really only ```CXX```?
or
2) Should VTK find the C compiler and set ```CMAKE_C_COMPILER_LOADED``` appropriately?
I am new(ish) to VTK, so I am unsure if VTK already addresses this by intending solution #1 above. Any input is appreciated.https://gitlab.kitware.com/vtk/vtk/-/issues/17730Use std::mersenne_twister_engine2019-11-16T08:49:10-05:00Ben BoeckelUse std::mersenne_twister_engineVTK has a copy of a Mersenne twister PRNG in `Common/Core/vtkMersenneTwister_Private.cxx`. Instead, C++11 has [`std::mersenne_twister_engine`](https://en.cppreference.com/w/cpp/numeric/random/mersenne_twister_engine).
Cc: @robertmaynard...VTK has a copy of a Mersenne twister PRNG in `Common/Core/vtkMersenneTwister_Private.cxx`. Instead, C++11 has [`std::mersenne_twister_engine`](https://en.cppreference.com/w/cpp/numeric/random/mersenne_twister_engine).
Cc: @robertmaynard @utkarsh.ayachithttps://gitlab.kitware.com/vtk/vtk/-/issues/17722VTK 8.2.0 vtkIntersectionPolyDataFilter::TriangleTriangleIntersection stack s...2022-09-27T15:17:41-04:00chrisadamsonmcriVTK 8.2.0 vtkIntersectionPolyDataFilter::TriangleTriangleIntersection stack smashing due to numerical errorFollowing on from issue #17012
This triangle pair does not intersect (they look almost coplanar):
```
V = [1.5181 3.23314 -14.2567; ...
1.52291 2.49478 -14.3478; ...
1.48537 3.14193 -13.5191; ...
1.56011 1.85889 -15.1692; ...
1.52772 1...Following on from issue #17012
This triangle pair does not intersect (they look almost coplanar):
```
V = [1.5181 3.23314 -14.2567; ...
1.52291 2.49478 -14.3478; ...
1.48537 3.14193 -13.5191; ...
1.56011 1.85889 -15.1692; ...
1.52772 1.75642 -14.4389; ...
1.52291 2.49478 -14.3478];
F = [1 2 3; 4 5 6];
```
![triangle_intersect](/uploads/709d612319cfcecf215d91e087cd4b72/triangle_intersect.png)
but the code falls into the line-plane intersection tests starting at line 2123 of ./Filters/General/vtkIntersectionPolyDataFilter.cxx.
Using a tolerance of 1e-6, the values within the loop are:
```
val1: 1, t: 0.999997
val2: 1, t: 0.999967 <----
val1: 0, t: -5.96659e-11
val2: 1, t: 0.999999 <----
val1: 1, t: 0.999967
val2: 1, t: 6.01444e-11
```
The t values are close to 1 but don't exceed threshold, the ts2 index is never set and causes a segmentation fault later.
The only triangle pairs I have found that have this problem don't actually intersect. So an easy fix is to edit
line 2157 to be: if (index1 > 2 && ts1 < 50)
line 2162 to be: if (index2 > 2 && ts2 < 50)
Then it will fall through and return 0 (non-intersecting).https://gitlab.kitware.com/vtk/vtk/-/issues/17721Support CMake 3.16 UNITY_BUILD2023-12-17T10:07:05-05:00Julien SchuellerSupport CMake 3.16 UNITY_BUILDI assume VTK built time can be reduced significantly using CMake 3.16 unity build support:
https://cmake.org/cmake/help/latest/prop_tgt/UNITY_BUILD.html
To get to a point where using ```cmake -DCMAKE_UNITY_BUILD=ON``` works we need 2 t...I assume VTK built time can be reduced significantly using CMake 3.16 unity build support:
https://cmake.org/cmake/help/latest/prop_tgt/UNITY_BUILD.html
To get to a point where using ```cmake -DCMAKE_UNITY_BUILD=ON``` works we need 2 things:
- Disable the UNITY_BUILD property of third-party dependencies targets (I tried, the build fails here first)
- Blacklist sources files that should be excluded from unity builds with the source file property SKIP_UNITY_BUILD_INCLUSION (static variables conflict, conflicting headers...)
what do you think @ben.boeckel ?