VTK issueshttps://gitlab.kitware.com/vtk/vtk/-/issues2023-09-27T07:59:01-04:00https://gitlab.kitware.com/vtk/vtk/-/issues/19110XR: Add option to pick all actors2023-09-27T07:59:01-04:00Mathieu Westphal (Kitware)XR: Add option to pick all actors**Story**: As a ParaView user, I would like to grab or pick all objects of the scene at once instead of one at a time.
**Suggestion**: Investigate the possibility to grab or pick all objects at once (e.g. using a checkbox in the menu?)....**Story**: As a ParaView user, I would like to grab or pick all objects of the scene at once instead of one at a time.
**Suggestion**: Investigate the possibility to grab or pick all objects at once (e.g. using a checkbox in the menu?).
Add a modifier button to provide a modified version of the original grab/pick.https://gitlab.kitware.com/vtk/vtk/-/issues/19109VR: vtkMolecule are not displated correctly in VR2023-09-27T07:37:30-04:00Mathieu Westphal (Kitware)VR: vtkMolecule are not displated correctly in VR**Description**: **Molecules** (`vtkMolecule` type) are not displayed correctly in VR mode (see picture where atoms are not scaled properly).
![BadMoleculeRendering](/uploads/bdf6391d50e2a4694c9d1633a6f877dc/BadMoleculeRendering.png)**Description**: **Molecules** (`vtkMolecule` type) are not displayed correctly in VR mode (see picture where atoms are not scaled properly).
![BadMoleculeRendering](/uploads/bdf6391d50e2a4694c9d1633a6f877dc/BadMoleculeRendering.png)https://gitlab.kitware.com/vtk/vtk/-/issues/19108VR: Investigate possibilities to test interactions and rendering2023-09-27T06:21:56-04:00Mathieu Westphal (Kitware)VR: Investigate possibilities to test interactions and renderingInvestigate solutions for rendering and interactions CI with VR:
- Monado: https://monado.dev/
- PerceptionDevice: https://learn.microsoft.com/en-us/windows/mixed-reality/develop/advanced-concepts/perception-simulation-standaloneInvestigate solutions for rendering and interactions CI with VR:
- Monado: https://monado.dev/
- PerceptionDevice: https://learn.microsoft.com/en-us/windows/mixed-reality/develop/advanced-concepts/perception-simulation-standalonehttps://gitlab.kitware.com/vtk/vtk/-/issues/19107TestAvatar: Move to VR module2023-09-27T06:03:32-04:00Mathieu Westphal (Kitware)TestAvatar: Move to VR moduleTestAvatar is not specific to OpenVR, should be moved to VR moduleTestAvatar is not specific to OpenVR, should be moved to VR modulehttps://gitlab.kitware.com/vtk/vtk/-/issues/19106vtkOpenXRUtilities: Make it a namespace instead of a class2023-09-27T05:50:15-04:00Mathieu Westphal (Kitware)vtkOpenXRUtilities: Make it a namespace instead of a classvtkOpenXRUtilities should be a namespace instead of a classvtkOpenXRUtilities should be a namespace instead of a classhttps://gitlab.kitware.com/vtk/vtk/-/issues/19105OpenXR: Display controller model2024-03-01T17:42:16-05:00Mathieu Westphal (Kitware)OpenXR: Display controller modelAdd support for displaying controller model using OpenXR.Add support for displaying controller model using OpenXR.https://gitlab.kitware.com/vtk/vtk/-/issues/19104VR: Improve vtkVRControlsHelper/vtkVRModel doc2023-09-27T05:39:21-04:00Mathieu Westphal (Kitware)VR: Improve vtkVRControlsHelper/vtkVRModel docvtkVRControlsHelper and vtkVRModel documentation is very sparse, improve itvtkVRControlsHelper and vtkVRModel documentation is very sparse, improve ithttps://gitlab.kitware.com/vtk/vtk/-/issues/19103XR: Rework interaction mechanism to avoid duplication of logic and .json file2024-03-01T17:42:44-05:00Mathieu Westphal (Kitware)XR: Rework interaction mechanism to avoid duplication of logic and .json file - Create a mechanism to generate .json file as needed, either at runtime or compile time
- Create a generic .json file for any unknow headset to fallback on
Was:
```
Create a generic binding .json to fallback for all other controlle... - Create a mechanism to generate .json file as needed, either at runtime or compile time
- Create a generic .json file for any unknow headset to fallback on
Was:
```
Create a generic binding .json to fallback for all other controllers
Implement a generic way of handling actions (action paths, action updates/processing, etc.)
```
```
**Description**: When using VTK or ParaView with OpenVR or OpenXR, a given controller brand does not always have the same button mappings for the same action. This is also the case between different controllers, which makes it confusing to interact in XR.
**Objective**: Unify controller bindings in the JSON files for **(i)** all controllers, for **(ii)** VTK and ParaView, as well as for **(iii)** OpenVR and OpenXR.
Ideally, try to use:
- Joysticks for movement (left for movement, right for elevation)
- Triggers for trigger actions
- Grip buttons for grip actions (else use buttons)
- Right controller button for opening the menu
```https://gitlab.kitware.com/vtk/vtk/-/issues/19102vtkVRRenderWindowInteractor: Implement InternalCreateTimer/InternalDestroyTimer2023-09-27T04:56:01-04:00Mathieu Westphal (Kitware)vtkVRRenderWindowInteractor: Implement InternalCreateTimer/InternalDestroyTimer`vtkVRRenderWindowInteractor::InternalCreateTimer` and `vtkVRRenderWindowInteractor::InternalDestroyTimer` are missing, let's implement them`vtkVRRenderWindowInteractor::InternalCreateTimer` and `vtkVRRenderWindowInteractor::InternalDestroyTimer` are missing, let's implement themhttps://gitlab.kitware.com/vtk/vtk/-/issues/19099Easier data access for parallel VTK formats2023-09-26T13:06:26-04:00Boonthanome NouanesengsyEasier data access for parallel VTK formatsIt would be useful for users if there was an easier method to fetch data from parallel VTK formats. Currently, a user will need to step through all the pieces of a multipiece dataset, and fetch the arrays individually. Then there are als...It would be useful for users if there was an easier method to fetch data from parallel VTK formats. Currently, a user will need to step through all the pieces of a multipiece dataset, and fetch the arrays individually. Then there are also issues like ghost cells and points that need to be taken into account.
So it would be good to have a method to fetch a cell or point data array that
- contains all data over all partitions
- returns data in a consistent manner
- takes into account ghost cells or ghost points
Another way to phrase this is "give me the data as if this was a serial dataset". We've discussed it with Kitware, and some method in the Numpy VTK integration sounds like a natural fit.
@patchett2002 @cory.quammen @berkgevecihttps://gitlab.kitware.com/vtk/vtk/-/issues/19098IO Improvements Proposal: Documentation, Safety, Performance, Input/Output Re...2023-09-26T10:38:37-04:00Spiros TsalikisIO Improvements Proposal: Documentation, Safety, Performance, Input/Output ResourceThe VTK IO directory as a whole could potentially be improved in various ways:
1. Documentation:
1. Current Status: https://docs.vtk.org/en/latest/supported_data_formats.html lists the formats that are currently supported by VTK.
...The VTK IO directory as a whole could potentially be improved in various ways:
1. Documentation:
1. Current Status: https://docs.vtk.org/en/latest/supported_data_formats.html lists the formats that are currently supported by VTK.
2. Problem: This list is located at https://gitlab.kitware.com/vtk/vtk/-/blob/master/Documentation/docs/supported_data_formats.yaml, and since it's manually generated, it's easy to forget to update it. Many people choose libraries based on if their file formats are supported or not, and omitting to update this list could be critical.
3. Suggested Solution: This list could potentially be scraped by looking
1. vtk.module related information that could include file extensions supported, and format documentation
2. the classes ending with Reader/Writer and get the list of classes
3. and the brief description of each class
2. Safety:
1. Current Status: various readers when reading a file, they assume that the file is properly written.
2. Problem: Files are usually properly written, but if they are not, VTK (and the applications using VTK) may crash. Also, various readers/writers use C functions, such as ``atoi``, that are not memory safe which can lead to other types of crashes.
3. Suggested Solution: use C++ functions that perform error checking and make sure that every call of them checks for errors.
3. Performance:
1. Almost all readers/writer are using C functions or C++ streams
2. Problem: These C functions are slow and not safe, and streams are super slow.
3. Suggested Solution: Develop functions for converting string from/to values libraries such as ``fast_float``, ``fmt``. An example is ``vtkValueFromString``.
4. Input/Output Resource:
1. Current Status: Various Readers/Writers can read from a file, and some can read also from strings
2. Problem: Most readers (with the exception of the complex ones that read one Meta files to read specific files) should support reading from any type of resource such as files, or strings, or something else in the future. ``vtkResourceStream`` started this work to support various resources, but it's now only for reading, not writing too, and it was integrated into only 3 readers (PLY, OBJ, glTF).
3. Suggested Solution: Make ``vtkResourceStream`` bi-directionally and expand its usage to all readers/writers possible.
P.S. Feel free to edit the above description if you have further ideas or edits.
KUS: @ben.boeckel @christos.tsolakis @cory.quammen @berkgeveci @will.schroeder
KEU: @mwestphal @alexy.pellegrini
Others: @wascott @patchett2002 @acbauerSpiros TsalikisSpiros Tsalikishttps://gitlab.kitware.com/vtk/vtk/-/issues/19097WASM: Run C++ tests in webassembly environments2024-03-26T20:21:01-04:00Jaswant Panchumarti (Kitware)WASM: Run C++ tests in webassembly environmentsCurrently, VTK C++ tests are run only on x86_64 desktops. VTK advertises support for the wasm32-emscripten architecture and there is a CI build job which ensures that VTK continues to compile with emscripten, which is great, but not enou...Currently, VTK C++ tests are run only on x86_64 desktops. VTK advertises support for the wasm32-emscripten architecture and there is a CI build job which ensures that VTK continues to compile with emscripten, which is great, but not enough because there are folks who use vtk.wasm in production. It is currently impossible to know whether a merge request breaks something in wasm without someone sitting down to code up a test case manually. This is pointless because there are already a large number of C++ tests in VTK.
So far, we've been able to identify and fix:
1. regression introduced by https://gitlab.kitware.com/vtk/vtk/-/merge_requests/10356 (fixed by https://gitlab.kitware.com/vtk/vtk/-/merge_requests/10521)
2. regression introduced by https://gitlab.kitware.com/vtk/vtk/-/merge_requests/10403 (fixed by https://gitlab.kitware.com/vtk/vtk/-/merge_requests/10466)
3. https://gitlab.kitware.com/vtk/vtk/-/merge_requests/10503 could've easily been caught in a unit test.
4. Somebody broke vertex visibility and the feature to render vertices as spheres. Still don't know when/where it occurred.
In all the above cases, we could have saved a lot of time and resources if the C++ unit tests in VTK source ran automatically in the browser too. It's not really all that complicated or new and emscripten has been doing it for a long time.
After looking at emscripten's [automated workflows](https://app.circleci.com/pipelines/github/emscripten-core/emscripten/30669/workflows/4e4b1434-6a1a-402e-8640-e183830e6fde), here's some ideas:
1. Have two test jobs for now. (firefox, chromium) Can be expanded to include nodejs for pure compute and wasmtime for wasi based tests.
2. Since the priority is rendering, the focus is on browsers. It's best to not use the OS provided browsers, as we do not wish to pollute user data directory. So, download firefox, chrome tarballs and set the `BROWSER` environment variable to something like:
```sh
# For firefox
export BROWSER="/root/firefox/firefox -headless -profile /root/tmp-firefox-profile/"
# For chromium
export BROWSER="/root/chrome-linux/chrome --enable-unsafe-webgpu --no-first-run -start-maximized --no-sandbox --user-data-dir=/root/tmp-chromium-profile --enable-experimental-web-platform-features --remote-debugging-port=1234 --enable-experimental-webassembly-features --js-flags=--experimental-wasm-memory64 --experimental-wasm-stack-switching --experimental-wasm-type-reflection --media-cache-size=1 --disable-application-cache --incognito"
```
3. Write a python script (`vtkBrowserTestDriver.py`) to launch browser and run the wasm tests. This script can use the builtin `webbrowser` python module to open browser windows. `ExternalData_add_test` in `vtkModuleTesting.cmake` could run this python script with the remaining test arguments.
```sh
python vtkBrowserTestDriver.py --executable vtkRenderingCoreCxxTests.js --args -D ... -V ... -T ...
```
I'm currently optimizing the memory usage in VTK OpenGL ES polydata mapper. As it could potentially break a number of things which are hard to test manually, I plan to come up with basic testing infrastructure as outlined above soon.https://gitlab.kitware.com/vtk/vtk/-/issues/19095QT MainWindow overlapping with other viewer2023-09-25T04:49:07-04:00Joseph BurgessQT MainWindow overlapping with other viewerThis is a small demo. My project is much larger. However, this seems to replicate similar results. I have 2 QVTKRenderWindowInteractors. When I resize them painting bugs appear. In my project's case, one of the windows is just white whic...This is a small demo. My project is much larger. However, this seems to replicate similar results. I have 2 QVTKRenderWindowInteractors. When I resize them painting bugs appear. In my project's case, one of the windows is just white which should not be happening and the other side widgets seem to be painted into the background of the docking widget which holds the Interactor. I tried to see if the painting events were triggering for my project and I saw that only one of the viewers painting events was going off. I also tried getting the painting event to fire by calling repaint but that didn't seem to work. Again this is just a demo with similar results. When I place 2 normal widgets in the resizing works fine. It seems to be an issue with how vtk connects to QT.
This is a picture of the actual glitch on my application.
![image](/uploads/24bb0b641f31bbb06105d084b4e47f87/image.png)
![image](/uploads/68fc6b3e90c524c86f89e1266a616b1f/image.png)
This is the error on the demo application:
![image](/uploads/c892ace0571ff7e20c55cab118ceee63/image.png)
```
from PyQt6 import QtWidgets, QtGui, QtCore
import sys
from vtkmodules.qt.QVTKRenderWindowInteractor import QVTKRenderWindowInteractor
class CustomWidget(QtWidgets.QWidget):
def __init__(self, parent=None):
super().__init__(parent)
layout = QtWidgets.QVBoxLayout(self)
layout.setContentsMargins(0, 0, 0, 0)
layout.setSpacing(0)
label = QtWidgets.QLabel("Coordinates Label", self)
self.interactor = QVTKRenderWindowInteractor(self)
self.interactor.Initialize()
self.interactor.Start()
layout.addWidget(label)
layout.addWidget(self.interactor)
def trigger_render(self):
if self.interactor:
self.interactor.GetRenderWindow().Render()
class MainWindow(QtWidgets.QMainWindow):
def __init__(self, parent=None):
super().__init__(parent)
self.dock_widget1 = QtWidgets.QDockWidget("Dock 1", self)
custom_widget1 = CustomWidget(self.dock_widget1)
self.dock_widget1.setWidget(custom_widget1)
self.addDockWidget(QtCore.Qt.DockWidgetArea.BottomDockWidgetArea, self.dock_widget1)
self.dock_widget2 = QtWidgets.QDockWidget("Dock 2", self)
custom_widget2 = CustomWidget(self.dock_widget2)
self.dock_widget2.setWidget(custom_widget2)
self.addDockWidget(QtCore.Qt.DockWidgetArea.BottomDockWidgetArea, self.dock_widget2)
self.resize(800, 600)
# Trigger render after the widget has been shown
QtCore.QTimer.singleShot(0, custom_widget1.trigger_render)
QtCore.QTimer.singleShot(0, custom_widget2.trigger_render)
def main():
app = QtWidgets.QApplication(sys.argv)
window = MainWindow()
window.show()
sys.exit(app.exec())
if __name__ == "__main__":
main()
```https://gitlab.kitware.com/vtk/vtk/-/issues/19092Doxygen: tag file generated, but not published2023-09-22T08:11:46-04:00Tomasetti RominDoxygen: tag file generated, but not published`VTK` produces a `Doxygen`-based documentation. This is nice!
However, I could not find the generated `.tag` file that I'd like to use for linking your documentation from mine (https://www.doxygen.nl/manual/external.html), though it see...`VTK` produces a `Doxygen`-based documentation. This is nice!
However, I could not find the generated `.tag` file that I'd like to use for linking your documentation from mine (https://www.doxygen.nl/manual/external.html), though it seems it is generated (see https://gitlab.kitware.com/vtk/vtk/-/blob/master/Utilities/Doxygen/doxyfile.in#L22).
I think it is just a matter of installing the generated tag file somewhere in these lines:
https://gitlab.kitware.com/vtk/vtk/-/blob/master/Utilities/Doxygen/CMakeLists.txt#L75-L79.
I think this issue can be easily/quickly sort out with. Maybe adding `__vtk_install_documentation_files("*.tag")` could do the trick.Christos TsolakisChristos Tsolakishttps://gitlab.kitware.com/vtk/vtk/-/issues/19087Issue opening large VTKHDF file2023-12-11T09:59:25-05:00jordimuelaIssue opening large VTKHDF fileAfter discussion in the Paraview forum, I think there is an issue opening large HDFVTK files. I'll try to sum up what is happening from the original Paraview forum thread where we discussed the issue with @julien.fausty: https://discours...After discussion in the Paraview forum, I think there is an issue opening large HDFVTK files. I'll try to sum up what is happening from the original Paraview forum thread where we discussed the issue with @julien.fausty: https://discourse.paraview.org/t/issue-opening-large-vtkhdf-file/12810
We are developing a CFD Code (SOD2D https://gitlab.com/bsc_sod2d/sod2d_gitlab) and our output results are formatted using VTKHDF format.
Till now, we had no problems with it and we are able to generate the output files and read them properly using ParaView. Since we use high-order Lagrangian elements we have two options to save the meshes/results:
- Using high-order lagrange hexahedra (we interpolate the results using equidistant node distribution)
- Linealising the mesh (we “transform” and divide the p-order elements into several first order hexahedra)
Till here no problem, everything working well!
The problem arose a couple of weeks ago when pushing the software and we computed a case for meshes with more than 1 billion nodes. Trying to open the mesh or the results in Paraview gets the following error:
```
[…]
HDF5-DIAG: Error detected in HDF5 (1.12.1) thread 0:
#000: /builds/gitlab-kitware-sciviz-ci/build/superbuild/hdf5/src/src/H5Dio.c line 179 in H5Dread(): can’t read data
major: Dataset
minor: Read failed
#001: /builds/gitlab-kitware-sciviz-ci/build/superbuild/hdf5/src/src/H5VLcallback.c line 2011 in H5VL_dataset_read(): dataset read failed
major: Virtual Object Layer
minor: Read failed
#002: /builds/gitlab-kitware-sciviz-ci/build/superbuild/hdf5/src/src/H5VLcallback.c line 1978 in H5VL__dataset_read(): dataset read failed
major: Virtual Object Layer
minor: Read failed
#003: /builds/gitlab-kitware-sciviz-ci/build/superbuild/hdf5/src/src/H5VLnative_dataset.c line 159 in H5VL__native_dataset_read(): could not get a validated dataspace from file_space_id
major: Invalid arguments to routine
minor: Bad value
#004: /builds/gitlab-kitware-sciviz-ci/build/superbuild/hdf5/src/src/H5S.c line 266 in H5S_get_validated_dataspace(): selection + offset not within extent
major: Dataspace
minor: Out of range
( 202.168s) [pvserver.46 ]vtkHDFReaderImplementat:864 ERR| vtkHDFReader (0x1514c150): Error H5Dread start: 18446744071577530368, 140159467271832, 0 count: 1555968, 354777680, 354776672
( 202.168s) [pvserver.46 ] vtkHDFReader.cxx:440 ERR| vtkHDFReader (0x1514c150): Cannot read the Connectivity array
( 202.168s) [pvserver.46 ] vtkExecutive.cxx:753 ERR| vtkPVCompositeDataPipeline (0x1514fe70): Algorithm vtkFileSeriesReader(0x1514e570) returned failure for request: vtkInformation (0x15227980)
Debug: Off
Modified Time: 163221
Reference Count: 1
Registered Events: (none)
Request: REQUEST_DATA
FROM_OUTPUT_PORT: 0
ALGORITHM_AFTER_FORWARD: 1
FORWARD_DIRECTION: 0
[…]
```
I have checked the mesh/results files in our code and the values look ok. I don’t know if the issue can be related to int32 / int64 for the `vtkIdType`… This mesh goes above the int32 limit and in fact, we had to refactor our code for these cases allowing us to store larger global ids.
Of course, the mesh is partitioned in several ranks (for this particular case 5520 ranks), so the local ids do not arrive at the int32 limit, but maybe when trying to read the HDF5 file affects the variable `vtkIdType offset` in HDFReader.cxx. No idea, just a guess…
We have tried two different versions of paraview (5.10.1 & 5.11) getting the same error. We have asked the support of our cluster and they told us that the Paraview versions we have in the cluster are the precompiled versions, so I expect to have the flag compilation `VTK_USE_64BIT_IDS`, but cannot be sure…
In summary, our code is able to read and use the mesh file (stored in H5), but Paraview cannot open it giving the error I posted above. For all the meshes that we have done till now there has been no problem, and this error showed when going to this very large mesh, let me show the values:
```
HDF5 “cube-5520.hdf” {
GROUP “VTKHDF” {
ATTRIBUTE “Type” {
DATATYPE H5T_STRING {
STRSIZE 16;
STRPAD H5T_STR_NULLPAD;
CSET H5T_CSET_ASCII;
CTYPE H5T_C_S1;
}
DATASPACE SCALAR
}
ATTRIBUTE “Version” {
DATATYPE H5T_STD_I32LE
DATASPACE SIMPLE { ( 2 ) / ( 2 ) }
}
GROUP “CellData” {
DATASET “mpi_rank” {
DATATYPE H5T_STD_U8LE
DATASPACE SIMPLE { ( 1073741824 ) / ( 1073741824 ) }
}
}
DATASET “Connectivity” {
DATATYPE H5T_STD_I64LE
DATASPACE SIMPLE { ( 8589934592 ) / ( 8589934592 ) }
}
GROUP “FieldData” {
}
DATASET “NumberOfCells” {
DATATYPE H5T_STD_I64LE
DATASPACE SIMPLE { ( 5520 ) / ( 5520 ) }
}
DATASET “NumberOfConnectivityIds” {
DATATYPE H5T_STD_I64LE
DATASPACE SIMPLE { ( 5520 ) / ( 5520 ) }
}
DATASET “NumberOfPoints” {
DATATYPE H5T_STD_I64LE
DATASPACE SIMPLE { ( 5520 ) / ( 5520 ) }
}
DATASET “Offsets” {
DATATYPE H5T_STD_I64LE
DATASPACE SIMPLE { ( 1073747344 ) / ( 1073747344 ) }
}
GROUP “PointData” {
}
DATASET “Points” {
DATATYPE H5T_IEEE_F32LE
DATASPACE SIMPLE { ( 1147407183, 3 ) / ( 1147407183, 3 ) }
}
DATASET “Types” {
DATATYPE H5T_STD_U8LE
DATASPACE SIMPLE { ( 1073741824 ) / ( 1073741824 ) }
}
}
}
```
We checked the `NumberOf*` datasets and they look OK. I have also checked the connectivity array, plotting its values for each 8000 positions and at different 'start points' of the array, and also looks good. (see https://drive.google.com/drive/folders/1sj3SAcNpb7hb-vpqvNT7pgx4YYGJ_l70)
Since we were suspicious the issue came due to the size of the array getting passed through a 32bit integer at some point, I created a tool that allows me to ‘externally’ link the original hdf5 file that was failing and only include some of the ranks (the original mesh was partitioned in 5520 ranks).
If I do a ‘new’ mesh including only the first 1300 ranks, so the “Connectivity” array has a size of **2022899200** I can open the mesh in PV. On the other hand, if I include the first 1400 ranks, with a “Connectivity” size of **2178507264** the PV gives the same error detailed before, and the int32 limit is **2147483647** so values just under/above it. Therefore, I think this confirms that the issue is related to a 32-bit integer issue.
With this in mind, we compiled a ParaView 5.11.1 version in our cluster from source files with the flag VTK_USE_64BIT_IDS = ON, so in theory, the `vtkIdType` variables must be 64-bit. However, when opening the original file with this compiled ParaView version the error was exactly the same as with the precompiled version.
The mesh causing this issue is large, it weighs 125Gb so is difficult to share it, but if needed, I can try.
Thank you so much and if you need anything from my side please do not hesitate to ask.
BR!
### EDIT
To reproduce this issue, run this script [generate_unstructured_grid.py](/uploads/be0c0ec96898242bdadf301b83ab82e3/generate_unstructured_grid.py).
You will be able to open this generated file in vtk.
Then use the variable `nCubePerDim_64Bit` instead of `nCubePerDim_32Bit` in the `generate_data()` method and rerun the script.
You will have the same issue than above about `Connectivities` array.https://gitlab.kitware.com/vtk/vtk/-/issues/19086vtkGLTFImporter create too many actors with multi parts dataset2024-01-26T02:42:25-05:00Mathieu Westphal (Kitware)vtkGLTFImporter create too many actors with multi parts datasetvtkGLTFImporter create one actor per glTF part, this is not great as some dataset can have hundreds of parts, and VTK is not optimized for displaying hundreds of actors, it would be nice to be able to modify this behavior with an option ...vtkGLTFImporter create one actor per glTF part, this is not great as some dataset can have hundreds of parts, and VTK is not optimized for displaying hundreds of actors, it would be nice to be able to modify this behavior with an option to merge parts in the importer
Example with a specific [file](https://drive.google.com/file/d/1FwAYgYvJA5gdOGId0xBMuTwMSLCdzXy6/view?usp=sharing) using the GLTFImporter example from: https://examples.vtk.org/site/Cxx/IO/GLTFImporter/
```
time ./GLTFImporter ~/tmp/asterisk-v3-1.56mps.gltf
2023-09-17 12:44:23.272 ( 1.410s) [ 36455B80]vtkGLTFDocumentLoaderIn:1324 WARN| vtkGLTFDoc supported by this loader. The extension will be ignored.
^C
real 1m4.830s
user 1m50.365s
sys 0m18.583s
```https://gitlab.kitware.com/vtk/vtk/-/issues/19084Quick CI run support2024-03-28T22:13:03-04:00Ben BoeckelQuick CI run support`Do: test` runs all CI which ends up being very expensive and cause long queue/wait times for results. Instead, offer a mechanism to run just "quick" tests.
# Implementation
## move "quick" jobs to a separate stage (`Do: test -s quick`...`Do: test` runs all CI which ends up being very expensive and cause long queue/wait times for results. Instead, offer a mechanism to run just "quick" tests.
# Implementation
## move "quick" jobs to a separate stage (`Do: test -s quick`)
### Pros
- easy "play" button in the UI as well
### Cons
- need to specify `needs: []` and `dependencies: []` in CI for jobs in the stage after it
## name certain jobs as "quick" (`Do test -n quick`)
### Pros
- localized change
### Cons
- Per-job play interaction in the UI
# Which jobs?
At least one from each platform:
- macos-arm64
- linux "everything"
- windows
Also important in the set:
- static
- kitshttps://gitlab.kitware.com/vtk/vtk/-/issues/19079FindEXPAT: investigate incompatibility with Debian/CMake2023-09-13T15:24:36-04:00Ben BoeckelFindEXPAT: investigate incompatibility with Debian/CMakehttps://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050506https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050506Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/19075Check if display is available2023-09-28T04:30:11-04:00Benedikt (2xB)Check if display is availableThe application I work on uses VTK for visualization. Sometimes, no display is available, e.g. because one runs the application on a server. This leads to segmentation faults in the call to `XSync` in `vtkXRenderWindowInteractor::Initial...The application I work on uses VTK for visualization. Sometimes, no display is available, e.g. because one runs the application on a server. This leads to segmentation faults in the call to `XSync` in `vtkXRenderWindowInteractor::Initialize()`.
It seems like every way I could use VTK to test for the existence of a display - e.g. by calling vtkRenderWindow::GetScreenSize - aborts program execution if no display is found, so it seems like VTK at the moment can't be used to check if a display is available and I have to write custom, e.g. X11 and therefore system dependent code.
Am I missing something there? Otherwise I would like to request the ability to check whether a display is available before VTK aborts the program or the ability to catch the error VTK throws when no display is available as a feature.https://gitlab.kitware.com/vtk/vtk/-/issues/19074Fix event vtkCommand::MouseMoveEvent in QVTKInteractorAdapter class.2024-03-15T12:51:53-04:00George GevorgyanFix event vtkCommand::MouseMoveEvent in QVTKInteractorAdapter class.## Description
There is a class called `QVTKInteractorAdapter` that acts as a bridge between `QtQuick` and `VTK` for interaction. `Qt` has an event called `QEvent::HoverMove`, which is triggered when the cursor moves inside a hover widg...## Description
There is a class called `QVTKInteractorAdapter` that acts as a bridge between `QtQuick` and `VTK` for interaction. `Qt` has an event called `QEvent::HoverMove`, which is triggered when the cursor moves inside a hover widget. This event corresponds to the `vtkCommand::MouseMoveEvent` event in VTK.
[But it is not implemented in `QVTKInteractorAdapter::ProcessEvent`](https://gitlab.kitware.com/vtk/vtk/-/blob/master/GUISupport/Qt/QVTKInteractorAdapter.cxx?ref_type=heads#L106):
```cpp
if (t == QEvent::MouseButtonPress || t == QEvent::MouseButtonRelease ||
t == QEvent::MouseButtonDblClick || t == QEvent::MouseMove)
{
// ...
}
```
As you can see, only the following types of events are handled:
* MouseButtonPress
* MouseButtonRelease
* MouseButtonDblClick
* MouseMove
But the `HoverMove` event is not mentioned here. It is necessary to add processing logic for it.
## Solution
I tried to fix it myself and that's what I got:
```cpp
//...
if (t == QEvent::MouseButtonPress || t == QEvent::MouseButtonRelease ||
t == QEvent::MouseButtonDblClick || t == QEvent::MouseMove ||
t == QEvent::HoverMove) // <--- adding check here
{
QMouseEvent* e2 = static_cast<QMouseEvent*>(e);
// give interactor the event information
#if QT_VERSION < QT_VERSION_CHECK(6, 0, 0)
auto x = e2->x();
auto y = e2->y();
#else
auto x = e2->position().x();
auto y = e2->position().y();
#endif
iren->SetEventInformationFlipY(
static_cast<int>(x * this->DevicePixelRatio + DevicePixelRatioTolerance),
static_cast<int>(y * this->DevicePixelRatio + DevicePixelRatioTolerance),
(e2->modifiers() & Qt::ControlModifier) > 0 ? 1 : 0,
(e2->modifiers() & Qt::ShiftModifier) > 0 ? 1 : 0, 0,
e2->type() == QEvent::MouseButtonDblClick ? 1 : 0);
iren->SetAltKey((e2->modifiers() & Qt::AltModifier) > 0 ? 1 : 0);
if (t == QEvent::MouseMove || t == QEvent::HoverMove) // and here <--
{
iren->InvokeEvent(vtkCommand::MouseMoveEvent, e2);
}
//...
}
//...
```
## Results
As a result, `QtQuick` now works with mouse move events. For example, it fixes the interaction with `vtkCameraOrientationWidget`, as `VTK` now properly handles mouse hover events correctly.
## Environment
This bug was discovered in `VTK` 9\.2 and has not been resolved in the `VTK` 9\.3 beta version. It is possible that this issue has been present in earlier versions as well, but I have only tested it with these two versions.