VTK issueshttps://gitlab.kitware.com/vtk/vtk/-/issues2024-03-27T09:03:35-04:00https://gitlab.kitware.com/vtk/vtk/-/issues/19294Hyper Tree Super Cursors doesn't support masks which lead to crash2024-03-27T09:03:35-04:00Loïc GaillardHyper Tree Super Cursors doesn't support masks which lead to crashThe `vtkHyperTreeGridNonOrientedUnlimitedSuperCursor` doesn't support the use of masks, which can lead to a crash when used with a masked input. It could be added so that it can be used in other filters such as `vtkHyperTreeGridGradient`.The `vtkHyperTreeGridNonOrientedUnlimitedSuperCursor` doesn't support the use of masks, which can lead to a crash when used with a masked input. It could be added so that it can be used in other filters such as `vtkHyperTreeGridGradient`.https://gitlab.kitware.com/vtk/vtk/-/issues/19293Masked fraction bias in vtkRandomHyperTreeGridSource isn't exposed2024-03-27T09:02:10-04:00Loïc GaillardMasked fraction bias in vtkRandomHyperTreeGridSource isn't exposedIn `vtkRandomHyperTreeGridSource`, it is possible to apply a random mask. This mask is subject to a bias depending on the branching factor and the number of tree but it currently isn't exposed by any means by the class. It could be handy...In `vtkRandomHyperTreeGridSource`, it is possible to apply a random mask. This mask is subject to a bias depending on the branching factor and the number of tree but it currently isn't exposed by any means by the class. It could be handy to be able to access it through a property or a method.https://gitlab.kitware.com/vtk/vtk/-/issues/19292vtkCellCenters() generates non plausible centers for vtk.VTK_CONVEX_POINT_SET2024-03-27T09:01:13-04:00Jan TecklenburgvtkCellCenters() generates non plausible centers for vtk.VTK_CONVEX_POINT_SETWhen I apply vtkCellCenters() to a unstructured grid with cell types vtk.VTK_CONVEX_POINT_SET (41), the cell centers are not in the centers of the cells.
Steps for reproduction:
[test.vtu](/uploads/9a1836a6a95817dcf4634b466307f9f9/test...When I apply vtkCellCenters() to a unstructured grid with cell types vtk.VTK_CONVEX_POINT_SET (41), the cell centers are not in the centers of the cells.
Steps for reproduction:
[test.vtu](/uploads/9a1836a6a95817dcf4634b466307f9f9/test.vtu)
```
import vtk
import numpy as np
expected_values = [[9, 0, 0.5], [12, 0, 0.5],
[15, 0, 0.5], [18, 0, 0.5],
[21, 0, 0.5], [24, 0, 0.5],
[27, 0, 0.5]]
# Lese die VTU-Datei ein
reader = vtk.vtkXMLUnstructuredGridReader()
reader.SetFileName("test.vtu")
reader.Update()
# Erstelle den vtkCellCenters-Filter
cell_centers = vtk.vtkCellCenters()
cell_centers.SetInputConnection(reader.GetOutputPort())
cell_centers.Update()
# Hole die Mittelpunkte
centers = cell_centers.GetOutput()
# Drucke die Mittelpunkte
for i in range(centers.GetNumberOfPoints()):
print(expected_values[i])
print(centers.GetPoint(i))
print("-----")
```
returns
```
[9, 0, 0.5]
(8.56698751449585, -1.25, 0.5)
-----
[12, 0, 0.5]
(11.0, -1.0000000000000002, 0.5)
-----
[15, 0, 0.5]
(13.755050659179688, -0.595491498708725, 0.5)
-----
[18, 0, 0.5]
(16.700961112976074, -0.25, 0.5)
-----
[21, 0, 0.5]
(19.730704307556152, 0.012229330837726593, 0.5)
-----
[24, 0, 0.5]
(22.792892456054688, 0.2071067690849303, 0.5)
-----
[27, 0, 0.5]
(25.864808082580566, 0.35286852717399597, 0.5)
```
Here the first value is the expected value and the second value is calculated by vtkCellCenters()https://gitlab.kitware.com/vtk/vtk/-/issues/19291Update minimum OpenGL version to 4.12024-03-26T09:12:56-04:00Jaswant Panchumarti (Kitware)Update minimum OpenGL version to 4.1This should be easy as almost all VTK applications out there use 4.5 already. The three OpenGL render window classes will have to drop support for less than 4.1 from and ensure a clean CI.
If not all, most modern computers are capable o...This should be easy as almost all VTK applications out there use 4.5 already. The three OpenGL render window classes will have to drop support for less than 4.1 from and ensure a clean CI.
If not all, most modern computers are capable of 4.5
- Mesa 12 onwards support OpenGL 4.3 (ubuntu 20.04 has mesa 21.2.6, debian 10 has 18.3.6, many distros considered 'old' have a mesa version > 18.)
- macOS only supports upto 4.1, this is the reason we can't aim higher than 4.1Jaswant Panchumarti (Kitware)Jaswant Panchumarti (Kitware)https://gitlab.kitware.com/vtk/vtk/-/issues/19290Revisit vtk-wasm wheel setup2024-03-26T15:43:09-04:00Jaswant Panchumarti (Kitware)Revisit vtk-wasm wheel setupThe existing logic uses a `setup.cfg` (instead of `pyproject.toml`) which makes vtk-wasm depend upon a vtk wheel is not robust. It implements a catch all `major.minor.*` so that `major.minor.patch.devN` tags are accepted. However, this i...The existing logic uses a `setup.cfg` (instead of `pyproject.toml`) which makes vtk-wasm depend upon a vtk wheel is not robust. It implements a catch all `major.minor.*` so that `major.minor.patch.devN` tags are accepted. However, this is wrong because serdes can be inconsistent across different patch versions. Could it use `toml` as well?
See https://gitlab.kitware.com/vtk/vtk/-/merge_requests/10898#note_1496985 and https://gitlab.kitware.com/vtk/vtk/-/merge_requests/10898#note_1499110Jaswant Panchumarti (Kitware)Jaswant Panchumarti (Kitware)https://gitlab.kitware.com/vtk/vtk/-/issues/19289pycache: Allows tests to fail the first time and pass all subsequent ones2024-03-25T14:12:10-04:00Spiros Tsalikispycache: Allows tests to fail the first time and pass all subsequent onesI had a test in which i was accessing memory that i was not supposed to.
The CI was failing every single time i would run it.
I tried to reproduced the same container locally, and my test failed the first time, because the memory that ...I had a test in which i was accessing memory that i was not supposed to.
The CI was failing every single time i would run it.
I tried to reproduced the same container locally, and my test failed the first time, because the memory that accessed wrongly was giving me garbage. All subsequent times i executed the test, it was passing because the invalid memory location instead of having garbage now it included always 0.
This was cause because the first time there was no pycache, and all subsequent ones, there was pycache.
To reproduce build:
1. Build fedora34_mpi_ospray_python_qt_tbb:
2. In vtkOrientPolyData::TraverseAndOrder comment out the folowing code:
```
if (npts < 3)
{
continue;
}
```
3. Execute VTK::FiltersGeneralPython-tableBasedClip
This can potentially affect all python flaky CI tests, that fail once in while, because a previous test might create the pycache and then they access it, so instead of garbage you know get valid results.
One idea would be to disable the creation of pycache for CI.
@ben.boeckel @ryan.krattiger1 @mwestphal @cory.quammen @berkgeveci @jaswant.panchumartiSpiros TsalikisSpiros Tsalikishttps://gitlab.kitware.com/vtk/vtk/-/issues/19288vtkHDFReader: FieldData in pdc/multiblock isn't supported2024-03-21T10:57:15-04:00Lucas GivordvtkHDFReader: FieldData in pdc/multiblock isn't supportedCurrently, vtkHDFReader doesn't support FieldData for partitioned dataset collection and multiblock dataset.
To reproduce that in ParaView master, I provide these 2 files which are valid (based on VTKHDF File Format 2.1) but their field...Currently, vtkHDFReader doesn't support FieldData for partitioned dataset collection and multiblock dataset.
To reproduce that in ParaView master, I provide these 2 files which are valid (based on VTKHDF File Format 2.1) but their field datas are missing:
- [composite.vtkhdf](/uploads/f75547c370acd19c83ad1308ba0f96ef/composite.vtkhdf)
- [composite_transient.vtkhdf](/uploads/bfd31057332b85037fdd7532ff7929f0/composite_transient.vtkhdf)
### Some hints for developer
FieldData are mostly append in this [method](https://gitlab.kitware.com/vtk/vtk/-/blob/master/IO/HDF/vtkHDFReader.cxx?ref_type=heads#L793) which hasn't been updated when we added support for composite data in the vtkHDFReaderhttps://gitlab.kitware.com/vtk/vtk/-/issues/19287Renderer.PickProp does not work when SSAO render-pass is set2024-03-21T08:41:12-04:00Ruben de BruinRenderer.PickProp does not work when SSAO render-pass is setThe PickProp function of renderer does not work when a SSAO pass is present.
This is easily worked around by setting the render passes to None before executing the PickProp function:
```python
store = renderer.GetPass()
renderer...The PickProp function of renderer does not work when a SSAO pass is present.
This is easily worked around by setting the render passes to None before executing the PickProp function:
```python
store = renderer.GetPass()
renderer.SetPass(None)
assemblyPath = renderer.PickProp(self.start_x, self.start_y, self.end_x, self.end_y)
renderer.SetPass(store)
```
But it makes more sense to add this the the PickProp function itself.https://gitlab.kitware.com/vtk/vtk/-/issues/19286vtkPolyData: Inconsistent ordering of inserting cells2024-03-21T10:54:16-04:00Spiros TsalikisvtkPolyData: Inconsistent ordering of inserting cellsThe following tests dont insert cells in the following order: verts, lines, polys, strips
- [ ] VTK::CommonDataModelCxx-TestPolyDataRemoveCell
- [ ] VTK::CommonDataModelCxx-TestPolyDataRemoveDeletedCells
- [ ] VTK::FiltersModel...The following tests dont insert cells in the following order: verts, lines, polys, strips
- [ ] VTK::CommonDataModelCxx-TestPolyDataRemoveCell
- [ ] VTK::CommonDataModelCxx-TestPolyDataRemoveDeletedCells
- [ ] VTK::FiltersModelingPython-TestContourLoopExtraction
- [ ] VTK::FiltersModelingPython-TestCookieCutter
- [ ] VTK::FiltersSourcesCxx-TestGlyphSource2DResolution
- [ ] VTK::FiltersSourcesPython-glyph2D
- [ ] VTK::InteractionWidgetsCxx-TestAngleWidget2D
- [ ] VTK::InteractionWidgetsCxx-TestBiDimensionalWidget
- [ ] VTK::InteractionWidgetsCxx-TestDistanceWidget
- [ ] VTK::InteractionWidgetsCxx-TestMultipleViewports
- [ ] VTK::InteractionWidgetsCxx-TestProgrammaticPlacement
- [ ] VTK::InteractionWidgetsCxx-TestSeedWidget
- [ ] VTK::InteractionWidgetsCxx-TestSeedWidget2
- [ ] VTK::IOCatalystConduitCxx-MPI-TestDataObjectToConduit
- [ ] VTK::IOCatalystConduitCxx-TestDataObjectToConduit
- [ ] VTK::IOXdmf2Cxx-XdmfTestVTKIO
- [ ] VTK::IOXdmf3Python-VToXLoop
- [ ] VTK::RenderingContext2DPython-multiPolyDataItems
Once these tests are fixed, we should add a warning inside `vtkPolyData::InsertNextCell` to let people know that this will not be allowed in the future. And then we will be throwing a warning.
Related MR https://gitlab.kitware.com/vtk/vtk/-/merge_requests/10974.
cc: @will.schroeder @jaswant.panchumarti @sankhesh @cory.quammen @berkgeveci @mwestphal @charles.gueunetSpiros TsalikisSpiros Tsalikishttps://gitlab.kitware.com/vtk/vtk/-/issues/19285vtkCellSizeFilter() generates non plausible values for cell types 13 and 412024-03-27T09:01:19-04:00Jan TecklenburgvtkCellSizeFilter() generates non plausible values for cell types 13 and 41**Describe the bug, what's wrong, and what you expected.**
I created an unstructured grid with different types of prisms. Then I calculated the cell volumes with vtkCellSizeFilter().
For cell type vtk.VTK_WEDGE (13) I find negativ volu...**Describe the bug, what's wrong, and what you expected.**
I created an unstructured grid with different types of prisms. Then I calculated the cell volumes with vtkCellSizeFilter().
For cell type vtk.VTK_WEDGE (13) I find negativ volumes.
For cell type vtk.VTK_CONVEX_POINT_SET (41) the volumes do not seem to be plausible when there are more than one cell in the grid.
**Summary of reproduction**
1. When the prism is of type 13, the volume is negative. When the same prism is of type 41, the volume is positive and as expected.
2. The given order of points results in positive volumes for all types except for type 13. (-> I assume, the calculation of the volumes is not consistent for different cell types)
3. The volume of prisms of type 41 is as expected, when this prism is the first one in the grid. (-> I assume, the algorithm to calculate the volume is correct)
4. The volume of prisms of type 41 are not as expected, when there is more than one prism in the grid and the prism is not the first element in the grid. (-> I assume, the algorithm picks wrong points to calculate the volume)
**Steps to reproduce the bug.**
Here is a volume comparision for prisms with different number of edges.
```
import numpy as np
import matplotlib.pyplot as plt
import vtk
import pyvista as pv
def area_polygon(p):
"""
Calculates the area on a polygon given by an array of points.
https://en.wikipedia.org/wiki/Shoelace_formula#Generalization
"""
npoints = np.shape(p)[0]
A = 0
for i in np.arange(npoints):
A = A + np.cross(p[i, :], p[(i+1) % npoints, :])
return np.linalg.norm(A)/2
def area(n=100, radius=1):
"""
Calculates the area of a polygon with n edges given by polygon_edges().
For radius 1 the value tends towards pi.
"""
p = polygon_edges(n, radius)
return area_polygon(p)
def polygon_edges(n, radius=1, plot=False):
"""
Returns n evenly distributed 3D points on a circle with the given radius
"""
i = np.linspace(0, 2*np.pi, n+1)
i = np.delete(i, n)
p = np.column_stack((np.sin(i)*radius, np.cos(i)*radius, np.ones(n)))
if plot:
plt.plot(p[:, 0], p[:, 1], 'o')
plt.show()
return p
def UnstructuredGrid(coords, ind, cell_types):
# Erstelle ein VTK-UnstructuredGrid-Objekt
grid = vtk.vtkUnstructuredGrid()
# Erstelle Punkte
points = vtk.vtkPoints()
for coord in coords:
points.InsertNextPoint(coord)
grid.SetPoints(points)
# Erstelle Zellen
cell_array = vtk.vtkCellArray()
for i, cell_type_id in enumerate(cell_types):
cell = vtk.vtkIdList()
for j in range(len(ind[i])):
cell.InsertNextId(ind[i][j])
cell_array.InsertNextCell(cell)
grid.SetCells(cell_types, cell_array)
return grid
def get_element_volumes(mesh):
# Create a vtkCellSizeFilter
sizeFilter = vtk.vtkCellSizeFilter()
sizeFilter.SetInputData(mesh)
sizeFilter.Update()
# Get the output data set
output = sizeFilter.GetOutput()
# Get the volume array
volumes = output.GetCellData().GetArray("Volume")
# Convert the volume array to a list
volumes_list = [volumes.GetValue(i) for i in range(volumes.GetNumberOfTuples())]
return volumes_list
# When there are many prism in the grid, cell type 41 gives wrong volumes
edge_min, edge_max = 3, 9
# When there is only one cell in the grid, cell type 41 gives correct volumes
#edge_min, edge_max = 7, 7
test = 1 # Check cell types from ctype (see below)
# test = 2 # Check 41 -> vtk.VTK_CONVEX_POINT_SET only
shift_factor = 3
edges = np.arange(edge_min, edge_max+1)
# Type of geometry
ctype = {3: vtk.VTK_WEDGE, # -> 13
4: vtk.VTK_HEXAHEDRON, # -> 12
5: vtk.VTK_PENTAGONAL_PRISM, # -> 15
6: vtk.VTK_HEXAGONAL_PRISM, # -> 16
7: vtk.VTK_CONVEX_POINT_SET} # -> 41
# Init arrays
ind = list()
coords = np.empty((0, 3))
cell_type = list()
index = 0
# Create prism with different number of edges for unstructured grid
for n in edges:
p = polygon_edges(n)
p[:, 0] = p[:, 0] + shift_factor * n
p = np.vstack([p, p])
p[n:, 2] = 0
coords = np.vstack((coords, p))
#ind.append(2*n)
#ind = ind + list(range(index, index+2*n))
ind.append(list(range(index, index+2*n)))
index = index + 2*n
if test == 1:
cell_type.append(ctype.get(n, vtk.VTK_CONVEX_POINT_SET))
else:
cell_type.append(vtk.VTK_CONVEX_POINT_SET)
grid = UnstructuredGrid(coords, ind, cell_type)
pv.UnstructuredGrid(grid).plot(show_edges=True)
# Calculate actual volume of cells
volumes = get_element_volumes(grid)
# Calculate reference values for volumes of cells
# Height of cells is 1 -> volume = area * 1
# Reference values are plausible, because with increasing number of edges n
# the value tends towards pi for edges on a circle with radius 1.
reference_volume = [area(n) for n in np.arange(edge_min, edge_max+1)]
# Compare actual and reference volumes
print("Cell type | Actual value | Reference value -> match?")
for [vol_ac, vol_des, ct] in zip(volumes, reference_volume, cell_type):
match = ":)" if abs(vol_ac - vol_des) < 1e-4 else "X"
print(f'{ct} | {vol_ac: .8f} | {vol_des: .8f} -> {match}')
```
1. This test gives for "test = 1"
```
Cell type | Actual value | Reference value -> match?
13 | -1.29903746 | 1.29903811 -> X
12 | 2.00000000 | 2.00000000 -> :)
15 | 2.37764177 | 2.37764129 -> :)
16 | 2.59807777 | 2.59807621 -> :)
41 | -1.04465834 | 2.73641019 -> X
41 | 0.76634582 | 2.82842712 -> X
41 | 0.66068331 | 2.89254424 -> X
```
Here you can see, that the volume calculated for prism 13 is negativ, but needs to be positiv.
The volumes calculated for prisms of type 41 is always not matching the reference values.
This grid has seven cells.
2. This test gives for "test = 2" and "edge_min, edge_max = 3, 3":
```
Cell type | Actual value | Reference value -> match?
41 | 1.29903746 | 1.29903811 -> :)
```
Here is only one cell in the grid and the volume for a prism with 3 edges is calculated as expected.
3. And finally this test gives for "test = 2" and "edge_min, edge_max = 7, 7"
```
Cell type | Actual value | Reference value -> match?
41 | 2.73641041 | 2.73641019 -> :)
```
Again, here is only one cell in the grid and the volume for a prism with 7 edges is calculated as expected.https://gitlab.kitware.com/vtk/vtk/-/issues/19284Problems occur when vtk is cross-compiled under window2024-03-22T03:57:56-04:00jim wangProblems occur when vtk is cross-compiled under windowThe following error occurs when I compile vtk in vcpkg.
CMake Error at CMake/vtkInstallCMakePackageCompileTools.cmake:5 (message):
vtkInstallCMakePackageCompileTools is missing input variables.
Call Stack (most recent call first):
C...The following error occurs when I compile vtk in vcpkg.
CMake Error at CMake/vtkInstallCMakePackageCompileTools.cmake:5 (message):
vtkInstallCMakePackageCompileTools is missing input variables.
Call Stack (most recent call first):
CMakeLists.txt:76 (include)
Reproduction steps:
git clone vcpkg
.\bootstrap-vcpkg.bat
./vcpkg install vtk:arm64-windows
platform:windows
complier: ninja.exehttps://gitlab.kitware.com/vtk/vtk/-/issues/19283testTransmit: UnstructuredGrid fails2024-03-19T06:08:39-04:00Ben BoeckeltestTransmit: UnstructuredGrid failsJob [#9491195](https://gitlab.kitware.com/vtk/vtk/-/jobs/9491195) failed for bf3d8421840a36c329d50b454a066612f7586b92:
`vtkTransmitUnstructuredGridPiece` fails on the `assert resArray.GetValue(0) == 1` assertion. Needs investigation.
C...Job [#9491195](https://gitlab.kitware.com/vtk/vtk/-/jobs/9491195) failed for bf3d8421840a36c329d50b454a066612f7586b92:
`vtkTransmitUnstructuredGridPiece` fails on the `assert resArray.GetValue(0) == 1` assertion. Needs investigation.
Cc: @berkgevecihttps://gitlab.kitware.com/vtk/vtk/-/issues/19282Implement SerDes for vtkOpenGLSkybox2024-03-18T15:53:21-04:00Jaswant Panchumarti (Kitware)Implement SerDes for vtkOpenGLSkyboxJaswant Panchumarti (Kitware)Jaswant Panchumarti (Kitware)https://gitlab.kitware.com/vtk/vtk/-/issues/19281SerDes wrapper should handle the lack of marshal macros in a marshallable module2024-03-21T22:14:35-04:00Jaswant Panchumarti (Kitware)SerDes wrapper should handle the lack of marshal macros in a marshallable module`vtkWrapSerDes` should warn when no classes have VTK_MARSHAL* macro in module with `INCLUDE_MARSHAL`.
This tool cannot remember previous invocations, so it's tricky to find out how many classes, if any have had auto generated code.`vtkWrapSerDes` should warn when no classes have VTK_MARSHAL* macro in module with `INCLUDE_MARSHAL`.
This tool cannot remember previous invocations, so it's tricky to find out how many classes, if any have had auto generated code.Jaswant Panchumarti (Kitware)Jaswant Panchumarti (Kitware)https://gitlab.kitware.com/vtk/vtk/-/issues/19280Investigate whether excluded classes need serdes2024-03-21T22:14:27-04:00Jaswant Panchumarti (Kitware)Investigate whether excluded classes need serdesProperites of these types are currently excluded from serialization with the reason "serdes not implemented". Does this have a side-effect? Is some information lost? Need to build examples that use these in order to better understand wha...Properites of these types are currently excluded from serialization with the reason "serdes not implemented". Does this have a side-effect? Is some information lost? Need to build examples that use these in order to better understand what's missing.
1. `vtkInformation`
2. `vtkAbstractPicker`
3. `vtkPickingManager`Jaswant Panchumarti (Kitware)Jaswant Panchumarti (Kitware)https://gitlab.kitware.com/vtk/vtk/-/issues/19279[Windows] Python-VTK remove library hash suffix2024-03-22T09:11:45-04:00Noah[Windows] Python-VTK remove library hash suffixCurrently, the pre-built libraries that VTK ships on windows in its python package (in `vtk.libs`) are suffixed with hashes:
![image](/uploads/54a921d97d644c4b59cf3538a667f948/image.png)
Would it be possible to remove said suffixes and...Currently, the pre-built libraries that VTK ships on windows in its python package (in `vtk.libs`) are suffixed with hashes:
![image](/uploads/54a921d97d644c4b59cf3538a667f948/image.png)
Would it be possible to remove said suffixes and simply keep the names as `vtksys-9.3.dll`?
The reason I'm asking is because we are currently developing a native python module that dynamically links against vtk and in an effort to reduce duplicate libraries we've made our module load the python-vtk libraries at runtime.
This works on Linux as the `.so` files are named as expected. But due to the aforementioned suffixes this approach does not work on windows.https://gitlab.kitware.com/vtk/vtk/-/issues/19278Incorectly formated .vtp file cause crash segfault when being displayed2024-03-17T06:35:53-04:00Mathieu Westphal (Kitware)Incorectly formated .vtp file cause crash segfault when being displayedAn incorrectly formatted file can crash any application trying to display it and there is no way to avoid it.
IMO I/O code should sanitize the input and just fail to read in that case:
ASCII version: [a.vtp](/uploads/cb82dead9ec68aa5ac7...An incorrectly formatted file can crash any application trying to display it and there is no way to avoid it.
IMO I/O code should sanitize the input and just fail to read in that case:
ASCII version: [a.vtp](/uploads/cb82dead9ec68aa5ac7149b30662ece2/a.vtp)
Appended version: [a.vtp](/uploads/f6e1ad457e6915a0f77c0ec43005294d/a.vtp)
Backtrace when reading with ParaView:
```
Thread 1 "paraview" received signal SIGSEGV, Segmentation fault.
vtkPolyData::ComputeCellsBounds (this=0x55555d574f60) at /home/glow/dev/paraview/pv1/src/VTK/Common/DataModel/vtkPolyData.cxx:388
388 ptUses[pts[ptIdx]] = 1;
(gdb) bt
#0 vtkPolyData::ComputeCellsBounds (this=0x55555d574f60) at /home/glow/dev/paraview/pv1/src/VTK/Common/DataModel/vtkPolyData.cxx:388
#1 0x00007fffefe04da2 in vtkPolyData::GetCellsBounds (this=0x55555d574f60, bounds=0x7fffffffc240) at /home/glow/dev/paraview/pv1/src/VTK/Common/DataModel/vtkPolyData.cxx:401
#2 0x00007ffff3b6aeee in vtkCompositeDataDisplayAttributes::ComputeVisibleBoundsInternal (cda=0x55555ebff730, dobj=0x55555d574f60, bbox=0x7fffffffc4a0, parentVisible=true)
at /home/glow/dev/paraview/pv1/src/VTK/Rendering/Core/vtkCompositeDataDisplayAttributes.cxx:1024
#3 0x00007ffff3b6ae2a in vtkCompositeDataDisplayAttributes::ComputeVisibleBoundsInternal (cda=0x55555ebff730, dobj=0x55555ef58740, bbox=0x7fffffffc4a0, parentVisible=true)
at /home/glow/dev/paraview/pv1/src/VTK/Rendering/Core/vtkCompositeDataDisplayAttributes.cxx:1014
#4 0x00007ffff3b6ae2a in vtkCompositeDataDisplayAttributes::ComputeVisibleBoundsInternal (cda=0x55555ebff730, dobj=0x55555ef62bc0, bbox=0x7fffffffc4a0, parentVisible=true)
at /home/glow/dev/paraview/pv1/src/VTK/Rendering/Core/vtkCompositeDataDisplayAttributes.cxx:1014
#5 0x00007ffff3b6ac6c in vtkCompositeDataDisplayAttributes::ComputeVisibleBounds (cda=0x55555ebff730, dobj=0x55555ef62bc0, bounds=0x55555e417610)
at /home/glow/dev/paraview/pv1/src/VTK/Rendering/Core/vtkCompositeDataDisplayAttributes.cxx:988
#6 0x00007fffe6fbea7c in vtkGeometryRepresentation::GetBounds (dataObject=0x55555ef62bc0, bounds=0x55555e417610, cdAttributes=0x55555ebff730)
at /home/glow/dev/paraview/pv1/src/Remoting/Views/vtkGeometryRepresentation.cxx:557
#7 0x00007fffe6fc4f2e in vtkGeometryRepresentation::ComputeVisibleDataBounds (this=0x55555e417450) at /home/glow/dev/paraview/pv1/src/Remoting/Views/vtkGeometryRepresentation.cxx:1898
#8 0x00007fffe6fbe182 in vtkGeometryRepresentation::ProcessViewRequest (this=0x55555e417450, request_type=0x55555572e7d0, inInfo=0x5555583fc980, outInfo=0x55555ef5e6f0)
at /home/glow/dev/paraview/pv1/src/Remoting/Views/vtkGeometryRepresentation.cxx:412
#9 0x00007fffe6fd9727 in vtkGeometryRepresentationWithFaces::ProcessViewRequest (this=0x55555e417450, request_type=0x55555572e7d0, inInfo=0x5555583fc980, outInfo=0x55555ef5e6f0)
at /home/glow/dev/paraview/pv1/src/Remoting/Views/vtkGeometryRepresentationWithFaces.cxx:50
#10 0x00007fffe71601ab in vtkPVView::CallProcessViewRequest (this=0x555555a86af0, type=0x55555572e7d0, inInfo=0x5555583fc980, outVec=0x5555583f8bb0)
at /home/glow/dev/paraview/pv1/src/Remoting/Views/vtkPVView.cxx:570
#11 0x00007fffe715fa19 in vtkPVView::Update (this=0x555555a86af0) at /home/glow/dev/paraview/pv1/src/Remoting/Views/vtkPVView.cxx:455
#12 0x00007fffe7109e13 in vtkPVRenderView::Update (this=0x555555a86af0) at /home/glow/dev/paraview/pv1/src/Remoting/Views/vtkPVRenderView.cxx:1373
#13 0x00007fffe7108fa0 in vtkPVRenderView::ResetCamera (this=0x555555a86af0) at /home/glow/dev/paraview/pv1/src/Remoting/Views/vtkPVRenderView.cxx:1190
#14 0x00007fffe79ed5ad in vtkPVRenderViewCommand (arlu=0x555555a13d90, ob=0x555555a86af0, method=0x55555d572009 "ResetCamera", msg=..., resultStream=...)
at /home/glow/dev/paraview/pv1/build/CMakeFiles/vtkRemotingViewsCS/vtkPVRenderViewClientServer.cxx:229
#15 0x00007ffff4bb2398 in vtkClientServerInterpreter::CallCommandFunction
(this=0x555555a13d90, cname=0x7fffe72b801c "vtkPVRenderView", ptr=0x555555a86af0, method=0x55555d572009 "ResetCamera", msg=..., result=...)
```
This can be fixed in `ComputeCellBounds` but this method is valid to assume point ids are valid in cells at this point.https://gitlab.kitware.com/vtk/vtk/-/issues/19277vtkDataObjectTree->GetNumberOfChildren() is a protected member2024-03-15T06:41:35-04:00WillIsbackvtkDataObjectTree->GetNumberOfChildren() is a protected memberDear community,
As I am working with vtkDataObjectTree, i have compilation error saying the method **GetNumberOfChildren() is protected** and so I can't use it. However in the [doc](https://vtk.org/doc/nightly/html/classvtkDataObjectTre...Dear community,
As I am working with vtkDataObjectTree, i have compilation error saying the method **GetNumberOfChildren() is protected** and so I can't use it. However in the [doc](https://vtk.org/doc/nightly/html/classvtkDataObjectTree.html) it clearly say it's a **public member**.
I code in c++ and my vtk includes are libraries from ParaView_5.11.
Best regards,
Williamhttps://gitlab.kitware.com/vtk/vtk/-/issues/19276Incomplete instructions to build vtkParse.tab.c2024-03-18T02:35:57-04:00Jaswant Panchumarti (Kitware)Incomplete instructions to build vtkParse.tab.cI ran into inconsistencies when generating `vtkParse.tab.c` from `vtkParse.y`. I followed all instructions in https://gitlab.kitware.com/vtk/vtk/-/tree/master/Wrapping/Tools?ref_type=heads#vtkparsey. It suggests a series of patches that ...I ran into inconsistencies when generating `vtkParse.tab.c` from `vtkParse.y`. I followed all instructions in https://gitlab.kitware.com/vtk/vtk/-/tree/master/Wrapping/Tools?ref_type=heads#vtkparsey. It suggests a series of patches that must be manually applied. Even after all those patches, `vtkParse.tab.c` fails to compile successfully. Most of these are a case of garbage-in-garbage-out.
As a reminder, [vtkParse.y](https://gitlab.kitware.com/vtk/vtk/-/blob/master/Wrapping/Tools/vtkParse.y?ref_type=heads) contains the rules for parsing a C++ header file. This is a core part of the python/java wrapping tools.
Here's what I found inconsitent/missing:
1. There is a wrong use of `==` operator instead of `=` op in `vtkParse.y`. Generates
```c
static const char** MacroIncludes == NULL;
```
when it should be
```c
static const char** MacroIncludes = NULL;
```
2. Instructions don't ask to add `// NOLINTNEXTLINE(bugprone-suspicious-include)` before `#include "lex.yy.c"`.
3. Invokes `vtkParsePreprocess_Init` with incorrect args. `vtkParsePreprocess_Init` doesn't take `dt`.
4. Doesn't address the prologue docstring containing copyright from FSF.
5. There are more static inlines in `vtkParse.tab.c`, which could mean somebody skipped runing `bison` on `vtkParse.y` or didn't follow the instructions correctly.
I ran these commands with bison 3.8.2
```shell
$ bison --no-lines -b vtkParse vtkParse.y
$ clang-format-8 -i ./vtkParse.tab.c
```
It would be nice if `vtkParse.tab.c` is configure-time generated from `vtkParse.y`, patched and styled in CMake, but that needs bison on windows, which is not readily available.https://gitlab.kitware.com/vtk/vtk/-/issues/19275vtkAxisActor2D AdjustLabels does not move ticks2024-03-19T03:20:00-04:00Nicolas VuaillevtkAxisActor2D AdjustLabels does not move ticks`vtkAxisActor2D` has a mode called `AdjustLabels`, enabled by default, in which, from the doc:
> the labels and ticks are adjusted for "nice" numerical values to make it easier to read the labels.
The issue is that it **does not place ...`vtkAxisActor2D` has a mode called `AdjustLabels`, enabled by default, in which, from the doc:
> the labels and ticks are adjusted for "nice" numerical values to make it easier to read the labels.
The issue is that it **does not place the ticks accordingly** to the new label values.
## Example
This is visible in the `vtkBarChartActor` test, that uses this configuration for internal `vtkAxisActor2D` for vertical axis. See the baseline:
![image](/uploads/47520bed4db8fd9d75aafb708dcb7866/image.png)
For readability, I have switched first and last bar. Adding a print in the test, it shows that this first purple bar has **a value of** `73.4915`, which is inconsistent with the `75.0` tick mark.
The `vtkBarChartActor` configure its `vtkAxisActor2D` only with:
```
Number Of Labels: 5
Range: (84.3021, 0.212141)
```