VTK issueshttps://gitlab.kitware.com/vtk/vtk/-/issues2024-02-05T04:43:41-05:00https://gitlab.kitware.com/vtk/vtk/-/issues/19241VTKHDF Assembly links2024-02-05T04:43:41-05:00Juan Jose CasafrancaVTKHDF Assembly linksI have a VTKHDF file with a MultiBlockDataSet assembly, and when I tri to open in Paraview (master branch and master VTK), the file loads fine, but I get several errors in the CLI.
```
HDF5-DIAG: Error detected in HDF5 (1.13.1) thread ...I have a VTKHDF file with a MultiBlockDataSet assembly, and when I tri to open in Paraview (master branch and master VTK), the file loads fine, but I get several errors in the CLI.
```
HDF5-DIAG: Error detected in HDF5 (1.13.1) thread 0:
#000: /home/jjcasmar/seddi/projects/paraview/VTK/ThirdParty/hdf5/vtkhdf5/src/H5Ldeprec.c line 290 in vtkhdf5_H5Literate_by_name1(): link iteration failed
major: Links
minor: Iteration failed
#001: /home/jjcasmar/seddi/projects/paraview/VTK/ThirdParty/hdf5/vtkhdf5/src/H5VLcallback.c line 5340 in vtkhdf5_H5VL_link_specific(): unable to execute link specific callback
major: Virtual Object Layer
minor: Can't operate on object
#002: /home/jjcasmar/seddi/projects/paraview/VTK/ThirdParty/hdf5/vtkhdf5/src/H5VLcallback.c line 5306 in H5VL__link_specific(): unable to execute link specific callback
major: Virtual Object Layer
minor: Can't operate on object
#003: /home/jjcasmar/seddi/projects/paraview/VTK/ThirdParty/hdf5/vtkhdf5/src/H5VLnative_link.c line 384 in vtkhdf5_H5VL__native_link_specific(): error iterating over links
major: Links
minor: Iteration failed
#004: /home/jjcasmar/seddi/projects/paraview/VTK/ThirdParty/hdf5/vtkhdf5/src/H5Lint.c line 2244 in vtkhdf5_H5L_iterate(): link iteration failed
major: Links
minor: Iteration failed
#005: /home/jjcasmar/seddi/projects/paraview/VTK/ThirdParty/hdf5/vtkhdf5/src/H5Gint.c line 923 in vtkhdf5_H5G_iterate(): error iterating over links
major: Symbol table
minor: Iteration failed
#006: /home/jjcasmar/seddi/projects/paraview/VTK/ThirdParty/hdf5/vtkhdf5/src/H5Gobj.c line 669 in vtkhdf5_H5G__obj_iterate(): no creation order index to query
major: Symbol table
minor: Bad value
HDF5-DIAG: Error detected in HDF5 (1.13.1) thread 0:
#000: /home/jjcasmar/seddi/projects/paraview/VTK/ThirdParty/hdf5/vtkhdf5/src/H5Ldeprec.c line 290 in vtkhdf5_H5Literate_by_name1(): link iteration failed
major: Links
minor: Iteration failed
#001: /home/jjcasmar/seddi/projects/paraview/VTK/ThirdParty/hdf5/vtkhdf5/src/H5VLcallback.c line 5340 in vtkhdf5_H5VL_link_specific(): unable to execute link specific callback
major: Virtual Object Layer
minor: Can't operate on object
#002: /home/jjcasmar/seddi/projects/paraview/VTK/ThirdParty/hdf5/vtkhdf5/src/H5VLcallback.c line 5306 in H5VL__link_specific(): unable to execute link specific callback
major: Virtual Object Layer
minor: Can't operate on object
#003: /home/jjcasmar/seddi/projects/paraview/VTK/ThirdParty/hdf5/vtkhdf5/src/H5VLnative_link.c line 384 in vtkhdf5_H5VL__native_link_specific(): error iterating over links
major: Links
minor: Iteration failed
#004: /home/jjcasmar/seddi/projects/paraview/VTK/ThirdParty/hdf5/vtkhdf5/src/H5Lint.c line 2244 in vtkhdf5_H5L_iterate(): link iteration failed
major: Links
minor: Iteration failed
#005: /home/jjcasmar/seddi/projects/paraview/VTK/ThirdParty/hdf5/vtkhdf5/src/H5Gint.c line 923 in vtkhdf5_H5G_iterate(): error iterating over links
major: Symbol table
minor: Iteration failed
#006: /home/jjcasmar/seddi/projects/paraview/VTK/ThirdParty/hdf5/vtkhdf5/src/H5Gobj.c line 669 in vtkhdf5_H5G__obj_iterate(): no creation order index to query
major: Symbol table
minor: Bad value
```
I have added the order creation property when writing the files, but still.
This is the file[test.vtkhdf](/uploads/b9e9453385ae467c2ba1f1d6106c6956/test.vtkhdf)https://gitlab.kitware.com/vtk/vtk/-/issues/19239Off-axis projection broken with OSPRay and ANARI2024-03-04T16:24:40-05:00Scott WittenburgOff-axis projection broken with OSPRay and ANARINeither the OSPRay nor ANARI rendering backends seem to take into account the off-axis projection flag or the eye position when doing off-axis projection. Without that, neither of those rendering backends will work in a CAVE environment...Neither the OSPRay nor ANARI rendering backends seem to take into account the off-axis projection flag or the eye position when doing off-axis projection. Without that, neither of those rendering backends will work in a CAVE environment.
While I was working on !10837, @thomas.galland noticed that fixing the stereo image separation didn't break two other tests that enable off-axis projection, using:
```
camera->SetUseOffAxisProjection(1);
camera->SetEyePosition(eyePosition);
```
The two tests are:
```
/data/scott/projects/VTK/vtkSrc/Rendering/ANARI/Testing/Cxx/TestAnariStereo.cxx
/data/scott/projects/VTK/vtkSrc/Rendering/RayTracing/Testing/Cxx/TestOSPRayStereo.cxx
```
Both of these tests enable off-axis projection and set the eye position, but neither of the camera node classes ([here](https://gitlab.kitware.com/vtk/vtk/-/blob/master/Rendering/RayTracing/vtkOSPRayCameraNode.cxx) and [here](https://gitlab.kitware.com/vtk/vtk/-/blob/master/Rendering/ANARI/vtkAnariCameraNode.cxx)) do anything with those values.
It's not clear to me yet exactly what is required to fix this. Looking around the interwebz, I found this tech [report](https://arxiv.org/pdf/2311.05887.pdf) from Nov 2023 entitled "A Practical Guide to Implementing Off-Axis Stereo Projection Using Existing Ray Tracing Libraries". Is it possible we need to implement one of those strategies to get VTK off-axis projection working correctly with OSPRay and ANARI?https://gitlab.kitware.com/vtk/vtk/-/issues/19238VTKHDF file format: cell type in PolyData should be optional2024-02-05T06:05:13-05:00Lucas GivordVTKHDF file format: cell type in PolyData should be optional## Context
Currently, if someone define a PolyData in a VTKHDF file, even if the polydata will contain only polygon, this file needs to add the structure for each other cell types.
In this [example](/uploads/be4a47a96aea5d024bd790c33...## Context
Currently, if someone define a PolyData in a VTKHDF file, even if the polydata will contain only polygon, this file needs to add the structure for each other cell types.
In this [example](/uploads/be4a47a96aea5d024bd790c33d23663e/HDFWriter_cow.vtp.vtkhdf) the dataset should have only polygon but needs to define `Lines`, `Vertices` etc...
![image](/uploads/26b423439c206d877cacfd0bbc069c0f/image.png)
## Solution
We may want to update the VTKHDF file format to make these groups optional.
Note that this change can have some impact for the Transient data file format as we do some assumption when we compute the cell offset.
cc @mwestphal @jjcasmar @danlipsa @charles.gueunethttps://gitlab.kitware.com/vtk/vtk/-/issues/19237VTKHDF file format: spec for UnstructuredGrid doesn't specify which cells are...2024-02-05T06:05:13-05:00Lucas GivordVTKHDF file format: spec for UnstructuredGrid doesn't specify which cells are supported or notCurrent VTKHDF file format doesn't list suppported/unsupported vtk cell types in the spec : https://docs.vtk.org/en/latest/design_documents/VTKFileFormats.html#unstructured-grid
cc @mwestphal @charles.gueunetCurrent VTKHDF file format doesn't list suppported/unsupported vtk cell types in the spec : https://docs.vtk.org/en/latest/design_documents/VTKFileFormats.html#unstructured-grid
cc @mwestphal @charles.gueunetLucas GivordLucas Givordhttps://gitlab.kitware.com/vtk/vtk/-/issues/19234MSAA does not have any effect on semi-transparent actors2024-02-09T13:54:01-05:00baker-XieMSAA does not have any effect on semi-transparent actorsProblem description:
It seems MSAA does not have effect on semi-transparent actors, here is the minimal example
https://github.com/baker-Xie/vtk_msaa_bug
Reproduce step:
1. create 2 cube in the scene, each cube with a actor
2. cube1's...Problem description:
It seems MSAA does not have effect on semi-transparent actors, here is the minimal example
https://github.com/baker-Xie/vtk_msaa_bug
Reproduce step:
1. create 2 cube in the scene, each cube with a actor
2. cube1's opacity = 1, cube2's opacity = 0.5 (or other value < 1)
3. render
Result:
![image](/uploads/f73e29b7b646ce71a7388d4131d037e2/image.png)https://gitlab.kitware.com/vtk/vtk/-/issues/192329.3.0 fails to compile: error: incompatible function pointer types passing 'h...2024-03-22T08:39:33-04:00yurivict9.3.0 fails to compile: error: incompatible function pointer types passing 'herr_t (hid_t, const char *, const H5L_info2_t *, void *)' (aka 'int (long, const char *, const H5L_info2_t *, void *)') to parameter of type 'H5L_iterate1_t' (aka 'int (*)(long,```
/usr/ports/math/vtk9/work/VTK-9.3.0/ThirdParty/cgns/vtkcgns/src/adfh/ADFH.c:1127:34: warning: incompatible pointer types passing 'H5L_info2_t *' to parameter of type 'H5L_info1_t *' [-Wincompatible-pointer-types]
herr = H5Lget_info...```
/usr/ports/math/vtk9/work/VTK-9.3.0/ThirdParty/cgns/vtkcgns/src/adfh/ADFH.c:1127:34: warning: incompatible pointer types passing 'H5L_info2_t *' to parameter of type 'H5L_info1_t *' [-Wincompatible-pointer-types]
herr = H5Lget_info(id, D_LINK, &sb, H5P_DEFAULT);
^~~
/usr/local/include/H5Lpublic.h:1703:73: note: passing argument to parameter 'linfo' here
H5_DLL herr_t H5Lget_info1(hid_t loc_id, const char *name, H5L_info1_t *linfo /*out*/, hid_t lapl_id);
^
/usr/ports/math/vtk9/work/VTK-9.3.0/ThirdParty/cgns/vtkcgns/src/adfh/ADFH.c:1287:92: error: incompatible function pointer types passing 'herr_t (hid_t, const char *, const H5L_info2_t *, void *)' (aka 'int (long, const char *, const H5L_info2_t *, void *)') to parameter of type 'H5L_iterate1_t' (aka 'int (*)(long, const char *, const H5L_info1_t *, void *)') [-Wincompatible-function-pointer-types]
if (! is_link(id)) H5Literate_by_name(id, name, H5_INDEX_CRT_ORDER, H5_ITER_INC, NULL, delete_children, data, H5P_DEFAULT);
^~~~~~~~~~~~~~~
/usr/local/include/H5Lpublic.h:1908:87: note: passing argument to parameter 'op' here
H5_iter_order_t order, hsize_t *idx, H5L_iterate1_t op, void *op_data,
^
/usr/ports/math/vtk9/work/VTK-9.3.0/ThirdParty/cgns/vtkcgns/src/adfh/ADFH.c:1447:63: error: incompatible function pointer types passing 'herr_t (hid_t, const char *, const H5L_info2_t *, void *)' (aka 'int (long, const char *, const H5L_info2_t *, void *)') to parameter of type 'H5L_iterate1_t' (aka 'int (*)(long, const char *, const H5L_info1_t *, void *)') [-Wincompatible-function-pointer-types]
H5Literate(gid, H5_INDEX_CRT_ORDER, H5_ITER_NATIVE, NULL, fix_dimensions, NULL);
^~~~~~~~~~~~~~
/usr/local/include/H5Lpublic.h:1835:42: note: passing argument to parameter 'op' here
H5L_iterate1_t op, void *op_data);
^
/usr/ports/math/vtk9/work/VTK-9.3.0/ThirdParty/cgns/vtkcgns/src/adfh/ADFH.c:1542:65: error: incompatible function pointer types passing 'herr_t (hid_t, const char *, const H5L_info2_t *, void *)' (aka 'int (long, const char *, const H5L_info2_t *, void *)') to parameter of type 'H5L_iterate1_t' (aka 'int (*)(long, const char *, const H5L_info1_t *, void *)') [-Wincompatible-function-pointer-types]
!H5Literate(hpid, H5_INDEX_CRT_ORDER, H5_ITER_NATIVE, NULL, compare_children, (void *)&stat)) {
^~~~~~~~~~~~~~~~
/usr/local/include/H5Lpublic.h:1835:42: note: passing argument to parameter 'op' here
H5L_iterate1_t op, void *op_data);
```
Version: 9.3.0
clang-16
FreeBSD 14.0https://gitlab.kitware.com/vtk/vtk/-/issues/19231VTKHDFWriter not compatible with concurrent writing using MPI2024-01-19T06:01:51-05:00Louis GombertVTKHDFWriter not compatible with concurrent writing using MPIWhen the VTKHDF Writer is called by several processes at the same time in an MPI setting, only the first process can write to the file, and the others raise an error.
Concurrent writing is supposed to work natively in HDF5. We should at...When the VTKHDF Writer is called by several processes at the same time in an MPI setting, only the first process can write to the file, and the others raise an error.
Concurrent writing is supposed to work natively in HDF5. We should at least make sure that the writer is aware of MPI and that concurrent writing does not raise HDF5 errors, and then distribute the data evenly between processes for partitioned data.https://gitlab.kitware.com/vtk/vtk/-/issues/19230GhostCellsGenerator slowdown and error for fields that are float2024-01-23T11:01:21-05:00Caitlin RossGhostCellsGenerator slowdown and error for fields that are floatPrior to !10830, we were using GhostCellsGenerator in vtkFidesReader, it's being removed but there are some issues we found that should probably be looked into.
1. It caused a large slowdown on unstructured data. I don't have the exact ...Prior to !10830, we were using GhostCellsGenerator in vtkFidesReader, it's being removed but there are some issues we found that should probably be looked into.
1. It caused a large slowdown on unstructured data. I don't have the exact timing breakdown for large scale data, but the vtkFidesReader was taking 30 minutes to load data. When they used ADIOS directly to read the file, it only takes about 15 seconds to read the full file. I was given a much smaller version of the dataset that still showed the issue and executing the GhostCellsGenerator caused about a 5x slowdown. @berkgeveci says the slowdown is more than should be expected and should be investigated.
2. There was an issue with fields that are `float`. Two datasets were generated where the only change is the type of a field. If it's `double`, there was no issue, but with `float`, we'd get the following error:
```
vtkGenericDataArray.txx:564 ERR| . 23vtkAOSDataArrayTemplateIfE (0x291a11390): Source array too small, requested tuple at index 14929, but there are only 14645 tuples in the array.
```
I pulled it up in a debugger and here is the backtrace to it, but I don't know much about this filter so I haven't looked any deeper than this:
```
#0 vtkGenericDataArray<vtkAOSDataArrayTemplate<float>, float>::InsertTuples(vtkIdList*, vtkIdList*, vtkAbstractArray*)
(this=0x5555b01b1f10, dstIds=0x5555ba623cd0, srcIds=0x5555bec9c6f0, source=0x5555f7bf9a30)
at /home/local/KHQ/caitlin.ross/dev/paraview/master/VTK/Common/Core/vtkGenericDataArray.txx:562
#1 0x00007fffee5f54da in vtkAOSDataArrayTemplate<float>::InsertTuples(vtkIdList*, vtkIdList*, vtkAbstractArray*)
(this=0x5555b01b1f10, dstIds=0x5555ba623cd0, srcIds=0x5555bec9c6f0, source=0x5555f7bf9a30)
at /home/local/KHQ/caitlin.ross/dev/paraview/master/VTK/Common/Core/vtkAOSDataArrayTemplate.h:254
#2 0x00007fff640debdd in (anonymous namespace)::FillReceivedGhostFieldData(vtkFieldData*, vtkFieldData*, vtkIdList*, vtkIdList*) (sourceFD=0x5555c56a54c0, destFD=0x5555b01b5920, sourceIds=0x5555bec9c6f0, destIds=0x5555ba623cd0)
at /home/local/KHQ/caitlin.ross/dev/paraview/master/VTK/Parallel/DIY/vtkDIYGhostUtilities.cxx:5114
#3 0x00007fff640eb2ef in (anonymous namespace)::FillReceivedPointBuffersForUnstructuredData<vtkUnstructuredGrid>(vtkDIYGhostUtilities::DataSetTypeToBlockTypeConverter<vtkUnstructuredGrid>::BlockType*, int, int, vtkUnstructuredGrid*)
(block=0x555596aeed00, myGid=2, gid=1, output=0x5555b019bcd0)
at /home/local/KHQ/caitlin.ross/dev/paraview/master/VTK/Parallel/DIY/vtkDIYGhostUtilities.cxx:5420
#4 0x00007fff640df5e9 in (anonymous namespace)::FillReceivedGhosts((anonymous namespace)::UnstructuredGridBlock*, int, int, vtkUnstructuredGrid*, int) (block=0x555596aeed00, myGid=2, gid=1, output=0x5555b019bcd0, outputGhostLevels=0)
at /home/local/KHQ/caitlin.ross/dev/paraview/master/VTK/Parallel/DIY/vtkDIYGhostUtilities.cxx:5436
#5 0x00007fff640f5992 in (anonymous namespace)::FillReceivedGhosts<vtkUnstructuredGrid>(vtkdiy2::Master const&, std::vector<vtkUnstructuredGrid*, std::allocator<vtkUnstructuredGrid*> >&, int) (master=..., outputs=..., outputGhostLevels=0)
at /home/local/KHQ/caitlin.ross/dev/paraview/master/VTK/Parallel/DIY/vtkDIYGhostUtilities.cxx:5601
#6 0x00007fff640e581b in vtkDIYGhostUtilities::FillGhostArrays(vtkdiy2::Master const&, std::vector<vtkUnstructuredGrid*, std::allocator<vtkUnstructuredGrid*> >&, int) (master=..., outputs=..., outputGhostLevels=0)
at /home/local/KHQ/caitlin.ross/dev/paraview/master/VTK/Parallel/DIY/vtkDIYGhostUtilities.cxx:6689
#7 0x00007fff64146cc6 in vtkDIYGhostUtilities::GenerateGhostCells<vtkUnstructuredGrid>(std::vector<vtkUnstructuredGrid*, std::allocator<vtkUnstructuredGrid*> >&, std::vector<vtkUnstructuredGrid*, std::allocator<vtkUnstructuredGrid*> >&, int, vtkMultiProcessController*) (inputs=..., outputs=..., outputGhostLevels=0, controller=0x5555901d1ac0)
at /home/local/KHQ/caitlin.ross/dev/paraview/master/VTK/Parallel/DIY/vtkDIYGhostUtilities.txx:717
#8 0x00007fff640e5950 in vtkDIYGhostUtilities::GenerateGhostCellsUnstructuredGrid(std::vector<vtkUnstructuredGrid*, std::allocator<vtkUnstructuredGrid*> >&, std::vector<vtkUnstructuredGrid*, std::allocator<vtkUnstructuredGrid*> >&, int, vtkMultiProcessController*) (inputs=..., outputs=..., outputGhostLevels=0, controller=0x5555901d1ac0)
at /home/local/KHQ/caitlin.ross/dev/paraview/master/VTK/Parallel/DIY/vtkDIYGhostUtilities.cxx:6736
#9 0x00007fff65d29cde in vtkGhostCellsGenerator::RequestData(vtkInformation*, vtkInformationVector**, vtkInformationVector*)
(this=0x555594604960, inputVector=0x5555b01b5090, outputVector=0x5555b01af650)
at /home/local/KHQ/caitlin.ross/dev/paraview/master/VTK/Filters/ParallelDIY2/vtkGhostCellsGenerator.cxx:234
```https://gitlab.kitware.com/vtk/vtk/-/issues/19229vtkTesting.interact doesn't work with vtkpython.2024-01-17T10:18:29-05:00Jaswant Panchumarti (Kitware)vtkTesting.interact doesn't work with vtkpython.When running a VTK python test interactively, some tests call vtkTesting.interact(), which prints a message to the console
```
Press Enter/Return to continue with the testing. -->
```
Nothing happens after pressing Enter.
I've found t...When running a VTK python test interactively, some tests call vtkTesting.interact(), which prints a message to the console
```
Press Enter/Return to continue with the testing. -->
```
Nothing happens after pressing Enter.
I've found this smaller example to show the inconsistency of `input` with `vtkpython` vs `python`. See how `vtkpython` doesn't recognize that `Enter` was pressed. I had to Ctrl+C my way out.
```sh
9:58:53 $ cat test.py
input("Press Enter/Return")
print("Enter/Return was pressed")
9:58:57 $ ./bin/vtkpython test.py
Press Enter/Return
^C
9:59:08 $ python3 test.py
Press Enter/Return
Enter/Return was pressed
```https://gitlab.kitware.com/vtk/vtk/-/issues/19227vtkTriangle 'dead code' not dead when give NaNs2024-01-17T09:28:39-05:00NathanaelJvtkTriangle 'dead code' not dead when give NaNs[See discussion here](https://discourse.vtk.org/t/vtktriangle-fails-with-assertion-arrived-in-a-branch-thought-to-be-dead-when-called-from-findclosestpoint/13066?u=nathanaelj)
vtkTriangle returns an assertion about dead code when it is ...[See discussion here](https://discourse.vtk.org/t/vtktriangle-fails-with-assertion-arrived-in-a-branch-thought-to-be-dead-when-called-from-findclosestpoint/13066?u=nathanaelj)
vtkTriangle returns an assertion about dead code when it is given NaN inputs. This was identified when NaNs were input to the 'FindClosestpoint' function in a cell locator object.
The assertion is found in line 306 of vtkTriangles.cxx
I've been asked to create an issue to ensure that a test can be added for this case too.https://gitlab.kitware.com/vtk/vtk/-/issues/19223vtkClipPolyData incorrectly work2024-01-15T02:24:39-05:00zhang-qiang-githubvtkClipPolyData incorrectly workI am using vtkClipPolyData to cut a mesh, but it give a incorrect result.
The code is:
```
import vtkmodules.all as vtk
import numpy as np
def CreateActor(ply: vtk.vtkPolyData, color=[1, 0, 0]):
mapper = vtk.vtkPolyDataMapper()
...I am using vtkClipPolyData to cut a mesh, but it give a incorrect result.
The code is:
```
import vtkmodules.all as vtk
import numpy as np
def CreateActor(ply: vtk.vtkPolyData, color=[1, 0, 0]):
mapper = vtk.vtkPolyDataMapper()
mapper.SetInputData(ply)
mapper.ScalarVisibilityOff()
actor = vtk.vtkActor()
actor.SetMapper(mapper)
actor.GetProperty().SetColor(color[0], color[1], color[2])
actor.GetProperty().SetOpacity(0.3)
return actor
def CutMesh(ply: vtk.vtkPolyData):
plyClone = vtk.vtkPolyData()
plyClone.DeepCopy(ply)
centers = np.array([
[25.54791, 131.9023, 570.03764],
[46.95663, 83.99182, 511.02341],
[58.50379, 42.54272, 577.24325],
[37.09508, 90.45326, 636.25748],
])
############################################################################
########## after remove the minus sign, this function output a wrong cut result
normals = -np.array([ # NOTE THE MINUS SIGN
[0.34503, -0.93555, 0.07544],
[-0.07840, 0.05137, 0.99560],
[-0.34503, 0.93555, -0.07544],
[0.07840, -0.05137, -0.99560],
])
############################################################################
vpoints = vtk.vtkPoints()
for i in range(4):
vpoints.InsertNextPoint(centers[i])
vectors = vtk.vtkFloatArray()
vectors.SetNumberOfComponents(3)
for n in normals:
vectors.InsertNextTuple3(n[0], n[1], n[2])
planes = vtk.vtkPlanes()
planes.SetPoints(vpoints)
planes.SetNormals(vectors)
clipper = vtk.vtkClipPolyData()
clipper.SetInputData(plyClone)
clipper.SetClipFunction(planes)
clipper.GenerateClippedOutputOff()
clipper.GenerateClipScalarsOff()
clipper.SetValue(0)
clipper.Update()
newply = clipper.GetOutput()
return CreateActor(newply, [0, 1, 0])
reader = vtk.vtkOBJReader()
reader.SetFileName('before.obj')
reader.Update()
oriMesh = CreateActor(reader.GetOutput(), [1, 0, 0])
newMesh = CutMesh(reader.GetOutput())
renderer = vtk.vtkRenderer()
renderer.AddActor(oriMesh)
renderer.AddActor(newMesh)
renderer.SetBackground(1, 1, 1)
renWin = vtk.vtkRenderWindow()
renWin.AddRenderer(renderer)
iren = vtk.vtkRenderWindowInteractor()
iren.SetRenderWindow(renWin)
iren.SetInteractorStyle(vtk.vtkInteractorStyleTrackballCamera())
iren.Initialize()
iren.Start()
```
The data is: https://github.com/zhang-qiang-github/data/blob/main/before.obj
The result is correct:
![image](/uploads/8c9875c107949f040a706f4021ceb4a2/image.png)
Fig. 1
The whole mesh is the original mesh. The yellow mesh is the cutted result.
However, if I remove the minu sign for normals, for example:
```
############################################################################
########## after remove the minus sign, this function output a wrong cutted result
normals = np.array([ # NOTE THE MINUS SIGN
[0.34503, -0.93555, 0.07544],
[-0.07840, 0.05137, 0.99560],
[-0.34503, 0.93555, -0.07544],
[0.07840, -0.05137, -0.99560],
])
############################################################################
```
In my opinion, the cutted part should be the red part in Fig. 1. However, the result is:
![image](/uploads/f407969dba06dc69be72d5e25b096a04/image.png)
The environment is:
```
win 10
python 3.9.12
vtk 9.2.6
```
The `discourse.vtk.org` website is: https://discourse.vtk.org/t/vtkclippolydata-incorrectly-work/13046
Any suggestion is appreciated~~~https://gitlab.kitware.com/vtk/vtk/-/issues/19221Disabled tests since image comparison method update2024-03-15T10:08:49-04:00Yohann Bearzi (Kitware)Disabled tests since image comparison method updateBelow is a list of disabled tests until we decide what to do with them. We can either:
* Fix the problem if there is one
* Replace a baseline if the new behavior is better
* Add a baseline if the result is good enough
Format: test imag...Below is a list of disabled tests until we decide what to do with them. We can either:
* Fix the problem if there is one
* Replace a baseline if the new behavior is better
* Add a baseline if the result is good enough
Format: test image - baseline
- [ ] FiltersCorePython-glyphComb
![glyphComb.png](/uploads/ea0ca583b65d191151062a5e3f2a8516/glyphComb.png) ![image](/uploads/db0b66aca26705ad2bd1f68cd24e68d5/image.png)
* [ ] FiltersCorePython-TestSynchronizedTemplate2D
![TestImage](https://open.cdash.org/image/828245) ![TestSynchronizedTemplates2D.png](/uploads/c61c075d25c5be7584ab28a3defb31f8/TestSynchronizedTemplates2D.png)
* [ ] RenderingOpenGL2Cxx-TestCompositePolyDataMapper2ScalarOpacity
* [ ] RenderingOpenGL2Cxx-TestCompositePolyDataMapperScalarOpacity
![TestImage](https://open.cdash.org/image/845065) ![TestCompositePolyDataMapper2ScalarsSurfaceOpacity.png](/uploads/b8a3d5ad043809aae4c679ad0883cf62/TestCompositePolyDataMapper2ScalarsSurfaceOpacity.png)
* [ ] GUISupportQtCxx-TestQVTKRenderWidgetWithDisabledInteractor (Windows)
* [ ] GUISupportQtCxx-TestQVTKOpenGLWidgetWithDisabledInteractor
* [ ] GUISupportQtCxx-TestQVTKOpenGLNativeWidgetWithDisabledInteractor
![TestImage](https://open.cdash.org/image/845888) ![TestQVTKOpenGLWindowWithDisabledInteractor.png](/uploads/ac506823dba7667a15a1937c8d9e0d84/TestQVTKOpenGLWindowWithDisabledInteractor.png)
* [ ] FiltersHyperTreeCxx-TestHyperTreeGridTernary3DGeometryLargeMaterialBits
![TestImage](https://open.cdash.org/image/845350) ![TestHyperTreeGridTernary3DGeometryLargeMaterialBits.png](/uploads/068c07f6d905da92ba74e6c6b870573e/TestHyperTreeGridTernary3DGeometryLargeMaterialBits.png)
* [ ] RenderingRayTracingCxx-TestSmartVolumeMapper
* [ ] RenderingRayTracingCxx-TestOSPRayVolumeMapper
* [ ] RenderingRayTracingCxx-TestOSPRayVolumeRenderer
![image.png](/uploads/38e9f37a30cde25a125d6ee86d3a66db/image.png) ![foo.png](/uploads/c5a9b39d822915bb07c4e17812b3913a/foo.png)
* [ ] RenderingRayTracingCxx-TestOSPRayAMRVolumeRenderer
![image.png](/uploads/ed834d5e745d03bcf8688389029be2ee/image.png) ![foo.png](/uploads/ed2548707e2c60f00ba69b938f6db6e4/foo.png)
* [ ] Â FiltersFlowPathsCxx-TestStreamTracerSurface
![TestImage](https://open.cdash.org/image/857219) ![image.png](/uploads/877cd6788a4a62a6eece72413d5896ed/image.png)
* [ ] RenderingRayTracingCxx-TestOSPRayMultiBlockPartialArrayFieldData
![TestImage](https://open.cdash.org/image/856655) ![foo.png](/uploads/5a497d51ac90fda5f38bcb98676bd903/foo.png)
* [ ] FiltersSourcesPython-TestEllipseArcSourceResolution
![image.png](/uploads/6d6186ca6c50ffb08e759dbd5ebcf972/image.png) ![TestEllipseArcSourceResolution.png](/uploads/bf19450825ab83a444b838a49264b0e5/TestEllipseArcSourceResolution.png)https://gitlab.kitware.com/vtk/vtk/-/issues/19218TestProbeLineFilter occasionally fail on HTG with SMP enabled2024-01-11T03:47:27-05:00Mathieu Westphal (Kitware)TestProbeLineFilter occasionally fail on HTG with SMP enabledTestProbeLineFilter occasionally fail with SMP enabled
- Build VTK with SMP enabled (in my case TBB), Testing and FilterParallelDIY2 enabled
- `ctest -R TestProbeLineFilter --repeat-until-fail 100`
- Fail after a few tries with
```...TestProbeLineFilter occasionally fail with SMP enabled
- Build VTK with SMP enabled (in my case TBB), Testing and FilterParallelDIY2 enabled
- `ctest -R TestProbeLineFilter --repeat-until-fail 100`
- Fail after a few tries with
```
832: Test command: /usr/bin/mpiexec "-n" "2" "/home/glow/dev/vtk/vtk1/build/bin/vtkFiltersParallelDIY2CxxTests-MPI" "TestProbeLineFilter" "-D" "/home/glow/dev/vtk/vtk1/build/ExternalData/Testing" "-T" "/home/glow/dev/vtk/vtk1/build/Testing/Temporary"
832: Working Directory: /home/glow/dev/vtk/vtk1/build/Filters/ParallelDIY2/Testing/Cxx
832: Environment variables:
832: VTK_TESTING
832: Test timeout computed to be: 1500
832: ( 0.044s) [main thread ]TestProbeLineFilter.cxx:276 INFO| Testing vtkProbeLineFilter with 2D data input (cut wavelet)
832: ( 0.044s) [main thread ]TestProbeLineFilter.cxx:276 INFO| Testing vtkProbeLineFilter with 2D data input (cut wavelet)
832: ( 0.055s) [main thread ]TestProbeLineFilter.cxx:340 INFO| Testing vtkProbeLineFilter with polydata output
832: ( 0.055s) [main thread ]TestProbeLineFilter.cxx:340 INFO| Testing vtkProbeLineFilter with polydata output
832: ( 0.067s) [main thread ]TestProbeLineFilter.cxx:362 INFO| Testing vtkProbeLineFilter with multiblock output
832: ( 0.068s) [main thread ]TestProbeLineFilter.cxx:362 INFO| Testing vtkProbeLineFilter with multiblock output
832: ( 0.081s) [main thread ]TestProbeLineFilter.cxx:462 INFO| Testing vtkProbeLineFilter with 2D HyperTreeGrid input
832: ( 0.082s) [main thread ]TestProbeLineFilter.cxx:462 INFO| Testing vtkProbeLineFilter with 2D HyperTreeGrid input
832: ( 0.092s) [main thread ]TestProbeLineFilter.cxx:504 INFO| Testing vtkProbeLineFilter with 3D HyperTreeGrid input
832: ( 0.093s) [main thread ]TestProbeLineFilter.cxx:504 INFO| Testing vtkProbeLineFilter with 3D HyperTreeGrid input
Test #832: VTK::FiltersParallelDIY2Cxx-MPI-TestProbeLineFilter ... Passed 0.24 sec
Start 832: VTK::FiltersParallelDIY2Cxx-MPI-TestProbeLineFilter
832: Test command: /usr/bin/mpiexec "-n" "2" "/home/glow/dev/vtk/vtk1/build/bin/vtkFiltersParallelDIY2CxxTests-MPI" "TestProbeLineFilter" "-D" "/home/glow/dev/vtk/vtk1/build/ExternalData/Testing" "-T" "/home/glow/dev/vtk/vtk1/build/Testing/Temporary"
832: Working Directory: /home/glow/dev/vtk/vtk1/build/Filters/ParallelDIY2/Testing/Cxx
832: Environment variables:
832: VTK_TESTING
832: Test timeout computed to be: 1500
832: ( 0.044s) [main thread ]TestProbeLineFilter.cxx:276 INFO| Testing vtkProbeLineFilter with 2D data input (cut wavelet)
832: ( 0.044s) [main thread ]TestProbeLineFilter.cxx:276 INFO| Testing vtkProbeLineFilter with 2D data input (cut wavelet)
832: ( 0.053s) [main thread ]TestProbeLineFilter.cxx:340 INFO| Testing vtkProbeLineFilter with polydata output
832: ( 0.054s) [main thread ]TestProbeLineFilter.cxx:340 INFO| Testing vtkProbeLineFilter with polydata output
832: ( 0.067s) [main thread ]TestProbeLineFilter.cxx:362 INFO| Testing vtkProbeLineFilter with multiblock output
832: ( 0.067s) [main thread ]TestProbeLineFilter.cxx:362 INFO| Testing vtkProbeLineFilter with multiblock output
832: ( 0.081s) [main thread ]TestProbeLineFilter.cxx:462 INFO| Testing vtkProbeLineFilter with 2D HyperTreeGrid input
832: ( 0.082s) [main thread ]TestProbeLineFilter.cxx:462 INFO| Testing vtkProbeLineFilter with 2D HyperTreeGrid input
832: ( 0.086s) [main thread ]TestProbeLineFilter.cxx:157 ERR| Probe Line on HTG 2D failed for point 0.0625, 0.0625 with depth nan when it should be 2
832: ( 0.092s) [main thread ]TestProbeLineFilter.cxx:504 INFO| Testing vtkProbeLineFilter with 3D HyperTreeGrid input
832: ( 0.092s) [main thread ]TestProbeLineFilter.cxx:504 INFO| Testing vtkProbeLineFilter with 3D HyperTreeGrid input
832: --------------------------------------------------------------------------
832: Primary job terminated normally, but 1 process returned
832: a non-zero exit code. Per user-direction, the job has been aborted.
832: --------------------------------------------------------------------------
832: --------------------------------------------------------------------------
832: mpiexec detected that one or more processes exited with non-zero status, thus causing
832: the job to be terminated. The first process to do so was:
832:
832: Process name: [[55031,1],0]
832: Exit code: 1
832: --------------------------------------------------------------------------
Test #832: VTK::FiltersParallelDIY2Cxx-MPI-TestProbeLineFilter ...***Failed Error regular expression found in output. Regex=[ERR\|] 2.26 sec
0% tests passed, 1 tests failed out of 1
Label Time Summary:
VTK::FiltersParallelDIY2 = 4.51 sec*proc (1 test)
vtkFiltersParallelDIY2 = 4.51 sec*proc (1 test)
Total Test time (real) = 3.32 sec
The following tests FAILED:
832 - VTK::FiltersParallelDIY2Cxx-MPI-TestProbeLineFilter (Failed)
Errors while running CTest
```https://gitlab.kitware.com/vtk/vtk/-/issues/19217Add `vtkAbstractComplexGestureRecognizer`2024-01-10T03:56:38-05:00Jean-Christophe Fillion-RobinAdd `vtkAbstractComplexGestureRecognizer`Originally posed by @jcfr in https://gitlab.kitware.com/vtk/vtk/-/merge_requests/10786#note_1462226
> Add a class like `vtkAbstractComplexGestureRecognizer` that would be a "friend" of `vtkVRRenderWindowInteractor`.
>
> The class `vtkR...Originally posed by @jcfr in https://gitlab.kitware.com/vtk/vtk/-/merge_requests/10786#note_1462226
> Add a class like `vtkAbstractComplexGestureRecognizer` that would be a "friend" of `vtkVRRenderWindowInteractor`.
>
> The class `vtkRenderWindowInteractor3D` would have a `Set/GetComplexGestureRecognizer()`
>
> Then the implementation of `vtkVRRenderWindowInteractor::HandleComplexGestureEvents/RecognizeComplexGesture` would delegrate the calls to `this->ComplexGestureRecognizer->HandleComplexGestureEvents/RecognizeComplexGesture`.
>
> That way, in the context of Slicer, I could have the same recognizer for both the `OpenXR` and `OpenVR` runtimes.
>
> **Rational:** This would allow to access ivars like the following without having to add additional set/get functions:
> * `StartingPhysicalEventPositions` / `PhysicalEventPositions`
> * `StartingPhysicalEventPoses` / `PhysicalEventPoses`
> * `StartingPhysicalToWorldMatrix`
Originally posed by @LucasGandelKitware in https://gitlab.kitware.com/vtk/vtk/-/merge_requests/10786#note_1464424
> I am fine with placing the complex gesture logic in a dedicated class, but I think the accessors are preferred over the "friend" class approach, as this will also help interactor styles to access the PhysicalEventPoses of both controllers for custom interactions.
>
> This is highly related to a design issue in VTK, where the event data that is passed to callback does not contain enough information when a more global state is required.https://gitlab.kitware.com/vtk/vtk/-/issues/19216VTU Grid Data in Separate File2024-01-08T04:19:55-05:00Jonathan HodgesVTU Grid Data in Separate FileSeveral users have requested the ability to have grid data stored in a separate file for the VTK data formats (see example discussion linked below). I took at stab at making this change for the unstructured grid format on my branch. I th...Several users have requested the ability to have grid data stored in a separate file for the VTK data formats (see example discussion linked below). I took at stab at making this change for the unstructured grid format on my branch. I think it is most of the way there but the code is seg faulting. My expectation is that I am missing something in the two calls I am making to bring the point and cell elements from the separate file into the original file. (Line 167 of vtkXMLUnstructuredGridReader.cxx and Line 448 of vtkXMLUnstructuredDataReader.cxx). I have attached my test case I have been using to develop the change. What are your thoughts?
[testBuild.tar](/uploads/4c77e34bb755866e2a70ea66f324730e/testBuild.tar)
https://discourse.paraview.org/t/vtk-separate-mesh-and-data-files/10134/2
https://gitlab.kitware.com/jhodges/vtkhttps://gitlab.kitware.com/vtk/vtk/-/issues/19213vtkHyperTreeGridContour: does not support `VTK_DISPATCH_TYPED_ARRAYS`2024-01-02T03:33:31-05:00Ben BoeckelvtkHyperTreeGridContour: does not support `VTK_DISPATCH_TYPED_ARRAYS`The `vtkNew<ArrayType>` in `ConvertToIndexedArrayWorker` doesn't work with `vtkTypedDataArray`. The Windows/Debug CI disables the module until this is resolved.
Cc: @spiros.tsalikis @yohann.bearziThe `vtkNew<ArrayType>` in `ConvertToIndexedArrayWorker` doesn't work with `vtkTypedDataArray`. The Windows/Debug CI disables the module until this is resolved.
Cc: @spiros.tsalikis @yohann.bearzihttps://gitlab.kitware.com/vtk/vtk/-/issues/19212Windows Debug test timeouts2024-01-02T04:58:06-05:00Ben BoeckelWindows Debug test timeoutsExcluded in !10787.Excluded in !10787.https://gitlab.kitware.com/vtk/vtk/-/issues/19211TestInSituExodus: `testContourFilter` fails2024-01-04T06:57:18-05:00Ben BoeckelTestInSituExodus: `testContourFilter` failsOutput:
```
102: Point mismatch at point index: 0
102: Expected: 0 0 8.48997
102: Actual: 0 0 3.48997
102: Contour filter output mismatch.
```
There is a `vtkContourFilter_IS_FIXED` defined to `0` in `IO/Exodus/Testing/Cxx/TestIn...Output:
```
102: Point mismatch at point index: 0
102: Expected: 0 0 8.48997
102: Actual: 0 0 3.48997
102: Contour filter output mismatch.
```
There is a `vtkContourFilter_IS_FIXED` defined to `0` in `IO/Exodus/Testing/Cxx/TestInSituExodus.cxx` to mask out the test for now. Added in !10787.
Cc: @spiros.tsalikis @dcthomp @utkarsh.ayachithttps://gitlab.kitware.com/vtk/vtk/-/issues/19210Missing GL_ES_VERSION_3_0 guard for GL_TEXTURE_CUBE_MAP_SEAMLESS in GL_ES_VER...2024-01-02T12:54:42-05:00StefanBruensMissing GL_ES_VERSION_3_0 guard for GL_TEXTURE_CUBE_MAP_SEAMLESS in GL_ES_VERSION_3_0 in vtkDGOpenGLRenderer.cxxhttps://gitlab.kitware.com/vtk/vtk/-/blame/v9.3.0/Rendering/CellGrid/vtkDGOpenGLRenderer.cxx?ref_type=tags?ref_type=tags&page=2#L1049-L1054
GL_TEXTURE_CUBE_MAP_SEAMLESS is not a valid constant for GLES - GLES 2.0 does not support seamle...https://gitlab.kitware.com/vtk/vtk/-/blame/v9.3.0/Rendering/CellGrid/vtkDGOpenGLRenderer.cxx?ref_type=tags?ref_type=tags&page=2#L1049-L1054
GL_TEXTURE_CUBE_MAP_SEAMLESS is not a valid constant for GLES - GLES 2.0 does not support seamless textures, and for GLES 3.x it is always on, see https://registry.khronos.org/OpenGL/specs/es/3.2/es_spec_3.2.pdf#section.G.2
This only affects the 9.3 branch (AFAICS), the relevant code was removed in master with https://gitlab.kitware.com/vtk/vtk/-/commit/9adc1ed8aa934031d3c9b61ca142d2f834126661
Also see:
https://gitlab.kitware.com/vtk/vtk/-/merge_requests/5758#note_598567
https://gitlab.kitware.com/vtk/vtk/-/merge_requests/6446#note_694923https://gitlab.kitware.com/vtk/vtk/-/issues/19209Proposed alteration and completion of vtkFillHolesFilter algorithm's multiple...2024-01-04T21:52:43-05:00Dan SebaldProposed alteration and completion of vtkFillHolesFilter algorithm's multiple edge neighbors scenarioThe vtkFillHolesFilter algorithm builds the mesh (links) for a polydata object, extracts the cell edges that have no adjacent cells, then navigates those edges to define holes and point data used for the triangulation routine. To do thi...The vtkFillHolesFilter algorithm builds the mesh (links) for a polydata object, extracts the cell edges that have no adjacent cells, then navigates those edges to define holes and point data used for the triangulation routine. To do this, it keeps an array of "visited[]" Booleans for each of the edges to inherently group edges into separate connected holes. In the first portion of the vtkFillHolesFilter algorithm is the following test to determine which direction to navigate based on the built-links neighboring edges:
~~~
Lines->GetCellNeighbors(currentCellId, endId, neighbors);
if (neighbors->GetNumberOfIds() == 0)
{
valid = 0;
}
else if (neighbors->GetNumberOfIds() > 1)
{
// have to logically split this vertex
valid = 0;
}
else
{
neiId = neighbors->GetId(0);
visited[neiId] = 1;
Lines->GetCellPoints(neiId, npts, pts);
endId->SetId(0, (pts[0] != endId->GetId(0) ? pts[0] : pts[1]));
currentCellId = neiId;
}
~~~
It's that second condition that I'd like to draw attention to. I'm not certain what was meant by "have to logically split", other than the interpretation that this isn't complete. Is there some general method of logically splitting the vertex? Is it "vertex" or cell "edge"?
Let me begin with explaining why this second condition should be addressed. I would expect that vtkFillHolesFilter works fairly well as is, especially for VTK repository data sets. That is, the multiple-neighbor condition may not happen too often from the developers' standpoint. However, when working with data acquired from some kind of scanning process and then some kind of further spatial processing, it's not uncommon to have strange things appear in a model surface, such as a manifold wrapping inward on itself. If one clips through such a model and tries to fill the hole left behind, it's conceivable and not unlikely to end up with the more-than-one-neighbor scenario.
Beyond the algorithm not addressing the second condition, if and when it does arise, setting "valid" to 0 results in some really bad behavior. Look at the whole code, including the outer loop, and notice that things don't stop when valid becomes 0. Instead, the inner loop exits, leaving a bunch (and it could be a large number) of unvisited edges for which the outer loop will attempt to start with those unvisited cells and likely reach the same bottleneck. In other words, lots of going around in the same loop, tossing the same points into the triangulation input, etc. Just very unpredictable, and will stall a program in the least, possibly crashing somewhere along the way. I've drawn up an illustration to help explain:
![figure_eight_drawing](/uploads/a580cc397a005ee9ca0aff93976edd8c/figure_eight_drawing.png)
So, what to do with the multiple-neighbors condition? Well, one initial thought that comes to mind is simply pick the first neighbor in the list and proceed. Easy enough to program, which I did, but that has a problem. As I added in the illustration, that strategy can navigate into an adjacent hole and by chance never get out of that circular path.
Well, then let's add a requirement that we pick the first neighbor in the list that has *not yet been visited*. The visited[] array is readily available. Shown in the figure, that might navigate to the next, adjacent, smaller hole, but when that smaller hole navigation gets back to the complex-edged-vertex all but one edge has been visited. Navigation continues back on the original loop, eventually reaching the start, as designed. It's conceivable that the neighbors arrangement is such that navigation stays on the larger hole and doesn't visit the smaller hole. However, in that case the outer-for-loop is still searching for unvisited edges to start with, so eventually the smaller hole is included as well, as a separate collection of points for the triangulation method. Getting back to the "have to logically split" comment in the code, the proposed alteration is more of randomly-picking a direction, yet it seems to work itself out, when taken as a whole.
Note that what I explained in the previous paragraph, i.e., follow the path of the first neighbor that hasn't yet been visited, is a generic approach. The 0-neighbors and 1-neighbor scenarios both fit in that context. That means that the proposed change in the attached patch file, i.e.,
~~~
// Advance to next, non-visited cell, if one exists, otherwise invalidate and stop
Lines->GetCellNeighbors(currentCellId, endId, neighbors);
vtkIdType nNei = neighbors->GetNumberOfIds();
vtkIdType nextNei = 0;
for (; nextNei < nNei; nextNei++)
{
neiId = neighbors->GetId(nextNei);
if (!visited[neiId])
{
visited[neiId] = 1;
Lines->GetCellPoints(neiId, npts, pts);
endId->SetId(0, (pts[0] != endId->GetId(0) ? pts[0] : pts[1]));
currentCellId = neiId;
break;
}
}
if (nextNei >= nNei)
{
valid = 0;
}
~~~
really isn't much of a increase in overall code.
[generalized_multiple_neighbor_edges_vtkFillHolesFilter_2023-12-27.diff](/uploads/232345f094b8edc38ade1963d6f028dd/generalized_multiple_neighbor_edges_vtkFillHolesFilter_2023-12-27.diff)
In the patch file, notice that I moved the "is valid" test to a lesser scope. As I see it, if the navigation fails, all hope is lost. (Not totally true, but to discard "broken" hole links and find only the good hole links would require more arrays in order to keep track of things. In other words, only include data once a successful return-to-start happens.) But, at the same time, the new strategy would be more robust to "valid" ever becoming 0. Can the 0-neighbors scenario actually occur? The answer might be "no", considering whether the link-building process inherently obviates the condition. Perhaps the worst that could happen is the triangulation comes out not quite as desired.