VTK issueshttps://gitlab.kitware.com/vtk/vtk/-/issues2021-04-12T13:53:59-04:00https://gitlab.kitware.com/vtk/vtk/-/issues/18172VTPC writer cannot write partitioned datasets with no datasets.2021-04-12T13:53:59-04:00Utkarsh AyachitVTPC writer cannot write partitioned datasets with no datasets.* open can.ex2 with Ioss reader, apply.
* save data as VTPC, you'll get errors.
Now check all blocks/sidesets/nodesets etc. on the Ioss reader and repeat...the errors are gone.* open can.ex2 with Ioss reader, apply.
* save data as VTPC, you'll get errors.
Now check all blocks/sidesets/nodesets etc. on the Ioss reader and repeat...the errors are gone.https://gitlab.kitware.com/vtk/vtk/-/issues/18029Progressive passes in scivis raytracing have no effect.2021-04-13T12:07:18-04:00Christos TsolakisProgressive passes in scivis raytracing have no effect.It looks like in current master (d937d82d2e14a2d591972e998ae7a0d608073bcf) if one creates an OSPRay-enabled renderer with MaxFrames > 1 , repeated calls of `Render` have no effect if the `scivis` method is used. The expected behavior is ...It looks like in current master (d937d82d2e14a2d591972e998ae7a0d608073bcf) if one creates an OSPRay-enabled renderer with MaxFrames > 1 , repeated calls of `Render` have no effect if the `scivis` method is used. The expected behavior is to get a higher quality rendering with each call.
To validate use the modified test introduced by this patch [regression.patch](/uploads/6a224657b2853efc91afc3d15e916765/regression.patch). It loads a model and uses two different methods (`pathtracer` and `scivis`) to render it using 5 rendering passes. After each pass a screenshot is captured. The expectation is to have different (as seen by `diff` command) screenshots at each iteration. To run use `./bin/vtkRenderingRayTracingCxxTests "TestOSPRayPass" "-D" "./ExternalData/Testing"`.
Notice the generated images. For `pathtracer` the produced screenshots are different (as expected) while for `scivis` they are all the same.
`git bisect` reveals that the first offending commit is e713782029ca328c124ae6527b2cacccea69d06c.
This also affects ParaView see https://gitlab.kitware.com/paraview/paraview/-/issues/20272
cc: @demarle @utkarsh.ayachithttps://gitlab.kitware.com/vtk/vtk/-/issues/17290ospray path tracer lacks volume rendering2021-04-13T12:13:48-04:00David E. DeMarleospray path tracer lacks volume renderingneeds to be implemented in ospray firstneeds to be implemented in ospray firsthttps://gitlab.kitware.com/vtk/vtk/-/issues/18133Follow-up from "Cmake cmp0115 warnings"2021-04-14T16:07:42-04:00Ben BoeckelFollow-up from "Cmake cmp0115 warnings"The following discussion from !7677 should be addressed:
- [ ] @ben.boeckel started a [discussion](https://gitlab.kitware.com/vtk/vtk/-/merge_requests/7677#note_910695): (+3 comments)
> @vbolea @sujin.philip `TestVTKMImplicitDataA...The following discussion from !7677 should be addressed:
- [ ] @ben.boeckel started a [discussion](https://gitlab.kitware.com/vtk/vtk/-/merge_requests/7677#note_910695): (+3 comments)
> @vbolea @sujin.philip `TestVTKMImplicitDataArray.cxx` hasn't been actually built in a while due to a missed extension in the `CMakeLists.txt` file. It doesn't compile today because it's probably been ignored for so long. Could one of you provide a diff I can add to this MR?Sujin PhilipSujin Philiphttps://gitlab.kitware.com/vtk/vtk/-/issues/18131Follow-up from "Ci macos"2021-04-14T16:10:12-04:00Ben BoeckelFollow-up from "Ci macos"The following discussion from !7613 should be addressed:
- [ ] @ben.boeckel started a [discussion](https://gitlab.kitware.com/vtk/vtk/-/merge_requests/7613#note_906980): (+5 comments)
> @utkarsh.ayachit `TestIossFilePatternMatchin...The following discussion from !7613 should be addressed:
- [ ] @ben.boeckel started a [discussion](https://gitlab.kitware.com/vtk/vtk/-/merge_requests/7613#note_906980): (+5 comments)
> @utkarsh.ayachit `TestIossFilePatternMatching` is using private classes. Thoughts?Utkarsh AyachitUtkarsh Ayachithttps://gitlab.kitware.com/vtk/vtk/-/issues/17852Fix example PATH handling2021-04-14T16:11:53-04:00Ben BoeckelFix example PATH handlingIn the Examples code, `PATH` is set as a test property at configure time. Instead, the `TEST_INCLUDE_FILES` directory property should be used to augment the environment at test time. It looks like this is available in 3.12.
Cc: @tjcoron...In the Examples code, `PATH` is set as a test property at configure time. Instead, the `TEST_INCLUDE_FILES` directory property should be used to augment the environment at test time. It looks like this is available in 3.12.
Cc: @tjcorona @brad.kingBen BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/17483C++14 deprecation macro support2021-04-14T16:12:44-04:00Ben BoeckelC++14 deprecation macro support`VTK_DEPRECATED` is `[[deprecated]]` in C++14 mode. However, this does not mix well with `__attribute__` for export macros. Compiler-specific export attributes may be required. This is best done as a fix to `GenerateExportHeader.cmake` a...`VTK_DEPRECATED` is `[[deprecated]]` in C++14 mode. However, this does not mix well with `__attribute__` for export macros. Compiler-specific export attributes may be required. This is best done as a fix to `GenerateExportHeader.cmake` and upstreamed to CMake (VTK can carry the patch though).
If export macros can't be fixed before 9.0, `[[deprecated]]` should not be used until it is.
Cc: @seanmBen BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/17498Matplotlib test failures2021-04-14T16:17:21-04:00Ben BoeckelMatplotlib test failuresThese tests are failing:
- [`VTK::RenderingMatplotlibCxx-TestRenderString`](https://open.cdash.org/testSummary.php?project=11&name=VTK::RenderingMatplotlibCxx-TestRenderString&date=2019-01-24)
- [`VTK::RenderingMatplotlibCxx-TestGL2...These tests are failing:
- [`VTK::RenderingMatplotlibCxx-TestRenderString`](https://open.cdash.org/testSummary.php?project=11&name=VTK::RenderingMatplotlibCxx-TestRenderString&date=2019-01-24)
- [`VTK::RenderingMatplotlibCxx-TestGL2PSMathTextOutput-VerifyRasterizedPNG`](https://open.cdash.org/testSummary.php?project=11&name=VTK::RenderingMatplotlibCxx-TestGL2PSMathTextOutput-VerifyRasterizedPNG&date=2019-01-24)
on a few machines due to mismatched image sizes. May be related to other tests which are failing due to fonts.
Cc: @allisonvacantiUtkarsh AyachitUtkarsh Ayachithttps://gitlab.kitware.com/vtk/vtk/-/issues/17435Port Python tests to `import vtkmodules`2021-04-14T16:17:50-04:00Ben BoeckelPort Python tests to `import vtkmodules`Currently, if something goes wrong with a single Python module, `import vtk` can fail (usually due to `PATH` missing some external library on Windows). This causes nearly all of VTK's Python tests to fail. Instead, only required modules ...Currently, if something goes wrong with a single Python module, `import vtk` can fail (usually due to `PATH` missing some external library on Windows). This causes nearly all of VTK's Python tests to fail. Instead, only required modules should be imported to isolate them from other failures.
Cc: @utkarsh.ayachithttps://gitlab.kitware.com/vtk/vtk/-/issues/17478Static python failing2021-04-14T16:21:17-04:00Ben BoeckelStatic python failingSomething is blocking the loading of the modules added to the inittab. I have logs that they're there. If the modules are added to the top-level, they work, but if they're in the `vtkmodules` package, they fail. Needs investigation.Something is blocking the loading of the modules added to the inittab. I have logs that they're there. If the modules are added to the top-level, they work, but if they're in the `vtkmodules` package, they fail. Needs investigation.https://gitlab.kitware.com/vtk/vtk/-/issues/18161vtkLagrangeWedge has bad memory write2021-04-22T13:38:36-04:00Andrew BauervtkLagrangeWedge has bad memory writeFor second order vtkLagrangeWedge cell when the complete polynomial basis is enabled there are memory writes to the -1 index of some stl vectors. See https://gitlab.kitware.com/vtk/vtk/-/merge_requests/7789 for a coded up example showcas...For second order vtkLagrangeWedge cell when the complete polynomial basis is enabled there are memory writes to the -1 index of some stl vectors. See https://gitlab.kitware.com/vtk/vtk/-/merge_requests/7789 for a coded up example showcasing that.https://gitlab.kitware.com/vtk/vtk/-/issues/18183vtkXMLStructuredDataWriter fails with WriteToOutputStringOn()2021-04-22T22:02:52-04:00Kitware RobotvtkXMLStructuredDataWriter fails with WriteToOutputStringOn()**This issue was created automatically from an original [Mantis Issue](http://paraview.org/Bug/view.php?id=16090). Further discussion may take place here.**
---
ERROR: In /tmp/vtk20160219-59710-1ih9gsl/VTK-7.0.0/IO/XML/vtkXMLStructured...**This issue was created automatically from an original [Mantis Issue](http://paraview.org/Bug/view.php?id=16090). Further discussion may take place here.**
---
ERROR: In /tmp/vtk20160219-59710-1ih9gsl/VTK-7.0.0/IO/XML/vtkXMLStructuredDataWriter.cxx, line 124
vtkXMLRectilinearGridWriter (0x7fe17b31b390): The FileName or Stream must be set first.
ERROR: In /tmp/vtk20160219-59710-1ih9gsl/VTK-7.0.0/Common/ExecutionModel/vtkExecutive.cxx, line 784
vtkCompositeDataPipeline (0x7fe17b31cc10): Algorithm vtkXMLRectilinearGridWriter(0x7fe17b31b390) returned failure for request: vtkInformation (0x7fe17b31e9f0)
in structuredDataWriter it reads (line 121):
if (!this->Stream && !this->FileName)
{
this->SetErrorCode(vtkErrorCode::NoFileNameError);
vtkErrorMacro("The FileName or Stream must be set first.");
return 0;
}
while in unstructuredDataWriter (line 117):
if(!this->Stream && !this->FileName && !this->WriteToOutputString)
{
this->SetErrorCode(vtkErrorCode::NoFileNameError);
vtkErrorMacro("The FileName or Stream must be set first or "
"the output must be written to a string.");
return 0;
}
Is omitting outputting to a string a deliberate curtailing of the functionality of the structuredWriter??https://gitlab.kitware.com/vtk/vtk/-/issues/18180Access violation in vtkCommonInformationKeyManager::ClassFinalize() on dynami...2021-04-23T12:13:50-04:00MK-3PPAccess violation in vtkCommonInformationKeyManager::ClassFinalize() on dynamic library unloading (at least 8.2.0 and 9.0.1)When VTK is loaded and unloaded dynamically under Windows, there is an Access Violation in `vtkCommonInformationKeyManager::ClassFinalize()`.
Test code below. There might be a more minimalistic way to showcase the problem. I came in fro...When VTK is loaded and unloaded dynamically under Windows, there is an Access Violation in `vtkCommonInformationKeyManager::ClassFinalize()`.
Test code below. There might be a more minimalistic way to showcase the problem. I came in from using the Point Cloud Library (depends on VTK) and circled the problem to loading and unloading `vtkFiltersGeneral-9.0(d).dll`. The Access Violation then triggers in `vtkCommonCore-9.0(d).dll`. Just loading and unloading `vtkCommonCore-9.0(d).dll` does not trigger the Access Violation.
**The issue was initially observed in VTK 8.2 binaries that shipped with PCL. It was then confirmed in own builds of VTK 8.2.0 and VTK 9.0.1.
VTK 8.2.0, VTK 9.0.1 and test program built with VC16.**
This triggers the issue:
```
#include <Windows.h>
int main() {
BOOL setpath = SetDllDirectoryA("$(VTK_PATH)\\bin\\Debug");
HMODULE hMod = LoadLibraryA("vtkFiltersGeneral-9.0d.dll");
if (hMod) {
BOOL freed = FreeLibrary(hMod); // Access Violation.
}
return 0;
}
```
Stack trace:
```
vtkCommonCore-9.0d.dll!vtkCommonInformationKeyManager::ClassFinalize() Zeile 84 C++
vtkCommonCore-9.0d.dll!vtkCommonInformationKeyManager::~vtkCommonInformationKeyManager() Zeile 49 C++
vtkCommonCore-9.0d.dll!`dynamic atexit destructor for 'vtkCommonInformationKeyManagerInstance''() C++
ucrtbased.dll!00007ff97ed85107() Unbekannt
ucrtbased.dll!00007ff97ed84b15() Unbekannt
ucrtbased.dll!00007ff97ed84c4a() Unbekannt
ucrtbased.dll!00007ff97ed852b1() Unbekannt
vtkCommonCore-9.0d.dll!__scrt_dllmain_uninitialize_c() Zeile 399 C++
vtkCommonCore-9.0d.dll!dllmain_crt_process_detach(const bool is_terminating) Zeile 182 C++
vtkCommonCore-9.0d.dll!dllmain_crt_dispatch(HINSTANCE__ * const instance, const unsigned long reason, void * const reserved) Zeile 220 C++
vtkCommonCore-9.0d.dll!dllmain_dispatch(HINSTANCE__ * const instance, const unsigned long reason, void * const reserved) Zeile 293 C++
vtkCommonCore-9.0d.dll!_DllMainCRTStartup(HINSTANCE__ * const instance, const unsigned long reason, void * const reserved) Zeile 335 C++
ntdll.dll!00007ff9d62c5021() Unbekannt
ntdll.dll!00007ff9d630da45() Unbekannt
ntdll.dll!00007ff9d62ced3b() Unbekannt
ntdll.dll!00007ff9d62cef8b() Unbekannt
ntdll.dll!00007ff9d62cf449() Unbekannt
ntdll.dll!00007ff9d62cf3c3() Unbekannt
KernelBase.dll!00007ff9d35e715e() Unbekannt
PCL FreeLibrary.exe!main() Zeile 39 C++
```
Incident site:
![Clipboard01](/uploads/cfecc2052abeb0c1fc570cba75c84d09/Clipboard01.png)
Watch:
```
*i 0x0000021e3875ca60 {Name=0x0000021e38764f10 "LABEL" Location=0x0000021e38765050 "vtkAnnotation" } vtkInformationKey * &
i {0x0000021e3875ca60 {Name=0x0000021e38764f10 "LABEL" Location=0x0000021e38765050 "vtkAnnotation" }} std::_Vector_iterator<std::_Vector_val<std::_Simple_types<vtkInformationKey *>>>
key 0x0000021e3875ca60 {Name=0x0000021e38764f10 "LABEL" Location=0x0000021e38765050 "vtkAnnotation" } vtkInformationKey *
vtkCommonInformationKeyManagerKeys 0x0000021e38730d50 { size=128 } vtkCommonInformationKeyManagerKeysType *
```https://gitlab.kitware.com/vtk/vtk/-/issues/18185Wrappers don't check OPTIONAL_DEPENDS2021-04-26T12:16:03-04:00David GobbiWrappers don't check OPTIONAL_DEPENDSWhen wrapping a module, the wrappers use PRIVATE\_DEPENDS to ascertain which modules contain headers that are used by that module (in addition to the DEPENDS modules, which are included implicitly). Code should be added to vtkModuleWrap...When wrapping a module, the wrappers use PRIVATE\_DEPENDS to ascertain which modules contain headers that are used by that module (in addition to the DEPENDS modules, which are included implicitly). Code should be added to vtkModuleWrapPython.cmake and vtkModuleWrapJava.cmake so that any OPTIONAL\_DEPENDS are also used, for each existing target.
As a work-around, the wrappers are still using the heuristic that classes beginning with "vtk" are derived from vtkObjectBase unless the hierarchy files say otherwise, but this heuristic is not always correct, and when it is wrong the generated method is uncallable.
Note that the circular "dependency" of CommonCore on CommonDataModel is a peculiar situation that the wrappers will have to deal with if the heuristic is removed. The "dependency" exists because vtkInformationDataObjectKey class uses vtkDataObject and the vtkWindow class uses vtkImageData.Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/18186[Python] vtkOBJImporter MTL issue ?2021-04-26T22:07:26-04:00Ali ZAKARIAali.zakaria@outlook.com[Python] vtkOBJImporter MTL issue ?
[bakeGroundCorrected](/uploads/4796796f6d51986d1d4a70705c1d63f8/bakeGroundCorrected.png)
[Ground.obj](/uploads/fbc20858c73768f45e1b9218493f8f30/Ground.obj)
[Ground.mtl](/uploads/f17510c1771f63d828a15b1284c9c88d/Ground.mtl)
```
obj = "G...
[bakeGroundCorrected](/uploads/4796796f6d51986d1d4a70705c1d63f8/bakeGroundCorrected.png)
[Ground.obj](/uploads/fbc20858c73768f45e1b9218493f8f30/Ground.obj)
[Ground.mtl](/uploads/f17510c1771f63d828a15b1284c9c88d/Ground.mtl)
```
obj = "Ground.obj"
mtl = "Ground.mtl"
importer = vtk.vtkOBJImporter()
importer.SetFileName(obj)
importer.SetFileNameMTL(mtl)
importer.SetTexturePath("./")
ren = vtk.vtkRenderer()
renWin = vtk.vtkRenderWindow()
iren = vtk.vtkRenderWindowInteractor()
renWin.AddRenderer(ren)
iren.SetRenderWindow(renWin)
importer.SetRenderWindow(renWin)
importer.Update()
ren.ResetCamera()
ren.GetActiveCamera().SetPosition(10, 10, -10)
ren.ResetCamera()
renWin.SetSize(800, 600)
iren.Start()
```
* VTK
![image](/uploads/9ddf214d04fb1ffd0c2d6251bcaa747f/image.png)
* Meshlab
![image](/uploads/356952e086e7ecb7a72bd33381b9c555/image.png)https://gitlab.kitware.com/vtk/vtk/-/issues/18103openfoam crashes on non-integer dimensions2021-04-27T21:03:12-04:00olesenopenfoam crashes on non-integer dimensionsHad wondered about the code myself, and this [forum posting](https://discourse.paraview.org/t/paraview-crash-when-change-time-step/6351) confirms it: the vtkOpenFOAMReader expects integers for field dimensions.
His input had this:
```
d...Had wondered about the code myself, and this [forum posting](https://discourse.paraview.org/t/paraview-crash-when-change-time-step/6351) confirms it: the vtkOpenFOAMReader expects integers for field dimensions.
His input had this:
```
dimensions [0 0.5 -0.5 0 0 0 0];
```
which causes the crash.
The vtkFoamEntryValue::ReadDimensionSet() method in the vtkOpenFOAMReader needs to accept floats.
In the stringify routine, will need modified logic for checking, possibly with modified exponents.
Eg, writing the above without any brackets
```
m0.5/s0.5
```
looks (IMO) fairly ugly, but with brackets
```
m^(0.5)/s^(0.5)
```
looks pretty messy.
These are however, secondary factors. Mostly need to not crash on these types of dimensions.olesenolesenhttps://gitlab.kitware.com/vtk/vtk/-/issues/18179openfoam reader fails with uncollated lagrangian data2021-04-27T21:03:12-04:00olesenopenfoam reader fails with uncollated lagrangian dataThe reader seems to have been written on the assumption that any lagrangian data are available on _all_ processor sub-directories. It uses a central naming mechanism accordingly. However, OpenFOAM can generate data sets in which lagrangi...The reader seems to have been written on the assumption that any lagrangian data are available on _all_ processor sub-directories. It uses a central naming mechanism accordingly. However, OpenFOAM can generate data sets in which lagrangian data are only available on a subset of processors.
The current logic means that missing lagrangian data will scan as zero clouds (the last result) instead of retaining what had been scanned until that point.olesenolesenhttps://gitlab.kitware.com/vtk/vtk/-/issues/18125openfoam reader ignores point patch values2021-04-27T21:03:13-04:00olesenopenfoam reader ignores point patch values- noticed in this [openfoam issue](https://develop.openfoam.com/Development/openfoam/-/issues/2010)- noticed in this [openfoam issue](https://develop.openfoam.com/Development/openfoam/-/issues/2010)olesenolesenhttps://gitlab.kitware.com/vtk/vtk/-/issues/16061Add support for rendering inside a QML/Qt Quick scene2021-04-27T22:55:09-04:00Kitware RobotAdd support for rendering inside a QML/Qt Quick scene**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=16061). Further discussion may take place here.**
---
Similar to the way VTK provides QVTKWidget for rendering inside a Qt Widgets ap...**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=16061). Further discussion may take place here.**
---
Similar to the way VTK provides QVTKWidget for rendering inside a Qt Widgets application, a class should be provided for rendering inside a Qt Quick application. See minimal proof-of-concept demo of `QVTKFramebufferObjectItem` class here:
https://gist.github.com/nocnokneo/c3fb01bb7ecaf437f7d6https://gitlab.kitware.com/vtk/vtk/-/issues/18094openfoam slow to load data2021-04-28T03:13:22-04:00olesenopenfoam slow to load data[Issue raised on discourse](https://discourse.paraview.org/t/loading-openfoam-decomposed-case-takes-more-than-8-hours/6302)
FYI: @mwestphal and @roland[Issue raised on discourse](https://discourse.paraview.org/t/loading-openfoam-decomposed-case-takes-more-than-8-hours/6302)
FYI: @mwestphal and @rolandolesenolesen