VTK issueshttps://gitlab.kitware.com/vtk/vtk/-/issues2021-02-05T15:44:57-05:00https://gitlab.kitware.com/vtk/vtk/-/issues/18104Incorrect line depth after point-picking fix2021-02-05T15:44:57-05:00Aron HelserIncorrect line depth after point-picking fixWe are seeing a regression in the depth of lines rendered as tubes, after MR !7281 . Lines are draw in front of polygonal geometry at an incorrect depth.
Reproduction in ParaView:
![edge_depth_bug_pv](/uploads/a747ec61d02f680f20c902bc45...We are seeing a regression in the depth of lines rendered as tubes, after MR !7281 . Lines are draw in front of polygonal geometry at an incorrect depth.
Reproduction in ParaView:
![edge_depth_bug_pv](/uploads/a747ec61d02f680f20c902bc4559d624/edge_depth_bug_pv.png)
To reproduce:
- Add Box source
- Apply Extract Edges filter
- set Render Lines as Tubes, Line Width 3
- Add Cone source, change color
- Radius 0.25, Height 0.5, Center 0.25, 0.5, 0.5
Expect the tip of the cone to intersect the tubes at the corner, instead the tube is show in front of the cone well away from the box corner.
Here are screenshots from our commercial client VTK app, with VTK just before and after !7281:
![enterprise_bad_edges](/uploads/c8eb2db4335b5e9070c31d41b8af5a36/enterprise_bad_edges.png)
![enterprise_good_edges](/uploads/415bea40420d6c47ce28508f2b6c3ae3/enterprise_good_edges.png)Ken MartinKen Martinhttps://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/18099Stop importing `vtk` in tests2023-01-18T21:19:32-05:00Ben BoeckelStop importing `vtk` in testsMany Python tests import the `vtk` module. This ends up importing *every* VTK module. If just one module has a problem, every Python test ends up failing. Instead, tests should import the module and class from the `vtkmodules` package.
...Many Python tests import the `vtk` module. This ends up importing *every* VTK module. If just one module has a problem, every Python test ends up failing. Instead, tests should import the module and class from the `vtkmodules` package.
@mwestphal Here's an idea for a hackathon
Cc: @utkarsh.ayachit @vboleaDavid GobbiDavid Gobbihttps://gitlab.kitware.com/vtk/vtk/-/issues/18097DeprecationWarning: Converting `np.character` to a dtype is deprecated. When ...2023-10-23T21:03:13-04:00Alex MoldovanDeprecationWarning: Converting `np.character` to a dtype is deprecated. When using pv.wrap(np.array)Getting a
`\Anaconda3\envs\py37_sd\lib\site-packages\vtkmodules\util\numpy_support.py:68:DeprecationWarning: Converting np.character to a dtype is deprecated. The current result is np.dtype(np.str_) which is not strictly correct. Note t...Getting a
`\Anaconda3\envs\py37_sd\lib\site-packages\vtkmodules\util\numpy_support.py:68:DeprecationWarning: Converting np.character to a dtype is deprecated. The current result is np.dtype(np.str_) which is not strictly correct. Note that np.character is generally deprecated and S1 should be used.`
Warning when I run
```python
import vtk
import numpy as np
import pyvista as pv
a = np.array([[0.5,0.5,0.5]])
b = pv.wrap(a)
```
Updated Numpy, VTK and latest PyVista
```md
# Name Version Build Channel
alabaster 0.7.12 py37_0
appdirs 1.4.4 py_0
argon2-cffi 20.1.0 py37he774522_1
astropy 4.2 py37h2bbff1b_0
async_generator 1.10 py37h28b3542_0
atomicwrites 1.4.0 py_0
attrs 20.3.0 pyhd3eb1b0_0
babel 2.9.0 pyhd3eb1b0_0
backcall 0.2.0 py_0
blas 1.0 mkl
bleach 3.2.3 pyhd3eb1b0_0
brotlipy 0.7.0 py37h2bbff1b_1003
bzip2 1.0.8 he774522_0
ca-certificates 2021.1.19 haa95532_0
cached-property 1.5.2 py_0
certifi 2020.12.5 py37haa95532_0
cffi 1.14.4 py37hcd4344a_0
cftime 1.3.1 py37h080aedc_0
chardet 4.0.0 py37haa95532_1003
colorama 0.4.4 pyhd3eb1b0_0
coverage 5.3.1 py37h2bbff1b_2
cryptography 3.3.1 py37hcd4344a_0
curl 7.71.1 h2a8f88b_1
cycler 0.10.0 py37_0
decorator 4.4.2 py_0
defusedxml 0.6.0 py_0
docutils 0.16 py37_1
docxtpl 0.11.3 pyhd3deb0d_0 conda-forge
double-conversion 3.1.5 ha925a31_1
eigen 3.3.7 h74a9793_0
entrypoints 0.3 py37_0
expat 2.2.10 h33f27b4_2
ffmpeg 4.3.1 ha925a31_0 conda-forge
freetype 2.10.4 hd328e21_0
geos 3.8.0 h33f27b4_0
gl2ps 1.4.2 h0597ee9_0 conda-forge
glew 2.1.0 h39d44d4_2 conda-forge
h5py 3.1.0 nompi_py37h19fda09_100 conda-forge
hdf4 4.2.13 h712560f_2
hdf5 1.10.6 nompi_h5268f04_1114 conda-forge
icc_rt 2019.0.0 h0cc432a_1
icu 58.2 ha925a31_3
idna 2.10 pyhd3eb1b0_0
imageio 2.9.0 py_0
imagesize 1.2.0 py_0
importlib-metadata 2.0.0 py_1
importlib_metadata 2.0.0 1
iniconfig 1.1.1 pyhd3eb1b0_0
intel-openmp 2020.2 254
ipykernel 5.3.4 py37h5ca1d4c_0
ipython 7.10.2 py37h39e3cac_0
ipython_genutils 0.2.0 pyhd3eb1b0_1
ipywidgets 7.6.3 pyhd3eb1b0_1
jedi 0.17.2 py37haa95532_1
jinja2 2.11.2 pyhd3eb1b0_0
joblib 1.0.0 pyhd3eb1b0_0
jpeg 9d h8ffe710_0 conda-forge
jsoncpp 1.8.4 h74a9793_0
jsonschema 3.2.0 py_2
jupyter 1.0.0 py37_7
jupyter_client 6.1.7 py_0
jupyter_console 6.2.0 py_0
jupyter_core 4.7.0 py37haa95532_0
jupyterlab_pygments 0.1.2 py_0
jupyterlab_widgets 1.0.0 pyhd3eb1b0_1
kiwisolver 1.3.0 py37hd77b12b_0
krb5 1.18.2 hc04afaa_0
libcurl 7.71.1 h2a8f88b_1
libiconv 1.15 h1df5818_7
libnetcdf 4.7.4 nompi_h3a9aa94_107 conda-forge
libogg 1.3.2 he774522_0
libpng 1.6.37 h2a8f88b_0
libsodium 1.0.18 h62dcd97_0
libssh2 1.9.0 h7a1dbc1_1
libtheora 1.1.1 h62dcd97_1004 conda-forge
libtiff 4.1.0 h56a325e_1
libxml2 2.9.10 hb89e7f3_3
libxslt 1.1.34 he774522_0
loguru 0.5.3 py37hc8dfbb8_2 conda-forge
lxml 4.6.2 py37h9b66d53_0
lz4-c 1.9.2 hf4a77e7_3
m2w64-gcc-libgfortran 5.3.0 6
m2w64-gcc-libs 5.3.0 7
m2w64-gcc-libs-core 5.3.0 7
m2w64-gmp 6.1.0 2
m2w64-libwinpthread-git 5.0.0.4634.697f757 2
markupsafe 1.1.1 py37hfa6e2cd_1
matplotlib 3.3.2 haa95532_0
matplotlib-base 3.3.2 py37hba9282a_0
meshio 4.3.8 pyhd8ed1ab_0 conda-forge
mistune 0.8.4 py37hfa6e2cd_1001
mkl 2020.2 256
mkl-service 2.3.0 py37h196d8e1_0
mkl_fft 1.2.0 py37h45dec08_0
mkl_random 1.1.1 py37h47e9c7a_0
more-itertools 8.6.0 pyhd3eb1b0_0
msys2-conda-epoch 20160418 1
nb_conda 2.2.1 py37_0
nb_conda_kernels 2.3.1 py37haa95532_0
nbclient 0.5.1 py_0
nbconvert 6.0.7 py37_0
nbformat 5.1.2 pyhd3eb1b0_1
nest-asyncio 1.4.3 pyhd3eb1b0_0
netcdf4 1.5.5.1 nompi_py37h4965ef1_101 conda-forge
nose 1.3.7 pyhd3eb1b0_1006
notebook 6.2.0 py37haa95532_0
numpy 1.19.2 py37hadc3359_0
numpy-base 1.19.2 py37ha3acd2a_0
olefile 0.46 py37_0
openssl 1.1.1i h2bbff1b_0
packaging 20.8 pyhd3eb1b0_0
pandas 1.1.5 py37hf11a4ad_0
pandoc 2.11 h9490d1a_0
pandocfilters 1.4.3 py37haa95532_1
parso 0.7.0 py_0
pickleshare 0.7.5 pyhd3eb1b0_1003
pillow 7.0.0 py37hcc1f983_0
pip 20.3.3 py37haa95532_0
pluggy 0.13.1 py37_0
proj 7.1.1 h7d85306_3 conda-forge
prometheus_client 0.9.0 pyhd3eb1b0_0
prompt-toolkit 3.0.8 py_0
prompt_toolkit 3.0.8 0
pugixml 1.10 ha925a31_1 conda-forge
py 1.10.0 pyhd3eb1b0_0
pycparser 2.20 py_2
pyerfa 1.7.1.1 py37h2bbff1b_1
pygments 2.7.4 pyhd3eb1b0_0
pyopenssl 20.0.1 pyhd3eb1b0_1
pyparsing 2.4.7 pyhd3eb1b0_0
pyqt 5.9.2 py37h6538335_2
pyreadline 2.1 py37_1
pyrsistent 0.17.3 py37he774522_0
pysocks 1.7.1 py37_1
pytest 6.2.2 py37haa95532_1
python 3.7.9 h60c2a47_0
python-dateutil 2.8.1 py_0
python-docx 0.8.10 py_0 conda-forge
python_abi 3.7 1_cp37m conda-forge
pytz 2020.5 pyhd3eb1b0_0
pyvista 0.27.4 pyhd8ed1ab_0 conda-forge
pywin32 227 py37he774522_1
pywinpty 0.5.7 py37_0
pyzmq 20.0.0 py37hd77b12b_1
qt 5.9.7 vc14h73c81de_0
qtconsole 4.7.7 py_0
qtpy 1.9.0 py_0
requests 2.25.1 pyhd3eb1b0_0
scikit-learn 0.23.2 py37h47e9c7a_0
scipy 1.5.2 py37h9439919_0
scooby 0.5.6 pyh9f0ad1d_0 conda-forge
seaborn 0.11.1 pyhd3eb1b0_0
send2trash 1.5.0 pyhd3eb1b0_1
setuptools 52.0.0 py37haa95532_0
shapely 1.7.1 py37h210f175_0
sip 4.19.8 py37h6538335_0
six 1.15.0 py37haa95532_0
snowballstemmer 2.1.0 pyhd3eb1b0_0
sphinx 3.4.3 pyhd3eb1b0_0
sphinxcontrib-applehelp 1.0.2 py_0
sphinxcontrib-devhelp 1.0.2 py_0
sphinxcontrib-htmlhelp 1.0.3 py_0
sphinxcontrib-jsmath 1.0.1 py_0
sphinxcontrib-qthelp 1.0.3 py_0
sphinxcontrib-serializinghtml 1.1.4 py_0
sqlite 3.33.0 h2a8f88b_0
tbb 2020.3 h74a9793_0
tbb-devel 2020.3 h74a9793_0
terminado 0.9.2 py37haa95532_0
testpath 0.4.4 py_0
threadpoolctl 2.1.0 pyh5ca1d4c_0
tk 8.6.10 he774522_0
toml 0.10.1 py_0
tornado 6.1 py37h2bbff1b_0
traitlets 5.0.5 py_0
urllib3 1.26.3 pyhd3eb1b0_0
utfcpp 3.1.2 0 conda-forge
vc 14.2 h21ff451_1
vs2015_runtime 14.27.29016 h5e58377_2
vtk 9.0.1 no_osmesa_py37h047e439_102 conda-forge
wcwidth 0.2.5 py_0
webencodings 0.5.1 py37_1
wheel 0.36.2 pyhd3eb1b0_0
widgetsnbextension 3.5.1 py37_0
win32_setctime 1.0.3 py_0 conda-forge
win_inet_pton 1.1.0 py37haa95532_0
wincertstore 0.2 py37_0
winpty 0.4.3 4
xz 5.2.5 h62dcd97_0
zeromq 4.3.3 ha925a31_3
zipp 3.4.0 pyhd3eb1b0_0
zlib 1.2.11 h62dcd97_4
zstd 1.4.5 h04227a9_0
```9.1David GobbiDavid Gobbihttps://gitlab.kitware.com/vtk/vtk/-/issues/18096macOS deprecation warnings2021-02-03T10:09:51-05:00Ben BoeckelmacOS deprecation warningsVTK is currently using some APIs which are deprecated in the newest macOS releases. Could these be resolved at some point?
```
../VTK/Rendering/OpenGL2/vtkCocoaRenderWindow.mm:391:22: warning: 'view' is deprecated: first deprecated in m...VTK is currently using some APIs which are deprecated in the newest macOS releases. Could these be resolved at some point?
```
../VTK/Rendering/OpenGL2/vtkCocoaRenderWindow.mm:391:22: warning: 'view' is deprecated: first deprecated in macOS 10.14 [-Wdeprecated-declarations]
bool ok = [context view] != nil;
^
/Applications/Xcode-12.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSOpenGL.h:193:36: note: property 'view' is declared deprecated here
@property (nullable, weak) NSView *view API_DEPRECATED("", macos(10.0,10.14));
^
/Applications/Xcode-12.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSOpenGL.h:193:36: note: 'view' has been explicitly marked deprecated here
../VTK/Rendering/OpenGL2/vtkCocoaRenderWindow.mm:862:15: warning: 'setWantsBestResolutionOpenGLSurface:' is deprecated: first deprecated in macOS 10.14 - Use NSOpenGLView instead. [-Wdeprecated-declarations]
[glView setWantsBestResolutionOpenGLSurface:wantsBest];
^
/Applications/Xcode-12.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSOpenGLView.h:47:16: note: property 'wantsBestResolutionOpenGLSurface' is declared deprecated here
@property BOOL wantsBestResolutionOpenGLSurface API_DEPRECATED("Use NSOpenGLView instead.", macos(10.7,10.14));
^
/Applications/Xcode-12.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSOpenGLView.h:47:16: note: 'setWantsBestResolutionOpenGLSurface:' has been explicitly marked deprecated here
../VTK/Rendering/OpenGL2/vtkCocoaRenderWindow.mm:882:15: warning: 'setWantsBestResolutionOpenGLSurface:' is deprecated: first deprecated in macOS 10.14 - Use NSOpenGLView instead. [-Wdeprecated-declarations]
[glView setWantsBestResolutionOpenGLSurface:wantsBest];
^
/Applications/Xcode-12.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSOpenGLView.h:47:16: note: property 'wantsBestResolutionOpenGLSurface' is declared deprecated here
@property BOOL wantsBestResolutionOpenGLSurface API_DEPRECATED("Use NSOpenGLView instead.", macos(10.7,10.14));
^
/Applications/Xcode-12.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSOpenGLView.h:47:16: note: 'setWantsBestResolutionOpenGLSurface:' has been explicitly marked deprecated here
../VTK/Rendering/OpenGL2/vtkCocoaRenderWindow.mm:903:14: warning: 'setView:' is deprecated: first deprecated in macOS 10.14 - Use NSOpenGLView to provide OpenGL content in a Cocoa app. [-Wdeprecated-declarations]
[context setView:view];
^
/Applications/Xcode-12.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSOpenGL.h:193:36: note: property 'view' is declared deprecated here
@property (nullable, weak) NSView *view API_DEPRECATED("", macos(10.0,10.14));
^
/Applications/Xcode-12.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSOpenGL.h:194:1: note: 'setView:' has been explicitly marked deprecated here
- (void)setView:(nullable NSView *)view API_DEPRECATED("Use NSOpenGLView to provide OpenGL content in a Cocoa app.", macos(10.0,10.14));
^
../VTK/Rendering/OpenGL2/vtkCocoaRenderWindow.mm:1025:42: warning: 'NSOpenGLCPSwapInterval' is deprecated: first deprecated in macOS 10.14 [-Wdeprecated-declarations]
[context setValues:&one forParameter:NSOpenGLCPSwapInterval];
^~~~~~~~~~~~~~~~~~~~~~
NSOpenGLContextParameterSwapInterval
/Applications/Xcode-12.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSOpenGL.h:258:39: note: 'NSOpenGLCPSwapInterval' has been explicitly marked deprecated here
static const NSOpenGLContextParameter NSOpenGLCPSwapInterval API_DEPRECATED_WITH_REPLACEMENT("NSOpenGLContextParameterSwapInterval", macos(10.5,10.14)) = NSOpenGLContextParameterSwapInterval;
^
../VTK/Rendering/OpenGL2/vtkCocoaRenderWindow.mm:1061:16: warning: 'setView:' is deprecated: first deprecated in macOS 10.14 - Use NSOpenGLView to provide OpenGL content in a Cocoa app. [-Wdeprecated-declarations]
[context setView:view];
^
/Applications/Xcode-12.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSOpenGL.h:193:36: note: property 'view' is declared deprecated here
@property (nullable, weak) NSView *view API_DEPRECATED("", macos(10.0,10.14));
^
/Applications/Xcode-12.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSOpenGL.h:194:1: note: 'setView:' has been explicitly marked deprecated here
- (void)setView:(nullable NSView *)view API_DEPRECATED("Use NSOpenGLView to provide OpenGL content in a Cocoa app.", macos(10.0,10.14));
^
6 warnings generated.
```
Cc: @seanm @cory.quammenSean McBrideSean McBridehttps://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 @rolandolesenolesenhttps://gitlab.kitware.com/vtk/vtk/-/issues/18091openfoam reader fails with some multiregion cases2021-01-27T20:03:10-05:00olesenopenfoam reader fails with some multiregion casesmultiregion case may or may not have a "default" region. The current reader setup however expects its existence and fails when it is missing.multiregion case may or may not have a "default" region. The current reader setup however expects its existence and fails when it is missing.olesenolesenhttps://gitlab.kitware.com/vtk/vtk/-/issues/18089Getting rid of input ghost level parameter in diy ghost cell generator2021-09-28T11:01:12-04:00Yohann Bearzi (Kitware)Getting rid of input ghost level parameter in diy ghost cell generatorThis issue follows !7548. Currently, the diy based ghost cell generator (`vtkGhostCellsGenerator`) takes as input the number of ghost layers of the input set of data sets. This amount of ghost layers is then used to peel off ghosts from ...This issue follows !7548. Currently, the diy based ghost cell generator (`vtkGhostCellsGenerator`) takes as input the number of ghost layers of the input set of data sets. This amount of ghost layers is then used to peel off ghosts from the input when generating them in the output. This peeling step is important because we have no guarantee on the uniformity of the inputs w.r.t. ghosts. This input paramter makes sense if every block in the input have the same number of ghost layers, but this is not enforced.
There is a way to not rely on this input parameter by doing an extensive sweeping of the input data sets one by one to determine the amount of ghost layers in each of them. This should be done in the function `PeelOfGhostLayers` in `vtkDIYGhostUtilities.cxx`.Yohann Bearzi (Kitware)Yohann Bearzi (Kitware)https://gitlab.kitware.com/vtk/vtk/-/issues/18085openfoam reader ignores noSlip type2022-01-20T09:55:18-05:00olesenopenfoam reader ignores noSlip typeas noted in [openfoam issue #1981](https://develop.openfoam.com/Development/openfoam/-/issues/1981), some of the boundary handling can be quite misleading.
The OpenFOAM reader has some special provision for patches with a "values" entry...as noted in [openfoam issue #1981](https://develop.openfoam.com/Development/openfoam/-/issues/1981), some of the boundary handling can be quite misleading.
The OpenFOAM reader has some special provision for patches with a "values" entry. In some cases, this is also used to define cell-to-point interpolated values too. If this entry is missing, it uses the patch cell value instead. This works well for many cases, but for a _noSlip_ boundary condition it is quite misleading.
Probably need some additional patch handling for particular types, without attempting to replicate all of OpenFOAM.olesenolesenhttps://gitlab.kitware.com/vtk/vtk/-/issues/18083The Opacity example is abnormal. When the Opacity is less than 1, the object ...2021-01-15T09:57:58-05:00WangZP10969The Opacity example is abnormal. When the Opacity is less than 1, the object disappearsDear sir
Test example: https://kitware.github.io/vtk-examples/site/Cxx/Visualization/Opacity/
VTK 9.0.1
Windows10-x64
I only modified the 35 lines of the example, which is the part to adjust the transparency
But when the transparency ...Dear sir
Test example: https://kitware.github.io/vtk-examples/site/Cxx/Visualization/Opacity/
VTK 9.0.1
Windows10-x64
I only modified the 35 lines of the example, which is the part to adjust the transparency
But when the transparency is less than 1, the object will disappear
Is there a problem with my writing? Or is the routine not suitable for this version of vtk9.0.1?
Looking forward to your help
`line 35: sphereActor->GetProperty()->SetOpacity(0.7);`
![image](/uploads/73df05a9d8178e079d9e33d32cf2095a/image.png)
`line 35: sphereActor->GetProperty()->SetOpacity(1);`
![image](/uploads/25fc965cc7a22913b2a282991c8d7391/image.png)
```
#include <vtkActor.h>
#include <vtkCamera.h>
#include <vtkCubeSource.h>
#include <vtkNamedColors.h>
#include <vtkNew.h>
#include <vtkPolyDataMapper.h>
#include <vtkProperty.h>
#include <vtkRenderWindow.h>
#include <vtkRenderWindowInteractor.h>
#include <vtkRenderer.h>
#include <vtkSphereSource.h>
int main(int, char*[])
{
vtkNew<vtkNamedColors> colors;
// Cube
vtkNew<vtkCubeSource> cubeSource;
vtkNew<vtkPolyDataMapper> cubeMapper;
cubeMapper->SetInputConnection(cubeSource->GetOutputPort());
vtkNew<vtkActor> cubeActor;
cubeActor->GetProperty()->SetOpacity(0.5);
cubeActor->SetMapper(cubeMapper);
cubeActor->GetProperty()->SetColor(colors->GetColor3d("MistyRose").GetData());
// Sphere
vtkNew<vtkSphereSource> sphereSource;
vtkNew<vtkPolyDataMapper> sphereMapper;
sphereMapper->SetInputConnection(sphereSource->GetOutputPort());
vtkNew<vtkActor> sphereActor;
sphereActor->GetProperty()->SetColor(
colors->GetColor3d("LightGreen").GetData());
sphereActor->GetProperty()->SetOpacity(0.7);
sphereActor->SetMapper(sphereMapper);
// Create renderers and add actors of plane and cube
vtkNew<vtkRenderer> renderer;
renderer->AddActor(cubeActor);
renderer->AddActor(sphereActor);
// Add renderer to renderwindow and render
vtkNew<vtkRenderWindow> renderWindow;
renderWindow->AddRenderer(renderer);
renderWindow->SetWindowName("Opacity");
renderer->SetBackground(colors->GetColor3d("DimGray").GetData());
renderWindow->Render();
renderer->GetActiveCamera()->Azimuth(-22.5);
renderer->GetActiveCamera()->Elevation(30);
vtkNew<vtkRenderWindowInteractor> interactor;
interactor->SetRenderWindow(renderWindow);
renderWindow->Render();
interactor->Start();
return EXIT_SUCCESS;
}
```https://gitlab.kitware.com/vtk/vtk/-/issues/18082openfoam reader segfaults on large meshes2021-03-23T13:45:50-04:00olesenopenfoam reader segfaults on large meshesIssue reported on [discourse](https://discourse.paraview.org/t/segementation-fault-when-opening-openfoam-data/6063).
As part of #18081 took a closer look at some of the internals. Likely related to overrunning 32-bit integers.
@jpouderouxIssue reported on [discourse](https://discourse.paraview.org/t/segementation-fault-when-opening-openfoam-data/6063).
As part of #18081 took a closer look at some of the internals. Likely related to overrunning 32-bit integers.
@jpouderouxolesenolesenhttps://gitlab.kitware.com/vtk/vtk/-/issues/18081openfoam reader ignores embedded 32/64-bit information2021-01-27T20:03:09-05:00olesenopenfoam reader ignores embedded 32/64-bit informationThe additional `arch` information in FoamFile header provides information about the precision of the contents (integer and floats). However, most of the reader doesn't handle this properly and blindly applies the values from the GUI in v...The additional `arch` information in FoamFile header provides information about the precision of the contents (integer and floats). However, most of the reader doesn't handle this properly and blindly applies the values from the GUI in various places.
For mixed workflows this becomes as complete disaster (ie, SEGFAULT).
For an example of a "mixed workflow":
- surface preparation and meshing (snappyHexMesh) with 64-bit labels and double precision
- initial calculation with the same settings
- restart and run calculation with mixed precision - field storage in single precision, with the linear solver running in double precision.
Since the internal file representation changes between time steps, there is no GUI setting that works.olesenolesenhttps://gitlab.kitware.com/vtk/vtk/-/issues/18080Weird output library names in OSX2021-01-15T11:36:15-05:00B3nniWeird output library names in OSXIn OSX, for both v9.0.1 and head (594734), some (not all) shared output libraries are named `libvtk<name>9.0.9.0.0.dylib` (for head), or `libvtk<name>9.0.9.0.1` (for v9.0.1).
Everything kinda works, because there are symlinks created at...In OSX, for both v9.0.1 and head (594734), some (not all) shared output libraries are named `libvtk<name>9.0.9.0.0.dylib` (for head), or `libvtk<name>9.0.9.0.1` (for v9.0.1).
Everything kinda works, because there are symlinks created at the correct spot:
`libvtk<name>9.0.dylib` -> `libvtk<name>9.0.x.dylib` -> `libvtk<name>9.0.9.0.x.dylib`
However, I assume, the libraries should actually be created directly to `libvtk<name>9.0.x.dylib`, with only the first symlink in the above chain necessary. (Nothing ever links to the 9.0.9.0.x versions.). This was also the behaviour in the past.
Below, I attached a script to reproduce the behaviour and list system info, and its output on my machine.
```bash
#!/bin/bash
cwd=$(pwd)
git clone https://github.com/Kitware/VTK.git src
mkdir bin
mkdir ins
cd bin
echo "Cmakeing..."
cmake -G Xcode \
-DCMAKE_INSTALL_PREFIX:PATH=$cwd/ins \
-VTK_BUILD_TESTING=false \
-VTK_BUILD_DOCUMENTATION=false \
../src > /dev/null
cd ..
echo "Building..."
cmake --build ./bin --target install --config Release > /dev/null
echo "--- CMAKE ver: ---"
cmake --version
echo "--- DEV ENV: ---"
system_profiler SPDeveloperToolsDataType
echo "--- First 5 weirdly named VTK libs in build tree: ---"
ls ./bin/lib/Release/*9.0.9* | head -5
echo "--- Same names in install tree: ---"
ls ./ins/lib/*9.0.9* | head -5
```
Output:
```
$ ./vtk_compile_test.sh
Cloning into 'src'...
remote: Enumerating objects: 160, done.
remote: Counting objects: 100% (160/160), done.
remote: Compressing objects: 100% (122/122), done.
remote: Total 594894 (delta 61), reused 99 (delta 35), pack-reused 594734
Receiving objects: 100% (594894/594894), 225.58 MiB | 10.85 MiB/s, done.
Resolving deltas: 100% (455435/455435), done.
Updating files: 100% (18397/18397), done.
Cmakeing...
Building...
--- CMAKE ver: ---
cmake version 3.19.2
CMake suite maintained and supported by Kitware (kitware.com/cmake).
--- DEV ENV: ---
Developer:
Developer Tools:
Version: 11.6 (11E708)
Location: /Applications/Xcode.app
Applications:
Xcode: 11.6 (16141)
Instruments: 11.6 (64535.76)
SDKs:
iOS:
13,6: (17G64)
iOS Simulator:
13,6: (17G64)
macOS:
10.15.6: (19G68)
19,0:
tvOS:
13,4: (17L255)
tvOS Simulator:
13,4: (17L255)
watchOS:
6,2: (17T255)
watchOS Simulator:
6,2: (17T255)
--- First 5 weirdly named VTK libs in build tree: ---
./bin/lib/Release/libvtkChartsCore-9.0.9.0.0.dylib
./bin/lib/Release/libvtkCommonColor-9.0.9.0.0.dylib
./bin/lib/Release/libvtkCommonComputationalGeometry-9.0.9.0.0.dylib
./bin/lib/Release/libvtkCommonCore-9.0.9.0.0.dylib
./bin/lib/Release/libvtkCommonDataModel-9.0.9.0.0.dylib
--- Same names in install tree: ---
./ins/lib/libvtkChartsCore-9.0.9.0.0.dylib
./ins/lib/libvtkCommonColor-9.0.9.0.0.dylib
./ins/lib/libvtkCommonComputationalGeometry-9.0.9.0.0.dylib
./ins/lib/libvtkCommonCore-9.0.9.0.0.dylib
./ins/lib/libvtkCommonDataModel-9.0.9.0.0.dylib
```https://gitlab.kitware.com/vtk/vtk/-/issues/18078VTK Loguru incompatible with Alpine Linux2023-05-26T21:03:14-04:00Mathieu Westphal (Kitware)VTK Loguru incompatible with Alpine LinuxBuilding VTK without any options on Alpine will fail with the following:
```
[ 88%] Linking CXX executable ../../bin/vtkProbeOpenGLVersion-9.0
/usr/lib/gcc/x86_64-alpine-linux-musl/9.3.0/../../../../x86_64-alpine-linux-musl/bin/ld: /vtk...Building VTK without any options on Alpine will fail with the following:
```
[ 88%] Linking CXX executable ../../bin/vtkProbeOpenGLVersion-9.0
/usr/lib/gcc/x86_64-alpine-linux-musl/9.3.0/../../../../x86_64-alpine-linux-musl/bin/ld: /vtk/vtk_build/lib64/libvtkloguru-9.0.so.1: undefined reference to `backtrace_symbols'
/usr/lib/gcc/x86_64-alpine-linux-musl/9.3.0/../../../../x86_64-alpine-linux-musl/bin/ld: /vtk/vtk_build/lib64/libvtkloguru-9.0.so.1: undefined reference to `backtrace'
collect2: error: ld returned 1 exit status
```
loguru is suposed to be compatible with alpine, so not sure what would be the right resolution.
In any case, passing -DVTK_ENABLE_LOGGING=OFF work around the issue.
FYI @ben.boeckel @michael.miglioreBen BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/18077vtkImageReslice problem on multi-frame DICOMs2021-01-21T11:08:27-05:00Philipp WeissenbachervtkImageReslice problem on multi-frame DICOMsOS: Windows 10
VTK: v9.0.0
I am using `vtkImageReslice` to extract interpolated slices of a DICOM dataset to store them as preview images in JPEG format with the `vtkJPEGWriter`.
With single-frame DICOMS this works as expected but with ...OS: Windows 10
VTK: v9.0.0
I am using `vtkImageReslice` to extract interpolated slices of a DICOM dataset to store them as preview images in JPEG format with the `vtkJPEGWriter`.
With single-frame DICOMS this works as expected but with multi-frame DICOMS, the output of the `vtkImageReslice` filter returns a `vtkImageData` with correct dimensionality, but a big number of components (one component for each frame within the dataset).
When invoking the `vtkJPEGWriter` I get error messages that the maximum supported number of components are exceeded (e.g. `414 > 10` in my case).
What's the preferred method to get interpolated slices out of the multi-frame DICOM to store them as JPEG images?
Example code:
Input: multi-frame DICOM with 414 frames
```
// Reading in the image and orientation computation not shown here
// Extract a slice in the desired orientation
vtkSmartPointer<vtkImageReslice> reslice =
vtkSmartPointer<vtkImageReslice>::New();
reslice->SetInputConnection(_dicomReader->GetOutputPort());
reslice->SetOutputDimensionality(2);
reslice->SetResliceAxes(resliceAxes);
reslice->SetInterpolationModeToLinear();
double range[2];
_dicomReader->GetOutput()->GetScalarRange(range);
//set backgroundlevel
reslice->SetBackgroundLevel(range[0]);
reslice->AutoCropOutputOn();
reslice->SetOutputExtent(imageDimensions);
reslice->SetOutputSpacing(imageSpacing);
reslice->Update();
```https://gitlab.kitware.com/vtk/vtk/-/issues/18076vtkDICOMReader->Update() endless loop2021-01-30T14:26:35-05:00Philipp WeissenbachervtkDICOMReader->Update() endless loopOS: Windows 10
VTK: v9.0.1
I've got a single-frame DICOM image, which when read by the `vtkDICOMReader` results in an endless loop within the internal `mvtkDICOMParser`, specifically within the `while` loop in vtkDICOMParser.cxx line 21...OS: Windows 10
VTK: v9.0.1
I've got a single-frame DICOM image, which when read by the `vtkDICOMReader` results in an endless loop within the internal `mvtkDICOMParser`, specifically within the `while` loop in vtkDICOMParser.cxx line 2141-2257.
Unfortunatelly I cannot provide the DICOM file due to privacy policies. Each attempt to anonymize the DICOM image (rewriting the metaData, obfuscating the pixel data) which requires a re-safe of the image will result in a properly working DICOM file.
I found out, that the DICOM file has 3 bytes of trailing zeros (hex: `00 00 00 00 00 00`) in it. Removing those 3 bytes solves the issue.
![Trailing_Zeros](/uploads/f5c6b2e359b663ee3e25318b7351c6ea/Trailing_Zeros.png)
Is this file just corrupted, or are there any DICOM formats out there, which have those trailing zero bytes? I strongly think that the implementation of the `vtkDICOMReader` works as intended, but maybe someone could give me some kind of hint what's wrong with my use case.
Sincerely,
Philipp Weißenbacherhttps://gitlab.kitware.com/vtk/vtk/-/issues/18075Link failure w.r.t. pugixml2021-01-07T14:24:43-05:00Matthew WoehlkeLink failure w.r.t. pugixmlWhile trying to build VTK 9.0.1, I get the following errors:
```
[1/88] Linking CXX shared library lib64/libvtkIOCityGML-9.0.so.9.0.1
FAILED: lib64/libvtkIOCityGML-9.0.so.9.0.1
: && /usr/lib64/ccache/c++ -fPIC -std=c++11 -O2 -g -DNDEBUG...While trying to build VTK 9.0.1, I get the following errors:
```
[1/88] Linking CXX shared library lib64/libvtkIOCityGML-9.0.so.9.0.1
FAILED: lib64/libvtkIOCityGML-9.0.so.9.0.1
: && /usr/lib64/ccache/c++ -fPIC -std=c++11 -O2 -g -DNDEBUG -Wl,-lc -Wl,--no-undefined -shared -Wl,-soname,libvtkIOCityGML-9.0.so.1 -o lib64/libvtkIOCityGML-9.0.so.9.0.1 IO/CityGML/CMakeFiles/IOCityGML.dir/vtkCityGMLReader.cxx.o -Wl,-rpath,<build>/lib64: lib64/libvtkFiltersModeling-9.0.so.9.0.1 lib64/libvtkFiltersGeneral-9.0.so.9.0.1 lib64/libvtkFiltersCore-9.0.so.9.0.1 lib64/libvtkCommonExecutionModel-9.0.so.9.0.1 lib64/libvtkCommonDataModel-9.0.so.9.0.1 lib64/libvtkCommonTransforms-9.0.so.9.0.1 lib64/libvtkCommonMisc-9.0.so.9.0.1 lib64/libvtkCommonMath-9.0.so.9.0.1 lib64/libvtkCommonCore-9.0.so.9.0.1 -lpthread lib64/libvtksys-9.0.so.9.0.1 -ldl -Wl,-rpath-link,<build>/lib64 && :
/usr/bin/ld: IO/CityGML/CMakeFiles/IOCityGML.dir/vtkCityGMLReader.cxx.o: in function `vtkCityGMLReader::RequestData(vtkInformation*, vtkInformationVector**, vtkInformationVector*)':
<source>/IO/CityGML/vtkCityGMLReader.cxx:1053: undefined reference to `pugi::xml_document::xml_document()'
/usr/bin/ld: <source>/IO/CityGML/vtkCityGMLReader.cxx:1054: undefined reference to `pugi::xml_document::load_file(char const*, unsigned int, pugi::xml_encoding)'
/usr/bin/ld: <source>/IO/CityGML/vtkCityGMLReader.cxx:1057: undefined reference to `pugi::xml_parse_result::operator bool() const'
/usr/bin/ld: <source>/IO/CityGML/vtkCityGMLReader.cxx:1061: undefined reference to `pugi::xml_parse_result::description() const'
/usr/bin/ld: <source>/IO/CityGML/vtkCityGMLReader.cxx:1053: undefined reference to `pugi::xml_document::~xml_document()'
...many more similar undefined references...
```
I am using system pugixml. Note that the link line contains no reference to pugixml, despite that the module has a `PRIVATE_DEPENDS` on `VTK::pugixml`. Unfortunately, it is not easy to debug VTK's rather esoteric build system.
This is likely to be an issue for distribution packaging as well, since using the bundled pugixml is not an option.https://gitlab.kitware.com/vtk/vtk/-/issues/18074No python39 wheels available2021-07-02T05:43:10-04:00Daniel ScheiermannNo python39 wheels availableOn archlinux the current python version is 3.9.
I want to use vtk in a python package and it should be also available for those users.
Sadly there are no wheel build with python3.9.
To make the install process easier I build it myself an...On archlinux the current python version is 3.9.
I want to use vtk in a python package and it should be also available for those users.
Sadly there are no wheel build with python3.9.
To make the install process easier I build it myself and would like to provide the build. I would be happy, if you could add it to PyPI.https://gitlab.kitware.com/vtk/vtk/-/issues/18072vtkStringArray Memory Exceptions2021-01-07T04:39:18-05:00Philipp WeissenbachervtkStringArray Memory ExceptionsEnvironment of issue:
- Windows 10 Pro
- VTK v9.0.1
I've been using vtkStringArray in a programm of mine with the VTK v7.0.0 like so:
```
std::vector<std::string> fileList = Directory::ListAllFiles(dicomFolderPath, false);
std::vecto...Environment of issue:
- Windows 10 Pro
- VTK v9.0.1
I've been using vtkStringArray in a programm of mine with the VTK v7.0.0 like so:
```
std::vector<std::string> fileList = Directory::ListAllFiles(dicomFolderPath, false);
std::vector<std::string> nonDICOMs;
vtkSmartPointer<vtkDICOMReader> findNonDICOMS = vtkSmartPointer<vtkDICOMReader>::New();
vtkStringArray* filesToRead = vtkStringArray::New();
for (int i = 0; i < fileList.size(); i++)
{
if (!findNonDICOMS->CanReadFile(fileList.at(i).c_str()))
{
nonDICOMs.push_back(fileList.at(i));
}
else
{
filesToRead->InsertNextValue(fileList.at(i));
}
}
```
`fileList` is a `std::vector<std::string>>` and I'm checking if the vtkDICOMReader can read all the files within this list.
With VTK v7.0.0 everything works as expected. After the code snippet I'll get a vtkStringArray `filesToRead` containg all DICOMs readable by the `vtkDICOMReader`.
Today I wanted to update VTK to v9.0.0 and suddenly `vtkStringArray` throws exceptions when executing `filesToRead->InsertNextValue(fileList.at(i))`.
![image](/uploads/2eae336234e91d4c5f2518dd1e451d5c/image.png)
Same exception can be reproduced with this small code snippet:
```
vtkStringArray* filenames = vtkStringArray::New();
std::string temp = "test";
filenames->InsertNextValue(temp);
```
I've also tried to instantiate the `vtkStringArray` as a SmartPointer - same result.
Has something changed from v7.0.0 to v9.0.1 concerning the vtkStringArray`? Am I using it wrong - if so, why does it work with v7.0.0 and not in v9.0.1?
Sincerely,
Philipp Weißenbacherhttps://gitlab.kitware.com/vtk/vtk/-/issues/18071vtkOSPRayMaterialLibrary::InternalParseJSON() is slow when materials library ...2021-01-05T09:50:20-05:00Cory Quammencory.quammen@kitware.comvtkOSPRayMaterialLibrary::InternalParseJSON() is slow when materials library has many textures.A large amount of time is spent in a call to `vtksys::SystemTools::GetParentDirectory(filename)` inside a loop over textures. Since this parent never changes, moving the call outside the loop should speed things up.A large amount of time is spent in a call to `vtksys::SystemTools::GetParentDirectory(filename)` inside a loop over textures. Since this parent never changes, moving the call outside the loop should speed things up.Cory Quammencory.quammen@kitware.comCory Quammencory.quammen@kitware.com