VTK issueshttps://gitlab.kitware.com/vtk/vtk/-/issues2024-03-26T09:12:56-04:00https://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/19128Qt + osmesa = broken, but no CMake error?2023-10-11T14:45:01-04:00Matthew WoehlkeQt + osmesa = broken, but no CMake error?I configured VTK with (among other things):
```
-DVTK_BUILD_ALL_MODULES=ON
-DVTK_OPENGL_HAS_OSMESA:BOOL=ON
-DVTK_USE_X:BOOL=OFF
```
I am told that this is broken (note that `-DVTK_BUILD_ALL_MODULES=ON` enables Qt), and that CMake should...I configured VTK with (among other things):
```
-DVTK_BUILD_ALL_MODULES=ON
-DVTK_OPENGL_HAS_OSMESA:BOOL=ON
-DVTK_USE_X:BOOL=OFF
```
I am told that this is broken (note that `-DVTK_BUILD_ALL_MODULES=ON` enables Qt), and that CMake should have complained about it.https://gitlab.kitware.com/vtk/vtk/-/issues/19003RenderingVR: Add support for validating ActionManifest and BindingFile2024-03-01T17:41:58-05:00Jean-Christophe Fillion-RobinRenderingVR: Add support for validating ActionManifest and BindingFileThis issue was created to track additional improvements discussed in the context of https://gitlab.kitware.com/vtk/vtk/-/merge_requests/9892
_Originally posted by @jcfr in https://gitlab.kitware.com/vtk/vtk/-/merge_requests/9892#note_13...This issue was created to track additional improvements discussed in the context of https://gitlab.kitware.com/vtk/vtk/-/merge_requests/9892
_Originally posted by @jcfr in https://gitlab.kitware.com/vtk/vtk/-/merge_requests/9892#note_1326117_
> @LucasGandelKitware To follow up on our discussion, I generalized the definition of the action and bindings introducing `complexgestureaction` to be used in place of both `leftgripaction` and `rightgripaction`.
>
> I also looking into performing some error checking and warning reported to help developer transition but this would be a more involved changed to be consistently done for both `OpenVR` and `OpenXR`.
>
> Indeed, while the `OpenXR` implementation explicitly handle the parsing of both action and bindings `*.json`, the `OpenVR` implementation relies on `vr::VRInput()->SetActionManifestPath()` that is internally loading the action as well as the `default_bindings`.
>
> This means that to support our own json check in both `OpenVR` and `OpenXR`, we would need to add method like `ParseActionManifest` and `ParseDefaultBindingFile` to both, and report warnings in the following cases:
> * if either `leftgripaction` or `rightgripaction` are found in the manifest, report a warning
> * if at least one `complexgestureaction` output is specified in the bindings, report an error indicating that two are required.
_Originally posted by @LucasGandelKitware in https://gitlab.kitware.com/vtk/vtk/-/merge_requests/9892#note_1326117_
> Thanks @jcfr, the new approach looks much better as it allows for binding any button in order to handle complex gestures. Thank you very much for doing this change.
>
> Going a bit further with the checks you listed, we should also check that the 2 `complexgestureaction` output, are using a different path, one is for [left](https://gitlab.kitware.com/vtk/vtk/-/blob/930053f104685941bc2ddf527ad8b689c08438e8/Rendering/OpenVR/vtk_openvr_binding_oculus_touch.json#L24) and the other is for [right](https://gitlab.kitware.com/vtk/vtk/-/blob/930053f104685941bc2ddf527ad8b689c08438e8/Rendering/OpenVR/vtk_openvr_binding_oculus_touch.json#L60). Otherwise we can have 2 buttons of the same controller performing gesture recognition, which makes no sense.<br/>
> In addition, in your last point I think you meant "if only one" instead of "if at least one".https://gitlab.kitware.com/vtk/vtk/-/issues/18990Blanking points for structured grid.2023-06-07T02:59:33-04:00Jens Munk HansenBlanking points for structured grid.Hi Developers
Not really sure how to report issues. A template for how to fix issues appeared in the description
On the master branch:
SHA eab65effdf34d3853f2fcba8ba7256cdff41b26c
There is currently an issue blanking cell points. Th...Hi Developers
Not really sure how to report issues. A template for how to fix issues appeared in the description
On the master branch:
SHA eab65effdf34d3853f2fcba8ba7256cdff41b26c
There is currently an issue blanking cell points. The example https://examples.vtk.org/site/Cxx/StructuredGrid/BlankPoint/ produces the following output. I will most likely look into this myself sometimes next week, but I believe it is good practice to report such an issue.
![image](/uploads/2eb0008602363a0d1d99efb11dada026/image.png)
Thanks again
Jens Munk Hansenhttps://gitlab.kitware.com/vtk/vtk/-/issues/18825Choose one or more OpenGL rendering replacements2023-03-31T09:40:24-04:00David ThompsonChoose one or more OpenGL rendering replacementsVTK needs to migrate away from OpenGL for rendering as vendors (esp. Apple) are dropping support for it.
There are several alternatives and VTK is designed to allow implementations for each, although it is unrealistic to expect funding ...VTK needs to migrate away from OpenGL for rendering as vendors (esp. Apple) are dropping support for it.
There are several alternatives and VTK is designed to allow implementations for each, although it is unrealistic to expect funding exists to implement+maintain them all:
+ [ANARI](https://www.khronos.org/anari) is focused on ray-tracing rather than rasterization. It has support from many hardware vendors, but may not be a fully-functional replacement for some time.
+ [Dawn](https://dawn.googlesource.com/dawn) is a C++ implementation of the [WebGPU](https://webgpu.dev/) standard. Its intended audience is browser developers (esp. Google Chrome), but can be used standalone. The benefit is that [vtk.js implements rendering](https://github.com/Kitware/vtk-js/tree/master/Sources/Rendering/WebGPU) with WebGPU and most of this code could be easily adapted to C++.
+ [Vulkan](https://discourse.vtk.org/t/vulkan-development/3307) has some preliminary work done in VTK but is not natively supported on all platforms (Apple does not support it directly; a third-party adaptor named [MoltenVK](https://moltengl.com/moltenvk/) does exist).
+ [Metal](https://developer.apple.com/metal/) is an Apple-only compute-shader API. Because it is platform-specific, it is unlikely to be adopted.
+ [Direct3D v12](https://en.wikipedia.org/wiki/Direct3D#Direct3D_12) is a Windows-only compute-shader API. Because it is platform-specific, it is unlikely to be adopted.https://gitlab.kitware.com/vtk/vtk/-/issues/18453Wireframe black artefact (OSMesa, Intel chipset)2023-05-07T16:42:27-04:00Lucas GandelWireframe black artefact (OSMesa, Intel chipset)Black artefacts are visible when rendering a quad as wireframe on different hardware.
This has been reproduced with OSMesa and Intel UHD Graphics 630.
vtkResliceCursorWidget tests are impacted after forcing the representation of the wi...Black artefacts are visible when rendering a quad as wireframe on different hardware.
This has been reproduced with OSMesa and Intel UHD Graphics 630.
vtkResliceCursorWidget tests are impacted after forcing the representation of the widget to wireframe in order to workaround #18441. (See !8879) It only happens when the cursor is perfectly aligned with the camera view up. Moving the cursor a bit brings the color back.
<img src="/uploads/72c365864088c2c08eb1a5c7a3801638/ResliceCursorBlackLine.PNG" width="300" height="300">
<img src="/uploads/47f7df827ccbd0c49744486cfedfe3f0/ResliceCursorOK.PNG" width="300" height="300">
Similar issues can be reproduce with a simple quad rendered as wireframe.
<img src="/uploads/2e42bc2b6f0026fed99739a27766f203/PlaneSource1.PNG" width="500" height="300">
Please note:
- it only affect quads (vtkResliceCursorActor above is not using lines, but quads with a normal orthogonal to the camera direction).
- it seems to be caused by a wrong computation of `normalVCVSOutput` in [vtkOpenGLPolyDataMapper](https://gitlab.kitware.com/vtk/vtk/-/blob/master/Rendering/OpenGL2/vtkOpenGLPolyDataMapper.cxx#L2208).https://gitlab.kitware.com/vtk/vtk/-/issues/18098VTK Linux CI exclusions2022-07-08T04:36:07-04:00Ben BoeckelVTK Linux CI exclusionsThere are currently a host of tests being excluded on the "main" Linux build job due to some rendering quirks. It is unknown what the cause(s) of these problems are, but this issue is to track information about it. See `.gitlab/ci/ctest_...There are currently a host of tests being excluded on the "main" Linux build job due to some rendering quirks. It is unknown what the cause(s) of these problems are, but this issue is to track information about it. See `.gitlab/ci/ctest_test.cmake` (!7486) for the exclusion list.
Cc: @ken-martin @utkarsh.ayachit @sankheshhttps://gitlab.kitware.com/vtk/vtk/-/issues/17683floating point exceptions in rendering tests with Mesa3D2019-09-13T13:04:07-04:00David E. DeMarlefloating point exceptions in rendering tests with Mesa3DThere are apparently many test failures with mesa CPU rendering.
For example:
```
ctest -R TestFloor
Test project /home/demarle/Source/VTK/devel/mesa/vmaster/build
Start 720: VTK::RenderingOpenGL2Cxx-TestFloor
1/1 Test #720: VTK::Ren...There are apparently many test failures with mesa CPU rendering.
For example:
```
ctest -R TestFloor
Test project /home/demarle/Source/VTK/devel/mesa/vmaster/build
Start 720: VTK::RenderingOpenGL2Cxx-TestFloor
1/1 Test #720: VTK::RenderingOpenGL2Cxx-TestFloor ...***Exception: Numerical 0.77 sec
```
These failures were exposed by this commit:
https://gitlab.kitware.com/vtk/vtk/merge_requests/5441, which turned on floating point exception handling in our tests under gcc and with debug flags.
My results were with mesa 19.1.2 compiled like so:
```/usr/local/bin/meson build/ -Dplatforms=x11 -Dglx=gallium-xlib -Dgles=false -Dgles2=false -Degl=false -Dgallium-drivers=swrast -Dvulkan-drivers=[] -Ddri3=false -Ddri-drivers=[]```
We should track down these issues and fix or report them upstream and/or surpress them. We should make sure our nightly mesa submitters are up to the task of catching this type of problem too.https://gitlab.kitware.com/vtk/vtk/-/issues/17418Issues with Depth Peeling when used in Qt Quick2018-10-23T14:30:19-04:00Tomasz KapuścińskiIssues with Depth Peeling when used in Qt QuickOur software depends on depth peeling for transparency. In older version of VTK, the software worked just fine. After updating VTK to the newer version (8.1.1) with OpenGL2 back-end, trying to display transparent objects appears to break...Our software depends on depth peeling for transparency. In older version of VTK, the software worked just fine. After updating VTK to the newer version (8.1.1) with OpenGL2 back-end, trying to display transparent objects appears to break both VTK and Qt Quick because nothing is rendered correctly, not even other Qt Quick components. The issue doesn't disappear when we disable depth peeling during program execution. The issue also happens in an implementation written from scratch and this program when depth peeling is added to it: https://github.com/nicanor-romero/QtVtk. When trying to fix the problem we established that there might be a problem with framebuffer object binding or even OpenGL context when trying to use depth peeling. The program uses `vtkExternalOpenGLRenderWindow` for rendering the scene. The testing was performed on Windows 10 but I was told it also doesn't work on Mac OS. Since VTK doesn't have Qt Quick components, we use a custom implementation based on this example:
https://gist.github.com/nocnokneo/c3fb01bb7ecaf437f7d6
The included program has a scene with two transparent objects intersecting with each other, a cone and a sphere. Depth peeling is off for the first 50 frames, then it is turned on for the next 50 frames and then the program it turns it off. In default configuration, the first 50 frames are rendered correctly, but then nothing renders at all, the window is all white, even after depth peeling is turned off at frame 101. To render next frames just keep scaling the window by grabbing an edge. The program will write frame counter in the terminal and whether depth peeling is on or off for the convenience.
There are four boolean flags in customitem.h which can be used to control the program. Setting `m_useInternalFBO` to true will enable rendering to an FBO created in OpenGL. Turning it on doesn't change much. The scene is rendered to an FBO and then blitted to the main framebuffer but when the depth peeling is turned on, the screen turns white as before. Changing `m_useBlitFramebuffer` to false will disable blitting but the screen will still turn white. When `m_useResetOpenGL` is true, `resetOpenGLState()` is called on the window right before rendering with VTK. Enabling this somehow fixes the problem of white screen but the scene is completely missing. If you also set `m_useSetFramebuffer` to true, the framebuffer will be set right after the reset and the white screen problem somehow comes back.
When `m_useResetOpenGL` is true while other flags are false, you can sometimes see a strange pattern emerging on the screen, as if one of the peels was partially rendered. An example of this is in one of the attached files. Maybe you can make something out of this.
Correct transparency is an vital feature in our software. Default alpha blending doesn't give correct results and depth sorting is too slow to use due to complexity of our geometry. If you could find and solve the issue or at least help us find a way to solve this, we would be grateful. We spent a lot of time trying to solve this but nothing worked. I attach a zip file containing the example program, an image of the scene rendered by the program with depth peeling off and an image with the result of a strange render.
[vtkquickopengl2.zip](/uploads/c301c6862a598d78aede6d4339e4dd22/vtkquickopengl2.zip)
![scene](/uploads/2984bf5beef728af8d435be16bbd03a5/scene.png)
![strange](/uploads/a0cdc38cd5155f0ab804cb91926199fa/strange.png)https://gitlab.kitware.com/vtk/vtk/-/issues/17334OSPRay scivis renderer draws outside of the hull of unstructured grids2018-10-23T10:32:43-04:00Michael MiglioreOSPRay scivis renderer draws outside of the hull of unstructured gridsWhen there are holes in the bounding box of an unstructured grid, it looks that OSPRay fills space without cell with the color corresponding to value 0 and 100% opacity.
* VTK renderer:
![Screenshot_from_2018-06-07_14-57-12](/uploads...When there are holes in the bounding box of an unstructured grid, it looks that OSPRay fills space without cell with the color corresponding to value 0 and 100% opacity.
* VTK renderer:
![Screenshot_from_2018-06-07_14-57-12](/uploads/0e223a9a73e69089a985df7fd2195c5a/Screenshot_from_2018-06-07_14-57-12.png)
* OSPRay scivis renderer:
![Screenshot_from_2018-06-07_14-56-59](/uploads/60c88ffafea536b4b7629dbd7956965b/Screenshot_from_2018-06-07_14-56-59.png)https://gitlab.kitware.com/vtk/vtk/-/issues/17327VTK7.0 show point cloud for ios2018-10-23T10:15:06-04:00HollisJoeVTK7.0 show point cloud for iosWhen using VTK to display point cloud in IOS, the point cloud shows abnormal, and you cannot see a little cloud display. Thanks!When using VTK to display point cloud in IOS, the point cloud shows abnormal, and you cannot see a little cloud display. Thanks!https://gitlab.kitware.com/vtk/vtk/-/issues/17138Antialiasing issue in fullscreen QVtkOpenGLWidget2022-07-31T17:39:54-04:00Denys SenkinAntialiasing issue in fullscreen QVtkOpenGLWidgetI have such problem - when I make the vtkOpenGlWidget as separate window and call showFullscreen() on it, the antialiasing is set disabled and there is no way to turn it on. The mesh looks ugly, especially if the EdgeVisibillity is turne...I have such problem - when I make the vtkOpenGlWidget as separate window and call showFullscreen() on it, the antialiasing is set disabled and there is no way to turn it on. The mesh looks ugly, especially if the EdgeVisibillity is turned on - lines are not antialiased at all.
Normal look:
![image](/uploads/86e2bf7fe216f4811703528c701d8a49/image.png)
Ugly look (in fullscreen mode):
![image](/uploads/29e9d89d26d845c4a46b9a17a46dd58c/image.png)
It becomes uglier when I go back from fullscreen mode to normal mode
![image](/uploads/886aca0951586a43288ed42bfe547b70/image.png)
I have tried to set number of multisamples anywhere where I found, but nothing happens.
VTK 8.1 (latest master),
PCL 1.8.1,
Visual Studio 2015,
Windows 10,
NVidia 950Mhttps://gitlab.kitware.com/vtk/vtk/-/issues/17082vtkSSAAPass breaks the use of stencil buffer2018-10-23T12:59:34-04:00Julien FinetvtkSSAAPass breaks the use of stencil bufferUse of stencil buffer in actor custom rendering fails when vtkSSAAPass is in use.Use of stencil buffer in actor custom rendering fails when vtkSSAAPass is in use.https://gitlab.kitware.com/vtk/vtk/-/issues/17081vtkSSAAPass does not support renderer on layer != 02018-10-23T12:59:40-04:00Julien FinetvtkSSAAPass does not support renderer on layer != 0When rendering a renderer with Layer != 0, buffers are not cleared.
vtkSSASPass renders an un-Clear-ed black color buffer instead of transparent buffer.
To reproduce, simply add vtkSSAAPass to the renderer of a vtkOrientationMarkerWidget.When rendering a renderer with Layer != 0, buffers are not cleared.
vtkSSASPass renders an un-Clear-ed black color buffer instead of transparent buffer.
To reproduce, simply add vtkSSAAPass to the renderer of a vtkOrientationMarkerWidget.https://gitlab.kitware.com/vtk/vtk/-/issues/16996Some filter/renderPass disable GL_BLEND but never restore them2018-10-29T04:02:55-04:00Simon EsneaultSome filter/renderPass disable GL_BLEND but never restore themNamely :
- [ ] vtkDepthOfFieldPass.cxx
- [ ] vtkEDLShading.cxx
- [ ] vtkPointFillPass.cxx
- [ ] vtkSobelGradientMagnitudePass.cxx
- [x] vtkSSAAPass.cxx (!3003)
Hence if used with something like vtkTextActor or vtkBalloonRepres...Namely :
- [ ] vtkDepthOfFieldPass.cxx
- [ ] vtkEDLShading.cxx
- [ ] vtkPointFillPass.cxx
- [ ] vtkSobelGradientMagnitudePass.cxx
- [x] vtkSSAAPass.cxx (!3003)
Hence if used with something like vtkTextActor or vtkBalloonRepresentation the blending is disabled and the rendering incorrect